[OLPC Security] Extending theft-deterrence to support delegation.

[C. Scott Ananian]

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/ )