[要約] RFC 9173は、Bundle Protocol Security (BPSec)のためのデフォルトセキュリティコンテキストを定義します。この文書の目的は、データの機密性と完全性を保護するための基本的な方法を提供することです。主に、遅延耐性ネットワーク（DTN）などの信頼性が低いまたは遅延が大きいネットワーク環境での利用が想定されています。
Internet Engineering Task Force (IETF) E. Birrane, III
Request for Comments: 9173 A. White
Category: Standards Track S. Heiner
ISSN: 2070-1721 JHU/APL
January 2022
Default Security Contexts for Bundle Protocol Security (BPSec)
バンドルプロトコルセキュリティのデフォルトセキュリティコンテキスト（BPSEC）
Abstract
概要
This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (BPSec) implementations. These security contexts are intended to be used both for testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network.
このドキュメントでは、Bundle Protocol Security（BPSec）実装で使用できるデフォルトのIntegrityおよびConfidentalityセキュリティコンテキストを定義します。これらのセキュリティコンテキストは、BPSEC実装の相互運用性をテストし、他のセキュリティコンテキストが定義されていないか、またはそうでなければネットワークに必要なときに基本的なセキュリティ操作を提供するための両方で使用されることを目的としています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9173.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9173で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Requirements Language
3. Integrity Security Context BIB-HMAC-SHA2
3.1. Overview
3.2. Scope
3.3. Parameters
3.3.1. SHA Variant
3.3.2. Wrapped Key
3.3.3. Integrity Scope Flags
3.3.4. Enumerations
3.4. Results
3.5. Key Considerations
3.6. Security Processing Considerations
3.7. Canonicalization Algorithms
3.8. Processing
3.8.1. Keyed Hash Generation
3.8.2. Keyed Hash Verification
4. Security Context BCB-AES-GCM
4.1. Overview
4.2. Scope
4.3. Parameters
4.3.1. Initialization Vector (IV)
4.3.2. AES Variant
4.3.3. Wrapped Key
4.3.4. AAD Scope Flags
4.3.5. Enumerations
4.4. Results
4.4.1. Authentication Tag
4.4.2. Enumerations
4.5. Key Considerations
4.6. GCM Considerations
4.7. Canonicalization Algorithms
4.7.1. Calculations Related to Ciphertext
4.7.2. Additional Authenticated Data
4.8. Processing
4.8.1. Encryption
4.8.2. Decryption
5. IANA Considerations
5.1. Security Context Identifiers
5.2. Integrity Scope Flags
5.3. AAD Scope Flags
5.4. Guidance for Designated Experts
6. Security Considerations
6.1. Key Management
6.2. Key Handling
6.3. AES GCM
6.4. AES Key Wrap
6.5. Bundle Fragmentation
7. Normative References
Appendix A. Examples
A.1. Example 1 - Simple Integrity
A.1.1. Original Bundle
A.1.2. Security Operation Overview
A.1.3. Block Integrity Block
A.1.4. Final Bundle
A.2. Example 2 - Simple Confidentiality with Key Wrap
A.2.1. Original Bundle
A.2.2. Security Operation Overview
A.2.3. Block Confidentiality Block
A.2.4. Final Bundle
A.3. Example 3 - Security Blocks from Multiple Sources
A.3.1. Original Bundle
A.3.2. Security Operation Overview
A.3.3. Block Integrity Block
A.3.4. Block Confidentiality Block
A.3.5. Final Bundle
A.4. Example 4 - Security Blocks with Full Scope
A.4.1. Original Bundle
A.4.2. Security Operation Overview
A.4.3. Block Integrity Block
A.4.4. Block Confidentiality Block
A.4.5. Final Bundle
Appendix B. CDDL Expression
Acknowledgments
Authors' Addresses
The Bundle Protocol Security (BPSec) specification [RFC9172] provides inter-bundle integrity and confidentiality operations for networks deploying the Bundle Protocol (BP) [RFC9171]. BPSec defines BP extension blocks to carry security information produced under the auspices of some security context.
バンドルプロトコルセキュリティ（BPSEC）仕様[RFC9172]バンドルプロトコル（BP）[RFC9171]を展開するネットワークのバンドル間の整合性と機密保持演算を提供します。BPSECは、いくつかのセキュリティコンテキストの後援の下で生成されたセキュリティ情報を伝送するためのBP拡張ブロックを定義します。
This document defines two security contexts (one for an integrity service and one for a confidentiality service) for populating BPSec Block Integrity Blocks (BIBs) and Block Confidentiality Blocks (BCBs). This document assumes familiarity with the concepts and terminology associated with BP and BPSec, as these security contexts are used with BPSec security blocks and other BP blocks carried within BP bundles.
このドキュメントは、BPSecブロックのIntegrityブロック（BIB）を入力し、機密性ブロック（BCBS）をブロックするための2つのセキュリティコンテキスト（Integrity Service for Integrity Service for Integrity Service用の1つ）を定義します。これらのセキュリティコンテキストはBPSECセキュリティブロックやBPバンドル内で伝送された他のBPブロックが使用されるため、このドキュメントはBPおよびBPSECに関連する概念と用語に精通しています。
These contexts generate information that MUST be encoded using the Concise Binary Object Representation (CBOR) specification documented in [RFC8949].
これらのコンテキストは、[RFC8949]に記載されている簡潔なバイナリオブジェクト表現（CBOR）仕様を使用して符号化する必要がある情報を生成します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The BIB-HMAC-SHA2 security context provides a keyed-hash Message Authentication Code (MAC) over a set of plaintext information. This context uses the Secure Hash Algorithm 2 (SHA-2) discussed in [SHS] combined with the Hashed Message Authentication Code (HMAC) keyed hash discussed in [RFC2104]. The combination of HMAC and SHA-2 as the integrity mechanism for this security context was selected for two reasons:
BIB-HMAC-SHA2セキュリティコンテキストは、一連の平文情報を介してキー付きハッシュメッセージ認証コード（MAC）を提供します。このコンテキストでは、[RFC2104]で説明されているハッシュメッセージ認証コード（HMAC）キー付きハッシュと組み合わせた[SHS]で説明したセキュアハッシュアルゴリズム2（SHA-2）を使用します。このセキュリティコンテキストの整合性メカニズムとしてのHMACとSHA-2の組み合わせは、2つの理由から選択されました。
1. The use of symmetric keys allows this security context to be used in places where an asymmetric-key infrastructure (such as a public key infrastructure) might be impractical.
1. 対称鍵の使用により、このセキュリティコンテキストは、非対称キーインフラストラクチャ（公開鍵インフラストラクチャなど）が実用的である可能性がある場所で使用できます。
2. The combination HMAC-SHA2 represents a well-supported and well-understood integrity mechanism with multiple implementations available.
2. HMAC - SHA2の組み合わせは、利用可能な複数の実装を有する十分に支持されよく理解されている完全性機構を表す。
BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the supported length of the SHA-2 hash value. These variants correspond to HMAC 256/256, HMAC 384/384, and HMAC 512/512 as defined in Table 7 ("HMAC Algorithm Values") of [RFC8152]. The selection of which variant is used by this context is provided as a security context parameter.
Bib-HMAC-SHA2は、SHA-2ハッシュ値の担持された長さに基づいて、HMAC-SHAの3つの変異体をサポートします。これらの変形は、HMAC 256/256、HMAC 384/384、およびHMAC 512/512（「RFC8152」の表7（「HMACアルゴリズム値」）に対応しています。このコンテキストによってどのバリアントが使用されるかの選択は、セキュリティコンテキストパラメータとして提供されています。
The output of the HMAC MUST be equal to the size of the SHA2 hashing function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits for SHA-512.
HMACの出力は、SHA2ハッシュ関数のサイズに等しくなければなりません：SHA-256の256ビット、SHA-384のための384ビット、およびSHA-512の512ビットです。
The BIB-HMAC-SHA2 security context MUST have the security context identifier specified in Section 5.1.
Bib-HMAC-SHA2セキュリティコンテキストには、セキュリティコンテキスト識別子がセクション5.1にあります。
The scope of BIB-HMAC-SHA2 is the set of information used to produce the plaintext over which a keyed hash is calculated. This plaintext is termed the "Integrity-Protected Plaintext (IPPT)". The content of the IPPT is constructed as the concatenation of information whose integrity is being preserved from the BIB-HMAC-SHA2 security source to its security acceptor. There are five types of information that can be used in the generation of the IPPT, based on how broadly the concept of integrity is being applied. These five types of information, whether they are required, and why they are important for integrity are discussed as follows.
Bib-HMAC-SHA2の範囲は、キー付きハッシュが計算される平文を生成するために使用される情報のセットです。この平文は「整合性保護された平文（IPPT）」と呼ばれます。IPPTの内容は、完全性がBib-HMAC-SHA2セキュリティソースからそのセキュリティアクセプタに保存されている情報の連結として構築されています。IPPTの生成に使用できる情報には、整合性の概念がどの程度適用されているかに基づいて5種類の情報があります。これらの5種類の情報は、必要なのか、およびそれらが完全性にとって重要な理由について次のように議論されています。
Security target contents The contents of the block-type-specific data field of the security target MUST be included in the IPPT. Including this information protects the security target data and is considered the minimal, required set of information for an integrity service on the security target.
セキュリティ対象の内容セキュリティターゲットのブロック型固有のデータフィールドの内容は、IPPTに含める必要があります。この情報を含めて、セキュリティ対象データを保護し、セキュリティ対象のIntegrityサービスに関する最小限の必要な情報のセットと見なされます。
IPPT scope The determination of which optional types of information were used when constructing the IPPT MUST always be included in the IPPT. Including this information ensures that the scope of the IPPT construction at a security source matches the scope of the IPPT construction at security verifiers and security acceptors.
IPPT範囲IPPTを構築するときにどのオプションの種類の情報が使用されているかの決定が常にIPPTに含まれている必要があります。この情報を含めると、セキュリティ源でのIPPT構造の範囲がセキュリティ検証者およびセキュリティアクセプタのIPPT構造の範囲と一致することを保証します。
Primary block The primary block identifies a bundle, and once created, the contents of this block are immutable. Changes to the primary block associated with the security target indicate that the security target (and BIB) might no longer be in the correct bundle.
プライマリブロックプライマリブロックはバンドルを識別し、作成したらこのブロックの内容は不変です。セキュリティターゲットに関連付けられているプライマリブロックへの変更は、セキュリティターゲット（およびBIB）が正しいバンドルにない可能性があることを示します。
For example, if a security target and associated BIB are copied from one bundle to another bundle, the BIB might still contain a verifiable signature for the security target unless information associated with the bundle primary block is included in the keyed hash carried by the BIB.
たとえば、セキュリティターゲットと関連するBIBが1つのバンドルから別のバンドルにコピーされている場合、Bundleプライマリブロックに関連する情報がBIBによって運ばれるキー付きハッシュに含まれていない限り、BIBはセキュリティターゲットの検証可能な署名を含めることができます。
Including this information in the IPPT protects the integrity of the association of the security target with a specific bundle.
IPPT内のこの情報を含めて、セキュリティターゲットの関連付けの整合性を特定のバンドルと保護します。
Other fields of the security target The other fields of the security target include block identification and processing information. Changing this information changes how the security target is treated by nodes in the network even when the "user data" of the security target are otherwise unchanged.
セキュリティ対象の他のフィールドセキュリティターゲットの他のフィールドは、ブロック識別および処理情報を含む。この情報を変更すると、セキュリティターゲットの「ユーザーデータ」が変更されていない場合でも、セキュリティターゲットがネットワーク内のノードによってどのように扱われるかを変更します。
For example, if the block processing control flags of a security target are different at a security verifier than they were originally set at the security source, then the policy for handling the security target has been modified.
たとえば、セキュリティターゲットのブロック処理制御フラグがセキュリティソースでもともとセキュリティ検証子で異なる場合は、セキュリティターゲットを処理するためのポリシーが変更されました。
Including this information in the IPPT protects the integrity of the policy and identification of the security target data.
IPPT内のこの情報を含めて、ポリシーの整合性とセキュリティ対象データの識別を保護します。
Other fields of the BIB The other fields of the BIB include block identification and processing information. Changing this information changes how the BIB is treated by nodes in the network, even when other aspects of the BIB are unchanged.
BIBの他のフィールドBIBの他のフィールドは、ブロック識別および処理情報を含む。この情報を変更すると、BIBの他の側面が変更されていなくても、ネットワーク内のノードでBIBがどのように扱われるかが変更されます。
For example, if the block processing control flags of the BIB are different at a security verifier than they were originally set at the security source, then the policy for handling the BIB has been modified.
たとえば、BIBのブロック処理制御フラグがセキュリティソースでもともとセキュリティ検証者で異なる場合は、BIBを処理するためのポリシーが変更されました。
Including this information in the IPPT protects the integrity of the policy and identification of the security service in the bundle.
IPPT内のこの情報を含めると、バンドル内のセキュリティサービスの整合性と識別を保護します。
| NOTE: The security context identifier and security context
| parameters of the security block are not included in the
| IPPT because these parameters, by definition, are required
| to verify or accept the security service. Successful
| verification at security verifiers and security acceptors
| implies that these parameters were unchanged since being
| specified at the security source. This is the case because
| keys cannot be reused across security contexts and because
| the integrity scope flags used to define the IPPT are
| included in the IPPT itself.
The scope of the BIB-HMAC-SHA2 security context is configured using an optional security context parameter.
Bib-HMAC-SHA2セキュリティコンテキストの範囲は、オプションのセキュリティコンテキストパラメータを使用して構成されています。
BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, communicate key information, and define the scope of the IPPT.
Bib-HMAC-SHA2は、SHA-2の亜種を選択し、鍵情報の通信、およびIPPTの範囲を定義するようにパラメータ化できます。
This optional parameter identifies which variant of the SHA-2 algorithm is to be used in the generation of the authentication code.
このオプションのパラメータは、認証コードの生成にSHA-2アルゴリズムのどのバリアントを使用するかを識別します。
This value MUST be encoded as a CBOR unsigned integer.
この値は、CBOR符号なし整数としてエンコードする必要があります。
Valid values for this parameter are as follows.
このパラメータの有効な値は次のとおりです。
+=======+========================================+
| Value | Description |
+=======+========================================+
| 5 | HMAC 256/256 as defined in Table 7 |
| | ("HMAC Algorithm Values") of [RFC8152] |
+-------+----------------------------------------+
| 6 | HMAC 384/384 as defined in Table 7 |
| | ("HMAC Algorithm Values") of [RFC8152] |
+-------+----------------------------------------+
| 7 | HMAC 512/512 as defined in Table 7 |
| | ("HMAC Algorithm Values") of [RFC8152] |
+-------+----------------------------------------+
Table 1: SHA Variant Parameter Values
表1：SHAバリアントパラメータ値
When not provided, implementations SHOULD assume a value of 6 (indicating use of HMAC 384/384), unless an alternate default is established by local security policy at the security source, verifiers, or acceptor of this integrity service.
提供されていない場合、このIntegrityサービスのセキュリティソース、検証者、またはアクセプタで代替デフォルトが確立されていない限り、実装は6の値（HMAC 384/384の使用を示す）を想定する必要があります。
This optional parameter contains the output of the AES key wrap function as defined in [RFC3394]. Specifically, this parameter holds the ciphertext produced when running this key wrap algorithm with the input string being the symmetric HMAC key used to generate the security results present in the security block. The value of this parameter is used as input to the AES key wrap authenticated decryption function at security verifiers and security acceptors to determine the symmetric HMAC key needed for the proper validation of the security results in the security block.
このオプションパラメータには、[RFC3394]で定義されているAESキーラップ関数の出力が含まれています。具体的には、このパラメータは、セキュリティブロックに存在するセキュリティ結果を生成するために使用される対称HMACキーである入力文字列を使用して、このキーラップアルゴリズムを実行するときに生成された暗号文を保持します。このパラメータの値は、セキュリティブロック内のセキュリティブロックの適切な検証に必要な対称HMACキーを決定するために、セキュリティ検証者およびセキュリティアクセプタのAESキーラップ認証復号化機能への入力として使用されます。
This value MUST be encoded as a CBOR byte string.
この値はCBOBORバイト文字列としてエンコードする必要があります。
If this parameter is not present, then security verifiers and acceptors MUST determine the proper key as a function of their local BPSec policy and configuration.
このパラメータが存在しない場合は、セキュリティ検証者とアクセプタが自分のローカルBPSecポリシーと設定の関数として正しいキーを決定する必要があります。
This optional parameter contains a series of flags that describe what information is to be included with the block-type-specific data when constructing the IPPT value.
このオプションパラメータには、IPPT値を構築するときにブロックタイプ固有のデータに含まれる情報を記述する一連のフラグが含まれています。
This value MUST be represented as a CBOR unsigned integer, the value of which MUST be processed as a 16-bit field. The maximum value of this field, as a CBOR unsigned integer, MUST be 65535.
この値はCBOR符号なし整数として表す必要があります。その値は16ビットフィールドとして処理されなければなりません。このフィールドの最大値は、CBOR符号なし整数として、65535にする必要があります。
When not provided, implementations SHOULD assume a value of 7 (indicating all assigned fields), unless an alternate default is established by local security policy at the security source, verifier, or acceptor of this integrity service.
提供されていない場合、このIntegrityサービスのセキュリティソース、検証者、またはアクセプタで代替デフォルトが確立されていない限り、実装は7の値（割り当てられたフィールドを示す）を仮定する必要があります。
Implementations MUST set reserved and unassigned bits in this field to 0 when constructing these flags at a security source. Once set, the value of this field MUST NOT be altered until the security service is completed at the security acceptor in the network and removed from the bundle.
実装は、セキュリティソースでこれらのフラグを構築するときに、このフィールドの予約済みおよび割り当てられていないビットを0に設定する必要があります。設定されたら、このフィールドの値はネットワーク内のセキュリティアクセプタで完了し、バンドルから削除されるまで、このフィールドの値を変更してはなりません。
Bits in this field represent additional information to be included when generating an integrity signature over the security target. These bits are defined as follows.
このフィールドのビットは、セキュリティターゲットを介して整合性シグネチャを生成するときに含まれる追加情報を表します。これらのビットは次のように定義されています。
Bit 0 (the low-order bit, 0x0001): Include primary block flag
ビット0（下位ビット、0x0001）：プライマリブロックフラグを含める
Bit 1 (0x0002): Include target header flag
ビット1（0x0002）：ターゲットヘッダフラグを含める
Bit 2 (0x0004): Include security header flag
ビット2（0x0004）：セキュリティヘッダフラグを含める
Bits 3-7: Reserved
ビット3-7：予約済み
Bits 8-15: Unassigned
ビット8-15：未割り当て
The BIB-HMAC-SHA2 security context parameters are listed in Table 2. In this table, the "Parm Id" column refers to the expected parameter identifier described in Section 3.10 ("Parameter and Result Identification") of [RFC9172].
BIB-HMAC-SHA2のセキュリティコンテキストパラメータを表2に示します。この表では、「PARM ID」列は[RFC9172]のセクション3.10（ "パラメータと結果の識別"）で説明されている予想されるパラメータ識別子を指します。
An empty "Default Value" column indicates that the security context parameter does not have a default value.
空の「デフォルト値」列は、セキュリティコンテキストパラメータにデフォルト値がないことを示します。
+=========+=============+====================+===============+
| Parm Id | Parm Name | CBOR Encoding Type | Default Value |
+=========+=============+====================+===============+
| 1 | SHA Variant | unsigned integer | 6 |
+---------+-------------+--------------------+---------------+
| 2 | Wrapped Key | byte string | |
+---------+-------------+--------------------+---------------+
| 3 | Integrity | unsigned integer | 7 |
| | Scope Flags | | |
+---------+-------------+--------------------+---------------+
Table 2: BIB-HMAC-SHA2 Security Context Parameters
表2：BIB-HMAC-SHA2セキュリティコンテキストパラメータ
The BIB-HMAC-SHA2 security context results are listed in Table 3. In this table, the "Result Id" column refers to the expected result identifier described in Section 3.10 ("Parameter and Result Identification") of [RFC9172].
Bib-HMAC-SHA2のセキュリティコンテキストの結果を表3に示します。この表では、「結果ID」列とは、[RFC9172]のセクション3.10（「パラメータと結果の識別」）で説明されている予想される結果識別子を指します。
+========+==========+===============+======================+
| Result | Result | CBOR Encoding | Description |
| Id | Name | Type | |
+========+==========+===============+======================+
| 1 | Expected | byte string | The output of the |
| | HMAC | | HMAC calculation at |
| | | | the security source. |
+--------+----------+---------------+----------------------+
Table 3: BIB-HMAC-SHA2 Security Results
表3：Bib-HMAC-SHA2セキュリティ結果
HMAC keys used with this context MUST be symmetric and MUST have a key length equal to the output of the HMAC. For this reason, HMAC key lengths will be integers divisible by 8 bytes, and special padding-aware AES key wrap algorithms are not needed.
このコンテキストで使用されているHMACキーは対称でなければならず、HMACの出力に等しいキー長を持つ必要があります。このため、HMACキーの長さは8バイトで割り切れる整数になり、特別なパディング対応AESキーラップアルゴリズムは必要ありません。
It is assumed that any security verifier or security acceptor performing an integrity verification can determine the proper HMAC key to be used. Potential sources of the HMAC key include (but are not limited to) the following:
整合性検証を実行するセキュリティ検証者またはセキュリティアクセプタは、使用される適切なHMACキーを決定することができると仮定されています。HMACキーの潜在的なソースには、次のものが含まれます（ただし、これに限定されません）。
* Pre-placed keys selected based on local policy.
* ローカルポリシーに基づいて選択された事前に配置されたキー。
* Keys extracted from material carried in the BIB.
* BIBで運ばれる材料から抽出されたキー。
* Session keys negotiated via a mechanism external to the BIB.
* セッションキーは、BIBの外部のメカニズムを介してネゴシエートされました。
When an AES Key Wrap (AES-KW) [RFC3394] wrapped key is present in a security block, it is assumed that security verifiers and security acceptors can independently determine the key encryption key (KEK) used in the wrapping of the symmetric HMAC key.
AESキーラップ（AES-kW）[RFC3394] [RFC3394]をセキュリティブロックに存在すると、セキュリティ検証者とセキュリティアクセプタが独立して、対称HMACキーのラッピングで使用されるキー暗号化キー（KEK）を決定できると仮定されます。。
As discussed in Section 6 and emphasized here, it is strongly recommended that keys be protected once generated, both when they are stored and when they are transmitted.
ここで節で説明したように、それらが格納されているとき、およびそれらが送信されたときに、キーが一度生成されると、キーを保護することを強く推奨されます。
An HMAC calculated over the same IPPT with the same key will always have the same value. This regularity can lead to practical side-channel attacks whereby an attacker could produce known plaintext, guess at an HMAC tag, and observe the behavior of a verifier. With a modest number of trials, a side-channel attack could produce an HMAC tag for attacker-provided plaintext without the attacker ever knowing the HMAC key.
同じキーを持つ同じIPPTにわたって計算されたHMACは常に同じ値を持ちます。この規則性は、攻撃者が既知の平文を作成し、HMACタグで推測し、検証者の動作を観察する可能性がある実用的なサイドチャネル攻撃につながる可能性があります。適度な数の試験で、サイドチャネル攻撃は、攻撃者がHMACキーを知ることなく攻撃者に提供された平文のためのHMACタグを生成する可能性があります。
A common method of observing the behavior of a verifier is precise analysis of the timing associated with comparisons. Therefore, one way to prevent behavior analysis of this type is to ensure that any comparisons of the supplied and expected authentication tag occur in constant time.
検証者の動作を観察する一般的な方法は、比較に関連するタイミングの正確な分析です。したがって、このタイプの動作分析を防ぐ1つの方法は、指定された認証タグと予想される認証タグとの比較が一定になるようにすることです。
A constant-time comparison function SHOULD be used for the comparison of authentication tags by any implementation of this security context. In cases where such a function is difficult or impossible to use, the impact of side-channel attacks (in general) and timing attacks (specifically) need to be considered as part of the implementation.
このセキュリティコンテキストの任意の実装による認証タグの比較には、定数の比較関数を使用する必要があります。そのような機能が困難または不可能である場合、サイドチャネル攻撃の影響（一般的に）およびタイミング攻撃（具体的に）は、実装の一部として考慮する必要があります。
This section defines the canonicalization algorithm used to prepare the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The construction of the IPPT depends on the settings of the integrity scope flags that can be provided as part of customizing the behavior of this security context.
このセクションでは、BIB-HMAC-SHA2の完全性メカニズムへのIPPT入力を準備するために使用される正規化アルゴリズムを定義します。IPPTの構築は、このセキュリティコンテキストの動作をカスタマイズする部分として提供できる整合性スコープフラグの設定に依存します。
In all cases, the canonical form of any portion of an extension block MUST be created as described in [RFC9172]. The canonicalization algorithms defined in [RFC9172] adhere to the canonical forms for extension blocks defined in [RFC9171] but resolve ambiguities related to how values are represented in CBOR.
すべての場合において、[RFC9172]に記載されているように、拡張ブロックの任意の部分の標準形式を作成する必要があります。[RFC9172]で定義された正方価化アルゴリズムは、[RFC9171]で定義されている延長ブロックの標準形に準拠していますが、値がどのようにCBORで表されるかに関連したあいまいさを解決します。
The IPPT is constructed using the following process. While integrity scope flags might not be included in the BIB representing the security operation, they MUST be included in the IPPT value itself.
IPPTは次のプロセスを使用して構築されます。整合性スコープフラグがセキュリティ操作を表すBIBに含まれていない可能性があるが、それらはIPPT値自体に含める必要があります。
1. The canonical form of the IPPT starts as the CBOR encoding of the integrity scope flags in which all unset flags, reserved bits, and unassigned bits have been set to 0. For example, if the primary block flag, target header flag, and security header flag are each set, then the initial value of the canonical form of the IPPT will be 0x07.
1. IPPTの標準形式は、すべての未使用のフラグ、予約ビット、および未割り当てビットが0に設定されている整合性スコープフラグのCBORエンコードとして開始されます。たとえば、プライマリブロックフラグ、ターゲットヘッダーフラグ、およびセキュリティヘッダーフラグはそれぞれ設定されているので、IPPTの正規形の初期値は0x07になります。
2. If the primary block flag of the integrity scope flags is set to 1 and the security target is not the bundle's primary block, then a canonical form of the bundle's primary block MUST be calculated and the result appended to the IPPT.
2. Integrityスコープフラグのプライマリブロックフラグが1に設定され、セキュリティターゲットがバンドルのプライマリブロックではない場合は、Bundleのプライマリブロックの正規形を計算し、その結果がIPPTに追加されなければなりません。
3. If the target header flag of the integrity scope flags is set to 1 and the security target is not the bundle's primary block, then the canonical form of the block type code, block number, and block processing control flags associated with the security target MUST be calculated and, in that order, appended to the IPPT.
3. 整合性スコープフラグのターゲットヘッダフラグが1に設定され、セキュリティターゲットがバンドルのプライマリブロックではない場合、セキュリティターゲットに関連付けられているブロックタイプコード、ブロック番号、およびブロック処理制御フラグの正規形が必要である必要があります。その順序で、IPPTに追加されました。
4. If the security header flag of the integrity scope flags is set to 1, then the canonical form of the block type code, block number, and block processing control flags associated with the BIB MUST be calculated and, in that order, appended to the IPPT.
4. 整合性スコープフラグのセキュリティヘッダフラグが1に設定されている場合、BIBに関連付けられているブロックタイプコード、ブロック番号、およびブロック処理制御フラグの正規形を計算し、その順序でIPPTに追加する必要があります。。
5. The canonical form of the security target MUST be calculated and appended to the IPPT. If the security target is the primary block, this is the canonical form of the primary block. Otherwise, this is the canonical form of the block-type-specific data of the security target.
5. 正規形のセキュリティターゲットは計算され、IPPTに追加されなければなりません。セキュリティターゲットがプライマリブロックの場合、これは1次ブロックの正規形です。それ以外の場合、これはセキュリティターゲットのブロック型固有のデータの正規形です。
| NOTE: When the security target is the bundle's primary block,
| the canonicalization steps associated with the primary block
| flag and the target header flag are skipped. Skipping primary
| block flag processing, in this case, avoids adding the bundle's
| primary block twice in the IPPT calculation. Skipping target
| header flag processing, in this case, is necessary because the
| primary block of a bundle does not have the expected elements
| of a block header such as block number and block processing
| control flags.
During keyed hash generation, two inputs are prepared for the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These data items MUST be generated as follows.
キー付きハッシュ生成中に、適切なHMAC / SHA2アルゴリズムのために2つの入力が用意されています：HMACキーとIPPT。これらのデータ項目は次のように生成されなければなりません。
* The HMAC key MUST have the appropriate length as required by local security policy. The key can be generated specifically for this integrity service, given as part of local security policy, or obtained through some other key management mechanism as discussed in Section 3.5.
* HMACキーは、ローカルセキュリティポリシーで必要とされる適切な長さを持たなければなりません。このキーは、ローカルセキュリティポリシーの一部として与えられている、またはセクション3.5で説明されているように、この整合性サービスのために特別に生成することができます。
* Prior to the generation of the IPPT, if a Cyclic Redundancy Check (CRC) value is present for the target block of the BIB, then that CRC value MUST be removed from the target block. This involves both removing the CRC value from the target block and setting the CRC type field of the target block to "no CRC is present."
* IPPTの生成前に、BIBのターゲットブロックに対して巡回冗長検査（CRC）値が存在する場合、そのCRC値はターゲットブロックから削除されなければなりません。これには、ターゲットブロックからCRC値を削除し、ターゲットブロックのCRCタイプフィールドを "No CRCが存在する"に設定することが含まれます。
* Once CRC information is removed, the IPPT MUST be generated as discussed in Section 3.7.
* CRC情報が削除されると、IPPTはセクション3.7で説明されているように生成されなければなりません。
Upon successful hash generation, the following action MUST occur.
ハッシュ生成が成功すると、次の操作が発生する必要があります。
* The keyed hash produced by the HMAC/SHA2 variant MUST be added as a security result for the BIB representing the security operation on this security target, as discussed in Section 3.4.
* HMAC / SHA2バリアントによって生成されたキー付きハッシュは、セクション3.4で説明したように、このセキュリティターゲットのセキュリティ操作を表すBIBのセキュリティ結果として追加する必要があります。
Finally, the BIB containing information about this security operation MUST be updated as follows. These operations can occur in any order.
最後に、このセキュリティ操作に関する情報を含むBIBは次のように更新されなければなりません。これらの操作は任意の順序で発生する可能性があります。
* The security context identifier for the BIB MUST be set to the context identifier for BIB-HMAC-SHA2.
* BIBのセキュリティコンテキスト識別子は、BIB-HMAC-SHA2のコンテキスト識別子に設定する必要があります。
* Any local flags used to generate the IPPT MUST be placed in the integrity scope flags security context parameter for the BIB unless these flags are expected to be correctly configured at security verifiers and acceptors in the network.
* IPPTを生成するために使用されるローカルフラグは、ネットワーク内のセキュリティ検証者およびアクセプタで正しく構成されていると予想されない限り、BIBのIntegrity Scope Flagsセキュリティコンテキストパラメータに配置する必要があります。
* The HMAC key MAY be included as a security context parameter, in which case it MUST be wrapped using the AES key wrap function as defined in [RFC3394] and the results of the wrapping added as the wrapped key security context parameter for the BIB.
* HMACキーはセキュリティコンテキストパラメータとして含まれていてもよく、その場合、[RFC3394]で定義されているAESキーラップ関数とBIBのラップされたキーセキュリティコンテキストパラメータとして追加されたAESキーラップ関数を使用してラップする必要があります。
* The SHA variant used by this security context SHOULD be added as the SHA variant security context parameter for the BIB if it differs from the default key length. Otherwise, this parameter MAY be omitted if doing so provides a useful reduction in message sizes.
* このセキュリティコンテキストで使用されるSHAバリアントは、デフォルトのキー長と異なる場合は、BIBのSHAバリアントセキュリティコンテキストパラメータとして追加する必要があります。そうでなければ、このパラメータは、メッセージサイズの有用な削減を提供する場合、このパラメータは省略されてもよい。
Problems encountered in the keyed hash generation MUST be processed in accordance with local BPSec security policy.
キー付きハッシュ生成で発生した問題は、ローカルBPSECセキュリティポリシーに従って処理する必要があります。
During keyed hash verification, the input of the security target and an HMAC key are provided to the appropriate HMAC/SHA2 algorithm.
キー付きハッシュ検証中に、セキュリティターゲットとHMACキーの入力が適切なHMAC / SHA2アルゴリズムに提供されています。
During keyed hash verification, two inputs are prepared for the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These data items MUST be generated as follows.
キー付きハッシュ検証中に、適切なHMAC / SHA2アルゴリズムのために2つの入力が用意されています.HMACキーとIPPT。これらのデータ項目は次のように生成されなければなりません。
* The HMAC key MUST be derived using the wrapped key security context parameter if such a parameter is included in the security context parameters of the BIB. Otherwise, this key MUST be derived in accordance with security policy at the verifying node as discussed in Section 3.5.
* そのようなパラメータがBIBのセキュリティコンテキストパラメータに含まれている場合、HMACキーはラップされたキーセキュリティコンテキストパラメータを使用して派生する必要があります。それ以外の場合は、セクション3.5で説明したように、検証ノードのセキュリティポリシーに従って派生する必要があります。
* The IPPT MUST be generated as discussed in Section 3.7 with the value of integrity scope flags being taken from the integrity scope flags security context parameter. If the integrity scope flags parameter is not included in the security context parameters, then these flags MAY be derived from local security policy.
* Integrityスコープフラグから取得されているIntegrityスコープフラグの値をセキュリティコンテキストパラメータの値でセクション3.7で説明するようにIPPTを生成する必要があります。Integrityスコープフラグパラメータがセキュリティコンテキストパラメータに含まれていない場合、これらのフラグはローカルセキュリティポリシーから派生することがあります。
The calculated HMAC output MUST be compared to the expected HMAC output encoded in the security results of the BIB for the security target. If the calculated HMAC and expected HMAC are identical, the verification MUST be considered a success. Otherwise, the verification MUST be considered a failure.
計算されたHMAC出力は、セキュリティターゲットのBIBのセキュリティ結果でエンコードされた予想されるHMAC出力と比較する必要があります。計算されたHMACと予想されるHMACが同一である場合、検証は成功と見なされなければなりません。それ以外の場合、検証は失敗と見なされなければなりません。
If the verification fails or otherwise experiences an error or if any needed parameters are missing, then the verification MUST be treated as failed and processed in accordance with local security policy.
検証に失敗した場合、またはエラーが発生した場合、または必要なパラメータが欠落している場合は、検証はローカルセキュリティポリシーに従って失敗して処理されている必要があります。
This security service is removed from the bundle at the security acceptor as required by the BPSec specification [RFC9172]. If the security acceptor is not the bundle destination and if no other integrity service is being applied to the target block, then a CRC MUST be included for the target block. The CRC type, as determined by policy, is set in the target block's CRC type field, and the corresponding CRC value is added as the CRC field for that block.
このセキュリティサービスは、BPSEC仕様[RFC9172]に必要に応じてセキュリティアクセプタのバンドルから削除されます。セキュリティアクセプタがバンドル宛先ではなく、他のIntegrityサービスがターゲットブロックに適用されていない場合は、ターゲットブロックにCRCを含める必要があります。ポリシーによって決定されたCRCタイプは、ターゲットブロックのCRCタイプフィールドに設定され、対応するCRC値がそのブロックのCRCフィールドとして追加されます。
The BCB-AES-GCM security context replaces the block-type-specific data field of its security target with ciphertext generated using the Advanced Encryption Standard (AES) cipher operating in Galois/Counter Mode (GCM) [AES-GCM]. The use of AES-GCM was selected as the cipher suite for this confidentiality mechanism for several reasons:
BCB-AES-GCMセキュリティコンテキストは、ガロア/カウンタモード（GCM）[AES-GCM]で動作する高度な暗号化標準（AES）暗号を使用して生成されたCipherTextとのセキュリティターゲットのブロックタイプ固有のデータフィールドを置き換えます。AES-GCMを使用すると、いくつかの理由から、この機密性メカニズムのための暗号スイートとして選択されました。
1. The selection of a symmetric-key cipher suite allows for relatively smaller keys than asymmetric-key cipher suites.
1. 対称鍵暗号スイートの選択は、非対称キー暗号スイートよりも比較的小さいキーを可能にします。
2. The selection of a symmetric-key cipher suite allows this security context to be used in places where an asymmetric-key infrastructure (such as a public key infrastructure) might be impractical.
2. Symmetric Key Cipher Suiteの選択により、このセキュリティコンテキストを非対称キーインフラストラクチャ（公開鍵インフラストラクチャなど）が実用的である可能性がある場所で使用できます。
3. The use of the Galois/Counter Mode produces ciphertext with the same size as the plaintext making the replacement of target block information easier as length fields do not need to be changed.
3. Galois / Counterモードの使用は、長さのフィールドを変更する必要がないように、ターゲットブロック情報の交換をより簡単に置き換えることと同じサイズの暗号文を生成します。
4. The AES-GCM cipher suite provides authenticated encryption, as required by the BPSec protocol.
4. AES-GCM暗号スイートは、BPSECプロトコルによって必要に応じて認証された暗号化を提供します。
Additionally, the BCB-AES-GCM security context generates an authentication tag based on the plaintext value of the block-type-specific data and other additional authenticated data (AAD) that might be specified via parameters to this security context.
さらに、BCB-AES-GCMセキュリティコンテキストは、このセキュリティコンテキストにパラメータを介して指定されている可能性があるブロック型固有のデータの平文値および他の追加の認証データ（AAD）に基づいて認証タグを生成します。
This security context supports two variants of AES-GCM, based on the supported length of the symmetric key. These variants correspond to A128GCM and A256GCM as defined in Table 9 ("Algorithm Value for AES-GCM") of [RFC8152].
このセキュリティコンテキストは、対称鍵のサポートされている長さに基づいて、AES-GCMの2つの変形例をサポートしています。これらの変形は、表9（「RFC8152の「AES-GCMのアルゴリズム値」）で定義されているA128GCMおよびA256GCMに対応しています。
The BCB-AES-GCM security context MUST have the security context identifier specified in Section 5.1.
BCB-AES-GCMセキュリティコンテキストには、セキュリティコンテキスト識別子がセクション5.1に含まれている必要があります。
There are two scopes associated with BCB-AES-GCM: the scope of the confidentiality service and the scope of the authentication service. The first defines the set of information provided to the AES-GCM cipher for the purpose of producing ciphertext. The second defines the set of information used to generate an authentication tag.
BCB-AES-GCM：機密保持サービスの範囲と認証サービスの範囲に関連する2つのスコープがあります。最初に、暗号文を生成する目的でAES-GCM暗号に提供される情報のセットを定義します。2つ目は、認証タグを生成するために使用される情報のセットを定義します。
The scope of the confidentiality service defines the set of information provided to the AES-GCM cipher for the purpose of producing ciphertext. This MUST be the full set of plaintext contained in the block-type-specific data field of the security target.
機密保持サービスの範囲は、暗号文の生成を目的として、AES-GCM暗号に提供される情報のセットを定義しています。これは、セキュリティターゲットのブロックタイプ固有のデータフィールドに含まれる平文のフルセットです。
The scope of the authentication service defines the set of information used to generate an authentication tag carried with the security block. This information contains all data protected by the confidentiality service and the scope flags used to identify other optional information; it MAY include other information (additional authenticated data), as follows.
認証サービスの範囲は、セキュリティブロックで運ばれる認証タグを生成するために使用される情報のセットを定義します。この情報には、機密保持サービスによって保護されているすべてのデータと他のオプション情報の識別に使用されるスコープフラグが含まれています。次のように、他の情報（追加の認証データ）を含めることができます。
Primary block The primary block identifies a bundle, and once created, the contents of this block are immutable. Changes to the primary block associated with the security target indicate that the security target (and BCB) might no longer be in the correct bundle.
プライマリブロックプライマリブロックはバンドルを識別し、作成したらこのブロックの内容は不変です。セキュリティターゲットに関連付けられているプライマリブロックへの変更は、セキュリティターゲット（およびBCB）が正しいバンドルにない可能性があることを示します。
For example, if a security target and associated BCB are copied from one bundle to another bundle, the BCB might still be able to decrypt the security target even though these blocks were never intended to exist in the copied-to bundle.
たとえば、セキュリティターゲットと関連付けられているBCBが1つのバンドルから別のバンドルにコピーされている場合、BCBはまだこれらのブロックがコピーしたバンドルに存在することを意図していなかったとしても、セキュリティターゲットを復号化できます。
Including this information as part of additional authenticated data ensures that the security target (and security block) appear in the same bundle at the time of decryption as at the time of encryption.
追加の認証データの一部としてこの情報を含めることで、暗号化時の復号化時にセキュリティ対象（およびセキュリティブロック）が同じバンドルに表示されるようにします。
Other fields of the security target The other fields of the security target include block identification and processing information. Changing this information changes how the security target is treated by nodes in the network even when the "user data" of the security target are otherwise unchanged.
セキュリティ対象の他のフィールドセキュリティターゲットの他のフィールドは、ブロック識別および処理情報を含む。この情報を変更すると、セキュリティターゲットの「ユーザーデータ」が変更されていない場合でも、セキュリティターゲットがネットワーク内のノードによってどのように扱われるかを変更します。
For example, if the block processing control flags of a security target are different at a security verifier than they were originally set at the security source, then the policy for handling the security target has been modified.
たとえば、セキュリティターゲットのブロック処理制御フラグがセキュリティソースでもともとセキュリティ検証子で異なる場合は、セキュリティターゲットを処理するためのポリシーが変更されました。
Including this information as part of additional authenticated data ensures that the ciphertext in the security target will not be used with a different set of block policy than originally set at the time of encryption.
追加の認証データの一部としてこの情報を含めることで、セキュリティターゲット内の暗号文が、暗号化時に最初に設定されているよりも異なるブロックポリシーのセットでは使用されません。
Other fields of the BCB The other fields of the BCB include block identification and processing information. Changing this information changes how the BCB is treated by nodes in the network, even when other aspects of the BCB are unchanged.
BCBの他のフィールドBCBの他のフィールドは、ブロック識別および処理情報を含む。この情報を変更すると、BCBの他の側面が変更されていなくても、BCBがネットワーク内のノードによってどのように扱われるかを変更します。
For example, if the block processing control flags of the BCB are different at a security acceptor than they were originally set at the security source, then the policy for handling the BCB has been modified.
たとえば、BCBのブロック処理制御フラグがセキュリティソースでもともとセキュリティアクセプタで異なる場合は、BCBを処理するためのポリシーが変更されました。
Including this information as part of additional authenticated data ensures that the policy and identification of the security service in the bundle has not changed.
追加の認証データの一部としてこの情報を含めることで、バンドル内のセキュリティサービスのポリシーと識別が変更されていないことが保証されています。
| NOTE: The security context identifier and security context
| parameters of the security block are not included as
| additional authenticated data because these parameters, by
| definition, are those needed to verify or accept the
| security service. Therefore, it is expected that changes to
| these values would result in failures at security verifiers
| and security acceptors. This is the case because keys
| cannot be reused across security contexts and because the
| AAD scope flags used to identify the AAD are included in the
| AAD.
The scope of the BCB-AES-GCM security context is configured using an optional security context parameter.
BCB-AES-GCMセキュリティコンテキストの範囲は、オプションのセキュリティコンテキストパラメータを使用して構成されています。
BCB-AES-GCM can be parameterized to specify the AES variant, initialization vector, key information, and identify additional authenticated data.
BCB-AES-GCMは、AESのバリアント、初期化ベクトル、鍵情報、および追加の認証データを特定するようにパラメータ化できます。
This optional parameter identifies the initialization vector (IV) used to initialize the AES-GCM cipher.
このオプションパラメータは、AES-GCM暗号を初期化するために使用される初期化ベクトル（IV）を識別します。
The length of the initialization vector, prior to any CBOR encoding, MUST be between 8-16 bytes. A value of 12 bytes SHOULD be used unless local security policy requires a different length.
CBORエンコードの前の初期化ベクトルの長さは、8~16バイトの間でなければなりません。ローカルセキュリティポリシーが異なる長さを必要としない限り、12バイトの値を使用する必要があります。
This value MUST be encoded as a CBOR byte string.
この値はCBOBORバイト文字列としてエンコードする必要があります。
The initialization vector can have any value, with the caveat that a value MUST NOT be reused for multiple encryptions using the same encryption key. This value MAY be reused when encrypting with different keys. For example, if each encryption operation using BCB-AES-GCM uses a newly generated key, then the same IV can be reused.
初期化ベクトルは任意の値を持つことができ、警告は同じ暗号化キーを使用して複数の暗号化のために値を再利用してはいけません。この値は、さまざまなキーで暗号化するときに再利用できます。たとえば、BCB-AES-GCMを使用した各暗号化操作が新しく生成されたキーを使用する場合は、同じIVを再利用できます。
This optional parameter identifies the AES variant being used for the AES-GCM encryption, where the variant is identified by the length of key used.
このオプションのパラメータは、AES-GCM暗号化に使用されているAESバリアントを識別します。ここで、バリアントは使用されるキーの長さによって識別されます。
This value MUST be encoded as a CBOR unsigned integer.
この値は、CBOR符号なし整数としてエンコードする必要があります。
Valid values for this parameter are as follows.
このパラメータの有効な値は次のとおりです。
+=======+===========================================+
| Value | Description |
+=======+===========================================+
| 1 | A128GCM as defined in Table 9 ("Algorithm |
| | Value for AES-GCM") of [RFC8152] |
+-------+-------------------------------------------+
| 3 | A256GCM as defined in Table 9 ("Algorithm |
| | Value for AES-GCM") of [RFC8152] |
+-------+-------------------------------------------+
Table 4: AES Variant Parameter Values
表4：AESのバリアントパラメータ値
When not provided, implementations SHOULD assume a value of 3 (indicating use of A256GCM), unless an alternate default is established by local security policy at the security source, verifier, or acceptor of this integrity service.
提供されていない場合は、このIntegrityサービスのセキュリティソース、検証者、またはアクセプタでのローカルセキュリティポリシーによって別のデフォルトが確立されない限り、実装は3の値（A256GCMの使用を示す）を想定する必要があります。
Regardless of the variant, the generated authentication tag MUST always be 128 bits.
バリアントに関係なく、生成された認証タグは常に128ビットでなければなりません。
This optional parameter contains the output of the AES key wrap function as defined in [RFC3394]. Specifically, this parameter holds the ciphertext produced when running this key wrap algorithm with the input string being the symmetric AES key used to generate the security results present in the security block. The value of this parameter is used as input to the AES key wrap authenticated decryption function at security verifiers and security acceptors to determine the symmetric AES key needed for the proper decryption of the security results in the security block.
このオプションパラメータには、[RFC3394]で定義されているAESキーラップ関数の出力が含まれています。具体的には、このパラメータは、セキュリティブロックに存在するセキュリティ結果を生成するために使用される入力文字列が、このキーラップアルゴリズムを実行するときに生成された暗号文を保持します。このパラメータの値は、セキュリティ検証者およびセキュリティアクセプタのAESキーラップ認証済み復号化機能への入力として使用され、セキュリティブロックのセキュリティブロックの適切な復号化に必要な対称AESキーを決定します。
This value MUST be encoded as a CBOR byte string.
この値はCBOBORバイト文字列としてエンコードする必要があります。
If this parameter is not present, then security verifiers and acceptors MUST determine the proper key as a function of their local BPSec policy and configuration.
このパラメータが存在しない場合は、セキュリティ検証者とアクセプタが自分のローカルBPSecポリシーと設定の関数として正しいキーを決定する必要があります。
This optional parameter contains a series of flags that describe what information is to be included with the block-type-specific data of the security target as part of additional authenticated data (AAD).
このオプションのパラメータには、追加の認証されたデータ（AAD）の一部としてセキュリティターゲットのブロックタイプ固有のデータに含まれる情報を記述する一連のフラグが含まれています。
This value MUST be represented as a CBOR unsigned integer, the value of which MUST be processed as a 16-bit field. The maximum value of this field, as a CBOR unsigned integer, MUST be 65535.
この値はCBOR符号なし整数として表す必要があります。その値は16ビットフィールドとして処理されなければなりません。このフィールドの最大値は、CBOR符号なし整数として、65535にする必要があります。
When not provided, implementations SHOULD assume a value of 7 (indicating all assigned fields), unless an alternate default is established by local security policy at the security source, verifier, or acceptor of this integrity service.
提供されていない場合、このIntegrityサービスのセキュリティソース、検証者、またはアクセプタで代替デフォルトが確立されていない限り、実装は7の値（割り当てられたフィールドを示す）を仮定する必要があります。
Implementations MUST set reserved and unassigned bits in this field to 0 when constructing these flags at a security source. Once set, the value of this field MUST NOT be altered until the security service is completed at the security acceptor in the network and removed from the bundle.
実装は、セキュリティソースでこれらのフラグを構築するときに、このフィールドの予約済みおよび割り当てられていないビットを0に設定する必要があります。設定されたら、このフィールドの値はネットワーク内のセキュリティアクセプタで完了し、バンドルから削除されるまで、このフィールドの値を変更してはなりません。
Bits in this field represent additional information to be included when generating an integrity signature over the security target. These bits are defined as follows.
このフィールドのビットは、セキュリティターゲットを介して整合性シグネチャを生成するときに含まれる追加情報を表します。これらのビットは次のように定義されています。
Bit 0 (the low-order bit, 0x0001): Include primary block flag
ビット0（下位ビット、0x0001）：プライマリブロックフラグを含める
Bit 1 (0x0002): Include target header flag
ビット1（0x0002）：ターゲットヘッダフラグを含める
Bit 2 (0x0004): Include security header flag
ビット2（0x0004）：セキュリティヘッダフラグを含める
Bits 3-7: Reserved
ビット3-7：予約済み
Bits 8-15: Unassigned
ビット8-15：未割り当て
The BCB-AES-GCM security context parameters are listed in Table 5. In this table, the "Parm Id" column refers to the expected parameter identifier described in Section 3.10 ("Parameter and Result Identification") of [RFC9172].
BCB-AES-GCMのセキュリティコンテキストパラメータを表5に示します。この表では、 "Parm ID"列は[RFC9172]のセクション3.10（ "パラメータと結果の識別"）で説明されている予想されるパラメータ識別子を指します。
An empty "Default Value" column indicates that the security context parameter does not have a default value.
空の「デフォルト値」列は、セキュリティコンテキストパラメータにデフォルト値がないことを示します。
+=========+================+====================+===============+
| Parm Id | Parm Name | CBOR Encoding Type | Default Value |
+=========+================+====================+===============+
| 1 | Initialization | byte string | |
| | Vector | | |
+---------+----------------+--------------------+---------------+
| 2 | AES Variant | unsigned integer | 3 |
+---------+----------------+--------------------+---------------+
| 3 | Wrapped Key | byte string | |
+---------+----------------+--------------------+---------------+
| 4 | AAD Scope | unsigned integer | 7 |
| | Flags | | |
+---------+----------------+--------------------+---------------+
Table 5: BCB-AES-GCM Security Context Parameters
表5：BCB-AES-GCMセキュリティコンテキストパラメータ
The BCB-AES-GCM security context produces a single security result carried in the security block: the authentication tag.
BCB-AES-GCMセキュリティコンテキストは、セキュリティブロックで実行されている単一のセキュリティ結果を生成します。認証タグ。
NOTES:
ノート：
* The ciphertext generated by the cipher suite is not considered a security result as it is stored in the block-type-specific data field of the security target block. When operating in GCM mode, AES produces ciphertext of the same size as its plaintext; therefore, no additional logic is required to handle padding or overflow caused by the encryption in most cases.
* 暗号スイートによって生成された暗号文は、セキュリティターゲットブロックのブロックタイプ固有のデータフィールドに格納されているため、セキュリティ結果とは見なされません。GCMモードで動作する場合、AESは平文と同じサイズの暗号文を生成します。したがって、ほとんどの場合暗号化によって引き起こされるパディングまたはオーバーフローを処理するために追加のロジックは必要ありません。
* If the authentication tag can be separated from the ciphertext, then the tag MAY be separated and stored in the authentication tag security result field. Otherwise, the security target block MUST be resized to accommodate the additional 128 bits of authentication tag included with the generated ciphertext replacing the block-type-specific data field of the security target block.
* 認証タグを暗号文から分離できる場合は、そのタグを分離して認証タグセキュリティ結果フィールドに格納することができます。それ以外の場合、セキュリティターゲットブロックは、セキュリティターゲットブロックのブロックタイプ固有のデータフィールドを置き換えるCipherTextが組み込まれた追加の128ビットの認証タグに対応するようにサイズ変更されなければなりません。
The authentication tag is generated by the cipher suite over the security target plaintext input to the cipher suite as combined with any optional additional authenticated data. This tag is used to ensure that the plaintext (and important information associated with the plaintext) is authenticated prior to decryption.
認証タグは、任意の追加の認証されたデータと組み合わされたCipher SuiteへのCipher SuiteへのCipher Suiteへの暗号スイートによってCipher Suiteによって生成されます。このタグは、復号化の前に平文（および平文に関連する重要な情報）が認証されていることを確認するために使用されます。
If the authentication tag is included in the ciphertext placed in the security target block-type-specific data field, then this security result MUST NOT be included in the BCB for that security target.
認証タグがセキュリティターゲットブロックタイプ固有のデータフィールドに配置されている暗号文に含まれている場合、このセキュリティターゲットのBCBにこのセキュリティ結果を含まれてはいけません。
The length of the authentication tag, prior to any CBOR encoding, MUST be 128 bits.
CBORエンコーディングの前の認証タグの長さは128ビットでなければなりません。
This value MUST be encoded as a CBOR byte string.
この値はCBOBORバイト文字列としてエンコードする必要があります。
The BCB-AES-GCM security context results are listed in Table 6. In this table, the "Result Id" column refers to the expected result identifier described in Section 3.10 ("Parameter and Result Identification") of [RFC9172].
BCB-AES-GCMセキュリティコンテキストの結果を表6に示します。この表では、「結果ID」列とは、[RFC9172]のセクション3.10（「パラメータと結果の識別」）で説明されている予想される結果識別子を指します。
+===========+====================+====================+
| Result Id | Result Name | CBOR Encoding Type |
+===========+====================+====================+
| 1 | Authentication Tag | byte string |
+-----------+--------------------+--------------------+
Table 6: BCB-AES-GCM Security Results
表6：BCB-AES-GCMセキュリティ結果
Keys used with this context MUST be symmetric and MUST have a key length equal to the key length defined in the security context parameters or as defined by local security policy at security verifiers and acceptors. For this reason, content-encrypting key lengths will be integers divisible by 8 bytes, and special padding-aware AES key wrap algorithms are not needed.
このコンテキストで使用されているキーは対称的でなければならず、セキュリティコンテキストパラメータで定義されているキー長に等しい、またはセキュリティ検証者とアクセプタのローカルセキュリティポリシーによって定義されているようになる必要があります。このため、コンテンツ暗号化キー長は8バイトで割り切れられ、特別なパディング対応AESキーラップアルゴリズムは必要ありません。
It is assumed that any security verifier or security acceptor can determine the proper key to be used. Potential sources of the key include (but are not limited to) the following.
セキュリティ検証者またはセキュリティアクセプタが使用される適切なキーを決定できると仮定されます。キーの潜在的なソースには、次のことが含まれます（ただし、これに限定されません）。
* Pre-placed keys selected based on local policy.
* ローカルポリシーに基づいて選択された事前に配置されたキー。
* Keys extracted from material carried in the BCB.
* BCBで運ばれる材料から抽出されたキー。
* Session keys negotiated via a mechanism external to the BCB.
* セッションキーはBCBの外部のメカニズムを介してネゴシエートされました。
When an AES-KW wrapped key is present in a security block, it is assumed that security verifiers and security acceptors can independently determine the KEK used in the wrapping of the symmetric AES content-encrypting key.
AES-KWラップキーがセキュリティブロックに存在すると、セキュリティ検証者とセキュリティアクセプタが対称AESコンテンツ暗号化キーのラッピングで使用されるKEKを独立して決定できると仮定されます。
The security provided by block ciphers is reduced as more data is processed with the same key. The total number of AES blocks processed with a single key for AES-GCM is recommended to be less than 2^64, as described in Appendix B of [AES-GCM].
ブロック暗号によって提供されるセキュリティは、より多くのデータが同じキーで処理されるにつれて減少します。[AES-GCM]の付録Bの付記Bで説明されているように、AES-GCM用の単一キーで処理されたAESブロックの総数を2 ^ 64未満にすることをお勧めします。
Additionally, there exist limits on the number of encryptions that can be performed with the same key. The total number of invocations of the authenticated encryption function with a single key for AES-GCM is required to not exceed 2^32, as described in Section 8.3 of [AES-GCM].
さらに、同じキーで実行できる暗号化の数に制限があります。[AES-GCM]のセクション8.3で説明されているように、AES-GCMの単一キーを持つ認証済み暗号化関数の呼び出しの総数は2 ^ 32を超えないように必要です。
As discussed in Section 6 and emphasized here, it is strongly recommended that keys be protected once generated, both when they are stored and when they are transmitted.
ここで節で説明したように、それらが格納されているとき、およびそれらが送信されたときに、キーが一度生成されると、キーを保護することを強く推奨されます。
The GCM cryptographic mode of AES has specific requirements that MUST be followed by implementers for the secure function of the BCB-AES-GCM security context. While these requirements are well documented in [AES-GCM], some of them are repeated here for emphasis.
AESのGCM暗号化モードには、BCB-AES-GCMセキュリティコンテキストの安全な機能のための実装者が続く特定の要件があります。これらの要件は[AES-GCM]によく文書化されていますが、それらのいくつかはここで強調されています。
* With the exception of the AES-KW function, the IVs used by the BCB-AES-GCM security context are considered to be per-invocation IVs. The pairing of a per-invocation IV and a security key MUST be unique. A per-invocation IV MUST NOT be used with a security key more than one time. If a per-invocation IV and key pair are repeated, then the GCM implementation is vulnerable to forgery attacks. Because the loss of integrity protection occurs with even a single reuse, this situation is often considered to have catastrophic security consequences. More information regarding the importance of the uniqueness of the IV value can be found in Appendix A of [AES-GCM].
* AES-kW機能を除いて、BCB-AES-GCMセキュリティコンテキストで使用されるIVSは呼び出しごとのIVSと見なされます。呼び出しごとのIVとセキュリティキーのペアリングは一意でなければなりません。呼び出しごとのIVを複数回以上のセキュリティキーで使用しないでください。呼び出しごとのIVとキーペアが繰り返される場合、GCM実装は偽造攻撃に対して脆弱です。完全性保護の喪失は単一の再利用でさえも起こるので、この状況はしばしば壊滅的なセキュリティの結果をもたらすと考えられています。IV値の一意性の重要性に関するさらなる情報は、[AES-GCM]の付録Aにあります。
Methods of generating unique IV values are provided in Section 8 of [AES-GCM]. For example, one method decomposes the IV value into a fixed field and an invocation field. The fixed field is a constant value associated with a device, and the invocation field changes on each invocation (such as by incrementing an integer counter). Implementers SHOULD carefully read all relevant sections of [AES-GCM] when generating any mechanism to create unique IVs.
独自のIV値を生成する方法は[AES-GCM]のセクション8に提供されています。例えば、1つの方法はIV値を固定フィールドと呼び出しフィールドに分解します。固定フィールドはデバイスに関連付けられた定数値であり、呼び出しフィールドは各呼び出しで変わります（整数カウンタをインクリメントするなど）。実装者は、一意のIVを作成するためのメカニズムを生成するときに、[AES-GCM]のすべての関連セクションを慎重に読み取る必要があります。
* The AES-KW function used to wrap keys for the security contexts in this document uses a single, globally constant IV input to the AES cipher operation and thus is distinct from the aforementioned requirement related to per-invocation IVs.
* この文書内のセキュリティコンテキストのキーを包むために使用されるAES-kW関数は、AES暗号操作に単一のグローバル定数IV入力を使用しているため、呼び出しごとのIVSに関連する前述の要件とは異なります。
* While any tag-based authentication mechanism has some likelihood of being forged, this probability is increased when using AES-GCM. In particular, short tag lengths combined with very long messages SHOULD be avoided when using this mode. The BCB-AES-GCM security context requires the use of 128-bit authentication tags at all times. Concerns relating to the size of authentication tags is discussed in Appendices B and C of [AES-GCM].
* あらゆるタグベースの認証メカニズムには鍛造される可能性があるが、この確率はAES-GCMを使用するときに増加します。特に、このモードを使用すると、非常に長いメッセージと組み合わされた短いタグ長を回避する必要があります。BCB-AES-GCMセキュリティコンテキストでは、常に128ビット認証タグを使用する必要があります。認証タグのサイズに関する懸念は、[AES-GCM]の付録BおよびCで説明されています。
* As discussed in Appendix B of [AES-GCM], implementations SHOULD limit the number of unsuccessful verification attempts for each key to reduce the likelihood of guessing tag values. This type of check has potential state-keeping issues when AES-KW is used, since an attacker could cause a large number of keys to be used at least once.
* [AES-GCM]の付録Bで説明されているように、実装は各鍵の失敗検証試行の数を制限する必要があります。タグ値を推測する可能性を軽減します。攻撃者が少なくとも1回使用されるように多数のキーを使用する可能性があるため、このタイプのチェックは、AES-KWが使用されている場合に潜在的な状態保持の問題を抱えています。
* As discussed in Section 8 ("Security Considerations") of [RFC9172], delay-tolerant networks have a higher occurrence of replay attacks due to the store-and-forward nature of the network. Because GCM has no inherent replay attack protection, implementors SHOULD attempt to detect replay attacks by using mechanisms such as those described in Appendix D of [AES-GCM].
* [RFC9172]のセクション8（「セキュリティ上の考慮事項」）で説明されているように、遅延耐性ネットワークは、ネットワークの店と前方の性質のために再生攻撃が大きい。GCMには固有のリプレイ攻撃保護がないため、「AES-GCM」の付録Dに記載されているメカニズムなどのメカニズムを使用して、実装者は再生攻撃を検出しようとするはずです。
This section defines the canonicalization algorithms used to prepare the inputs used to generate both the ciphertext and the authentication tag.
このセクションでは、暗号文と認証タグの両方を生成するために使用される入力を準備するために使用される正規化アルゴリズムを定義します。
In all cases, the canonical form of any portion of an extension block MUST be created as described in [RFC9172]. The canonicalization algorithms defined in [RFC9172] adhere to the canonical forms for extension blocks defined in [RFC9171] but resolve ambiguities related to how values are represented in CBOR.
すべての場合において、[RFC9172]に記載されているように、拡張ブロックの任意の部分の標準形式を作成する必要があります。[RFC9172]で定義された正方価化アルゴリズムは、[RFC9171]で定義されている延長ブロックの標準形に準拠していますが、値がどのようにCBORで表されるかに関連したあいまいさを解決します。
The BCB operates over the block-type-specific data of a block, but the BP always encodes these data within a single, definite-length CBOR byte string. Therefore, the plaintext used during encryption MUST be calculated as the value of the block-type-specific data field of the security target excluding the BP CBOR encoding.
BCBはブロックのブロックタイプ固有のデータを介して動作しますが、BPは常にこれらのデータを単一の明確なCBOBOBOBOBOBOBOBOBOBOBORバイト文字列内で符号化します。したがって、暗号化中に使用される平文は、BP CBOBOR符号化を除くセキュリティ対象のブロック型固有のデータフィールドの値として計算する必要があります。
Table 7 shows two CBOR-encoded examples and the plaintext that would be extracted from them. The first example is an unsigned integer, while the second is a byte string.
表7は、2つのCBORコード化された例とそれらから抽出される平文を示しています。最初の例は符号なし整数ですが、2番目の例はバイト文字列です。
+==============================+=======+==========================+
| CBOR Encoding (Hex) | CBOR | Plaintext Part (Hex) |
| | Part | |
| | (Hex) | |
+==============================+=======+==========================+
| 18ED | 18 | ED |
+------------------------------+-------+--------------------------+
| C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF |
+------------------------------+-------+--------------------------+
Table 7: CBOR Plaintext Extraction Examples
表7：CBOR平文抽出例
The ciphertext used during decryption MUST be calculated as the single, definite-length CBOR byte string representing the block-type-specific data field excluding the CBOR byte string identifying byte and optional CBOR byte string length field.
復号化中に使用される暗号文は、CBORバイト文字列を除くブロックタイプ固有のデータフィールドを表す単一の明確な長さのCBOBOBOBORバイト文字列として計算されなければなりません。
All other fields of the security target (such as the block type code, block number, block processing control flags, or any CRC information) MUST NOT be considered as part of encryption or decryption.
セキュリティ対象の他のすべてのフィールド（ブロック型コード、ブロック番号、ブロック処理制御フラグ、またはCRC情報など）は、暗号化または復号化の一部として考慮されてはならない。
The construction of additional authenticated data depends on the AAD scope flags that can be provided as part of customizing the behavior of this security context.
追加の認証データの構築は、このセキュリティコンテキストの動作をカスタマイズする部分として提供できるAADスコープフラグによって異なります。
The canonical form of the AAD input to the BCB-AES-GCM mechanism is constructed using the following process. While the AAD scope flags might not be included in the BCB representing the security operation, they MUST be included in the AAD value itself. This process MUST be followed when generating AAD for either encryption or decryption.
BCB-AES-GCMメカニズムへのAADの標準形式は、以下のプロセスを使用して構築されています。AADスコープフラグはセキュリティ操作を表すBCBに含まれていない可能性がありますが、それらはAAD値自体に含める必要があります。暗号化または復号化のいずれかのAADを生成するときにこのプロセスに従う必要があります。
1. The canonical form of the AAD starts as the CBOR encoding of the AAD scope flags in which all unset flags, reserved bits, and unassigned bits have been set to 0. For example, if the primary block flag, target header flag, and security header flag are each set, then the initial value of the canonical form of the AAD will be 0x07.
1. AADの標準的な形式は、すべての未設定フラグ、予約ビット、および未割り当てビットが0に設定されているAADスコープフラグのCBORエンコーディングとして始まります。たとえば、プライマリブロックフラグ、ターゲットヘッダーフラグ、およびセキュリティヘッダーフラグはそれぞれ設定されているので、AADの正規形の初期値は0x07になります。
2. If the primary block flag of the AAD scope flags is set to 1, then a canonical form of the bundle's primary block MUST be calculated and the result appended to the AAD.
2. AADスコープフラグのプライマリブロックフラグが1に設定されている場合、Canonical Formのバンドルのプライマリブロックを計算し、結果をAADに追加する必要があります。
3. If the target header flag of the AAD scope flags is set to 1, then the canonical form of the block type code, block number, and block processing control flags associated with the security target MUST be calculated and, in that order, appended to the AAD.
3. AADスコープフラグのターゲットヘッダフラグが1に設定されている場合、セキュリティターゲットに関連付けられているブロックタイプコード、ブロック番号、およびブロック処理制御フラグの正規形を計算し、その順序で添付する必要がある。AAD。
4. If the security header flag of the AAD scope flags is set to 1, then the canonical form of the block type code, block number, and block processing control flags associated with the BIB MUST be calculated and, in that order, appended to the AAD.
4. AADスコープフラグのセキュリティヘッダフラグが1に設定されている場合、BIBに関連するブロックタイプコード、ブロック番号、およびブロック処理制御フラグの正規形は、AADに追加されなければならず、その順序で。
During encryption, four data elements are prepared for input to the AES-GCM cipher: the encryption key, the IV, the security target plaintext to be encrypted, and any additional authenticated data. These data items MUST be generated as follows.
暗号化中に、AES-GCM暗号：暗号化される暗号化キー、IV、セキュリティ対象平文、および追加の認証済みデータへの入力用に4つのデータ要素が用意されています。これらのデータ項目は次のように生成されなければなりません。
Prior to encryption, if a CRC value is present for the target block, then that CRC value MUST be removed. This requires removing the CRC field from the target block and setting the CRC type field of the target block to "no CRC is present."
暗号化の前に、CRC値がターゲットブロックに存在する場合、そのCRC値を削除する必要があります。これには、ターゲットブロックからCRCフィールドを削除し、ターゲットブロックのCRCタイプフィールドを "No CRCが存在する"に設定する必要があります。
* The encryption key MUST have the appropriate length as required by local security policy. The key might be generated specifically for this encryption, given as part of local security policy, or obtained through some other key management mechanism as discussed in Section 4.5.
* 暗号化キーは、ローカルセキュリティポリシーによって必要な適切な長さを持たなければなりません。このキーは、ローカルセキュリティポリシーの一部として与えられたこの暗号化のために特に生成されるか、4.5節で説明したように他のいくつかの鍵管理メカニズムを通して取得されるかもしれません。
* The IV selected MUST be of the appropriate length. Because replaying an IV in counter mode voids the confidentiality of all messages encrypted with said IV, this context also requires a unique IV for every encryption performed with the same key. This means the same key and IV combination MUST NOT be used more than once.
* 選択されたIVは適切な長さでなければなりません。CounterモードでIVを再生すると、viodsがvoids voids voids in vidsがvoids a暗号化されたすべてのメッセージの機密性をvoidsにvoidsするため、同じキーで実行される暗号化ごとに一意のIVが必要です。これは、同じキーとIVの組み合わせを複数回使用しないでください。
* The security target plaintext for encryption MUST be generated as discussed in Section 4.7.1.
* 4.7.1項で説明したように、暗号化のためのセキュリティターゲット平文を生成する必要があります。
* Additional authenticated data MUST be generated as discussed in Section 4.7.2, with the value of AAD scope flags being taken from local security policy.
* 4.7.2項で説明されているように、追加の認証データを生成する必要があります.ADスコープフラグの値は、ローカルセキュリティポリシーから取得されます。
Upon successful encryption, the following actions MUST occur.
暗号化が成功すると、次の操作が発生する必要があります。
* The ciphertext produced by AES-GCM MUST replace the bytes used to define the plaintext in the security target block's block-type-specific data field. The block length of the security target MUST be updated if the generated ciphertext is larger than the plaintext (which can occur when the authentication tag is included in the ciphertext calculation, as discussed in Section 4.4).
* AES-GCMによって生成された暗号文は、セキュリティターゲット・ブロックのブロック・タイプ固有のデータ・フィールドに平文を定義するために使用されるバイトを置き換える必要があります。生成された暗号文が平文よりも大きい場合は、セキュリティターゲットのブロック長を更新する必要があります（セクション4.4で説明したように、認証タグがCipherTextの計算に含まれている場合に発生する可能性があります）。
* The authentication tag calculated by the AES-GCM cipher MAY be added as a security result for the security target in the BCB holding results for this security operation, in which case it MUST be processed as described in Section 4.4.
* AES-GCM暗号によって計算された認証タグは、このセキュリティ操作の結果を保持しているBCB保持結果のセキュリティターゲットのセキュリティ結果として追加されてもよく、その場合は4.4節で説明したように処理する必要があります。
* The authentication tag MUST be included either as a security result in the BCB representing the security operation or (with the ciphertext) in the security target block-type-specific data field.
* 認証タグは、セキュリティ操作を表すBCBのセキュリティ結果として、またはセキュリティ対象のブロックタイプ固有のデータフィールドに（暗号文を持つ）のいずれかを含める必要があります。
Finally, the BCB containing information about this security operation MUST be updated as follows. These operations can occur in any order.
最後に、このセキュリティ操作に関する情報を含むBCBは次のように更新されなければなりません。これらの操作は任意の順序で発生する可能性があります。
* The security context identifier for the BCB MUST be set to the context identifier for BCB-AES-GCM.
* BCBのセキュリティコンテキスト識別子は、BCB-AES-GCMのコンテキスト識別子に設定する必要があります。
* The IV input to the cipher MUST be added as the IV security context parameter for the BCB.
* 暗号へのIV入力をBCBのIVセキュリティコンテキストパラメータとして追加する必要があります。
* Any local flags used to generate AAD for this cipher MUST be placed in the AAD scope flags security context parameter for the BCB unless these flags are expected to be correctly configured at security verifiers and security acceptors in the network.
* この暗号のためにAADを生成するために使用されるローカルフラグは、これらのフラグがネットワーク内のセキュリティ検証者およびセキュリティアクセプタで正しく構成されていると予想されない限り、BCBのAAD Scope Flagsセキュリティコンテキストパラメータに配置する必要があります。
* The encryption key MAY be included as a security context parameter, in which case it MUST be wrapped using the AES key wrap function as defined in [RFC3394] and the results of the wrapping added as the wrapped key security context parameter for the BCB.
* 暗号化キーはセキュリティコンテキストパラメータとして含まれていてもよく、その場合は[RFC3394]で定義されているAESキーラップ関数とBCBの折り返しのキーセキュリティコンテキストパラメータとして追加されたAESキーラップ関数を使用してラップする必要があります。
* The AES variant used by this security context SHOULD be added as the AES variant security context parameter for the BCB if it differs from the default key length. Otherwise, this parameter MAY be omitted if doing so provides a useful reduction in message sizes.
* このセキュリティコンテキストで使用されているAESバリアントは、デフォルトのキー長と異なる場合は、BCBのAESバリアントセキュリティコンテキストパラメータとして追加する必要があります。そうでなければ、このパラメータは、メッセージサイズの有用な削減を提供する場合、このパラメータは省略されてもよい。
Problems encountered in the encryption MUST be processed in accordance with local security policy. This MAY include restoring a CRC value removed from the target block prior to encryption, if the target block is allowed to be transmitted after an encryption error.
暗号化で発生した問題は、ローカルセキュリティポリシーに従って処理する必要があります。これは、暗号化の前にターゲットブロックから削除されたCRC値を暗号化エラーの後に送信されることが許可されている場合、ターゲットブロックから削除されたCRC値を復元することを含み得る。
During decryption, five data elements are prepared for input to the AES-GCM cipher: the decryption key, the IV, the security target ciphertext to be decrypted, any additional authenticated data, and the authentication tag generated from the original encryption. These data items MUST be generated as follows.
復号化中に、AES-GCM暗号：復号化キー、IV、セキュリティ対象暗号文、任意の追加の認証データ、および元の暗号化から生成された認証タグへの入力用に5つのデータ要素が用意されています。これらのデータ項目は次のように生成されなければなりません。
* The decryption key MUST be derived using the wrapped key security context parameter if such a parameter is included in the security context parameters of the BCB. Otherwise, this key MUST be derived in accordance with local security policy at the decrypting node as discussed in Section 4.5.
* このようなパラメータがBCBのセキュリティコンテキストパラメータに含まれている場合、復号化キーはラップされたキーセキュリティコンテキストパラメータを使用して派生する必要があります。それ以外の場合は、セクション4.5で説明したように、復号化ノードのローカルセキュリティポリシーに従って派生する必要があります。
* The IV MUST be set to the value of the IV security context parameter included in the BCB. If the IV parameter is not included as a security context parameter, an IV MAY be derived as a function of local security policy and other BCB contents, or a lack of an IV security context parameter in the BCB MAY be treated as an error by the decrypting node.
* IVは、BCBに含まれるIVセキュリティコンテキストパラメータの値に設定する必要があります。IVパラメータがセキュリティコンテキストパラメータとして含まれていない場合、IVはローカルセキュリティポリシーおよび他のBCBコンテンツの関数として導出されてもよく、またはBCB内のIVセキュリティコンテキストパラメータの欠如がエラーとして扱われてもよい。復号化ノード。
* The security target ciphertext for decryption MUST be generated as discussed in Section 4.7.1.
* 復号化のためのセキュリティターゲット暗号文は、4.7.1項で説明されているように生成されなければなりません。
* Additional authenticated data MUST be generated as discussed in Section 4.7.2 with the value of AAD scope flags being taken from the AAD scope flags security context parameter. If the AAD scope flags parameter is not included in the security context parameters, then these flags MAY be derived from local security policy in cases where the set of such flags is determinable in the network.
* AADスコープフラグから取得されているAADスコープフラグの値は、4.7.2項で説明されているように、追加の認証データを生成する必要があります。AADスコープフラグパラメータがセキュリティコンテキストパラメータに含まれていない場合、これらのフラグは、そのようなフラグのセットがネットワーク内で決定可能である場合には、ローカルセキュリティポリシーから派生することができる。
* The authentication tag MUST be present either as a security result in the BCB representing the security operation or (with the ciphertext) in the security target block-type-specific data field.
* 認証タグは、セキュリティ操作を表すBCBのセキュリティ結果として、またはセキュリティ対象のブロックタイプ固有のデータフィールドの（暗号文で）存在する必要があります。
Upon successful decryption, the following action MUST occur.
復号化が成功すると、次の操作が発生しなければなりません。
* The plaintext produced by AES-GCM MUST replace the bytes used to define the ciphertext in the security target block's block-type-specific data field. Any changes to the security target block length field MUST be corrected in cases where the plaintext has a different length than the replaced ciphertext.
* AES-GCMによって作成された平文は、セキュリティターゲットブロックのブロックタイプ固有のデータフィールドに暗号文を定義するために使用されるバイトを置き換える必要があります。[セキュリティターゲットブロック長]フィールドの変更は、平文が置き換えられた暗号文とは異なる長さを持つ場合に修正する必要があります。
If the security acceptor is not the bundle destination and if no other integrity or confidentiality service is being applied to the target block, then a CRC MUST be included for the target block. The CRC type, as determined by policy, is set in the target block's CRC type field and the corresponding CRC value is added as the CRC field for that block.
セキュリティアクセプタがバンドル宛先ではなく、他の整合性または機密保持サービスがターゲットブロックに適用されていない場合は、ターゲットブロックにCRCを含める必要があります。ポリシーによって決定されたCRCタイプは、ターゲットブロックのCRCタイプフィールドに設定され、対応するCRC値がそのブロックのCRCフィールドとして追加されます。
If the ciphertext fails to authenticate, if any needed parameters are missing, or if there are other problems in the decryption, then the decryption MUST be treated as failed and processed in accordance with local security policy.
暗号文が認証に失敗した場合、必要なパラメータが欠落している場合、または復号化に他の問題がある場合は、復号化はローカルセキュリティポリシーに従って失敗して処理される必要があります。
This specification allocates two security context identifiers from the "BPSec Security Context Identifiers" registry defined in [RFC9172].
この仕様は、[RFC9172]で定義されている「BPSecセキュリティコンテキスト識別子」レジストリから2つのセキュリティコンテキスト識別子を割り当てます。
+=======+===============+===========+
| Value | Description | Reference |
+=======+===============+===========+
| 1 | BIB-HMAC-SHA2 | RFC 9173 |
+-------+---------------+-----------+
| 2 | BCB-AES-GCM | RFC 9173 |
+-------+---------------+-----------+
Table 8: Additional Entries for the BPSec Security Context Identifiers Registry
表8：BPSecセキュリティコンテキスト識別子レジストリの追加エントリ
The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field for which IANA has created and now maintains a new registry named "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the "Bundle Protocol" registry page. Table 9 shows the initial values for this registry.
Bib-HMAC-SHA2セキュリティコンテキストには、IANAが作成したIntegrityスコープフラグフィールドがあり、「バンドルプロトコル」レジストリページで「BPSEC BIB-HMAC-SHA2 Integrityスコープフラグ」という名前の新しいレジストリを維持します。表9に、このレジストリの初期値を示します。
The registration policy for this registry is Specification Required [RFC8126].
このレジストリの登録ポリシーは指定されています[RFC8126]。
The value range is unsigned 16-bit integer.
値の範囲は符号なし16ビット整数です。
+==============================+==================+===========+
| Bit Position (right to left) | Description | Reference |
+==============================+==================+===========+
| 0 | Include primary | RFC 9173 |
| | block flag | |
+------------------------------+------------------+-----------+
| 1 | Include target | RFC 9173 |
| | header flag | |
+------------------------------+------------------+-----------+
| 2 | Include security | RFC 9173 |
| | header flag | |
+------------------------------+------------------+-----------+
| 3-7 | Reserved | RFC 9173 |
+------------------------------+------------------+-----------+
| 8-15 | Unassigned | |
+------------------------------+------------------+-----------+
Table 9: BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry
表9：BPSEC BIB-HMAC-SHA2 Integrityスコープフラグレジストリ
The BCB-AES-GCM security context has an AAD Scope Flags field for which IANA has created and now maintains a new registry named "BPSec BCB-AES-GCM AAD Scope Flags" on the "Bundle Protocol" registry page. Table 10 shows the initial values for this registry.
BCB-AES-GCMセキュリティコンテキストには、IANAが作成したAADスコープフラグフィールドがあり、「バンドルプロトコル」レジストリページで「BPSEC BCB-AES-GCM AADスコープフラグ」という名前の新しいレジストリを管理しています。表10は、このレジストリの初期値を示しています。
The registration policy for this registry is Specification Required.
このレジストリの登録ポリシーは指定されています。
The value range is unsigned 16-bit integer.
値の範囲は符号なし16ビット整数です。
+==============================+==================+===========+
| Bit Position (right to left) | Description | Reference |
+==============================+==================+===========+
| 0 | Include primary | RFC 9173 |
| | block flag | |
+------------------------------+------------------+-----------+
| 1 | Include target | RFC 9173 |
| | header flag | |
+------------------------------+------------------+-----------+
| 2 | Include security | RFC 9173 |
| | header flag | |
+------------------------------+------------------+-----------+
| 3-7 | Reserved | RFC 9173 |
+------------------------------+------------------+-----------+
| 8-15 | Unassigned | |
+------------------------------+------------------+-----------+
Table 10: BPSec BCB-AES-GCM AAD Scope Flags Registry
表10：BPSEC BCB-AES-GCM AADスコープフラグレジストリ
New assignments within the "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" and "BPSec BCB-AES-GCM AAD Scope Flags" registries require review by a Designated Expert (DE). This section provides guidance to the DE when performing their reviews. Specifically, a DE is expected to perform the following activities.
「BPSEC BIB-HMAC-SHA2 Integrityスコープフラグ」および「BPSEC BCB-AES-GCM AADスコープフラグ」内の新規割り当ては、指定された専門家（DE）によるレビューを必要とします。このセクションでは、レビューを実行するときのDEへのガイダンスについて説明します。具体的には、DEは以下の活動を実行する予定です。
* Ascertain the existence of suitable documentation (a specification) as described in [RFC8126] and verify that the document is permanently and publicly available.
* [RFC8126]に記載されている適切なドキュメント（仕様）の存在を確認し、その文書が恒久的かつ公に利用可能であることを確認します。
* Ensure that any changes to the "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" registry clearly state how new assignments interact with existing flags and how the inclusion of new assignments affects the construction of the IPPT value.
* 「BPSEC BIB-HMAC-SHA2 Integrity Scope Flags」レジストリの変更が、新しい割り当てが既存のフラグと対話する方法、および新しい割り当てのIPPT値の構築にどのように影響するかを明確に示してください。
* Ensure that any changes to the "BPSec BCB-AES-GCM AAD Scope Flags" registry clearly state how new assignments interact with existing flags and how the inclusion of new assignments affects the construction of the AAD input to the BCB-AES-GCM mechanism.
* 「BPSEC BCB-AES-GCM AADスコープフラグ」の変更が、新しい割り当てが既存のフラグと対話する方法と新しい割り当ての含有がBCB-AES-GCMメカニズムへのAAD入力の構築にどのように影響するかを明確に述べていることを確認してください。
* Ensure that any processing changes proposed with new assignments do not alter any required behavior in this specification.
* 新しい割り当てで提案されている処理変更が、この仕様で必要な動作を変更しないことを確認してください。
Security considerations specific to a single security context are provided in the description of that context (see Sections 3 and 4). This section discusses security considerations that should be evaluated by implementers of any security context described in this document. Considerations can also be found in documents listed as normative references and should also be reviewed by security context implementors.
単一のセキュリティコンテキストに固有のセキュリティ上の考慮事項は、そのコンテキストの説明に記載されています（セクション3と4を参照）。このセクションでは、このドキュメントに記載されているセキュリティコンテキストの実装者によって評価されるべきセキュリティ上の考慮事項について説明します。実際の参照として記載されている文書には、セキュリティコンテキストの実装者によっても確認できます。
The delayed and disrupted nature of Delay-Tolerant Networking (DTN) complicates the process of key management because there might not be reliable, timely, round-trip exchange between security sources, security verifiers, and security acceptors in the network. This is true when there is a substantial signal propagation delay between nodes, when nodes are in a highly challenged communications environment, and when nodes do not support bidirectional communication.
遅延耐性ネットワーキング（DTN）の遅延および中断された性質は、ネットワーク内のセキュリティソース、セキュリティ検証者、およびセキュリティアクセプタ間の信頼性があり、タイムリーに、往復交換がない可能性があるため、鍵管理のプロセスを複雑にします。ノード間でノード間に実質的な信号伝播遅延がある場合、ノードが非常に困難な通信環境にある場合、およびノードが双方向通信をサポートしていない場合に当てはまります。
In these environments, key establishment protocols that rely on round-trip information exchange might not converge on a shared secret in a timely manner (or at all). Also, key revocation or key verification mechanisms that rely on access to a centralized authority (such as a certificate authority) might similarly fail in the stressing conditions of DTN.
これらの環境では、往復情報交換に依存する主要な確立プロトコルは、タイムリーな方法で共有秘密に収束しない可能性があります（またはまったく）。また、集中権限（認証局など）にアクセスすることに依存する鍵の失効または鍵検証メカニズムも同様にDTNのストレス条件で失敗する可能性があります。
For these reasons, the default security contexts described in this document rely on symmetric-key cryptographic mechanisms because asymmetric-key infrastructure (such as a public key infrastructure) might be impractical in this environment.
これらの理由から、この文書で説明されているデフォルトのセキュリティコンテキストは、非対称キーインフラストラクチャ（公開鍵インフラストラクチャなど）がこの環境では実用的ではない可能性があるため、対称鍵暗号化メカニズムに依存しています。
BPSec assumes that "key management is handled as a separate part of network management" [RFC9172]. This assumption is also made by the security contexts defined in this document, which do not define new protocols for key derivation, exchange of KEKs, revocation of existing keys, or the security configuration or policy used to select certain keys for certain security operations.
BPSECは、「キー管理はネットワーク管理の別の部分として扱われる」[RFC9172]を想定しています。この仮定は、この文書で定義されているセキュリティコンテキストによっても行われます。このドキュメントで定義されているセキュリティコンテキストは、鍵の導出、KEKの交換、特定のセキュリティ操作の特定のキーの選択に使用されるセキュリティ構成またはポリシーの新しいプロトコルを定義します。
Nodes using these security contexts need to perform the following kinds of activities, independent of the construction, transmission, and processing of BPSec security blocks.
これらのセキュリティコンテキストを使用するノードは、BPSECセキュリティブロックの構築、送信、および処理とは無関係に、以下の種類の活動を実行する必要があります。
* Establish shared KEKs with other nodes in the network using an out-of-band mechanism. This might include pre-sharing of KEKs or the use of older key establishment mechanisms prior to the exchange of BPSec security blocks.
* 帯域外のメカニズムを使用して、ネットワーク内の他のノードと共有KEKを確立します。これには、BPSECセキュリティブロックの交換前のKEKの事前共有または古い鍵確立メカニズムの使用が含まれる場合があります。
* Determine when a key is considered exhausted and no longer to be used in the generation, verification, or acceptance of a security block.
* キーが、セキュリティブロックの生成、検証、または受け入れに使用されなくなり、もう使用されなくなりました。
* Determine when a key is considered invalid and no longer to be used in the generation, verification, or acceptance of a security block. Such revocations can be based on a variety of mechanisms, including local security policy, time relative to the generation or use of the key, or other mechanisms specified through network management.
* セキュリティブロックの生成、検証、または受け入れに使用されるように、キーが無効と考慮され、もう使用されることができなくなります。そのような回避は、ローカルセキュリティポリシー、鍵の生成または使用に対する時間、またはネットワーク管理によって指定されたその他のメカニズムを含むさまざまなメカニズムに基づくことができます。
* Determine, through an out-of-band mechanism such as local security policy, what keys are to be used for what security blocks. This includes the selection of which key should be used in the evaluation of a security block received by a security verifier or a security acceptor.
* ローカルセキュリティポリシーなどのアウトオブバンドメカニズムを通じて、どのキーを使用するかをセキュリティブロックに使用することを決定します。これには、セキュリティ検証者またはセキュリティアクセプタによって受信されたセキュリティブロックの評価にどのキーを使用する必要があるかを含む。
The failure to provide effective key management techniques appropriate for the operational networking environment can result in the compromise of those unmanaged keys and the loss of security services in the network.
オペレーショナルネットワーキング環境に適した効果的な鍵管理技術を提供しなかった場合、それらの管理されていない鍵とネットワーク内のセキュリティサービスの喪失が損なわれる可能性があります。
Once generated, keys should be handled as follows.
発生したら、キーは次のように処理されます。
* It is strongly RECOMMENDED that implementations protect keys both when they are stored and when they are transmitted.
* 実装は、それらが保存されているときとそれらが送信されたときにキーを保護することを強くお勧めします。
* In the event that a key is compromised, any security operations using a security context associated with that key SHOULD also be considered compromised. This means that the BIB-HMAC-SHA2 security context SHOULD NOT be treated as providing integrity when used with a compromised key, and BCB-AES-GCM SHOULD NOT be treated as providing confidentiality when used with a compromised key.
* キーが侵害された場合、そのキーに関連するセキュリティコンテキストを使用したセキュリティ操作も侵害されるべきであると見なされるべきである。つまり、BIB-HMAC-SHA2セキュリティコンテキストは、侵入先のキーで使用されたときに整合性を提供するものとして扱われるべきではなく、BCB-AES-GCMは侵入先のキーとともに使用されたときに機密性を提供するものとして扱われるべきではありません。
* The same key, whether a KEK or a wrapped key, MUST NOT be used for different algorithms as doing so might leak information about the key.
* KEKまたはラップされたキーが同じキーであろうと、キーに関する情報を漏洩する可能性があるため、KEKまたはラップされたキーを使用しないでください。
* A KEK MUST NOT be used to encrypt keys for different security contexts. Any KEK used by a security context defined in this document MUST only be used to wrap keys associated with security operations using that security context. This means that a compliant security source would not use the same KEK to wrap keys for both the BIB-HMAC-SHA2 and BCB-AES-GCM security contexts. Similarly, any compliant security verifier or security acceptor would not use the same KEK to unwrap keys for different security contexts.
* さまざまなセキュリティコンテキストのキーを暗号化するためにKEKを使用しないでください。このドキュメントで定義されているセキュリティコンテキストで使用されている任意の任意の任意の任意のセキュリティコンテキストを使用して、セキュリティ操作に関連付けられているキーをラップするためにのみ使用する必要があります。つまり、準拠セキュリティソースは、BIB-HMAC-SHA2とBCB-AES-GCMセキュリティコンテキストの両方にキーをラップするために同じKEKを使用しないことを意味します。同様に、準拠セキュリティ検証者またはセキュリティアクセプターは、異なるセキュリティコンテキストのためにキーを押し抜くために同じKEKを使用しないであろう。
There are a significant number of considerations related to the use of the GCM mode of AES to provide a confidentiality service. These considerations are provided in Section 4.6 as part of the documentation of the BCB-AES-GCM security context.
機密保持サービスを提供するためのAESのGCMモードの使用に関連するかなりの数の考慮事項があります。これらの考慮事項は、BCB-AES-GCMセキュリティコンテキストの文書の一部としてセクション4.6で提供されています。
The length of the ciphertext produced by the GCM mode of AES will be equal to the length of the plaintext input to the cipher suite. The authentication tag also produced by this cipher suite is separate from the ciphertext. However, it should be noted that implementations of the AES-GCM cipher suite might not separate the concept of ciphertext and authentication tag in their Application Programming Interface (API).
AESのGCMモードによって生成された暗号文の長さは、暗号スイートへの平文入力の長さに等しくなります。この暗号スイートによっても生成された認証タグは、暗号文とは別のものです。ただし、AES-GCM暗号スイートの実装は、それらのアプリケーションプログラミングインタフェース（API）に暗号文と認証タグの概念を分離しない可能性があることに注意してください。
Implementations of the BCB-AES-GCM security context can either keep the length of the target block unchanged by holding the authentication tag in a BCB security result or alter the length of the target block by including the authentication tag with the ciphertext replacing the block-type-specific data field of the target block. Implementations MAY use the authentication tag security result in cases where keeping target block length unchanged is an important processing concern. In all cases, the ciphertext and authentication tag MUST be processed in accordance with the API of the AES-GCM cipher suites at the security source and security acceptor.
BCB-AES-GCMセキュリティコンテキストの実装は、BCBセキュリティ結果の認証タグを保持することによってターゲットブロックの長さを変更しないか、または認証タグをブロックの置き換えの暗号化タグを含めることによってターゲットブロックの長さを変更することができます。ターゲットブロックのタイプ固有のデータフィールド。実装は、ターゲットブロック長が変更されずに重要な処理に関する問題がある場合に、認証タグのセキュリティ結果を使用することができます。すべての場合において、暗号文および認証タグは、セキュリティソースおよびセキュリティアクセプタのAES-GCM暗号スイートのAPIに従って処理されなければなりません。
The AES-KW algorithm used by the security contexts in this document does not use a per-invocation initialization vector and does not require any key padding. Key padding is not needed because wrapped keys used by these security contexts will always be multiples of 8 bytes. The length of the wrapped key can be determined by inspecting the security context parameters. Therefore, a key can be unwrapped using only the information present in the security block and the KEK provided by local security policy at the security verifier or security acceptor.
この文書のセキュリティコンテキストによって使用されるAES-kWアルゴリズムは、呼び出しごとの初期化ベクトルを使用しておらず、キーパディングを必要としません。これらのセキュリティコンテキストによって使用されるラップされたキーが常に8バイトの倍数になるため、キーパディングは必要ありません。ラップされたキーの長さは、セキュリティコンテキストパラメータを検査することによって決定できます。したがって、セキュリティ検証者またはセキュリティアクセサリでローカルセキュリティポリシーによって提供される情報のみを使用して、キーを開くことができます。
Bundle fragmentation might prevent security services in a bundle from being verified after a bundle is fragmented and before the bundle is re-assembled. Examples of potential issues include the following.
バンドルの断片化は、バンドルが断片化され、バンドルが再組み立てられる前にバンドル内のセキュリティサービスが検証されないようにする可能性があります。潜在的な問題の例には、以下が含まれます。
* If a security block and its security target do not exist in the same fragment, then the security block cannot be processed until the bundle is re-assembled. If a fragment includes an encrypted target block, but not its BCB, then a receiving Bundle Protocol Agent (BPA) will not know that the target block has been encrypted.
* セキュリティブロックとそのセキュリティターゲットが同じフラグメントに存在しない場合、バンドルが再組み立てられるまでセキュリティブロックを処理することはできません。フラグメントに暗号化されたターゲットブロックが含まれているが、そのBCBは含まれていない場合、受信バンドルプロトコルエージェント（BPA）はターゲットブロックが暗号化されていることを知りません。
* A security block can be cryptographically bound to a bundle by setting the integrity scope flags (for BIB-HMAC-SHA2) or the AAD scope flags (for BCB-AES-GCM) to include the bundle primary block. When a security block is cryptographically bound to a bundle, it cannot be processed even if the security block and target both coexist in the fragment. This is because fragments have different primary blocks than the original bundle.
* バンドルプライマリブロックを含めるために、セキュリティブロック（BIB-HMAC-SHA2用）またはAADスコープフラグ（BCB-AES-GCM用）を設定することで、バンドルに暗号的にバインドすることができます。セキュリティブロックがバンドルに暗号的にバインドされている場合は、セキュリティブロックとターゲットの両方がフラグメント内で共存する場合でも処理できません。これは、フラグメントが元のバンドルよりも異なるプライマリブロックを持つためです。
* If security blocks and their target blocks are repeated in multiple fragments, policy needs to determine how to deal with issues where a security operation verifies in one fragment but fails in another fragment. This might happen, for example, if a BIB block becomes corrupted in one fragment but not in another fragment.
* セキュリティブロックとそのターゲットブロックが複数のフラグメントで繰り返される場合、ポリシーは、セキュリティ操作が1つのフラグメントで検証されているが別のフラグメントで失敗する問題に対処する方法を決定する必要があります。これは、たとえば、BIBブロックが1つのフラグメントで破損しているが別の断片ではない場合に発生する可能性があります。
Implementors should consider how security blocks are processed when a BPA fragments a received bundle. For example, security blocks and their targets could be placed in the same fragment if the security block is not otherwise cryptographically bound to the bundle being fragmented. Alternatively, if security blocks are cryptographically bound to a bundle, then a fragmenting BPA should consider encapsulating the bundle first and then fragmenting the encapsulating bundle.
BPAフラグメントが受信したバンドルのときにセキュリティブロックがどのように処理されるかを実装者に検討する必要があります。たとえば、セキュリティブロックが断片化されているバンドルに非暗号的にバインドされていない場合は、セキュリティブロックとそのターゲットを同じフラグメントに配置できます。あるいは、セキュリティブロックがバンドルに暗号的にバインドされている場合、フラグメント化BPAは最初にバンドルをカプセル化してからカプセル化バンドルを断片化することを検討する必要があります。
[AES-GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, <https://doi.org/10.6028/NIST.SP.800-38D>.
[AES-GCM] DWIRING、M。、「ブロック暗号化モードのための推奨事項：ガロア/カウンタモード（GCM）およびGMAC」、NIST特別出版物800-38D、DOI 10.6028 / NIST.SP.800-38D、2007年11月、<https：//doi.org/10.6028/nist.sp.800-38d>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Belleare、M.、およびR. Canetti、 "HMAC：メッセージ認証のための鍵付きハッシング"、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-編集者.org / info / rfc2104>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[RFC3394] Schaad、J.およびR. Housley、 "Advanced Encryption Standard（AES）キーラップアルゴリズム"、RFC 3394、DOI 10.17487 / RFC3394、2002年9月、<https：//www.rfc-editor.org/info/RFC3394>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.
[RFC8152] Schaad、J.、 "CBORオブジェクトの署名と暗号化（CORE）"、RFC 8152、DOI 10.17487 / RFC8152、2017年7月、<https://www.rfc-editor.org/info/rfc8152>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, <https://www.rfc-editor.org/info/rfc8742>.
[RFC8742] Bormann、C.、「CBOR）シーケンス」、RFC 8742、DOI 10.17487 / RFC8742、2020年2月、<https：//www.rfc-editor.org/info/rfc8742>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.
[RFC9171] Burleigh、S、Fall、K.、およびE.Birrane、III、「バンドルプロトコルバージョン7」、RFC 9171、DOI 10.17487 / RFC9171、2022年1月、<https：//www.rfc-editor.org/ RFC / RFC9171>。
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, <https://www.rfc-editor.org/rfc/rfc9172>.
[RFC9172] Birrane、III、E.およびK。マッキーバー、「バンドルプロトコルセキュリティ（BPSEC）」、RFC 9172、DOI 10.17487 / RFC9172、2022年1月、<https：//www.rfc-editor.org/rfc/rfc9172>。
[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/ final>.
[SHS]国立標準技術研究所、「安全なハッシュスタンダード（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<https：//csrc.nist.gov/出版物/詳細/ FIPS / 180/4 /最終>。
This appendix is informative.
この付録は有益です。
This appendix presents a series of examples of constructing BPSec security blocks (using the security contexts defined in this document) and adding those blocks to a sample bundle.
この付録では、BPSECセキュリティブロックを構築し（この文書で定義されているセキュリティコンテキストを使用して）、サンプルバンドルにそれらのブロックを追加する一連の例を示します。
The examples presented in this appendix represent valid constructions of bundles, security blocks, and the encoding of security context parameters and results. For this reason, they can inform unit test suites for individual implementations as well as interoperability test suites amongst implementations. However, these examples do not cover every permutation of security context parameters, security results, or use of security blocks in a bundle.
この付録に記載されている例は、バンドル、セキュリティブロック、およびセキュリティコンテキストパラメータのエンコードの有効な構成と結果を表します。このため、実装の中で個々の実装と相互運用性テストスイートのためのユニットテストスイートに通知することができます。ただし、これらの例では、セキュリティコンテキストパラメータ、セキュリティ結果、またはバンドル内のセキュリティブロックの使用のすべての置換をカバーしていません。
NOTES:
ノート：
* The bundle diagrams in this appendix are patterned after the bundle diagrams used in Section 3.11 ("BPSec Block Examples") of [RFC9172].
* この付録のバンドル図は、[RFC9172]のセクション3.11（「BPSecブロック例」）で使用したバンドル図の後にパターン化されています。
* Figures in this appendix identified as "(CBOR Diagnostic Notation)" are represented using the CBOR diagnostic notation defined in [RFC8949]. This notation is used to express CBOR data structures in a manner that enables visual inspection. The bundles, security blocks, and security context contents in these figures are represented using CBOR structures. In cases where BP blocks (to include BPSec security blocks) are comprised of a sequence of CBOR objects, these objects are represented as a CBOR sequence as defined in [RFC8742].
* 「（CBOR診断表記）」として識別されるこの付録の数値は、[RFC8949]で定義されているCBOR診断表記を使用して表されます。この表記法は、目視検査を可能にする方法でCBORデータ構造を表現するために使用されます。これらの図のバンドル、セキュリティブロック、およびセキュリティコンテキストの内容は、CBOR構造を使用して表されます。BPブロック（BPSECセキュリティブロックを含む）がCBOBORオブジェクトのシーケンスで構成されている場合、これらのオブジェクトは[RFC8742]で定義されているCBORシーケンスとして表されます。
* Examples in this appendix use the "ipn" URI scheme for endpoint ID naming, as defined in [RFC9171].
* この付録の例[RFC9171]で定義されているエンドポイントIDネーミングの「IPN」URI方式を使用します。
* The bundle source is presumed to be the security source for all security blocks in this appendix, unless otherwise noted.
* 特に断りのない限り、バンドルソースは、この付録のすべてのセキュリティブロックのセキュリティソースと推定されます。
This example shows the addition of a BIB to a sample bundle to provide integrity for the payload block.
この例は、ペイロードブロックの整合性を提供するためのサンプルバンドルへのBIBの追加を示しています。
The following diagram shows the original bundle before the BIB has been added.
次の図は、BIBが追加される前の元のバンドルを示しています。
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+
Figure 1: Example 1 - Original Bundle
図1：例1 - 元のバンドル
The Bundle Protocol version 7 (BPv7) bundle has no special block and bundle processing control flags, and no CRC is provided because the primary block is expected to be protected by an integrity service BIB using the BIB-HMAC-SHA2 security context.
バンドルプロトコルバンド7（BPV7）バンドルには特別なブロックとバンドル処理制御フラグがありません。プライマリブロックはBib-HMAC-SHA2セキュリティコンテキストを使用してIntegrity Service Bibによって保護されることが予想されるため、CRCは提供されません。
The bundle is sourced at the source node ipn:2.1 and destined for the destination node ipn:1.2. The bundle creation time is set to 0, indicating lack of an accurate clock, with a sequence number of 40. The lifetime of the bundle is given as 1,000,000 milliseconds since the bundle creation time.
バンドルは、ソースノードIPn：2.1でソースされ、宛先ノードIPN：1.2に宛先されます。バンドル作成時刻は0に設定され、シーケンス番号40の正確なクロックがないことを示しています。バンドルの寿命は、バンドル作成時間以降、1,000,000ミリ秒として与えられます。
The primary block is provided as follows.
プライマリブロックは以下のように提供される。
[
7, / BP version /
0, / flags /
0, / CRC type /
[2, [1,2]], / destination (ipn:1.2) /
[2, [2,1]], / source (ipn:2.1) /
[2, [2,1]], / report-to (ipn:2.1) /
[0, 40], / timestamp /
1000000 / lifetime /
]
Figure 2: Primary Block (CBOR Diagnostic Notation)
図2：プライマリブロック（CBOR診断表記）
The CBOR encoding of the primary block is:
プライマリブロックのCBORエンコードは次のとおりです。
0x88070000820282010282028202018202820201820018281a000f4240
Other than its use as a source of plaintext for security blocks, the payload has no required distinguishing characteristic for the purpose of this example. The sample payload is a 35-byte string.
セキュリティブロックの平文の原因としての使用以外のペイロードは、この例の目的のために必要な際立った特性を持たない。サンプルペイロードは35バイトの文字列です。
The payload is represented in the payload block as a byte string of the raw payload string. It is NOT represented as a CBOR text string wrapped within a CBOR binary string. The hex value of the payload is:
ペイロードは、RAWペイロード文字列のバイト文字列としてペイロードブロックに表されます。CBOBボタンのバイナリ文字列内に折り返されたCBORテキスト文字列としては表されていません。ペイロードの16進数は次のとおりです。
0x526561647920746f2067656e657261746520612033322d62797465207061796c6f 6164
6164を占める
The payload block is provided as follows.
ペイロードブロックは次のように提供されます。
[
1, / type code: Payload block /
1, / block number /
0, / block processing control flags /
0, / CRC type /
h'526561647920746f206765 / type-specific-data: payload /
6e657261746520612033322d
62797465207061796c6f6164'
]
Figure 3: Payload Block (CBOR Diagnostic Notation)
図3：ペイロードブロック（CBOR診断表記）
The CBOR encoding of the payload block is:
ペイロードブロックのCBORエンコードは次のとおりです。
0x85010100005823526561647920746f2067656e657261746520612033322d627974 65207061796c6f6164
6520706179606120333222D62797465265617606120333222D62792074656179720333222D62792352656647920333222D627923526561797465265617974652656647920333222D62797465265617974 652070617974F6164.
A BPv7 bundle is represented as an indefinite-length array consisting of the blocks comprising the bundle, with a terminator character at the end.
BPV7バンドルは、最後にターミネータ文字を備えた、バンドルを含むブロックからなる不定長の配列として表されます。
The CBOR encoding of the original bundle is:
元のバンドルのCBORエンコードは次のとおりです。
0x9f88070000820282010282028202018202820201820018281a000f424085010100 005823526561647920746f2067656e657261746520612033322d6279746520706179 6c6f6164ff
This example adds a BIB to the bundle using the BIB-HMAC-SHA2 security context to provide an integrity mechanism over the payload block.
この例では、Bib-HMAC-SHA2セキュリティコンテキストを使用してBUNDLEにBIBを追加して、ペイロードブロックを介して完全性メカニズムを提供します。
The following diagram shows the resulting bundle after the BIB is added.
次の図は、BIBが追加された後の結果のバンドルを示しています。
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Block Integrity Block | 11 | 2 |
| OP(bib-integrity, target=1) | | |
+----------------------------------------+-------+--------+
| Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+
Figure 4: Example 1 - Resulting Bundle
図4：例1 - 結果として得られるバンドル
In this example, a BIB is used to carry an integrity signature over the payload block.
この例では、ペイロードブロックの上に完全性シグネチャを伝送するためにBIBが使用されます。
For this example, the following configuration and security context parameters are used to generate the security results indicated.
この例では、次の設定とセキュリティコンテキストパラメータを使用して、表示されたセキュリティ結果を生成します。
This BIB has a single target and includes a single security result: the calculated signature over the payload block.
このBIBには単一のターゲットがあり、単一のセキュリティ結果が含まれています。ペイロードブロック上の計算署名。
Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant : HMAC 512/512 Scope Flags : 0x00 Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' IPPT : h'005823526561647920746f2067656e65 7261746520612033322d627974652070 61796c6f6164' Signature : h'3bdc69b3a34a2b5d3a8554368bd1e808 f606219d2a10a846eae3886ae4ecc83c 4ee550fdfb1cc636b904e2f1a73e303d cd4b6ccece003e95e8164dcc89a156e1'
Figure 5: Example 1 - Configuration, Parameters, and Results
図5：例1 - 構成、パラメータ、および結果
The abstract security block structure of the BIB's block-type-specific data field for this application is as follows.
このアプリケーションのBIBのブロック型固有データフィールドの抽象セキュリティブロック構造は次のとおりです。
[1], / Security Target - Payload block /
1, / Security Context ID - BIB-HMAC-SHA2 /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 2 Parameters /
[1, 7], / SHA Variant - HMAC 512/512 /
[3, 0x00] / Scope Flags - No Additional Scope /
],
[ / Security Results: 1 Result /
[ / Target 1 Results /
[1, h'3bdc69b3a34a2b5d3a8554368bd1e808 / MAC /
f606219d2a10a846eae3886ae4ecc83c
4ee550fdfb1cc636b904e2f1a73e303d
cd4b6ccece003e95e8164dcc89a156e1']
]
]
Figure 6: Example 1 - BIB Abstract Security Block (CBOR Diagnostic Notation)
図6：例1 - BIB抽象セキュリティブロック（CBOR診断表記）
The CBOR encoding of the BIB block-type-specific data field (the abstract security block) is:
BIBブロック型固有データフィールド（抽象セキュリティブロック）のCBORエンコードは次のとおりです。
0x810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a8554
368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2f1a7
3e303dcd4b6ccece003e95e8164dcc89a156e1
The complete BIB is as follows.
完全なBIBは以下の通りです。
[ 11, / type code / 2, / block number / 0, / flags / 0, / CRC type / h'810101018202820201828201078203008181820158403bdc69b3a34a 2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550 fdfb1cc636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1' ]
Figure 7: Example 1 - BIB (CBOR Diagnostic Notation)
図7：例1 - BIB（CBOR診断表記）
The CBOR encoding of the BIB block is:
BIBブロックのCBORエンコードは次のとおりです。
0x850b0200005856810101018202820201828201078203008181820158403bdc69b3
a34a2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1c
c636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1
The CBOR encoding of the full output bundle, with the BIB:
BIBを使用した、フル出力バンドルのCBORエンコード
0x9f88070000820282010282028202018202820201820018281a000f4240850b0200
005856810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a
8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2
f1a73e303dcd4b6ccece003e95e8164dcc89a156e185010100005823526561647920
746f2067656e657261746520612033322d62797465207061796c6f6164ff
This example shows the addition of a BCB to a sample bundle to provide confidentiality for the payload block. AES key wrap is used to transmit the symmetric key used to generate the security results for this service.
この例は、ペイロードブロックの機密性を提供するためのサンプルバンドルへのBCBの追加を示しています。AESキーラップは、このサービスのセキュリティ結果を生成するために使用される対称鍵を送信するために使用されます。
The following diagram shows the original bundle before the BCB has been added.
次の図は、BCBが追加される前の元のバンドルを示しています。
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+
Figure 8: Example 2 - Original Bundle
図8：例2 - 元のバンドル
The primary block used in this example is identical to the primary block presented for Example 1 in Appendix A.1.1.1.
この例で使用されているプライマリブロックは、付録A.1.1.1では例1に提示された1次ブロックと同じです。
In summary, the CBOR encoding of the primary block is:
要約すると、プライマリブロックのCBORエンコーディングは次のとおりです。
0x88070000820282010282028202018202820201820018281a000f4240
The payload block used in this example is identical to the payload block presented for Example 1 in Appendix A.1.1.2.
この例で使用されているペイロードブロックは、付録A.1.1.2では、実施例1に提示されたペイロードブロックと同じである。
In summary, the CBOR encoding of the payload block is:
要約すると、ペイロードブロックのCBORエンコーディングは次のとおりです。
0x85010100005823526561647920746f2067656e657261746520612033322d627974 65207061796c6f6164
6520706179606120333222D62797465265617606120333222D62792074656179720333222D62792352656647920333222D627923526561797465265617974652656647920333222D62797465265617974 652070617974F6164.
A BPv7 bundle is represented as an indefinite-length array consisting of the blocks comprising the bundle, with a terminator character at the end.
BPV7バンドルは、最後にターミネータ文字を備えた、バンドルを含むブロックからなる不定長の配列として表されます。
The CBOR encoding of the original bundle is:
元のバンドルのCBORエンコードは次のとおりです。
0x9f88070000820282010282028202018202820201820018281a000f424085010100 005823526561647920746f2067656e657261746520612033322d6279746520706179 6c6f6164ff
This example adds a BCB using the BCB-AES-GCM security context using AES key wrap to provide a confidentiality mechanism over the payload block and transmit the symmetric key.
この例では、AESキーラップを使用してBCB-AES-GCMセキュリティコンテキストを使用してBCBを追加し、ペイロードブロックを介して機密性メカニズムを提供し、対称鍵を送信します。
The following diagram shows the resulting bundle after the BCB is added.
次の図は、BCBが追加された後の結果のバンドルを示しています。
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Block Confidentiality Block | 12 | 2 |
| OP(bcb-confidentiality, target=1) | | |
+----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+
Figure 9: Example 2 - Resulting Bundle
図9：例2 - 結果のバンドル
In this example, a BCB is used to encrypt the payload block, and AES key wrap is used to encode the symmetric key prior to its inclusion in the BCB.
この例では、BCBがペイロードブロックを暗号化するために使用され、AESキーラップはBCBへの含有前に対称鍵をエンコードするために使用される。
For this example, the following configuration and security context parameters are used to generate the security results indicated.
この例では、次の設定とセキュリティコンテキストパラメータを使用して、表示されたセキュリティ結果を生成します。
This BCB has a single target -- the payload block. Three security results are generated: ciphertext that replaces the plaintext block-type-specific data to encrypt the payload block, an authentication tag, and the AES wrapped key.
このBCBには単一のターゲット - ペイロードブロックがあります。Pelaintextブロックタイプ固有のデータを置き換える3つのセキュリティ結果が生成され、ペイロードブロック、認証タグ、およびAESがキーが包まれたキーを暗号化します。
Content Encryption Key: h'71776572747975696f70617364666768' Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70' IV: h'5477656c7665313231323132' AES Variant: A128GCM AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892 96fabf34d7fae700' Scope Flags: 0x00 Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' AAD: h'00' Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04' Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241 e070b02619fc59c5214a22f08cd70795 e73e9a'
H'00 '認証タグ：H'eFA4B5AC010808JJ04'ペイロード暗号文：H'3A09C1E63FE23A7F66A59C73837241J070B02619FC59C5214A22F08CD70795 E73E9A '
Figure 10: Example 2 - Configuration, Parameters, and Results
図10：例2 - 構成、パラメータ、および結果
The abstract security block structure of the BCB's block-type-specific data field for this application is as follows.
このアプリケーションのBCBのブロック型固有データフィールドの抽象セキュリティブロック構造は次のとおりです。
[1], / Security Target - Payload block /
2, / Security Context ID - BCB-AES-GCM /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 4 Parameters /
[1, h'5477656c7665313231323132'], / Initialization Vector /
[2, 1], / AES Variant - A128GCM /
[3, h'69c411276fecddc4780df42c8a / AES wrapped key /
2af89296fabf34d7fae700'],
[4, 0x00] / Scope Flags - No extra scope/
],
[ / Security Results: 1 Result /
[ / Target 1 Results /
[1, h'efa4b5ac0108e3816c5606479801bc04'] / Payload Auth. Tag /
]
]
Figure 11: Example 2 - BCB Abstract Security Block (CBOR Diagnostic Notation)
図11：例2 - BCB抽象セキュリティブロック（CBOR診断表記）
The CBOR encoding of the BCB block-type-specific data field (the abstract security block) is:
BCBブロック型固有のデータフィールド（抽象セキュリティブロック）のCBORエンコードは次のとおりです。
0x8101020182028202018482014c5477656c76653132313231328202018203581869 c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150efa4b5 ac0108e3816c5606479801bc04
C411276FJDDC478020182035802960201820356296F42C8A2FJ1780282018201501820282018201501428201820150182820282015018282818201501829653182015018202820182035629652018203562965313231323296531327656296501820356C7666531820150404008181820150FA4B5 AC0108E3816C5606479801BC04
The complete BCB is as follows.
完全なBCBは以下の通りです。
[ 12, / type code / 2, / block number / 1, / flags - block must be replicated in every fragment / 0, / CRC type / h'8101020182028202018482014c5477656c766531323132313282020182035818 69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150 efa4b5ac0108e3816c5606479801bc04' ]
Figure 12: Example 2 - BCB (CBOR Diagnostic Notation)
図12：例2 - BCB（CBOR診断表記）
The CBOR encoding of the BCB block is:
BCBブロックのCBORエンコーディングは次のとおりです。
0x850c02010058508101020182028202018482014c5477656c766531323132313282
02018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081
81820150efa4b5ac0108e3816c5606479801bc04
The CBOR encoding of the full output bundle, with the BCB:
BCBを使用したフル出力バンドルのCBORエンコード
0x9f88070000820282010282028202018202820201820018281a000f4240850c0201
0058508101020182028202018482014c5477656c7665313231323132820201820358
1869c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150ef
a4b5ac0108e3816c5606479801bc04850101000058233a09c1e63fe23a7f66a59c73
03837241e070b02619fc59c5214a22f08cd70795e73e9aff
This example shows the addition of a BIB and BCB to a sample bundle. These two security blocks are added by two different nodes. The BCB is added by the source endpoint, and the BIB is added by a forwarding node.
この例は、サンプルバンドルへのBIBとBCBの追加を示しています。これら2つのセキュリティブロックは2つの異なるノードによって追加されます。BCBはソースエンドポイントによって追加され、BIBは転送ノードによって追加されます。
The resulting bundle contains a BCB to encrypt the Payload Block and a BIB to provide integrity to the primary block and Bundle Age Block.
結果のバンドルには、ペイロードブロックを暗号化するBCBとBIBがプライマリブロックとバンドルエージングブロックに整合性を提供するためのBIBを含みます。
The following diagram shows the original bundle before the security blocks have been added.
次の図は、セキュリティブロックが追加される前の元のバンドルを示しています。
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Extension Block: Bundle Age Block | 7 | 2 |
+----------------------------------------+-------+--------+
| Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+
Figure 13: Example 3 - Original Bundle
図13：例3 - 元のバンドル
The primary block used in this example is identical to the primary block presented for Example 1 in Appendix A.1.1.1.
この例で使用されているプライマリブロックは、付録A.1.1.1では例1に提示された1次ブロックと同じです。
In summary, the CBOR encoding of the primary block is:
要約すると、プライマリブロックのCBORエンコーディングは次のとおりです。
0x88070000820282010282028202018202820201820018281a000f4240
A Bundle Age Block is added to the bundle to help other nodes in the network determine the age of the bundle. The use of this block is recommended because the bundle source does not have an accurate clock (as indicated by the DTN time of 0).
ネットワーク内の他のノードがバンドルの時代を決定するのを助けるためにバンドルエイジブロックがバンドルに追加されます。バンドルソースに正確なクロックがないため、このブロックを使用することをお勧めします（DTN時間0で示すように）。
Because this block is specified at the time the bundle is being forwarded, the bundle age represents the time that has elapsed from the time the bundle was created to the time it is being prepared for forwarding. In this case, the value is given as 300 milliseconds.
このブロックはバンドルが転送されている時点で指定されているので、バンドルの年齢は、バンドルが転送の準備が整っている時間までの時間から経過した時間を表します。この場合、値は300ミリ秒として与えられます。
The Bundle Age extension block is provided as follows.
バンドルエージングエクステンションブロックは次のように提供されます。
[
7, / type code: Bundle Age Block /
2, / block number /
0, / block processing control flags /
0, / CRC type /
<<300>> / type-specific-data: age /
]
Figure 14: Bundle Age Block (CBOR Diagnostic Notation)
図14：バンドルエイジブロック（CBOR診断表記）
The CBOR encoding of the Bundle Age Block is:
バンドルエイジブロックのCBORエンコーディングは次のとおりです。
0x85070200004319012c
0x85070200004319012
The payload block used in this example is identical to the payload block presented for Example 1 in Appendix A.1.1.2.
この例で使用されているペイロードブロックは、付録A.1.1.2では、実施例1に提示されたペイロードブロックと同じである。
In summary, the CBOR encoding of the payload block is:
要約すると、ペイロードブロックのCBORエンコーディングは次のとおりです。
0x85010100005823526561647920746f2067656e657261746520612033322d627974 65207061796c6f6164
6520706179606120333222D62797465265617606120333222D62792074656179720333222D62792352656647920333222D627923526561797465265617974652656647920333222D62797465265617974 652070617974F6164.
A BPv7 bundle is represented as an indefinite-length array consisting of the blocks comprising the bundle, with a terminator character at the end.
BPV7バンドルは、最後にターミネータ文字を備えた、バンドルを含むブロックからなる不定長の配列として表されます。
The CBOR encoding of the original bundle is:
元のバンドルのCBORエンコードは次のとおりです。
0x9f88070000820282010282028202018202820201820018281a000f424085070200 004319012c85010100005823526561647920746f2067656e65726174652061203332 2d62797465207061796c6f6164ff
This example provides:
この例では、次の手順を実行します。
* a BIB with the BIB-HMAC-SHA2 security context to provide an integrity mechanism over the primary block and Bundle Age Block.
* Bib-HMAC-SHA2セキュリティコンテキストを持つBibは、プライマリブロックとバンドルエイジブロックを介して完全性メカニズムを提供します。
* a BCB with the BCB-AES-GCM security context to provide a confidentiality mechanism over the payload block.
* BCB-AES-GCMセキュリティコンテキストを持つBCBは、ペイロードブロックを介して機密性メカニズムを提供します。
The following diagram shows the resulting bundle after the security blocks are added.
次の図は、セキュリティブロックが追加された後の結果のバンドルを示しています。
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Block Integrity Block | 11 | 3 |
| OP(bib-integrity, targets=0, 2) | | |
+----------------------------------------+-------+--------+
| Block Confidentiality Block | 12 | 4 |
| OP(bcb-confidentiality, target=1) | | |
+----------------------------------------+-------+--------+
| Extension Block: Bundle Age Block | 7 | 2 |
+----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+
Figure 15: Example 3 - Resulting Bundle
図15：例3 - 結果のバンドル
In this example, a BIB is used to carry an integrity signature over the Bundle Age Block and an additional signature over the payload block. The BIB is added by a waypoint node -- ipn:3.0.
この例では、BIBは、ペイロードブロックを介してバンドルエイジブロックおよび追加のシグネチャを介して整合性シグネチャを伝送するために使用されます。BIBはウェイポイントノード - IPN：3.0によって追加されます。
For this example, the following configuration and security context parameters are used to generate the security results indicated.
この例では、次の設定とセキュリティコンテキストパラメータを使用して、表示されたセキュリティ結果を生成します。
This BIB has two security targets and includes two security results, holding the calculated signatures over the Bundle Age Block and primary block.
このBIBには2つのセキュリティターゲットがあり、バンドルエイジブロックとプライマリブロックの上に計算された署名を保持している2つのセキュリティ結果が含まれています。
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant: HMAC 256/256 Scope Flags: 0x00 Primary Block Data: h'88070000820282010282028202018202 820201820018281a000f4240' Bundle Age Block Data: h'4319012c' Primary Block IPPT: h'00581c88070000820282010282028202 018202820201820018281a000f4240' Bundle Age Block IPPT: h'004319012c' Primary Block Signature: h'cac6ce8e4c5dae57988b757e49a6dd14 31dc04763541b2845098265bc817241b' Bundle Age Block Signature: h'3ed614c0d97f49b3633627779aa18a33 8d212bf3c92b97759d9739cd50725596'
'004319012C'プライマリブロックシグネチャー：H'CAC6CE8E4C5DAE57988B757J49A6DD14 31DC04765BC817241B 'バンドルエイジブロックシグネチャー：H'3ed614C0D979B36A33627779A18A338D212BF3C92B9759JJ9739CD5072596'
Figure 16: Example 3 - Configuration, Parameters, and Results for the BIB
図16：例3 - BIBの構成、パラメータ、および結果
The abstract security block structure of the BIB's block-type-specific data field for this application is as follows.
このアプリケーションのBIBのブロック型固有データフィールドの抽象セキュリティブロック構造は次のとおりです。
[0, 2], / Security Targets /
1, / Security Context ID - BIB-HMAC-SHA2 /
1, / Security Context Flags - Parameters Present /
[2,[3, 0]], / Security Source - ipn:3.0 /
[ / Security Parameters - 2 Parameters /
[1, 5], / SHA Variant - HMAC 256 /
[3, 0] / Scope Flags - No Additional Scope /
],
[ / Security Results: 2 Results /
[ / Primary Block Results /
[1, h'cac6ce8e4c5dae57988b757e49a6dd14
31dc04763541b2845098265bc817241b'] / MAC /
],
[ / Bundle Age Block Results /
[1, h'3ed614c0d97f49b3633627779aa18a33
8d212bf3c92b97759d9739cd50725596'] / MAC /
]
]
Figure 17: Example 3 - BIB Abstract Security Block (CBOR Diagnostic Notation)
図17：例3 - BIB抽象セキュリティブロック（CBOR診断表記）
The CBOR encoding of the BIB block-type-specific data field (the abstract security block) is:
BIBブロック型固有データフィールド（抽象セキュリティブロック）のCBORエンコードは次のとおりです。
0x8200020101820282030082820105820300828182015820cac6ce8e4c5dae57988b
757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d97f49
b3633627779aa18a338d212bf3c92b97759d9739cd50725596
The complete BIB is as follows.
完全なBIBは以下の通りです。
[ 11, / type code / 3, / block number / 0, / flags / 0, / CRC type / h'8200020101820282030082820105820300828182015820cac6ce8e4c5dae5798 8b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9 7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596' ]
Figure 18: Example 3 - BIB (CBOR Diagnostic Notation)
図18：例3 - BIB（CBOR診断表記）
The CBOR encoding of the BIB block is:
BIBブロックのCBORエンコードは次のとおりです。
0x850b030000585c8200020101820282030082820105820300828182015820cac6ce
8e4c5dae57988b757e49a6dd1431dc04763541b2845098265bc817241b8182015820
3ed614c0d97f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596
In this example, a BCB is used encrypt the payload block. The BCB is added by the bundle source node, ipn:2.1.
この例では、BCBがペイロードブロックを暗号化するために使用されます。BCBはバンドルソースノード、IPn：2.1によって追加されます。
For this example, the following configuration and security context parameters are used to generate the security results indicated.
この例では、次の設定とセキュリティコンテキストパラメータを使用して、表示されたセキュリティ結果を生成します。
This BCB has a single target, the payload block. Two security results are generated: ciphertext that replaces the plaintext block-type-specific data to encrypt the payload block and an authentication tag.
このBCBには単一のターゲット、ペイロードブロックがあります。2つのセキュリティ結果が生成されます.Peploadブロックと認証タグを暗号化するための平文ブロックタイプ固有のデータを置き換えるCipherText。
Content Encryption Key: h'71776572747975696f70617364666768' IV: h'5477656c7665313231323132' AES Variant: A128GCM Scope Flags: 0x00 Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' AAD: h'00' Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04' Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241 e070b02619fc59c5214a22f08cd70795 e73e9a'
E070B02619FC59C5214A22F08CD70795 E73E9A '
Figure 19: Example 3 - Configuration, Parameters, and Results for the BCB
図19：例3 - BCBの構成、パラメータ、および結果
The abstract security block structure of the BCB's block-type-specific data field for this application is as follows.
このアプリケーションのBCBのブロック型固有データフィールドの抽象セキュリティブロック構造は次のとおりです。
[1], / Security Target - Payload block /
2, / Security Context ID - BCB-AES-GCM /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 3 Parameters /
[1, h'5477656c7665313231323132'], / Initialization Vector /
[2, 1], / AES Variant - AES 128 /
[4, 0] / Scope Flags - No Additional Scope /
],
[ / Security Results: 1 Result /
[
[1, h'efa4b5ac0108e3816c5606479801bc04'] / Payload Auth. Tag /
]
]
Figure 20: Example 3 - BCB Abstract Security Block (CBOR Diagnostic Notation)
図20：例3 - BCB抽象セキュリティブロック（CBOR診断表記）
The CBOR encoding of the BCB block-type-specific data field (the abstract security block) is:
BCBブロック型固有のデータフィールド（抽象セキュリティブロック）のCBORエンコードは次のとおりです。
0x8101020182028202018382014c5477656c76653132313231328202018204008181
820150efa4b5ac0108e3816c5606479801bc04
The complete BCB is as follows.
完全なBCBは以下の通りです。
[ 12, / type code / 4, / block number / 1, / flags - block must be replicated in every fragment / 0, / CRC type / h'8101020182028202018382014c5477656c766531323132313282020182040081 81820150efa4b5ac0108e3816c5606479801bc04' ]
[12、タイプコード/ 4、/ブロック番号/ 1、/ flags - ブロックはすべてのフラグメントで複製されなければなりません.0、/ CRCタイプ/ h'8102018282820202018204040081828202020182040081818282020201820400818282020201820400808132820202018204008182820202018204008081328202020182040081818282020182040080813816C5606479801BC04 ']
Figure 21: Example 3 - BCB (CBOR Diagnostic Notation)
図21：例3 - BCB（CBOR診断表記）
The CBOR encoding of the BCB block is:
BCBブロックのCBORエンコーディングは次のとおりです。
0x850c04010058348101020182028202018382014c5477656c766531323132313282
02018204008181820150efa4b5ac0108e3816c5606479801bc04
The CBOR encoding of the full output bundle, with the BIB and BCB added is:
BIBとBCBが追加されたフル出力バンドルのCBORエンコードは次のとおりです。
0x9f88070000820282010282028202018202820201820018281a000f4240850b0300 00585c8200020101820282030082820105820300828182015820cac6ce8e4c5dae57 988b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9 7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596850c0401005834 8101020182028202018382014c5477656c7665313231323132820201820400818182 0150efa4b5ac0108e3816c5606479801bc0485070200004319012c85010100005823 3a09c1e63fe23a7f66a59c7303837241e070b02619fc59c5214a22f08cd70795e73e 9aff
This example shows the addition of a BIB and BCB to a sample bundle. A BIB is added to provide integrity over the payload block, and a BCB is added for confidentiality over the payload and BIB.
この例は、サンプルバンドルへのBIBとBCBの追加を示しています。ペイロードブロックに対する整合性を提供するためにBIBが追加され、ペイロードとBIBに対する機密性のためにBCBが追加されます。
The integrity scope and additional authentication data will bind the primary block, target header, and the security header.
Integrityスコープと追加の認証データは、プライマリブロック、ターゲットヘッダー、およびセキュリティヘッダーにバインドされます。
The following diagram shows the original bundle before the security blocks have been added.
次の図は、セキュリティブロックが追加される前の元のバンドルを示しています。
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+
Figure 22: Example 4 - Original Bundle
図22：例4 - 元のバンドル
The primary block used in this example is identical to the primary block presented for Example 1 in Appendix A.1.1.1.
この例で使用されているプライマリブロックは、付録A.1.1.1では例1に提示された1次ブロックと同じです。
In summary, the CBOR encoding of the primary block is:
要約すると、プライマリブロックのCBORエンコーディングは次のとおりです。
0x88070000820282010282028202018202820201820018281a000f4240
The payload block used in this example is identical to the payload block presented for Example 1 in Appendix A.1.1.2.
この例で使用されているペイロードブロックは、付録A.1.1.2では、実施例1に提示されたペイロードブロックと同じである。
In summary, the CBOR encoding of the payload block is:
要約すると、ペイロードブロックのCBORエンコーディングは次のとおりです。
0x85010100005823526561647920746f2067656e657261746520612033322d627974 65207061796c6f6164
6520706179606120333222D62797465265617606120333222D62792074656179720333222D62792352656647920333222D627923526561797465265617974652656647920333222D62797465265617974 652070617974F6164.
A BPv7 bundle is represented as an indefinite-length array consisting of the blocks comprising the bundle, with a terminator character at the end.
BPV7バンドルは、最後にターミネータ文字を備えた、バンドルを含むブロックからなる不定長の配列として表されます。
The CBOR encoding of the original bundle is:
元のバンドルのCBORエンコードは次のとおりです。
0x9f88070000820282010282028202018202820201820018281a000f424085010100 005823526561647920746f2067656e657261746520612033322d6279746520706179 6c6f6164ff
This example provides:
この例では、次の手順を実行します。
* a BIB with the BIB-HMAC-SHA2 security context to provide an integrity mechanism over the payload block.
* ペイロードブロックを介して完全性メカニズムを提供するためのBib-HMAC-SHA2セキュリティコンテキストを持つBib。
* a BCB with the BCB-AES-GCM security context to provide a confidentiality mechanism over the payload block and BIB.
* BCB-AES-GCMセキュリティコンテキストを持つBCBは、ペイロードブロックとBIBを介して機密性メカニズムを提供するためのBCBです。
The following diagram shows the resulting bundle after the security blocks are added.
次の図は、セキュリティブロックが追加された後の結果のバンドルを示しています。
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Block Integrity Block (Encrypted) | 11 | 3 |
| OP(bib-integrity, target=1) | | |
+----------------------------------------+-------+--------+
| Block Confidentiality Block | 12 | 2 |
| OP(bcb-confidentiality, targets=1, 3) | | |
+----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+
Figure 23: Example 4 - Resulting Bundle
図23：例4 - 結果として得られるバンドル
In this example, a BIB is used to carry an integrity signature over the payload block. The IPPT contains the block-type-specific data of the payload block, the primary block data, the payload block header, and the BIB header. That is, all additional headers are included in the IPPT.
この例では、ペイロードブロックの上に完全性シグネチャを伝送するためにBIBが使用されます。IPPTには、ペイロードブロック、プライマリブロックデータ、ペイロードブロックヘッダー、およびBIBヘッダーのブロック型固有のデータが含まれています。つまり、すべての追加のヘッダーがIPPTに含まれています。
For this example, the following configuration and security context parameters are used to generate the security results indicated.
この例では、次の設定とセキュリティコンテキストパラメータを使用して、表示されたセキュリティ結果を生成します。
This BIB has a single target and includes a single security result: the calculated signature over the Payload block.
このBIBには単一のターゲットがあり、単一のセキュリティ結果が含まれています。ペイロードブロック上の計算署名。
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant: HMAC 384/384 Scope Flags: 0x07 (all additional headers) Primary Block Data: h'88070000820282010282028202018202 820201820018281a000f4240' Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' Payload Header: h'010100' BIB Header: h'0b0300' IPPT: h'07880700008202820102820282020182 02820201820018281a000f4240010100 0b03005823526561647920746f206765 6e657261746520612033322d62797465 207061796c6f6164' Payload Signature: h'f75fe4c37f76f046165855bd5ff72fbf d4e3a64b4695c40e2b787da005ae819f 0a2e30a2e8b325527de8aefb52e73d71,
Figure 24: Example 4 - Configuration, Parameters, and Results for the BIB
図24：例4 - BIBの構成、パラメータ、および結果
The abstract security block structure of the BIB's block-type-specific data field for this application is as follows.
このアプリケーションのBIBのブロック型固有データフィールドの抽象セキュリティブロック構造は次のとおりです。
[1], / Security Target - Payload block /
1, / Security Context ID - BIB-HMAC-SHA2 /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 2 Parameters /
[1, 6], / SHA Variant - HMAC 384/384 /
[3, 0x07] / Scope Flags - All additional headers /
],
[ / Security Results: 1 Result /
[ / Target 1 Results /
[1, h'f75fe4c37f76f046165855bd5ff72fbf / MAC /
d4e3a64b4695c40e2b787da005ae819f
0a2e30a2e8b325527de8aefb52e73d71']
]
]
Figure 25: Example 4 - BIB Abstract Security Block (CBOR Diagnostic Notation)
図25：例4 - BIB抽象セキュリティブロック（CBOR診断表記）
The CBOR encoding of the BIB block-type-specific data field (the abstract security block) is:
BIBブロック型固有データフィールド（抽象セキュリティブロック）のCBORエンコードは次のとおりです。
0x81010101820282020182820106820307818182015830f75fe4c37f76f046165855 bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb52 e73d71
BD5F72FFD4E3A64B4695C40J2B787DA005AE819F0A2A0787DA005AAE8190282078182820158207818282028207018282010682078182820106820201828201068202018282010682020182820102820781828201068207855555501068202018282056665855DA005AE819F0A2E30A2E8B325527DE8AEFB52 E73D71
The complete BIB is as follows.
完全なBIBは以下の通りです。
[ 11, / type code / 3, / block number / 0, / flags / 0, / CRC type / h'81010101820282020182820106820307818182015830f75fe4c37f76f0461658 55bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8 aefb52e73d71' ]
Figure 26: Example 4 - BIB (CBOR Diagnostic Notation)
図26：例4 - BIB（CBOR診断表記）
The CBOR encoding of the BIB block is:
BIBブロックのCBORエンコードは次のとおりです。
0x850b030000584681010101820282020182820106820307818182015830f75fe4c3 7f76f046165855bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b3 25527de8aefb52e73d71
In this example, a BCB is used encrypt the payload block and the BIB that provides integrity over the payload.
この例では、BCBはペイロードブロックとペイロードの整合性を提供するBIBを暗号化します。
For this example, the following configuration and security context parameters are used to generate the security results indicated.
この例では、次の設定とセキュリティコンテキストパラメータを使用して、表示されたセキュリティ結果を生成します。
This BCB has two targets: the payload block and BIB. Four security results are generated: ciphertext that replaces the plaintext block-type-specific data of the payload block, ciphertext to encrypt the BIB, and authentication tags for both the payload block and BIB.
このBCBには2つのターゲットがあります。ペイロードブロックとBIB。4つのセキュリティ結果が生成されます.peploadブロックの平文ブロック型固有データを置き換えるCipherText、CipheTextはBIBを暗号化し、ペイロードブロックとBIBの両方の認証タグです。
Key: h'71776572747975696f70617364666768 71776572747975696f70617364666768' IV: h'5477656c7665313231323132' AES Variant: A256GCM Scope Flags: 0x07 (All additional headers) Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' BIB Data: h'81010101820282020182820106820307 818182015830f75fe4c37f76f0461658 55bd5ff72fbfd4e3a64b4695c40e2b78 7da005ae819f0a2e30a2e8b325527de8 aefb52e73d71' Primary Block Data: h'88070000820282010282028202018202 820201820018281a000f4240' Payload Header: h'010100' BIB Header: h'0b0300' BCB Header: h'0c0201' Payload AAD: h'07880700008202820102820282020182 02820201820018281a000f4240010100 0c0201' BIB AAD: h'07880700008202820102820282020182 02820201820018281a000f42400b0300 0c0201' Payload Block Authentication Tag: h'd2c51cb2481792dae8b21d848cede99b' BIB Authentication Tag: h'220ffc45c8a901999ecc60991dd78b29' Payload Ciphertext: h'90eab6457593379298a8724e16e61f83 7488e127212b59ac91f8a86287b7d076 30a122' BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 902902064a2983910c4fb2340790bf42 0a7d1921d5bf7c4721e02ab87a93ab1e 0b75cf62e4948727c8b5dae46ed2af05 439b88029191'
キー：h'71776572747975696f70617364666768 71776572747975696f70617364666768' IV：h'5477656c7665313231323132' AESバリアント：A256GCMスコープフラグ：0x07の（すべての追加のヘッダー）ペイロードデータ：h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' BIBデータ：h'81010101820282020182820106820307 818182015830f75fe4c37f76f0461658 55bd5ff72fbfd4e3a64b4695c40e2b78 7da005ae819f0a2e30a2e8b325527de8 aefb52e73d71' プライマリブロックデータ： h'88070000820282010282028202018202 820201820018281a000f4240' ペイロードヘッダー：h'010100' BIBヘッダ：h'0b0300' BCBヘッダ：h'0c0201' ペイロードAAD：h'07880700008202820102820282020182 02820201820018281a000f4240010100 0c0201' BIB AAD：h'07880700008202820102820282020182 02820201820018281a000f42400b0300 0c0201' ペイロードブロック認証タグ：H 'd2c51cb2481792dae8b21d848cede99b' BIB認証タグ：h'220ffc45c8a901999ecc60991dd78b29' ペイロード暗号文：h'90eab6457593379298a8724e16e61f83 7488e127212b59ac91f8a86287b7d076 30a122' BIB暗号文：h'438ed6208eb1c 1ffb94d952175167DF0 902902064A2983910C4FB2340790BF42 0A7D1921D5BF7C4721E02AB87A93AB1E 0B75CF62J4948727C8B5DAE46ED2AF05 439B88029191 '
Figure 27: Example 4 - Configuration, Parameters, and Results for the BCB
図27：例4 - BCBの構成、パラメータ、および結果
The abstract security block structure of the BCB's block-type-specific data field for this application is as follows.
このアプリケーションのBCBのブロック型固有データフィールドの抽象セキュリティブロック構造は次のとおりです。
[3, 1], / Security Targets /
2, / Security Context ID - BCB-AES-GCM /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 3 Parameters /
[1, h'5477656c7665313231323132'], / Initialization Vector /
[2, 3], / AES Variant - AES 256 /
[4, 0x07] / Scope Flags - All headers in SHA hash /
],
[ / Security Results: 2 Results /
[
[1, h'220ffc45c8a901999ecc60991dd78b29'] / BIB Auth. Tag /
],
[
[1, h'd2c51cb2481792dae8b21d848cede99b'] / Payload Auth. Tag /
]
]
Figure 28: Example 4 - BCB Abstract Security Block (CBOR Diagnostic Notation)
図28：例4 - BCB抽象セキュリティブロック（CBOR診断表記）
The CBOR encoding of the BCB block-type-specific data field (the abstract security block) is:
BCBブロック型固有のデータフィールド（抽象セキュリティブロック）のCBORエンコードは次のとおりです。
0x820301020182028202018382014c5477656c766531323132313282020382040782 81820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792dae8b2 1d848cede99b
0x8203220132820203290220782 8182040782 818201502201328203820150220182028202980782 8182015022013282020329040782 81820150220509091DD78B2981820150D2C51CB2481792DA8B2 1D848CEDEE99B.
The complete BCB is as follows.
完全なBCBは以下の通りです。
[ 12, / type code / 2, / block number / 1, / flags - block must be replicated in every fragment / 0, / CRC type / h'820301020182028202018382014c5477656c7665313231323132820203820407 8281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792 dae8b21d848cede99b' ]
Figure 29: Example 4 - BCB (CBOR Diagnostic Notation)
図29：例4 - BCB（CBOR診断表記）
The CBOR encoding of the BCB block is:
BCBブロックのCBORエンコーディングは次のとおりです。
0x850c0201005849820301020182028202018382014c5477656c7665313231323132 8202038204078281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51c b2481792dae8b21d848cede99b
0x850201428202999922092202802901502209220282909992209220280290999922092DJ1828298182015018202829999220922028029015622018202829999220922028029829022092DD7828290999222092DD78282981820150D2C51C B2481792DJE8B21D848CEDEJ99B
The CBOR encoding of the full output bundle, with the security blocks added and payload block and BIB encrypted is:
セキュリティブロックが追加され、ペイロードブロックとBIBが暗号化されているフル出力バンドルのCBORエンコードは次のとおりです。
0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
005846438ed6208eb1c1ffb94d952175167df0902902064a2983910c4fb2340790bf
420a7d1921d5bf7c4721e02ab87a93ab1e0b75cf62e4948727c8b5dae46ed2af0543
9b88029191850c0201005849820301020182028202018382014c5477656c76653132
313231328202038204078281820150220ffc45c8a901999ecc60991dd78b29818201
50d2c51cb2481792dae8b21d848cede99b8501010000582390eab6457593379298a8
724e16e61f837488e127212b59ac91f8a86287b7d07630a122ff
For informational purposes, this section contains an expression of the IPPT and AAD structures using the Concise Data Definition Language (CDDL).
情報提供のために、このセクションには、簡潔なデータ定義言語（CDDL）を使用したIPPT構造とAAD構造体の式が含まれています。
NOTES:
ノート：
* Wherever the CDDL expression is in disagreement with the textual representation of the security block specification presented in earlier sections of this document, the textual representation rules.
* CDDL式は、この文書の以前のセクションで提示されているセキュリティブロック仕様のテキスト表現との対応がある場合、テキスト表現規則。
* The structure of BP bundles and BPSec security blocks are provided by other specifications; this appendix only provides the CDDL expression for structures uniquely defined in this specification. Items related to elements of a bundle, such as "primary-block", are defined in Appendix B of the Bundle Protocol version 7 [RFC9171].
* BPバンドルとBPSECセキュリティブロックの構造は、他の仕様によって提供されています。この付録では、この仕様で一意に定義されている構造体についてのCDDL式のみを提供します。「プライマリブロック」などのバンドルの要素に関連する項目は、バンドルプロトコルバージョン7 [RFC9171]の付録Bに定義されています。
* The CDDL itself does not have the concept of unadorned CBOR sequences as a top-level subject of a specification. The current best practice, as documented in Section 4.1 of [RFC8742], requires representing the sequence as an array with a comment in the CDDL noting that the array represents a CBOR sequence.
* CDDL自体は、仕様の最上位の課題として、未導CBOBOBORシーケンスの概念を持っていません。[RFC8742]のセクション4.1に記載されている現在のベストプラクティスは、ARRAYがCBOBORシーケンスを表すことをCDDL内のコメントを持つ配列としてシーケンスを表現する必要があります。
start = scope / AAD-list / IPPT-list ; satisfy CDDL decoders
scope = uint .bits scope-flags
scope-flags = &(
has-primary-ctx: 0,
has-target-ctx: 1,
has-security-ctx: 2,
)
; Encoded as a CBOR sequence
AAD-list = [
AAD-structure
]
; Encoded as a CBOR sequence
IPPT-list = [
AAD-structure,
target-btsd: bstr ; block-type-specific data of the target block.
]
AAD-structure = (
scope,
? primary-block, ; present if has-primary-ctx flag set
? block-metadata, ; present if has-target-ctx flag set
? block-metadata, ; present if has-security-ctx flag set
)
; Selected fields of a canonical block
block-metadata = (
block-type-code: uint,
block-number: uint,
block-control-flags,
)
Figure 30: IPPT and AAD Expressions
図30：IPPTとAAD式
Acknowledgments
謝辞
Amy Alford of the Johns Hopkins University Applied Physics Laboratory contributed useful review and analysis of these security contexts.
Johns Hopkins University Applied Physics LaboratorのApply Alfordこれらのセキュリティコンテキストの有用なレビューと分析を提供しました。
Brian Sipos kindly provided the CDDL expression in Appendix B.
Brian Siposは付録BのCDDL式を親切に提供しました。
Authors' Addresses
著者の住所
Edward J. Birrane, III The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd. Laurel, MD 20723 United States of America
Edward J. Birrane、III Johns Hopkins University Physics Laboratory 11100 Johns Hopkins RD。Laurel、MD 20723アメリカ合衆国
Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu
Alex White The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd. Laurel, MD 20723 United States of America
アレックスホワイトジョンズホプキンス大学Applied Physics Laboratory 11100 Johns Hopkins RD。Laurel、MD 20723アメリカ合衆国
Phone: +1 443 778 0845
Email: Alex.White@jhuapl.edu
Sarah Heiner The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd. Laurel, MD 20723 United States of America
Sarah Heiner Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins RD。Laurel、MD 20723アメリカ合衆国
Phone: +1 240 592 3704
Email: Sarah.Heiner@jhuapl.edu