[U-Boot] sha256_crypt for uboot

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Richard,

On Mon, 9 Jul 2012 10:55:18 -0400, Richard Retanubun
<richardretanubun@ruggedcom.com> wrote:
> >> Thanks for responding, I realize most people are probably away on
> >> summer holiday.
> >
> > Actually some of them are at a U-Boot developer's meeting in Geneva.
> 
> Uh-oh... Is it safe to place such a high concentration of hacker
> brains so close to CERN? :)

That's OK. The CERN folks must still be high on Higg's Boson, so the
place is safe right now. :)

> >> The primary concern here is the power of u-boot CLI. Once here,
> >> someone can manually load and boot the payload OS in a different
> >> mode that can bypass any user identification.

> >> Thus, we aim to add the ability uboot to identify users, much like
> >> the payload OS does before granting access to its CLI (if the user
> >> interrupts the boot process).
> >
> > This risk mitigation answer seems to address another risk than the
> > one above, i.e. you could address the risk above just as with
> > payload trust (i.e., some form of trusted boot) without needing to
> > introduce a whole user identification system.
> >
> In principal I agree.
> 
> In practice, for situations where one does not control the payload,
> how does one ensure it is trusted?

If you don't control the payload, then how can you expect to control
the users who bring it in, a control which is harder yet to achieve
that payload control? Hint: a piece of cryptographic signature
checking code is immune to greed or malevolence. A human is not. :)

> Our current approach is to say "as long as the automatic boot
> sequence is not modified, everything in the execution sequence is
> trusted. When an operator need to deviate from that auto boot
> sequence, then the operator needs to be authenticated."

Rephrase this as "as long as the boot sequence remains trusted, go
ahead with it. If it is not, then don't go ahead". Then implement a
chain of trust from ROM code to however far in the boot chain you
want. Assuming you have a three-stage (ROM, U-Boot, OS) boot chain,
then the chain of trust is: ROM is trusted;  ROM checks U-Boot's
signature and runs it only if U(Boot is trusted; U-Boot checks the
signature of whatever it is told to run, either from autoboot orfrom
command line, and runs it only if trusted.

If you keep the secret signature keys tightly to your chest, then you
don't need to trust users, or more precisely, misplaced trust in
someone won't have catastrophic effects, as that person can only run
what you have allowed to run. 

> > For the time being, I am still failing to see a viable reason for
> > introducing user management in mainline u-boot at all: it seems only
> > your solution (not even your problem) needs it.
> 
> Understood. For the time being, I'll aim to make my modifications to
> the source as standalone as I can so I don't get hit with merge
> conflicts.
> 
> Thanks for your time!

You're welcome.

> -- Richard Retanubun

Amicalement,
-- 
Albert.