3.1. Overview

The BIB-HMAC-SHA2 security context provides a keyed-hash Message Authentication Code (MAC) over a set of plain text 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:¶

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.¶
2. The combination HMAC-SHA2 represents a well-supported and well-understood integrity mechanism with multiple implementations available.¶

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.¶

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.¶

The BIB-HMAC-SHA2 security context MUST have the security context identifier specified in Section 5.1.¶

3.2. Scope

The scope of BIB-HMAC-SHA2 is the set of information used to produce the plain text over which a keyed hash is calculated. This plain text is termed the "Integrity-Protected Plain Text (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.¶

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 scope

The determination of which optional types of information were used when constructing the IPPT MUST, itself, 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.¶

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.¶

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.¶

Including this information in the IPPT protects the integrity of the association of the security target with a specific bundle.¶

Security target other fields

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.¶

BIB other fields

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.¶

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.¶

Including this information in the IPPT protects the integrity of the policy and identification of the security service in the bundle.¶

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.¶

3.3. Parameters

BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, communicate key information, and define the scope of the IPPT.¶

3.6. Security Processing Considerations

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 plain text and a 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 plain text without the attacker ever knowing the HMAC key.¶

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.¶

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.¶

3.8. Processing

4.1. Overview

The BCB-AES-GCM security context replaces the block-type-specific data field of its security target with cipher text 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:¶

1. The selection of a symmetric-key cipher suite allows for relatively smaller keys than asymmetric-key cipher suites.¶
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.¶
3. The use of the Galois/Counter Mode produces cipher text with the same size as the plain text making the replacement of target block information easier as length fields do not need to be changed.¶
4. The AES-GCM cipher suite provides authenticated encryption, as required by the BPSec protocol.¶

Additionally, the BCB-AES-GCM security context generates an authentication tag based on the plain text value of the block-type-specific data and other additional authenticated data (AAD) that might be specified via parameters to this security context.¶

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].¶

The BCB-AES-GCM security context MUST have the security context identifier specified in Section 5.1.¶

4.2. Scope

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 cipher text. The second defines the set of information used to generate an authentication tag.¶

The scope of the confidentiality service defines the set of information provided to the AES-GCM cipher for the purpose of producing cipher text. This MUST be the full set of plain text contained in the block-type-specific data field of the security target.¶

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.¶

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.¶

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.¶

Security target other fields

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 cipher text in the security target will not be used with a different set of block policy than originally set at the time of encryption.¶

BCB other fields

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.¶

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.¶

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.¶

4.3. Parameters

BCB-AES-GCM can be parameterized to specify the AES variant, initialization vector, key information, and identify additional authenticated data.¶

4.7. Canonicalization Algorithms

This section defines the canonicalization algorithms used to prepare the inputs used to generate both the cipher text and the authentication tag.¶

In all cases, the canonical form of any portion of an extension block MUST be performed 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.¶

4.8. Processing

5.2. Integrity Scope Flags

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.¶

The registration policy for this registry is Specification Required [RFC8126].¶

The value range is unsigned 16-bit integer.¶

5.3. AAD Scope Flags

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.¶

The registration policy for this registry is Specification Required.¶

The value range is unsigned 16-bit integer.¶

5.4. Guidance for Designated Experts

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.¶

• Ascertain the existence of suitable documentation (a specification) as described in [RFC8126] and verify that the document is permanently and publicly available.¶
• Ensure that any changes to the Integrity Scope Flags clearly state how new assignments interact with existing flags and how the inclusion of new assignments affects the construction of the IPPT value.¶
• Ensure that any changes to the AAD Scope Flags 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.¶
• Ensure that any processing changes proposed with new assignments do not alter any required behavior in this specification.¶

6.1. Key Management

The delayed and disrupted nature of Delay-Tolerant Networks (DTNs) 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.¶

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 a 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 key-encrypting keys, revocation of existing keys, or the security configuration or policy used to select certain keys for certain security operations.¶

Nodes using these security contexts need to perform the following kinds of activities, independent of the construction, transmission, and processing of BPSec security blocks.¶

• Establish shared key-encrypting-keys with other nodes in the network using an out-of-band mechanism. This might include pre-sharing of key encryption keys or the use of traditional key establishment mechanisms prior to the exchange of BPSec security blocks.¶
• 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.¶

6.2. Key Handling

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.¶
• The same key, whether a key-encrypting-key or a wrapped key, MUST NOT be used for different algorithms as doing so might leak information about the key.¶
• A key-encrypting-key MUST NOT be used to encrypt keys for different security contexts. Any key-encrypting-key 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 key-encrypting-key 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 key-encrypting-key to unwrap keys for different security contexts.¶

6.3. AES GCM

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.¶

The length of the cipher text produced by the GCM mode of AES will be equal to the length of the plain text input to the cipher suite. The authentication tag also produced by this cipher suite is separate from the cipher text. However, it should be noted that implementations of the AES-GCM cipher suite might not separate the concept of cipher text and authentication tag in their Application Programming Interface (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 cipher text 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 cipher text and authentication tag MUST be processed in accordance with the API of the AES-GCM cipher suites at the security source and security acceptor.¶

6.4. AES Key Wrap

The AES key wrap (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 key encryption key provided by local security policy at the security verifier or security acceptor.¶

6.5. Bundle Fragmentation

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 Processing Agent (BPA) will not know that the target block has been encrypted.¶
• 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.¶
• 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.¶

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.¶

A.1. Example 1: Simple Integrity

This example shows the addition of a BIB to a sample bundle to provide integrity for the payload block.¶

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

[
  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              /
]

[
  1,      / type code: Payload block /
  1,      / block number             /
  0,      / block processing flags   /
  0,      / CRC type                 /
  h'52656164792047656e65726174652061 / type-specific-data: payload /
    2033322062797465207061796c6f6164'
]

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Bundle Integrity Block                |   11  |    2   |
        |  OP(bib-integrity, target=1)           |       |        |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

 Key         : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
 SHA Variant : HMAC 512/512
 Scope Flags : 0x00
 Payload Data: h'52656164792047656e65726174652061
                 2033322062797465207061796c6f6164'
 Signature   : h'0654d65992803252210e377d66d0a8dc
                 18a1e8a392269125ae9ac198a9a598be
                 4b83d5daa8be2f2d16769ec1c30cfc34
                 8e2205fba4b3be2b219074fdd5ea8ef0'

[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 /
   [1, h'0654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598b
   e4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0']
]

[
  11, / type code    /
  2,  / block number /
  0,  / flags        /
  0,  / CRC type     /
  h'8101010182028202018282010782030081820158400654d65992803252210e377d66
  d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc34
  8e2205fba4b3be2b219074fdd5ea8ef0',
]

A.2. Example 2: Simple Confidentiality with Key Wrap

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.¶

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Bundle Confidentiality Block          |   12  |    2   |
        |  OP(bcb-confidentiality, target=1)     |       |        |
        +----------------------------------------+-------+--------+
        |  Payload Block (Encrypted)             |   1   |    1   |
        +----------------------------------------+-------+--------+

 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'52656164792047656e65726174652061
                       2033322062797465207061796c6f6164'
 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97'
 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
                       a563e32648b700c2784e26a990d91f9d'

[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 /
  [1, h'da08f4d8936024ad7c6b3b800e73dd97']    / Payload Auth. Tag /
]

[
  12, / type code /
  2,  / block number /
  1,  / flags - block must be replicated in every fragment /
  0,  / CRC type /
  h'8101020182028202018482014c5477656c766531323132313282020182035818
    69c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da
    08f4d8936024ad7c6b3b800e73dd97'
]

A.3. Example 3: Security Blocks from Multiple Sources

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.¶

The resulting bundle contains a BCB to encrypt the Payload Block and a BIB to provide integrity to the Primary and Bundle Age Block.¶

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Extension Block: Bundle Age Block     |   7   |    2   |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

[
  7,      / type code: Bundle Age block /
  2,      / block number /
  0,      / block processing flags /
  0,      / CRC type /
  <<300>> / type-specific-data: age /
]

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Bundle Integrity Block                |   11  |    3   |
        |  OP(bib-integrity, targets=0, 2)       |       |        |
        +----------------------------------------+-------+--------+
        |  Bundle Confidentiality Block          |   12  |    4   |
        |  OP(bcb-confidentiality, target=1)     |       |        |
        +----------------------------------------+-------+--------+
        |  Extension Block: Bundle Age Block     |   7   |    2   |
        +----------------------------------------+-------+--------+
        |  Payload Block (Encrypted)             |   1   |    1   |
        +----------------------------------------+-------+--------+

                Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
        SHA Variant: HMAC 256/256
        Scope Flags: 0x00
 Primary Block Data: h'88070000820282010282028202018202
                       820201820018281a000f4240'
 Bundle Age Block
               Data: h'85070200004319012c'
 Primary Block
          Signature: h'8e059b8e71f7218264185a666bf3e453
                       076f2b883f4dce9b3cdb6464ed0dcf0f'
 Bundle Age Block
          Signature: h'72dee8eba049a22978e84a95d0496466
                       8eb131b1ca4800c114206d70d9065c80'

[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/256        /
   [3, 0x00]    / Scope Flags            - No Additional Scope /
],
[           / Security Results: 2 Results /
   [1, h'8e059b8e71f7218264185a666bf3e453
         076f2b883f4dce9b3cdb6464ed0dcf0f'], / Primary Block   /
   [1, h'72dee8eba049a22978e84a95d0496466
         8eb131b1ca4800c114206d70d9065c80'] / Bundle Age Block /
]

[
  11, / type code /
  3,  / block number /
  0,  / flags  /
  0,  / CRC type /
  h'820002010182028203008282010582030082820158208e059b8e71f721826418
    5a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049
    a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80',
]

 Content Encryption
                Key: h'71776572747975696f70617364666768'
                 IV: h'5477656c7665313231323132'
        AES Variant: A128GCM
        Scope Flags: 0x00
       Payload Data: h'52656164792047656e65726174652061
                       2033322062797465207061796c6f6164'
 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97'
 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
                       a563e32648b700c2784e26a990d91f9d'

[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, 0x00]                / Scope Flags - No Additional Scope /
],
[                                 / Security Results: 1 Result /
  [1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag /
]

[
  12, / type code /
  4,  / block number /
  1,  / flags - block must be replicated in every fragment /
  0,  / CRC type /
  h'8101020182028202018382014c5477656c766531323132313282020182040081
    820150da08f4d8936024ad7c6b3b800e73dd97',
]

A.4. Example 4: Security Blocks with Full Scope

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.¶

The integrity scope and additional authentication data will bind the primary block, target header, and the security header.¶

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Bundle Integrity Block (Encrypted)    |   11  |    3   |
        |  OP(bib-integrity, target=1)           |       |        |
        +----------------------------------------+-------+--------+
        |  Bundle Confidentiality Block          |   12  |    2   |
        |  OP(bcb-confidentiality, targets=1, 3) |       |        |
        +----------------------------------------+-------+--------+
        |  Payload Block (Encrypted)             |   1   |    1   |
        +----------------------------------------+-------+--------+

                          Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
                  SHA Variant: HMAC 384/384
                  Scope Flags: 0x07  (all additional headers)
           Primary Block Data: h'88070000820282010282028202018202
                                 820201820018281a000f4240
                 Payload Data: h'52656164792047656e65726174652061
                                 2033322062797465207061796c6f6164'
               Payload Header: h'85010100005820'
                   BIB Header: h'850b0300005845'
            Payload Signature: h'07c84d929f83bee4690130729d77a1bd
                                 da9611cd6598e73d0659073ea74e8c27
                                 523b02193cb8ba64be58dbc556887aca

[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 in the SHA Hash /
],
[              / Security Results: 1 Result /
   [1, h'07c84d929f83bee4690130729d77a1bdda9611cd6598e73d
         0659073ea74e8c27523b02193cb8ba64be58dbc556887aca']
]

[
  11, / type code /
  3,  / block number /
  0,  / flags  /
  0,  / CRC type /
  h'81010101820282020182820106820307818201583007c84d929f83bee4690130
    729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58db
    c556887aca',
]

                          Key: h'71776572747975696f70617364666768
                                 71776572747975696f70617364666768'
                           IV: h'5477656c7665313231323132'
                  AES Variant: A256GCM
                  Scope Flags: 0x07  (All additional headers)
                 Payload Data: h'52656164792047656e65726174652061
                                 2033322062797465207061796c6f6164'
                     BIB Data: h'81010101820282020182820106820307
                                 818201583007c84d929f83bee4690130
                                 729d77a1bdda9611cd6598e73d065907
                                 3ea74e8c27523b02193cb8ba64be58db
                                 c556887aca
                          BIB
           Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e'
                Payload Block
           Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff'
           Payload Ciphertext: h'90eab64575930498d6aa654107f15e96
                                 319bb227706000abc8fcac3b9bb9c87e'
               BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0
                                 902a815f221ebc837a134efc13bfa82a
                                 2d5d317747da3eb54acef4ca839bd961
                                 487284404259b60be12b8aed2f3e8a36
                                 2836529f66'

[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'c95ed4534769b046d716e1cdfd00830e'],    / BIB Auth. Tag /
  [1, h'0e365c700e4bb19c0d991faff5345aff'] / Payload Auth. Tag /
]

[
  12, / type code /
  2,  / block number /
  1,  / flags - block must be replicated in every fragment /
  0,  / CRC type /
  h'820301020182028202018382014c5477656c7665313231323132820203820407
    82820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d
    991faff5345aff',
]

0x9f88070000820282010282028202018202820201820018281a000f4240850b03000
05845438ed6208eb1c1ffb94d952175167df0902a815f221ebc837a134efc13bfa82a
2d5d317747da3eb54acef4ca839bd961487284404259b60be12b8aed2f3e8a3628365
29f66850c0201005847820301020182028202018382014c5477656c76653132313231
3282020382040782820150c95ed4534769b046d716e1cdfd00830e8201500e365c700
e4bb19c0d991faff5345aff8501010000582090eab64575930498d6aa654107f15e96
319bb227706000abc8fcac3b9bb9c87eff.