I will analyze this further, later. However, I see one minor issue with this proposal right away: there is no way for a key to delegate some but not all of its authority. Thus, at every level, separate keys must be used for separate purposes - activation, kernel, ramdisk, and secure-reflash - or all of these permissions will be synonymous. This is totally feasible; however, this does limit the extensible usability of this format.<br>
<br>I suggest that the <serial number> part of the chained signed data be replaced by an application-specific <application>:<authorization details> field. For example, for activation, this could be <br>act01:<serial number><br>
3 2 1 ?<br><br>This data would be global across a signature (no provision for passing subsets of authorazation, a la spki), and would need a plaintext home in the sig02 format.<br><br>This allows for future definitions of, for example, a kernel signature format here, which would not have to be tied to serial number. It would also allow for a local school server to have a single key used for signing distinct authorizations with distinct expiration times, which seems simpler to me (especially as you imagine the number of distinct authorization types growing in the future).<br>
<br>Jameson<br><br><div class="gmail_quote">On Thu, Jun 12, 2008 at 1:17 PM, C. Scott Ananian <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As promised, here's an alternative which only touches the sig01<br>
signature format. I think I prefer this; let me know if you agree.<br>
--scott<br>
<br>
------------------------------------<br>
This is an alternate version of the previous proposal, which<br>
concentrates its changes on one part of the security system: the sig01<br>
signature format. By introducing a delegation/chaining mechanism into<br>
signatures, all parts of our security system which involve signatures<br>
can be delegated.<br>
<br>
Format details<br>
--------------<br>
<br>
We propose a 'sig02' signature format, as follows:<br>
<br>
sig02: hashname_1 key-or-keyid_1 expiration_1 data_1 hashname_2 ...\n<br>
3 2 2 6 1 N/64 1 16 1 M 1 ... 1<br>
<br>
The "hashname key expiration data" section is repeated as many<br>
times as there are signatures in the chain. We will call each<br>
repetition an 'sg' below. So the contents of a sig02 are:<br>
<br>
* The literal string "sig"<br>
* The two digit version number ("02")<br>
* A colon<br>
* A space<br>
At least one sg, consisting of:<br>
* A six character name for the hash function used by this signature<br>
o "sha256" indicates that this is an RSASSA-PSS signature<br>
using SHA256 as the hash and MGF1-SHA256 as the mask function.<br>
o "rmd160" indicates that this is an RSASSA-PKCS1-v1_5 signature<br>
using RIPEMD-160 as the hash function.<br>
* A space<br>
* At least 64 characters of key data in the key01 format. The<br>
characters must be a suffix of the full key data; if more than<br>
64 characters are present they are assumed to be the full key.<br>
o 64 characters is sufficient to include the exponent and<br>
the least significant bytes of the modulus<br>
o it is recommended that only keyid_1 be abbreviated.<br>
* A space<br>
* An ISO 8601 UTC expiration time in basic format (no dashes or<br>
colons) and no fractional seconds. (eg: "20070816T173500Z").<br>
After this time, the sg must no longer be considered valid.<br>
o The string "00000000T000000Z" indicates that the given<br>
sg never expires.<br>
* The signature data as a hexadecimal-encoded string. The encoded data<br>
is the octet string given by section 8.1.1/8.2.1 of RSA PKCS #1,<br>
version 2.1. The data to be signed is described below.<br>
* A space (if this sg confers a delegation) or a newline<br>
(terminating the signature chain).<br>
<br>
The sig02 line validates a byte string called the 'certified<br>
data'. For the final sg in the line, the 'data' field is a<br>
signature of the certified data using the keypair specified in the<br>
sg. For all other sgs, the 'data' field is a signature of the string:<br>
<next keyid>:<serial number>:<expiration time><br>
where key_1 is used to sign a string containing key_2, key_2 signs a<br>
string containing key_3, etc. Each delegation is bound to a specific<br>
laptop serial number (which should be the same if the signature is to<br>
be meaningful).<br>
<br>
A sig02 with delegation is formed by concatenating the signature<br>
of specific certified data onto a prefix of sgs which confer<br>
authority. A sig02 without delegation is identical to the sig01<br>
format, except for the additional expiration time field.<br>
<br>
Validating a file containing sig01 and sig02 signatures starts by<br>
scanning the file for sig01 and sig02 signatures with an initial<br>
'keyid' matching a trusted keypair. For a sig02, we then validate<br>
each sg in turn until we reach the final sg, which should validate<br>
against the certified data.<br>
<br>
Uses<br>
----<br>
Since the act01 lease format and dev01 key format incorporate a<br>
signature, they can be delegated by simply using the sig02 signature<br>
format instead of sig01.<br>
<br>
Kernels, ramdisks, and secure-reflash signatures can be delegated in<br>
the same way, but these signatures will are bound to a specific<br>
serial number. This will probably make this mechanism less useful.<br>
<br>
The theft-deterrence protocol can be delegated by simply redirecting<br>
the requests from <a href="http://antitheft.laptop.org" target="_blank">antitheft.laptop.org</a> to the school server, possibly<br>
via DNS redirection. The school server will include a delegated<br>
signature in its response, which gives it authority to answer for a<br>
specific delegated laptop. If the school server is not authoritative<br>
for a given laptop, it can relay the request to an upstream service if<br>
it has connectivity.<br>
<br>
No special initialization is necessary to inform the laptop that its<br>
theft-deterrence responses will be delegated.<br>
<br>
As before, current OFW releases ought to ignore 'sig02' signatures,<br>
which will punt activation to the initial ramdisk which can be updated<br>
to parse & accept them. In the future, OFW can parse the sig02 format<br>
itself, which will allow its use for developer keys, kernels,<br>
ramdisks, and secure reflash (if these uses are valuable in practice).<br>
<div><div></div><div class="Wj3C7c"><br>
--<br>
( <a href="http://cscott.net/" target="_blank">http://cscott.net/</a> )<br>
_______________________________________________<br>
Security mailing list<br>
<a href="mailto:Security@lists.laptop.org">Security@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/security" target="_blank">http://lists.laptop.org/listinfo/security</a><br>
</div></div></blockquote></div><br>