sha256_crypt for uboot
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
Signature · 1 line
Richard Retanubun
Hi Richard,
Quoted 15 lines · Richard Retanubun
Hello,
I am working on a project to allow uboot to authenticate users by using the same
sha256_cryptfunction that Linux user-space use for libcrypt [ref] http://www.akkadia.org/drepper/SHA-crypt.txtWe 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 theMakefileto allow a command to statically link to libcrypt? hacking it into the Makefile's $(PLATFORM_LIBS)?
Quoted 7 lines
3. Once I am done porting
sha256_cryptto 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?
Quoted 1 line
Thank you for everyone's time
Amicalement,
Signature · 1 line
Albert.
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.
Quoted 5 lines
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 --
Hi Richard,
Quoted 5 lines · 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.
Actually some of them are at a U-Boot developer's meeting in Geneva.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 23 lines
So far I got
sha256_crypt()andsha512_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_contextstruct that exist in u-boottypedef 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
Quoted 7 lines
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.
Quoted 1 line
-- Richard Retanubun --
Amicalement,
Signature · 1 line
Albert.
Quoted 4 lines
Quoted 2 lines
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? :)
Quoted 8 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 4 lines
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."
Quoted 3 lines
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
Hi Richard,
Quoted 7 lines · Richard Retanubun
Quoted 4 lines
Quoted 2 lines
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. :)
Quoted 13 lines
Quoted 4 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 3 lines
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.
Quoted 4 lines
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. :)
Quoted 4 lines
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.
Quoted 9 lines
Quoted 3 lines
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.
Quoted 1 line
-- Richard Retanubun
Amicalement,
Signature · 1 line
Albert.
Dear Richard Retanubun,
Quoted 3 lines · In message <[email protected]> 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
Signature · 4 lines
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.