Firmware Key and Signature Formats: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Update firmware formats)
(Tweak hashnames.)
Line 21: Line 21:


sig01: hashname keyid data\n
sig01: hashname keyid data\n
3 2 2 3 1 64 1 N 1
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 three character name for the hash function used by this signature
* A six character name for the hash function used by this signature
** "sha" indicates that this is an RSASSA-PSS signature using SHA256 as the hash and MGF1-SHA256 as the mask function.
** "sha256" indicates that this is an RSASSA-PSS signature using SHA256 as the hash and MGF1-SHA256 as the mask function.
** "rip" indicates that this is an RSASSA-PKCS1-v1_5 signature using RIPEMD-160 as the hash 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: sha keyid data\n
act01: expiration sig01: sha256 keyid data\n
3 2 2 16 1 3 2 2 3 1 64 1 N 1
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 "sha", of the string:
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 sha keyid data\n
dev01: sig01 sha256 keyid data\n
3 2 2 3 2 1 3 1 64 1 N 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 "sha", of the string:
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.

Resources