The scheme looks OK. The signed code paradigm is being used by Microsoft, Java et al. Unless I see the total picture, I cannot see if we are deviating from their sequences, in any serious way that matters. Most probably not. But we should check later, after the security spec is out and all sequences are fully developed.
We still need to figure out the size of the crypto code, but that is not a show-stopper, unless it consumes huge amount of resources. Embedding an OLPC public key in the bios for bootstrapping is fine. We need to make sure, it is protected properly and all the associated sequences that touch it, are analyzed for security. (I assume the imminent security spec will be a starting point for this) I also assume, each PC will have a unique serial number; anyway there is a unique MAC address as well. But, want to caution that either the key or the serial number or the MAC address can be spoofed (under proper conditions) and so we should make sure, we do not put *undue* trust in any of these artifacts. In fact, put the minimum trust required to do the processes we need, and document the sequences in the security spec/analysis document. Cheers <k/> > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ivan Krstic > Sent: Sunday, August 27, 2006 3:02 PM > To: Krishna Sankar > Cc: [email protected] > Subject: Re: [OLPC-devel] Secure BIOS on the OLPC > > Krishna Sankar wrote: > > a) How does the verification happen ? This is where the > > vulnerability will be. > > Small binary within the LB payload that uses standard crypto > signature verification. This part can be assumed fully > secure, as long as we ship the machines with a known-good > BIOS, which we obviously will. > > > b) Where would the certs be stored ? > > The OLPC public key(s) would be stored in the LB payload. > > > c) Will we ship with an embedded cert ? If so, how > can it be > > updated securely ? > > A new BIOS is allowed to introduce new BIOS keys, if it fits > some extra security requirements (that I won't document here, > but will be detailed in the security spec I intend to release > shortly). > > > d) Do we assume internet connectivity for cert > verification as > > well as for CRLS et al ? > > Not at all. > > > e) What else would this require in terms of > infrastructure ? > > Connected to power ? > > Absolutely nothing more than what's already there. > > > Will ask more Q as I think of. I would rather document this, think > > through and then start implementing. > > Unless someone can find a concrete security flaw with this > idea, we need to make the EC changes request sooner rather than later. > > -- > Ivan Krstić <[EMAIL PROTECTED]> | GPG: > 0x147C722D _______________________________________________ > Devel mailing list > [email protected] > http://mailman.laptop.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
