New branch on bios-crypto: delegation

Fri May 8 11:51:21 EDT 2009

Publishing what started as an review request -

Forwarded conversation
Subject: New branch on bios-crypto: delegation
------------------------

From: *Martin Langhoff* <martin.langhoff at gmail.com>
Date: Thu, May 7, 2009 at 6:43 PM
To: "Reuben K. Caron" <reuben at laptop.org>, Daniel Drake <dsd at laptop.org>,
"C. Scott Ananian" <cscott at laptop.org>

Hi guys,

Early heads up -- I am working on the tools included in bios-crypto to
prepare them to produce 'sig02' delegated signatures and specially
delegated leases.

The work I am doing is following the spec on the wiki and the examples
in the bitfrost code. You might want to give brief review at
http://dev.laptop.org/git/bios-crypto/commit/?h=delegation

- Scott, Daniel - I've patched sig01.c lightly so that it changes its
format slightly for sig02. C is not my native language; I don't think
I did anything particularly stupid, but a review would be welcome.

 - Scott: if you look at make-delegation.sh and the patches to sig01.c
-- does it make sense?

 - Reuben: have a look at the README

The remaining bit is to rework make-lease.sh to accept and use
delegation signature, like --chained works on make delegation. And
testing this end-to-end.

cheers,

m
--
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

----------
From: *Daniel Drake* <dsd at laptop.org>
Date: Thu, May 7, 2009 at 6:55 PM
To: Martin Langhoff <martin.langhoff at gmail.com>
Cc: "Reuben K. Caron" <reuben at laptop.org>, "C. Scott Ananian" <
cscott at laptop.org>

2009/5/7 Martin Langhoff <martin.langhoff at gmail.com>:
Don't forget that OFW needs to be taught about the new format, and
needs to be extended to correctly verify sig02 leases. Or is that
already being taken care of?

----------
From: *Martin Langhoff* <martin.langhoff at gmail.com>
Date: Thu, May 7, 2009 at 7:03 PM
To: Daniel Drake <dsd at laptop.org>
Cc: "Reuben K. Caron" <reuben at laptop.org>, "C. Scott Ananian" <
cscott at laptop.org>

It's not so important in the short term. OFW checks the leases, and
then it executes runos or actos depending on the outcome... but both
are the same thing ATM.

Once Mitch gets out of his 1.5 work, he'll have a chance to test his
patches for delegation support. As long as runos and actos remain the
same for that period... :-)

----------
From: *Daniel Drake* <dsd at laptop.org>
Date: Thu, May 7, 2009 at 8:50 PM
To: Martin Langhoff <martin.langhoff at gmail.com>
Cc: "Reuben K. Caron" <reuben at laptop.org>, "C. Scott Ananian" <
cscott at laptop.org>

No, it is important. If OFW doesnt trust the lease, it will boot with
the "activate" parameter passed to the kernel, which the OLPC
initramfs will unconditionally interpret as the machine being
unactivated. The consequence being that no systems with act02 leases
will boot.

Daniel

----------
From: *Martin Langhoff* <martin.langhoff at gmail.com>
Date: Thu, May 7, 2009 at 9:36 PM
To: Daniel Drake <dsd at laptop.org>
Cc: "Reuben K. Caron" <reuben at laptop.org>, "C. Scott Ananian" <
cscott at laptop.org>

Good pointer. As things stand, I have to hack inside of the initrd
anyway -- I can make sure that the initrd behaves properly in that
case.

It sounds like an easy enough fix -- do you think that there are more
reasons to worry?

----------
From: *Daniel Drake* <dsd at laptop.org>
Date: Thu, May 7, 2009 at 9:37 PM
To: Martin Langhoff <martin.langhoff at gmail.com>
Cc: "Reuben K. Caron" <reuben at laptop.org>, "C. Scott Ananian" <
cscott at laptop.org>

Changing the behaviour in this area sounds scary. For testing and
development, maybe OK, but I don't feel that this plan becomes
realistic without firmware support.

Daniel

----------
From: *Reuben K. Caron* <reuben at laptop.org>
Date: Thu, May 7, 2009 at 10:01 PM
To: Daniel Drake <dsd at laptop.org>
Cc: Martin Langhoff <martin.langhoff at gmail.com>, "C. Scott Ananian" <
cscott at laptop.org>

 From my understanding from
http://wiki.laptop.org/go/Firmware_Security#Process

1. OFW check for valid lease.sig
2. No valid lease.sig run actos.zip
3. actos.zip copies lease.sig to /security
4. Continue boot.

Since OFW will not see a valid lease.sig, will actos have to be run on every
boot? (Increasing boot time?) While not having OFW support is not ideal, I'm
not sure how much room there is in OFW for support. Since actos.zip and
runos.zip are signed by a different key how much does this actually effect
security (making changes to actos and runos) ?

Apologies if my understanding is grossly in error.

Reuben

----------
From: *Daniel Drake* <dsd at laptop.org>
Date: Thu, May 7, 2009 at 10:09 PM
To: reuben at laptop.org
Cc: Martin Langhoff <martin.langhoff at gmail.com>, "C. Scott Ananian" <
cscott at laptop.org>

2009/5/7 Reuben K. Caron <reuben at laptop.org>:
Firstly, note that when booting actos, OFW *additionally* passes an
"activate" parameter to the kernel.

actos and runos are actually the same file. They could theoretically
be different, and even if so they would be signed with the same key,
but they currently are not.

So, there's always one initramfs that boots. The initramfs looks for
the presence of the "activate" parameter when deciding what to do:

1. If the activate parameter is *not* present, it boots the system as
normal. Note that the initramfs does not check the lease even in this
case; it trusts the judgement that OFW made by not passing the
"activate" parameter.

2. If the activate parameter is present, the initramfs assumes that
there is no lease available on the system (it doesn't bother checking)
and starts hunting on SD, USB and wifi. In the discussions here, there
may well be an act02 lease present on the system which other parts of
the system will trust, but again, lease checking is currently *not*
part of this codepath; the initramfs only listens to what OFW had to
say about the situation.

IMO changing the semantics here is risky, there is probably a reason
that things are as they are (i.e. firmware-based security), and any
changes would require a careful discussion between all parties...

Daniel

----------
From: *Martin Langhoff* <martin.langhoff at gmail.com>
Date: Fri, May 8, 2009 at 9:49 AM
To: Daniel Drake <dsd at laptop.org>
Cc: reuben at laptop.org, "C. Scott Ananian" <cscott at laptop.org>

I went to sleep last night wondering about that, so re-read init and
antitheft.py first thing this morning. Your description is correct,
the init process trusts the boot parameter and doesn't recheck things.

It could very well switch to making the checks itself, and I'll argue
that it is actually a reasonable thing to do, as we're still within
the trusted codebase.
I agree that more discussion will be good.

However, I suspect that the actual reason is performance. What Mitch
has mentioned serveral times is that as OFW is making the checks, a
smaller, slimmer and faster(!) initrd could be used for the common
case (hence runos.zip being separate).

-- 
martin.langhoff at gmail.com
martin at laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff  - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20090508/fea6d11c/attachment.html>