Firmware Key and Signature Formats: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (added cats firmware and security)
(Update firmware formats)
Line 3: Line 3:
==Key==
==Key==


key01 data\n
key01: data\n
3 2 1 N 1
3 2 2 N 1


So that's:
So that's:
* The literal string "key"
* The literal string "key"
* The two digit version number ("01" for now)
* The two digit version number ("01" for now)
* A colon
* A space
* A space
* The key data
* The key data
Line 19: Line 20:
==Signature==
==Signature==


sig01 expiration keyid data\n
sig01: hashname keyid data\n
3 2 1 16 1 64 1 N 1
3 2 2 3 1 64 1 N 1


So that's:
So that's:
* The literal string "sig"
* The literal string "sig"
* The two digit version number ("01" for now)
* The two digit version number ("01" for now)
* A colon
* A space
* A space
* A three character name for the hash function used by this signature
⚫
* 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")
** "sha" indicates that this is an RSASSA-PSS signature using SHA256 as the hash and MGF1-SHA256 as the mask function.
⚫
** should consist of the string "00000000T000000Z" if not present or not applicable.
** firmware must ignore this expiration time if the signature is on a kernel or ramdisk.
** "rip" 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.)
** This includes the exponent and the least significant bytes of the modulus
** This includes the exponent and the least significant bytes of the modulus
* A space
* A space
* The signature data as a hexadecimal-encoded string. The encoded data is the ASN.1 DER encoding of an RSA PSS signature given by Appendix A.2.3 of [ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf RSA PKCS #1, version 2.1]. The hashAlgorithm field will have the value sha256, and the maskGenAlgorithm field will have the value mgf1SHA256.
* 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 [ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf RSA PKCS #1, version 2.1].
* A newline
* A newline


==Antitheft/Activation Lease==
==Antitheft/Activation Lease==


act01 sig01 expiration keyid data\n
act01: expiration sig01: sha keyid data\n
3 2 1 3 2 1 16 1 64 1 N 1
3 2 2 16 1 3 2 2 3 1 64 1 N 1


An activation lease begins with:
An activation lease begins with:
* The literal string 'act'
* The literal string 'act'
* The two digit version number ("01" for now)
* The two digit version number ("01" for now)
* a space
* A colon
* A space
⚫
It is then followed by a signature, in the format above, of the string:
⚫
* 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.
⚫
It is then followed by a signature, in the format above and with hashname "sha", 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 53: Line 58:


==Developer key==
==Developer key==
dev01 sig01 expiration keyid data\n
dev01: sig01 sha keyid data\n
3 2 1 3 2 1 16 1 64 1 N 1
3 2 2 3 2 1 3 1 64 1 N 1


An developer key begins with:
An developer key begins with:
* The literal string 'dev'
* The literal string 'dev'
* The two digit version number ("01" for now)
* The two digit version number ("01" for now)
* a space
* A colon
* A space
It is then followed by a signature, in the format above, of the string:
It is then followed by a signature, in the format above and with hashname "sha", of the string:
<serial-number>:<uuid>:00000000T000000Z
<serial-number>:<uuid>:00000000T000000Z
For example:
For example:

Revision as of 18:51, 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     3   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 three 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.
    • "rip" 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: sha keyid data\n
 3 2 2      16   1 3 2 2  3 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 "sha", 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 sha keyid data\n
 3 2 2  3 2 1 3 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 "sha", 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

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Firmware_Key_and_Signature_Formats&oldid=61778"