#9045 HIGH 8.2.1: key delegation

[Zarro Boogs per Child]

#9045: key delegation
---------------------------------+------------------------------------------
           Reporter:  kimquirk   |       Owner:  cscott       
               Type:  defect     |      Status:  new          
           Priority:  high       |   Milestone:  8.2.1        
          Component:  security   |     Version:  not specified
         Resolution:             |    Keywords:               
        Next_action:  never set  |    Verified:  0            
Deployment_affected:  Uruguay    |   Blockedby:               
           Blocking:             |  
---------------------------------+------------------------------------------
Changes (by cscott):

 * cc: wmb at firmworks.com, wad, mstone, edmcnierney (added)


Comment:

 This bug needs further design and review.

 The v2 signature mechanism requires a unique signature file per machine
 serial number.  This is reasonable for activation leases and developer
 keys (the design goal), but doesn't fit the current build reflashing
 procedure well: there would need to be a different fs.zip, in effect, for
 each machine you reflashed.  You could probably combine the keys for, say,
 up to 1k machines in a single fs.zip, but delegated signatures for 15k
 machines may well be impractical.  The relevant metrics are: how large is
 the signature (ie, does it prevent the build + signature from fitting on a
 reasonable sized key), and how much time is added to the reflash procedure
 by having to scan through a large number of signatures looking for the
 'right' one.

 One might extend the delegation mechanism to support wildcard serial
 numbers, which might make the leases more compact under some
 circumstances.  Or you could key delegation on some other property other
 than serial number, like the LOC tag -- but this would require Quanta to
 start adding this tag to the XO's mfg-data (currently it's in Quanta's
 database which is sent to us, but not actually written to the XO), and
 would complicate "repurposing" efforts if, say, G1G1 machines were
 diverted to Uruguay.

 It may be better just to give Uruguay custom firmware with their own key
 pairs and be done with it.  Michael Stone reports that Uruguay is excited
 about building their own firmware, kernels, and initramfs and hacking on
 security themselves.  We can't afford to maintain or support their changes
 in this case anyway, we might as well just cut them free.  There may be
 legal implications wrt our ability to satisfy developer key requests.

-- 
Ticket URL: <http://dev.laptop.org/ticket/9045#comment:1>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system