STATOAH2

Edit online

This rule_array keyword causes all data to be returned in one VUD block. The STATOAH2 keyword returns an output that is very similar to its predecessor STATOAHL. You must use it starting with CCA 8.0 on CEX8S cryptographic coprocessors. The returned data contains Dilithium public keys. The described structure also comprises extra data fields that contains output if the SIG2STAT keyword is specified.

The VUD block header and data has a layout as described in Table 1:
Table 1. Output data format for the STATOAH2 keyword

A table with five columns describing the layout of the VUD block header and data.
Offset Size Field Subordinate data type Description
Begin outer templating
4 1 Struct name signed_data_t Name of structure


Type: binary integer
Value:
0x82 (SIGNED_DATA_T: 0x82)y
5 1 Struct version signed_data_t Version of structure


Type:  binary integer
Value: 0x00
6 4 Signed data len signed_data_t Length of the entire signed_data_t structure, including appended data and signature


Type: binary integer, big-endian
10 4 Data offset signed_data_t Offset from start of the data sub-struct (here) to the start of the actual data payload.


Type:  binary integer, big-endian
Value: 0x14
14 4 Data len signed_data_t Length of the data payload


Type:  binary integer, big-endian
18 4 Sig offset signed_data_t Offset from start of the sig sub-structure (here) to the start of the actual signature.


Type:  binary integer, big-endian
22 4 Sig len signed_data_t Length of the signature


Type: binary integer, big-endian
26 4 Sig type signed_data_t Type of signature


Type: binary integer, big-endian
Value: 0x63 (CCA_DUAL_SIG  0x63)
signed_data_t: 26 bytes (+ VUD fields = 30 bytes)
Begin payload

Data format: This data matches the output from the secure bootloader of the adapter. Assuming the same nonce is provided and given correct ordering of operations (query the bootloader first) the payload data hashes to the same value as that data provided by the secure bootloader.

The overall structure is called health_t, as indicated by the enumerated value in the first struct_id_t name field. This contains multiple sub-structures, each reproduced here.
0 1 name struct_id_t Sub-structure that defines the name and version of the data structure

Enum value: HEALTH_T (0x90)
1 1 version struct_id_t HEALTH_T (0x00)
Begin: Rom_status_t
2 1 name Rom_status_t:struct_id_t Rom status name

Enum value: ROM_STATUS_T (0x00)
3 1 version Rom_status_t:struct_id_t Rom status version (0x00)
4 2 Rsvd1 Rom_status_t (0x00)
6 2 Rom_version Rom_status_t Rom_version is a packed representation of the POST0 and MB0 version numbers.
8 1 Page1_certified Rom_status_t Has the value 1 if MB1 has successfully performed an IBM_INIT command to the point of installing the page1 certificate and has value 0 otherwise.
9 2 Rsvd2 Rom_status_t 0x00
11 4 Boot_count_right Rom_status_t The number of times the card has been booted and SSP is reset. MB0 has run far enough to enforce the state rules.
15 8 adapterID Rom_status_t Byte array of adapter unique numeric serial number, taken from the DS3645 Silicon Serial Number register.
Begin: Rom_status_t:xcVpd_t Byte array of Vital Product Data (VPD), 0x100 total bytes.
23 1 Ds_tag Rom_status_t:xcVpd_t 0x82, tag for description field
24 2 Ds_length Rom_status_t:xcVpd_t 0x2C, description length
26 44 Ds Rom_status_t:xcVpd_t ASCII description
70 1 Vpdr_tag Rom_status_t:xcVpd_t 0x90, tag for VPDR field
71 2 Vpdr_length Rom_status_t:xcVpd_t 0x00CD, length of VPDR
73 2 Ec_tag Rom_status_t:xcVpd_t EC, ASCII tag for EC field
75 1 Ec_length Rom_status_t:xcVpd_t 0x07, length of EC field
76 7 Ec Rom_status_t:xcVpd_t ASCII field
83 2 Pn_tag Rom_status_t:xcVpd_t PN, ASCII tag for part number field
85 1 Pn_length Rom_status_t:xcVpd_t 0x07, length of PN field
86 7 Pn Rom_status_t:xcVpd_t ASCII field
93 2 Fn_tag Rom_status_t:xcVpd_t FN, ASCII tag for FRU number field
95 1 Fn_length Rom_status_t:xcVpd_t 0x07, length of FN field
96 7 Fn Rom_status_t:xcVpd_t ASCII field
103 2 Ve_tag Rom_status_t:xcVpd_t VE, ASCII tag for Secure part number field
105 1 Ve_length Rom_status_t:xcVpd_t 0x07, length of VE field
106 7 Ve Rom_status_t:xcVpd_t ASCII field
113 2 Mf_tag Rom_status_t:xcVpd_t MF, ASCII tag for manufacturing location field
115 1 Mf_length Rom_status_t:xcVpd_t 0x02, length of MF field
116 2 Mf Rom_status_t:xcVpd_t ASCII field
118 2 Sn_tag Rom_status_t:xcVpd_t SN, ASCII tag for serial number field
120 1 Sn_length Rom_status_t:xcVpd_t 0x0C, length of SN field
121 4 Sn_hdr Rom_status_t:xcVpd_t first part of serial number
125 8 Sn Rom_status_t:xcVpd_t Rest of serial number
133 2 cu_tag Rom_status_t:xcVpd_t CU tag
135 1 cu_length Rom_status_t:xcVpd_t 0x08
136 8 cu Rom_status_t:xcVpd_t Hex data; card unique value
144 2 Rv_tag Rom_status_t:xcVpd_t RV, ASCII tag for checksum field
146 1 Rv_length Rom_status_t:xcVpd_t Length of reserved field
147 1 Checksum Rom_status_t:xcVpd_t 1 byte checksum field
148 130 Reserved Rom_status_t:xcVpd_t Reserved field, all 0x00 bytes
278 1 End_tag Rom_status_t:xcVpd_t 0x78, end tag
End: Rom_status_t:xcVpd_t
279 1 Init_state Rom_status_t
280 1 Seg2_state Rom_status_t State of segment 2:


UNOWNED 0x00
OWNED_BUT_UNRELIABLE 0x01
RUNNABLE 0x02
RELIABLE_BUT_UNRUNNABLE 0x03
281 1 Seg3_state Rom_status_t State of segment 3 (same possible values as Seg2_state)
282 2 Owner2 Rom_status_t
284 2 Owner3 Rom_status_t
286 1 Active_seg1 Rom_status_t
287 2 Rsvd3 Rom_status_t
289 4 usr Rom_status_t
End: Rom_status_t + struct_id_t (291 + 2 = 293 bytes)
32 bytes nonce Raw nonce Value passed by user to be signed as part of the returned payload. This indicates the signature is live, not a replayed value that was calculated earlier.
Begin: var_t array for segment identifiers A var_t is a simple structure with 2 fields, specifying an offset and a length. These help you find the item the var_t describes.

In this section are three var_t structures, followed in the next section by three segment identifiers that are pointed to by the var_t structures.
0 4 Offset Var_t : for segment 1 Offset to the segment identifier from byte 0 of this field
4 4 length Var_t : for segment 1 Length of the segment identifier
8 4 Offset Var_t : for segment 2 Offset to the segment identifier from byte 0 of this field
12 4 length Var_t : for segment 2 Length of the segment identifier
16 4 Offset Var_t : for segment 3 Offset to the segment identifier from byte 0 of this field
20 4 length Var_t : for segment 3 Length of the segment identifier
End: var_t array (24 bytes)
Begin: segment identifiers array, struct is mbid_t mbid_t indicates: Miniboot identifier. Miniboo’ is the name for the secure boot loader that manages the firmware loaded to the adapter.
Begin: mbid_t for segment 1
0 1 name mbid_t:struct_id_t 0x81, name for mbid_t,
1 2 version mbid_t:struct_id_t 0x03, CCA_DUAL_SIG version of mbid_t: indicates that the secure bootloader uses ECDSA and CRDL-DSA to verify image for this loaded segment of firmware.
2 1 type mbid_t Type field:

Value is: FAM_OWNER 0x03

If type is FAM_OWNER, the adapterID is a bit vector that specifies onto which device families the image identified by the mbid_t parameter may be loaded. An attempt to load an image onto a device belonging to a family whose bit in adapterID is not set, will fail.
3 1 name mbid_t:ownerID_t: struct_id_t 0x80, name for ownerID_t structure
4 1 version mbid_t:ownerID_t: struct_id_t
5 1 seg mbid_t:ownerID_t Indicates the segment to which this ownerID_t applies, may be 0x01, 0x02 or 0x03.
6 2 Owner2 mbid_t:ownerID_t If the seg field holds 0x01, then this field holds 0x0000. Otherwise, this field holds the two-byte owner ID for the applicable segment 2.
8 2 Owner3 mbid_t:ownerID_t If the seg field holds 0x01 or 0x02, then this field holds 0x0000. Otherwise, this field holds the two-byte owner ID for the applicable segment 2.
10 1 trust1 mbid_t Owner specified value of what to do if a lower level segment is updated. This trust1 field value refers to segment 1, and is 0x00 if the seg value is 0x01. For other cases, the meaning implies to trust or not trust, and is of interest to holders of signing keys.
11 1 Trust2 mbid_t Owner specified value of what to do if a lower level segment is updated. This trust2 field value refers to segment 2, and is 0x00 if the seg value is 0x01 or 0x02. For other cases, the meaning implies to trust or not trust, and is of interest to holders of signing keys.
12 80 name mbid_t Byte array for image name
92 2 rev mbid_t Revision assigned to the segment by the owner of the segment that this mbid_t structure is describing
94 64 mbid_t
158 8 hash mbid_t SHA512 hash of the image identified by the name field
166 4 reserved mbid_t:Etc (var_t) Reserved field. The data has validity only inside the card.
170 4 reserved mbid_t:Etc (var_t) Reserved field. The data has validity only inside the card.
174 4 offset mbid_t:Token (var_t) Segment key pointer field.

This var_t parameter indicates the offset from byte 0 of this field to the beginning of the public key which describes the segment that this mbid_t represents.

178 4 len mbid_t:Token (var_t) Length of the public key token for the segment
Begin: mbid_t:token for segment 1 Explanation of the public key here

A firmware load operation is actually a pre-packaged and signed *command*, as recognized by the secure bootloader in the adapter. While it is commonly said that the firmware is signed, it is more accurate to say that the firmware load command is signed, and includes the new firmware. Each firmware load command has been signed by the owner of a signing key, and this owner becomes the owner of the segment after the owner’s firmware has been loaded. Thus we refer to the ‘segment owner’ as the person who held the private key that signed the command to load the firmware for that segment. Each firmware load command package also includes a signed version of the public key of the ‘segment owner’ for the segment to be loaded. The segment owner public key signature has been computed with the private key of the owner of the lower segment that is expected to have been installed. For example, consider load of a new segment 2:

  1. The segment 2 load command is a binary software image, with:
    1. firmware image for new segment 2
    2. command of how to load the segment 2
    3. signature over the firmware image and command, calculated with segment 2 owner private key
    4. segment 2 owner public key
    5. signature over segment 2 owner public key calculated with segment 1 owner private key
  2. The secure boot loader
    1. uses segment 1 owner public key to verify signature over segment 2 owner public key
    2. uses segment 2 owner public key to verify signature over firmware and command
    3. executes the command.

Given the above explanation, it is now possible to say that the public key included in the mbid_t is the segment owner public key for the segment that the mbid_t describes. If the mbid_t describes segment 1, then the segment 1 owner public key is included at the end of the mbid_t when returned from the adapter.
0 1 name mbid_t:token:struct_id_t struct_id_t, sub-structure that defines the name and version of the data structure

Enum value: ECC_TOKEN_T (0x97)
1 1 version mbid_t:token:struct_id_t 0x00
2 2 Rsvd1 mbid_t:token 0x00
4 4 tokenLength mbid_t:token Length of token including header.
8 4 Rsvd2 mbid_t:token 0x00
12 1 name mbid_t:token:struct_id_t struct_id_t defines the name and version of the data structure

Enum value: ECC_PUBLIC_TOKEN_T (0x99)
13 1 version mbid_t:token:struct_id_t 0x00
14 2 sectionLength mbid_t:token Length of this section
16 4 Rsvd1 mbid_t:token 0x00
20 1 curveType mbid_t:token Type of curve

Value: 0x00 (Prime/NIST)
21 1 Rsvd2 mbid_t:token 0x00
22 2 pLength mbid_t:token Length of curve

Value: 0x0209 (P521)
24 2 qLen mbid_t:token 0x91
26 1 Pubkey_preface mbid_t:token Value: 0x04
27 72 Ecc_public_x mbid_t:token
99 72 Ecc_public_y mbid_t:token Y value for the public key

Length is 66 bytes for ECC P521 key + padding bytes for hardware use of the value.

Dilithium public key: typedef struct mb_dilithium_public_t
171 8 der1 mbid_t:token

SEQ 0 x82 ( len 0 x942 )
SEQ ( len 15)
OBJID ( len 11)
179 11 OID1 mbid_t:token MB_DILITHIUM_87_OID
190 7 der2 mbid_t:token


NULL ( len 0)
BIT STRING 0 x82
( len 0 x92d ) (0 bits )
197 7 der3 mbid_t:token


SEQ 0 x82 ( len 0 x928 )
BIT STRING
( len 33) (0 bits )
204 32 nonce mbid_t:token rho (length is 32 bytes)
236 5 der4 mbid_t:token


BIT STRING 0 x82
( len 0 x901 ) (0 bits )
241 2304 t1 mbid_t:token K*low bits (vector)

Length is 2304 bytes for CRYSTALS-Dilithium (8,7) Round 2.
End: mbid_t:token for segment 1 (2545 bytes)
End: mbid_t for segment 1 (182 + 2545 = 2727 bytes)
2727 mbid_t mbid_t for segment 2 The mbid_t for each segment is the same size and has the same fields as the mbid_t for segment 1
2727 mbid_t mbid_t for segment 3 The mbid_t for each segment is the same size and has the same fields as the mbid_t for segment 1
End: segment identifiers array, struct is mbid_t (3 * 2727 bytes = 8181 bytes)
End payload

Begin signature section sig-section (if SIG2STAT passed)
0 132 ECDSA signature Raw r and s values Raw r and s values for signature over SHA-512 hash of payload. The r and s values are 66 bytes each, r is first.
132 4668 CRDL-DSA signature A byte string The CRDL-DSA signature is the concatenation of a bit-packed representation of z and encodings of h and c in that order.
Note: This process performs a SHAKE hash of the incoming SHA-512 hash of the payload before signing.
4800 64 Payload hash Raw hash value Raw SHA-512 hash over the payload. This is the value used for calculating the signature.
Total structure size: 

VUD length : 2 bytes
VUD header : 4 bytes ( CFQ_STATOAHL_VUD x0F12 )
signed_data_t : 26 bytes
health_t : 349 bytes ( includes Rom_status_t and Nonce )
mbid_t array : 8181 bytes ( 1 element per segment )
VUD header : 4 bytes ( DPK_CERT_SPLIT x0030 )
split_length : 2 bytes
Signature section and hash : 4864 bytes
Total VUD : 13432 bytes
CPRB + subfunction code (2) + rule_array_len (2) + key_block_len (2)
Total with T2 CPRB 224 + 2 + 2 + 2 + 13432 = 13662
Total with T7 CPRB 5566 + 2 + 2 + 2 + 13432 = 19004 (TKE does this)