This is a proposal to extend the current activation/theft-deterrence formats and protocols to support delegation. Connectivity to our deployments is not good enough in practice to support mandatory connections to antitheft.laptop.org in order to support passive or active kill functionality. Daily activation and active-kill authority needs to be delegated to schoolservers (or even to a teacher's XO) in order to be practical. Further, the mechanism must work even if no online connection can ever be made by the XO or XS to OLPC's upstream servers.
Further discussion: http://lists.laptop.org/pipermail/security/2008-June/000436.html Activation delegation --------------------- The first step is to introduce delegation into the activation lease format. The idea here is that OLPC will generate a 'delegate' activation lease, which says that, until the expiration time of the delegate lease, a specified keypair will be able to activate the machine. For example: OLPC signs: "delegate activation until 2009-01-1 to keyid ABCDEF" schoolserver w/ keyid ABCDEF daily signs: "activate machine until tomorrow" The durations of each of these leases can be varied to trade off trust in the schoolserver and the "market window" a thief has to sell the machine before the activation expires. For example, in places with less risk of theft the school server might generate weekly or monthly leases for the machines in the classroom, or it might generate longer leases before weekends, vacations, etc. If theft of a schoolserver is a concern, the top-level delegation to the schoolserver might be monthly; if the schoolserver is adequately protected by its own passwords the delegation might be yearly or "infinite". The same basic mechanism can work with an arbitrary chain of delegations. Each signature in the chain takes ~2s to check, and adds that amount of time to every boot. Excessive chain length should thus be avoided, but a three-level hierarchy such as: OLPC signs: "delegate activation 'forever' to Uruguay Min. Ed." Uruguay Min. Ed. signs: "delegate activation for the year to school#XXXX" School daily #XXXX signs: "activate until tomorrow" might be reasonable for some deployments. In particular, this structure would allow the country to manage the assignment of laptops to school servers without the involvement of OLPC's activation service. Technical implementation: ------------------------- The existing activation lease and developer key formats are defined by: http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats We add a new disposition type, 'D', to the activation lease and developer key formats. The 'D' character should be immediately followed by a space and then a 64-byte keyid in both the activation lease and developer key formats. We also change the version identifier to '02' for leases and keys with this disposition. A complete delegated lease looks like: act02: SHF12345678 D aa<60>aa 20090101T000000Z sig01: sha256 bb<60>bb 7<510>7 key01: 88<474>aa<60>aa act01: SHF12345678 K 20081201T000000Z sig01: sha256 aa<60>aa 9<510>9 I have used the notation <N> to indicate that N characters were elided from a field in this example. The bb<60>bb keyid corresponds to the public key held by OLPC. The aa<60>aa keyid in this example is the public key held by the schoolserver. The signed data for act02/dev02 includes '<disposition>:<keyid>' where the act01/dev01 formats have the substring '<disposition>' in the signed data. Note that the existing signature and key formats are newline terminated. Since I am trying to make the smallest possible changes to the existing formats, the result is effectively a three-line lease. I would encourage these lines to be kept together to allow efficient checking and easier separation of leases from a concatenated file, but in order to give ourselves future flexibility there shouldn't be any required ordering of the three lines. Absent firmware changes, OFW will ignore discard all three of the lines of this activation lease (the first two because the format is new, and the third because the keyid is not known to OFW) and invoke the activation code in the initial ramdisk. This activation code can correctly parse the lease and proceed with the boot process. Firmware support would be needed to support the equivalent delegation mechanism for developer keys. This functionality is less critical; OLPC should be routinely generating developer keys for all laptops manufactured, and since developer keys do not expire the delegation mechanism is not as useful. It could be argued that adding delegation to developer keys is needless complexity and should be omitted. Theft-deterrence protocol delegation ------------------------------------ The theft-deterrence protocol http://wiki.laptop.org/go/Theft_Deterrence_Protocol already provides a delegation mechanism. However, the mechanism was designed to include a request of the 'top-level' antitheft protocol at every query to confirm the delegation. The mechanism for delegating blacklists management to one server, updates to another, and lease renewal to a third is adequate but clumsy, requiring chaining the delegations between the multiple servers. The simplest workable extension to the delegation mechanism is to add an "expiration time" field to the delegate response. This allows future requests to bypass the top-level OLPC service until the expiration time is reached. Avoiding the first-boot ping of the top-level service is accomplished by specifying that a special file named '/security/delegate.json' will be interpreted to contain an initial response from the top-level server. It must be signed by the top-level server. The nonce in this request should be the sha256 hash of the string "<SN>:<UUID>" for the machine. The /security/delegate.json file should be deleted after it is processed. Delegating the theft-deterrence protocol confers authority to designate a given laptop 'stolen' or not. A local blacklist can be maintained on the schoolserver in cases where connectivity is inadequate to support distribution of a central blacklist. Secure reflash delegation ------------------------- Uruguay has expressed concern about the ability to bypass their security system by, for example, installing Peru's build on their machines using the secure reflash mechanism. I believe the fundamental issue here is solved by standardizing on this core security functionality across all deployments, so that Peru's build does not grant permissions denied by Uruguay's build. But the critical issue of protecting the root user on the machine remains: if Uruguay locks down root to prevent clock-resetting attacks, but Peru does not, then reflash can be used to gain root. Whatever protections are enforced by reflash must also be enforced by olpc-update. One proposal is to specify that a special file 'lock.key' in the /security directory on NAND be used to specify that, in addition to the usual fs.zip signatures, a valid signature by the key specified by lock.key is required in order to perform reflash or olpc-update. As long as only root is able to write/erase /security/lock.key, the desired protection can be accomplished. Alternatives ------------ The mechanism described here extends the act01 and dev01 formats. An alternative would be to extend the sig01 format to support arbitrarily-chained signatures. The expiration time and possibly serial-number binding would have to be moved into the signature format in that case, but this alternative might allow OLPC to uniformly delegate all the signed objects in the security system. It is not clear whether this is a workable mechanism in practice for things like kernel signatures, but it might suffice to allow a schoolserver to proxy for the upstream antitheft.laptop.org service. In fact, the delegation mechanism for the theft-deterrence protocol could be effectively replaced by simply directing the query first to the schoolserver (perhaps via DNS redirection by the schoolserver), and only querying upstream if the schoolserver is unable to provide an acceptably-signed response using its delegated authority. [I may attempt to explore this alternative in a future email.] A different alternative is to simply change the trusted keypairs in the firmware, os, ramdisk, secure reflash, and theft-deterrence/update code, effectively creating multiple separate domains of authority for each major deployment. This doesn't solve the necessity of delegating daily activation authority to a school server, unless either all school servers share a key pair, or else the build is customized for each school. A more limited version of this alternative is to simply allow for customization of the secure-reflash keypair in firmware for each deployment. This accomplishes the aims of secure reflash delegation with minimal collateral damage. ----------- Comments requested. Is there a way to accomplish our aims with less work or more generality? Are there security implications I'm not thinking of? Does this pass the Mitch Bradley sniff test? --scott -- ( http://cscott.net/ ) _______________________________________________ Security mailing list [email protected] http://lists.laptop.org/listinfo/security
