#4101 HIGH Never A: Need means to deprecate signed OS/firmware/etc images.

[Zarro Boogs per Child]

#4101: Need means to deprecate signed OS/firmware/etc images.
-------------------------------------------------------+--------------------
 Reporter:  cscott                                     |       Owner:  krstic        
     Type:  defect                                     |      Status:  new           
 Priority:  high                                       |   Milestone:  Never Assigned
Component:  security                                   |     Version:                
 Keywords:  wmb at firmworks.com, krstic, mstone, cscott  |    Verified:  0             
-------------------------------------------------------+--------------------
 To be concrete, the threat I am guarding against is the following:  we
 will have a signed build on the machines at MP time which does not
 have an antitheft client, and may have holes in initial activation
 security.  I am concerned that enterprising thieves will be able to
 downgrade future machines to the MP build in order to bypass
 activation and/or turn off antitheft.  (The threat is more general,
 but let's concentrate on this specific case for now.)

 I'm going to suggest doing at least one, but perhaps both, of the
 following things to make sure that we can deprecate old os releases:

 (1) test to ensure that all our code paths can handle multiple
 signatures from different keys in .sig files, so that we can change to
 a new key if we need to deprecate old code, and/or...

 (2) add an epoch marker to signatures (so we can deprecate old
 signatures w/o needing to generate a new key)

 I think (2) is worth doing even if we do (1), because having to
 generate (say) 100 signatures on a file seems much more painful than
 just generating 1 signature with epoch 100.

 (1) may be more or less done already, but I've never tested it, and I
 don't believe it works unless it's been well tested.  As an
 alternative, we could solve (1) by putting new signatures in
 differently-named files in the zip, and counting on OFW to ignore
 extra files which it didn't understand.  But again, we need it
 well-tested before we claim it's a solution.

 Mitch_Bradley: how exactly would the epoch thing work?
 C. Scott Ananian: We just add a new fixed width field -- say 4
 characters hexadecimal.  We ignore the field at the present, but
 generate all our signatures with it set to 0000.
 C. Scott Ananian: if we find out that our current software has a
 security problem, we start generating all our signatures with 0001,
 and release a new firmware which doesn't recognize any signature as
 valid unless the epoch is at least 0001
 C. Scott Ananian: this lets us upgrade old machines to the new
 firmware, while preventing "bad guys" from exploiting the ability to
 downgrade to the old broken firmware/os/whatever.

 Mitch_Bradley: we could bump to sig02:
 Mitch_Bradley: but that doesn't work...
 C. Scott Ananian: yes, we could just use the '01' as an epoch marker,
 but we need to ignore those bits (whichever ones they are) in the
 current firmware so that we can upgrade old machines to the new epoch
 Mitch_Bradley: yep, that's what I meant by "doesn't work"
 C. Scott Ananian: i believe this is functionally equivalent to
 releasing new firmware which only recognizes new keys, but saves us
 the trouble of generating multiple signatures for new builds (signed
 with old key, signed with new key)

 C. Scott Ananian: on the other hand, this whole "signature migration"
 discussion is specific to the signature process, so it should be
 orthogonal to the work we want to do today on secure nand reflash.
 It's just a change to how we format & validate signatures.

 Comments?  Again, my suggestion is that we do both (1) and (2) for MP,
 but that we should at least test means to accomplish (1) with the
 current firmware/initrd before we sign off on it as "good enough for
 MP".
  --scott

 [If we make the deprecation mechanism general to all signatures, it
 lets us deprecate generated activation leases, developer keys,
 firmware, OS images, and "pre-activation upgrade" images.  I can see
 definite uses for the latter three, a possible use for the first to
 counter some sort of "activation goes crazy" scenario, but no valid
 use for developer key deprecation.]

-- 
Ticket URL: <https://dev.laptop.org/ticket/4101>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system