[U-Boot] 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
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?
- 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)?
- 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,
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 --
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,
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
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,
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
participants (3)
-
Albert ARIBAUD -
Richard Retanubun -
Wolfgang Denk