[U-Boot] Password protection of U-Boot command line

[Graeme Russ]

Hi Wolfgang,

On Mon, Feb 13, 2012 at 6:17 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Graeme,
>
> In message <4F378753.4070808 at gmail.com> you wrote:
>>
>> > Do not do this in the boot loader.  It is not the environment for such
>> > things.  When it comes to security, you are automatically pulling in
>> > things like encryption technologies, key management, etc.  We do not
>> > want to pull this into a bootloader - it would just be a poor mans
>> > surrogate for a real OS.  Instead, do the logical step and use a
>> > proper OS that provides all these things for free, in a well-tested
>> > and protected environment.
>>
>> The issue is that the bootloader has complete access and control of
>> critical hardware components (Flash, environment storage, MAC address etc)
>> and at the moment there is no effective protection.
>
> There is nothing that a boot loadr can do, that cannot be done as well
> by appropriate Linux kernel code.

Yes, but that access can be controlled through logon credentials after
the OS has been loaded.

>> If all the bootloader did was transition to the OS without any support for
>> an interactive environment then the would not be a problem (aside from
>> hacking the hardware, but there is no way a bootloader can protect against
>> that anyway, so the point is moot)
>
> It is way easier to prevent a user from getting any interactive access
> to the boot loader at all than it is to protect such access by a
> password and open it only for "priviledged" users/

So basically you are suggesting to completely remove shell access in U-Boot
which is one thing that make U-Boot so attractive.

>
>> Suitable encryption is already in U-Boot (we have SHA and MD5 libraries
>> already)
>
> We have only checksumming. We do not have any kind of key management
> whatever.

Why do we need key management - We aren't doing any decrypting (I'm not
suggesting 'Secure Boot' here). All we are doing is comparing two
passwords which we can use secure hashing functions like SHA or MD5 for

>> > I disagree.  There are a large number of things that simply make no
>> > sense in boot loader context.
>>
>> I would agree if the bootloader did not have an interactive environment for
>> providing low-level access to things that need to be protected. But U-Boot
>> provides just that (and it is part of the reason so many people use it).
>
> You don't have to open access to such "things that need to be
> protected".  It is way easier not to provide such access at all then
> to try and protect it with a password.

Again, you are suggesting removing functionality that attract people to
U-Boot

>> By having these function in the bootloader:
>> a) The functionality is already there - they don't have to implement it
>> (which may be practically prohibitive for some CoTS embedded OSs)
>> a) They don't have to go all the way into the OS to use the functionality
>> b) They don't have to put those functions in the OS and thus provide a
>> potential security concern (if tools to modify the low-level environment
>> are not in /sbin/ then gaining root access by a buffer overrun is not so
>> serious)
>
> Sorry, but I really cannot follow you.

If you buy a CoTS OS for your embedded system, it may not come with a
command line, let alone the tools already provided in U-Boot. So you then
have the additional development cost of implementing all those features -
fine if your firmware is open source (you can just use the U-Boot code) but
if those features need to be integrated into the CoTS source code, you have
to go it alone (most PLC/RTU CoTS OSs are just a library that you link in
your code to produce a single, monotomic binary so using GPL code is out
of the question in those cases)

And if the OS you used does not have a command line, you have to implement
that on top - Often a non-trivial endeavour

So now you have implemented your own 'low level commands' and possibly your
own command line - How do you know it is secure. You now have to implement
some kind of secure access (a password!) to protect access to those
functions - functions already provided by U-Boot which would not be too
difficult (IMHO) to secure - A simple 'gate' where U-Boot drops into
command line mode requiring a password who's hash matches the hash stored
in an environment variable

>> So you either do not implement any 'critical' functions in the bootloader
>> (realistically that may mean not providing a command line at all) or secure
>> the bootloader to the same level as the OS
>
> Correct - in a protected environment I would not provide any
> interactive functionality for U-Boot at all.  Everything else is _way_
> too easy to break in.

Better that the security be developed, analysed and maintained by a large
group of open eyes than trusting your dev group of maybe two or three
people get it right...

Regards,

Graeme