AES SECMSG variable-length symmetric key token
View a table showing the format of the SECMSG variable-length symmetric key-token.
Offset (bytes) | Length (bytes) | Description | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Header |
|||||||||||||||||
000 | 01 |
Token identifier (note that it is intentional that an external key-token is not defined):
All unused values are reserved and undefined. |
|||||||||||||||
001 | 01 | Reserved, binary zero. | |||||||||||||||
002 | 02 |
Length in bytes of the overall token structure:
|
|||||||||||||||
004 | 01 |
Token version number (identifies the format of this key token):
|
|||||||||||||||
005 | 03 |
Reserved, binary zero. |
|||||||||||||||
End of header |
|||||||||||||||||
Wrapping information section (all data related to wrapping the key) |
|||||||||||||||||
008 | 01 |
Key material state:
All unused values are reserved and undefined. |
|||||||||||||||
009 | 01 |
Key verification pattern (KVP) type:
All unused values are reserved and undefined. |
|||||||||||||||
010 | 16 |
KVP (value depends on value of key material state, that is, the value at offset 8):
All unused values are reserved and undefined. |
|||||||||||||||
026 | 01 |
Encrypted section key-wrapping method (how data in the encrypted section is protected):
All unused values are reserved and undefined. |
|||||||||||||||
027 | 01 |
Hash algorithm used for wrapping key or encoding message. Meaning depends on whether the encrypted section key-wrapping method (value at offset 26) is no key-wrapping method or AESKW: No key-wrapping method (value at offset 26 is X'00') Hash algorithm used for wrapping key when encrypted section key-wrapping method is no key-wrapping method:
All unused values are reserved and undefined. The key token is internal. AESKW key-wrapping method (value at offset 26 is X'02') Hash algorithm used for wrapping key when encrypted section key-wrapping method is AESKW. The value indicates the algorithm used to calculate the hash digest of the associated data. The hash digest is included in the wrapped payload and is calculated starting at offset 30 for the length in bytes of all the associated data for the key token (length value at offset 32).
All unused values are reserved and undefined. The key token is internal. |
|||||||||||||||
028 | 01 |
Payload format version (identifies format of the payload).
All unused values are reserved and undefined. |
|||||||||||||||
029 | 01 |
Reserved, binary zero. |
|||||||||||||||
End of wrapping information section |
|||||||||||||||||
AESKW components: (1) associated data section and (2) optional wrapped AESKW formatted payload (no payload if no key present) |
|||||||||||||||||
Associated data section |
|||||||||||||||||
030 | 01 |
Associated data section version:
|
|||||||||||||||
031 | 01 |
Reserved, binary zero. |
|||||||||||||||
032 | 02 |
Length in bytes of all the associated data for the key token: 26 - 345. |
|||||||||||||||
034 | 01 |
Length in bytes of the optional key label (kl ) : 0 or 64 . |
|||||||||||||||
035 | 01 |
Length in bytes of the optional IBM extended associated data (iead ) : 0 . |
|||||||||||||||
036 | 01 |
Length in bytes of the optional user-definable associated data: 0 - 255 (uad ). |
|||||||||||||||
037 | 01 |
Reserved, binary zero. |
|||||||||||||||
038 | 02 | Length in bits of the wrapped payload ( pl ): 0,
640. For no key-wrapping method (no key present), plis 0. For an AESKW formatted payload, plis based on the key size of the algorithm type and the payload format version:
|
|||||||||||||||
040 | 01 |
Reserved, binary zero. |
|||||||||||||||
041 | 01 |
Algorithm type (algorithm for which the key can be used):
All unused values are reserved and undefined. |
|||||||||||||||
042 | 02 |
Key type (general class of the key):
All unused values are reserved and undefined. |
|||||||||||||||
044 | 01 |
Key usage fields count (kuf): 2. Key-usage field information defines restrictions on the use of the key. Each key-usage field is 2 bytes in length. The value in this field indicates how many 2-byte key usage fields follow. |
|||||||||||||||
045 | 01 |
Key-usage field 1, high-order byte (secure message encryption enablement):
All unused values are reserved and undefined. |
|||||||||||||||
046 | 01 | Key-usage field 1, low-order byte (user-defined extension control). | |||||||||||||||
047 | 01 |
Key-usage field 2, high-order byte (verb restriction):
All unused values are reserved and undefined. |
|||||||||||||||
048 | 01 |
Key-usage field 2, low-order byte (reserved). All bits are reserved and must be zero. |
|||||||||||||||
049 | 01 |
Key management fields count (kmf): 3. Key-management field information describes how the data is to be managed or helps with management of the key material. Each key-management field is 2 bytes in length. The value in this field indicates how many 2-byte key management fields follow. |
|||||||||||||||
050 | 01 |
Key-management field 1, high-order byte (symmetric-key export control). Note that an AES SECMSG key cannot be exported because it has no external key-token defined. Symmetric-key export control:
Unauthenticated asymmetric-key export control:
Authenticated asymmetric-key export control:
Raw-key export control:
All unused bits are reserved and must be zero. |
|||||||||||||||
051 | 01 |
Key-management field 1, low-order byte (export control by algorithm). Note that an AES SECMSG key can only be internal; it cannot be external. DES-key export control:
AES-key export control:
RSA-key export control:
All unused bits are reserved and must be zero. |
|||||||||||||||
052 | 01 |
Key-management field 2, high-order byte (key completeness). |
|||||||||||||||
053 | 01 |
Key-management field 2, low-order byte (security history). |
|||||||||||||||
054 | 01 |
Key-management field 3, high-order byte (pedigree original). |
|||||||||||||||
055 | 01 |
Key-management field 3, low-order byte (pedigree current). |
|||||||||||||||
056 | 01 | Optional key label. | |||||||||||||||
056 + kl |
iead | Optional IBM extended associated data (unused). | |||||||||||||||
056 + kl + iead |
uad | Optional user-defined associated data. | |||||||||||||||
End of associated data section |
|||||||||||||||||
Optional wrapped AESKW formatted payload, or wrapped PKOAEP2 encoded payload (no payload if no key present) |
|||||||||||||||||
056 + kl + iead + uad | (pl + 7) / 8 | Contents of payload (pl is in bits ) depending on the encrypted section key-wrapping method (value at offset 26): | |||||||||||||||
Value at offset 26 | Encrypted section key-wrapping method | Meaning | |||||||||||||||
X'00' | No key-wrapping method. Only applies when key is clear, that is, when the value at offset 8 = X'01'. | Only the key material will be in the payload. The key token is external or internal. | |||||||||||||||
X'02' | AESKW | An encrypted payload which the Segment 2 code creates by wrapping the unencrypted AESKW formatted payload. The payload is made up of the integrity check value, pad length, length of hash options and hash, hash options, hash of the associated data, key material, and padding. The key token is internal. | |||||||||||||||
X'03' | PKOAEP2 | An encrypted PKOAEP2 payload which the Segment 2 code creates using the RSAES-OAEP scheme of
the PKCS #1 v2.1 standard. The message M is encoded for a given hash algorithm using the
Bellare and Rogaway Optimal Asymmetric Encryption Padding (OAEP) method for encoding messages. For
PKAOEP2, M is defined as follows: M = [32 bytes: hAD] || [2 bytes: bit length of the clear key] || [clear key] where hAD is the message digest of the associated data, and is calculated using the SHA-256 algorithm starting at offset 30 for the length in bytes of all the associated data for the key token (length value at offset 32). The encoded message is wrapped with an RSA public-key according to the standard. The key token is external. |
|||||||||||||||
End of optional wrapped AESKW formatted payload | |||||||||||||||||
End of AESKW components | |||||||||||||||||
Note: All numbers are in big endian format.
|