[U-Boot] sha256_crypt for uboot

[U-Boot] sha256_crypt for uboot

[Richard Retanubun]

Hello,

I am working on a project to allow uboot to authenticate users by using the same sha256_crypt function that Linux user-space use for libcrypt
[ref] http://www.akkadia.org/drepper/SHA-crypt.txt

We chose sha256 because uboot already have support for doing sha256 hashes, I am wondering about a few things:
1. Has this been attempted before?

2. If I want to make a test command for a proof of concept using crypt(), how do I modify the Makefile to allow a
    command to statically link to libcrypt? hacking it into the Makefile's $(PLATFORM_LIBS)?

3. Once I am done porting sha256_crypt to use it using the facilities uboot has, is there any hope of getting this mainlined when I am done?
    If there is a policy to not unnecessarily add crypto algorithm, then I'll just keep it all in one file to reduce risk of merge conflict.
    If there is interest to mainline this, then I'll stage the supporting functions that uboot does not have yet (mempcpy, stpcpy, etc) into
    separate files.

Thank you for everyone's time
-- 
Richard Retanubun

[U-Boot] sha256_crypt for uboot

[Albert ARIBAUD]

Hi Richard,

On Wed, 27 Jun 2012 10:46:57 -0400, Richard Retanubun
<richardretanubun@ruggedcom.com> wrote:
> Hello,
> 
> I am working on a project to allow uboot to authenticate users by
> using the same sha256_crypt function that Linux user-space use for
> libcrypt [ref] http://www.akkadia.org/drepper/SHA-crypt.txt
> 
> We chose sha256 because uboot already have support for doing sha256
> hashes, I am wondering about a few things: 1. Has this been attempted
> before?
> 
> 2. If I want to make a test command for a proof of concept using
> crypt(), how do I modify the Makefile to allow a command to
> statically link to libcrypt? hacking it into the Makefile's
> $(PLATFORM_LIBS)?
> 
> 3. Once I am done porting sha256_crypt to use it using the facilities
> uboot has, is there any hope of getting this mainlined when I am
> done? If there is a policy to not unnecessarily add crypto algorithm,
> then I'll just keep it all in one file to reduce risk of merge
> conflict. If there is interest to mainline this, then I'll stage the
> supporting functions that uboot does not have yet (mempcpy, stpcpy,
> etc) into separate files.

Can't speak for Wolfgang of course, but my main question would be why
would U-Boot need to identify users when its payload OS can do this
with much more ease and flexibility?

IOW, what use case are you considering?

> Thank you for everyone's time

Amicalement,
-- 
Albert.

[U-Boot] sha256_crypt for uboot

[Richard Retanubun]

On 05/07/12 05:59 AM, Albert ARIBAUD wrote:
Hi Albert,

Thanks for responding, I realize most people are probably away on summer holiday.
>
> Can't speak for Wolfgang of course, but my main question would be why
> would U-Boot need to identify users when its payload OS can do this
> with much more ease and flexibility?
 > IOW, what use case are you considering?

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).

So far I got sha256_crypt() and sha512_crypt() working (sha512 is a bit slow due
to non-arch optimized string lib functions, but its working okay).

If there is interest in sha512, I can send it as a separate patch.

One question to the mailing list though, the sha256_context struct that exist in u-boot

typedef struct {
	uint32_t total[2];
	uint32_t state[8];
	uint8_t buffer[64];
} sha256_context;

Is a little different from the one in libc (i.e. it adds buflen and has a 128 char buffer)

struct sha256_ctx {
	uint32_t H[8];
	uint32_t total[2];
	uint32_t buflen;
	char buffer[128]; /* NB: always correctly aligned for uint32_t.  */
};

I can't seem to find mainlined boards that uses sha256.h (I am sure there are private ones)

Is it okay if I update the sha256.[ch] API to track the implementation from libc?

-- Richard Retanubun --

[U-Boot] sha256_crypt for uboot

[Albert ARIBAUD]

Hi Richard,

On Mon, 9 Jul 2012 09:50:05 -0400, Richard Retanubun
<richardretanubun@ruggedcom.com> wrote:
> On 05/07/12 05:59 AM, Albert ARIBAUD wrote:
> Hi Albert,
> 
> 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.

> > Can't speak for Wolfgang of course, but my main question would be
> > why would U-Boot need to identify users when its payload OS can do
> > this with much more ease and flexibility?
>  > IOW, what use case are you considering?
> 
> 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.

Ok, so this risk scenario is about untrusted payloads, not about
untrusted individuals. The difference is that u-boot already has a
concept of 'payload' but does not have or need any concept of 'user' so
far.

> 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.

> So far I got sha256_crypt() and sha512_crypt() working (sha512 is a
> bit slow due to non-arch optimized string lib functions, but its
> working okay).
> 
> If there is interest in sha512, I can send it as a separate patch.
> 
> One question to the mailing list though, the sha256_context struct
> that exist in u-boot
> 
> typedef struct {
> 	uint32_t total[2];
> 	uint32_t state[8];
> 	uint8_t buffer[64];
> } sha256_context;
> 
> Is a little different from the one in libc (i.e. it adds buflen and
> has a 128 char buffer)
> 
> struct sha256_ctx {
> 	uint32_t H[8];
> 	uint32_t total[2];
> 	uint32_t buflen;
> 	char buffer[128]; /* NB: always correctly aligned for
> uint32_t.  */ };
> 
> I can't seem to find mainlined boards that uses sha256.h (I am sure
> there are private ones)
> 
> Is it okay if I update the sha256.[ch] API to track the
> implementation from libc?

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.

> -- Richard Retanubun --

Amicalement,
-- 
Albert.

[U-Boot] sha256_crypt for uboot

[Richard Retanubun]

>> 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? :)

>> 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.
>
> Ok, so this risk scenario is about untrusted payloads, not about
> untrusted individuals. The difference is that u-boot already has a
> concept of 'payload' but does not have or need any concept of 'user' so
> far.

This is the hints I am getting from reading past conversations in the
mailing list as well, which I why I am testing the waters before
finalizing the patch.

>
>> 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?

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."

> 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!

-- Richard Retanubun

[U-Boot] sha256_crypt for uboot

[Albert ARIBAUD]

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.

[U-Boot] sha256_crypt for uboot

[Wolfgang Denk]

Dear Richard Retanubun,

In message <4FFAE18D.3080809@ruggedcom.com> you wrote:
>
> 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).

You are opening a can of worms here, and I bet you don't know yet how
big it is.  U-Boot has never been designed with any such level of
security in mind.

If you want securityu, then add it to an environment which has been
designed for it, i. e. use an OS like Linux.  Use U-Boot just to boot
this OS, and don't give anybody an easy chance to break in.

On the other hand, realize how complicated it is just to attach a JTAG
debugger and take over full controll of your board.  Yes, even if you
don't provide a connector to such an interface.  I know quite a number
of systems that have been "opened" this way.

Frankly, I doubt this makes sense from a technical point of view.
[Yes, I know that there are situations where management and.or
marketing asks for such stuff. But is that a good reason to do it?]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Old programmers never die, they just become managers.