Firmware Key and Signature Formats: Difference between revisions
(Update firmware formats) |
(Tweak hashnames.) |
||
Line 21: | Line 21: | ||
sig01: hashname keyid data\n |
sig01: hashname keyid data\n |
||
3 2 2 |
3 2 2 6 1 64 1 N 1 |
||
So that's: |
So that's: |
||
Line 28: | Line 28: | ||
* A colon |
* A colon |
||
* A space |
* A space |
||
* A |
* A six character name for the hash function used by this signature |
||
** " |
** "sha256" indicates that this is an RSASSA-PSS signature using SHA256 as the hash and MGF1-SHA256 as the mask function. |
||
** " |
** "rmd160" indicates that this is an RSASSA-PKCS1-v1_5 signature using RIPEMD-160 as the hash function. |
||
* A space |
* A space |
||
* The 64 character key ID, which are the trailing 64 characters of the "key data" in the key format above. (for the immediate future you can ignore this in the firmware, and just use a single key for each task.) |
* The 64 character key ID, which are the trailing 64 characters of the "key data" in the key format above. (for the immediate future you can ignore this in the firmware, and just use a single key for each task.) |
||
Line 40: | Line 40: | ||
==Antitheft/Activation Lease== |
==Antitheft/Activation Lease== |
||
act01: expiration sig01: |
act01: expiration sig01: sha256 keyid data\n |
||
3 2 2 16 1 3 2 2 |
3 2 2 16 1 3 2 2 6 1 64 1 N 1 |
||
An activation lease begins with: |
An activation lease begins with: |
||
Line 50: | Line 50: | ||
* The 16-character [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601] UTC expiration time in basic format (no dashes or colons) and no fractional seconds. (eg: "20070816T173500Z") |
* The 16-character [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601] UTC expiration time in basic format (no dashes or colons) and no fractional seconds. (eg: "20070816T173500Z") |
||
** should consist of the string "00000000T000000Z" if not present or not applicable. |
** should consist of the string "00000000T000000Z" if not present or not applicable. |
||
It is then followed by a signature, in the format above and with hashname " |
It is then followed by a signature, in the format above and with hashname "sha256", of the string: |
||
<serial-number>:<uuid>:<expiration time> |
<serial-number>:<uuid>:<expiration time> |
||
where the expiration time in the string is identical in format and content to the signature expiration time. |
where the expiration time in the string is identical in format and content to the signature expiration time. |
||
Line 58: | Line 58: | ||
==Developer key== |
==Developer key== |
||
dev01: sig01 |
dev01: sig01 sha256 keyid data\n |
||
3 2 2 3 2 1 |
3 2 2 3 2 1 6 1 64 1 N 1 |
||
An developer key begins with: |
An developer key begins with: |
||
Line 66: | Line 66: | ||
* A colon |
* A colon |
||
* A space |
* A space |
||
It is then followed by a signature, in the format above and with hashname " |
It is then followed by a signature, in the format above and with hashname "sha256", of the string: |
||
<serial-number>:<uuid>:00000000T000000Z |
<serial-number>:<uuid>:00000000T000000Z |
||
For example: |
For example: |
Revision as of 19:28, 25 August 2007
This page describes the key and signature formats understood by OFW. The Firmware Security page describes how these are used.
Key
key01: data\n 3 2 2 N 1
So that's:
- The literal string "key"
- The two digit version number ("01" for now)
- A colon
- A space
- The key data
- A newline
The key data is a hexadecimal-encoded octet string. The octet string is the ASN.1 DER encoding of an RSA public key given by Appendix A.1.1 of RSA PKCS #1, version 2.1.
Future versions of the key format might allow different algorithms.
Signature
sig01: hashname keyid data\n 3 2 2 6 1 64 1 N 1
So that's:
- The literal string "sig"
- The two digit version number ("01" for now)
- A colon
- A space
- A six character name for the hash function used by this signature
- "sha256" indicates that this is an RSASSA-PSS signature using SHA256 as the hash and MGF1-SHA256 as the mask function.
- "rmd160" indicates that this is an RSASSA-PKCS1-v1_5 signature using RIPEMD-160 as the hash function.
- A space
- The 64 character key ID, which are the trailing 64 characters of the "key data" in the key format above. (for the immediate future you can ignore this in the firmware, and just use a single key for each task.)
- This includes the exponent and the least significant bytes of the modulus
- A space
- The signature data as a hexadecimal-encoded string. The encoded data is the octet string given by section 8.1.1/8.2.1 of RSA PKCS #1, version 2.1.
- A newline
Antitheft/Activation Lease
act01: expiration sig01: sha256 keyid data\n 3 2 2 16 1 3 2 2 6 1 64 1 N 1
An activation lease begins with:
- The literal string 'act'
- The two digit version number ("01" for now)
- A colon
- A space
- The 16-character ISO 8601 UTC expiration time in basic format (no dashes or colons) and no fractional seconds. (eg: "20070816T173500Z")
- should consist of the string "00000000T000000Z" if not present or not applicable.
It is then followed by a signature, in the format above and with hashname "sha256", of the string:
<serial-number>:<uuid>:<expiration time>
where the expiration time in the string is identical in format and content to the signature expiration time.
For example:
SHF725001A0:414737D8-2312-9241-9C7B-9886CB74403C:20080819T052946Z
Developer key
dev01: sig01 sha256 keyid data\n 3 2 2 3 2 1 6 1 64 1 N 1
An developer key begins with:
- The literal string 'dev'
- The two digit version number ("01" for now)
- A colon
- A space
It is then followed by a signature, in the format above and with hashname "sha256", of the string:
<serial-number>:<uuid>:00000000T000000Z
For example:
SHF725001A0:414737D8-2312-9241-9C7B-9886CB74403C:00000000T000000Z
Note that the payload is identical to that of an activation lease, although developer keys never expire. The verification key used also differs.