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

[Graeme Russ]

Hi Wolfgang,

On 02/12/2012 07:09 AM, Wolfgang Denk wrote:
> Dear Graeme,
> 
> In message <4F35EBBF.3050106 at gmail.com> you wrote:
>>
>> I do a lot of work with Programmable Logic Controllers (PLCs) and Remote
>> Telemetry Units (RTUs). One example of what the bootloader is used for is
>> low-level configuration of the analogue input out output channels
>> (calibration). This is done by entering a command in the bootloader command
>> line and applying a known calibrated input (if calibrating an input
>> channel) or connecting to a calibrated measurement instrument (if
>> calibrating an output). This is not something that an end-user should be
>> doing (and can be very dangerous if the calibration is modified). These
>> inputs and outputs may be connected to critical equipment, and if something
>> goes wrong, the device manufacture needs a level of certainty that these
>> settings have not been changed.
>>
>> This is only one example - There are many other reasons that the end user
>> should be 'kept out' of the bootloader.
> 
> This implies the logic that these actions _have_ to be done in the boot
> loader, so you need to add security to it.
> 
> I doubt if this assumption is correct.  I think the calibration
> couldbe done as well (and in a much beter secured environment) when
> running an OS.

There is some truth to this :)

>> There has also been a recent bout of security breaches as a result of
>> hard-coded passwords in device firmware, so being able to set the password
>> is a must
> 
> The lower level access you provide to a system, the higher the risk
> that it can be broken in, and that break-ins will be of a more
> critical nature.
> 
>> I think some form of 'access level' might be useful one day - e.g. the
>> end-user can set a password to provide access to setting IP address while
>> the manufacturer has a password for calibration and MAC address
> 
> 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.

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)

Suitable encryption is already in U-Boot (we have SHA and MD5 libraries
already)

We would we need key management? My suggestion was to have an encrypted
password (SHA/MD5) as an environment variable - Enter password, SHA,
compare, access denied/granted...

>> These are all some basic random thoughts I have, but I think they
>> illustrate that as the bootloader expands in functionality, the need to
>> provide a measure of security also increases...
> 
> 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).

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)

Every stage of the boot process (up to and including the OS command line)
must provide the same level of protection for the same functionality. So if
a root user login is required to run 'setenv' in the OS, the same level of
protection is need in the bootloader if it provides a 'setenv' function.

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


Regards,

Graeme