[OLPC Security] Extending theft-deterrence to support delegation.
Jameson "Chema" Quinn
jquinn at cs.oberlin.edu
Thu Jun 12 16:32:04 EDT 2008
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.
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
act01:<serial number>
3 2 1 ?
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.
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).
Jameson
On Thu, Jun 12, 2008 at 1:17 PM, C. Scott Ananian <cscott at laptop.org> wrote:
> As promised, here's an alternative which only touches the sig01
> signature format. I think I prefer this; let me know if you agree.
> --scott
>
> ------------------------------------
> This is an alternate version of the previous proposal, which
> concentrates its changes on one part of the security system: the sig01
> signature format. By introducing a delegation/chaining mechanism into
> signatures, all parts of our security system which involve signatures
> can be delegated.
>
> Format details
> --------------
>
> We propose a 'sig02' signature format, as follows:
>
> sig02: hashname_1 key-or-keyid_1 expiration_1 data_1 hashname_2 ...\n
> 3 2 2 6 1 N/64 1 16 1 M 1 ... 1
>
> The "hashname key expiration data" section is repeated as many
> times as there are signatures in the chain. We will call each
> repetition an 'sg' below. So the contents of a sig02 are:
>
> * The literal string "sig"
> * The two digit version number ("02")
> * A colon
> * A space
> At least one sg, consisting of:
> * A six character name for the hash function used by this signature
> o "sha256" indicates that this is an RSASSA-PSS signature
> using SHA256 as the hash and MGF1-SHA256 as the mask function.
> o "rmd160" indicates that this is an RSASSA-PKCS1-v1_5 signature
> using RIPEMD-160 as the hash function.
> * A space
> * At least 64 characters of key data in the key01 format. The
> characters must be a suffix of the full key data; if more than
> 64 characters are present they are assumed to be the full key.
> o 64 characters is sufficient to include the exponent and
> the least significant bytes of the modulus
> o it is recommended that only keyid_1 be abbreviated.
> * A space
> * An ISO 8601 UTC expiration time in basic format (no dashes or
> colons) and no fractional seconds. (eg: "20070816T173500Z").
> After this time, the sg must no longer be considered valid.
> o The string "00000000T000000Z" indicates that the given
> sg never expires.
> * 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. The data to be signed is described below.
> * A space (if this sg confers a delegation) or a newline
> (terminating the signature chain).
>
> The sig02 line validates a byte string called the 'certified
> data'. For the final sg in the line, the 'data' field is a
> signature of the certified data using the keypair specified in the
> sg. For all other sgs, the 'data' field is a signature of the string:
> <next keyid>:<serial number>:<expiration time>
> where key_1 is used to sign a string containing key_2, key_2 signs a
> string containing key_3, etc. Each delegation is bound to a specific
> laptop serial number (which should be the same if the signature is to
> be meaningful).
>
> A sig02 with delegation is formed by concatenating the signature
> of specific certified data onto a prefix of sgs which confer
> authority. A sig02 without delegation is identical to the sig01
> format, except for the additional expiration time field.
>
> Validating a file containing sig01 and sig02 signatures starts by
> scanning the file for sig01 and sig02 signatures with an initial
> 'keyid' matching a trusted keypair. For a sig02, we then validate
> each sg in turn until we reach the final sg, which should validate
> against the certified data.
>
> Uses
> ----
> Since the act01 lease format and dev01 key format incorporate a
> signature, they can be delegated by simply using the sig02 signature
> format instead of sig01.
>
> Kernels, ramdisks, and secure-reflash signatures can be delegated in
> the same way, but these signatures will are bound to a specific
> serial number. This will probably make this mechanism less useful.
>
> The theft-deterrence protocol can be delegated by simply redirecting
> the requests from antitheft.laptop.org to the school server, possibly
> via DNS redirection. The school server will include a delegated
> signature in its response, which gives it authority to answer for a
> specific delegated laptop. If the school server is not authoritative
> for a given laptop, it can relay the request to an upstream service if
> it has connectivity.
>
> No special initialization is necessary to inform the laptop that its
> theft-deterrence responses will be delegated.
>
> As before, current OFW releases ought to ignore 'sig02' signatures,
> which will punt activation to the initial ramdisk which can be updated
> to parse & accept them. In the future, OFW can parse the sig02 format
> itself, which will allow its use for developer keys, kernels,
> ramdisks, and secure reflash (if these uses are valuable in practice).
>
> --
> ( http://cscott.net/ )
> _______________________________________________
> Security mailing list
> Security at lists.laptop.org
> http://lists.laptop.org/listinfo/security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080612/f0228482/attachment-0001.htm
More information about the Security
mailing list