Redesign image header and TLV format

Description

There are a few problems with the current format of the image header and the TLV:

  • The image header contains a TLV length field. Since it is in the header, it will be included in the signature. However, some signature algorithms produce variable length signatures (ASN.1 takes an extra byte to encode an INTEGER if the high bit is set), meaning we can't know the length until after the signature is computed. Currently, there is a hack to allow the TLV signature to be slightly larger than the actual signature.

  • The information about the signature is mixed between the two places. Some information is stored in the flags field, and some in individual TLVs. The means we really can't have multiple signatures, and even if we tried with more than one TLV entry, there is only a single key_id field in the header.

There are two approaches we could take. We could deprecate the TLV length field, and the current flag bits, and add a single flag bit to indicate the new format header. It might also be easier to just change the magic number to change the format. Suggestions for the implementation:

  • Information about the TLV and signatures should not be in the image header (no flags, no length).

  • The TLV can follow the image, and can either have a magic and length at the start, or have a TLV entry that ends an end (0xFF seems like a good end marker). The former is slightly easier to process images with an external tool, but does change the format of the TLV.

  • There should be TLV keys for the SHA256 hash (current is OK), and one for each specific type of signature. There are two choices, either have a TLV key for setting the current key_id, or make this part of the data stored in a signature.

  • The TLV fields for signatures should fully specify the signature type (meaning more than just RSA-2048, but the full RSA2048-SHA256-PSS. We probably don't want to use the variable length OID values, but the values used should probably correspond to an OID.

Another option to consider would be to not use the existing TLV format at all, and require the signature to be an ASN.1-encoded block. This would be extensible, probably not expand the code too much, since we already use ASN.1 for existing signatures. The block could be typed, and it would be possible to then use a real X.509 certificate, or chain if we deem that to ever be necessary or useful.

Status

Assignee

Aditi Hilbert

Reporter

David Brown

Labels

None

Fix versions

Priority

Medium