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

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

[Graeme Russ]

Hi All,

As an adjunct to a recent discussion, I wonder if there would be much
point in password protecting access to the U-Boot command line. The
password could be saved in an environment variable as an MD-5 or SHA-256
hash.

But I wonder if:

 a) It's worth it, and;
 b) If it would be secure anyway...

When U-Boot environment editing tools available in the host OS, it would
be fairly trivial to overwrite the password variable - Unless, of course,
the host OS did not support that functionality.

This feature may be usefull for devices where every part of the system
must be tightly controlled (medical devices, voting machines etc)

Regards,

Graeme

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

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButCLT2o=7QO4GbM0M5Tp3BYXPCpqr7Sx6WYH09JKcUdMFSA@mail.gmail.com> you wrote:
> 
> As an adjunct to a recent discussion, I wonder if there would be much
> point in password protecting access to the U-Boot command line. The
> password could be saved in an environment variable as an MD-5 or SHA-256
> hash.

We already have such protection, even if it's very simplistic: see
doc/README.autoboot (search for CONFIG_AUTOBOOT_DELAY_STR,
CONFIG_AUTOBOOT_STOP_STR resp. "bootdelaykey" and "bootstopkey").

> But I wonder if:
> 
>  a) It's worth it, and;
>  b) If it would be secure anyway...
> 
> When U-Boot environment editing tools available in the host OS, it would
> be fairly trivial to overwrite the password variable - Unless, of course,
> the host OS did not support that functionality.
> 
> This feature may be usefull for devices where every part of the system
> must be tightly controlled (medical devices, voting machines etc)

Well, in such devices you will typically disable interactive access at
all.

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
Extended Epstein-Heisenberg Principle: In an R & D orbit, only  2  of
the  existing 3 parameters can be defined simultaneously. The parame-
ters are: task, time and resources ($).

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

[Graeme Russ]

Hi Wolfgang,

On 02/10/2012 10:38 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <CALButCLT2o=7QO4GbM0M5Tp3BYXPCpqr7Sx6WYH09JKcUdMFSA@mail.gmail.com> you wrote:
>>
>> As an adjunct to a recent discussion, I wonder if there would be much
>> point in password protecting access to the U-Boot command line. The
>> password could be saved in an environment variable as an MD-5 or SHA-256
>> hash.
> 
> We already have such protection, even if it's very simplistic: see
> doc/README.autoboot (search for CONFIG_AUTOBOOT_DELAY_STR,
> CONFIG_AUTOBOOT_STOP_STR resp. "bootdelaykey" and "bootstopkey").

OK, so the thought of protecting the shell with a password has already
happened...But the implementation is to hard-code the password in the
U-Boot image or to have it unencrypted in the environment

I think we can agree that there is room for improvement :)

>> But I wonder if:
>>
>>  a) It's worth it, and;
>>  b) If it would be secure anyway...
>>
>> When U-Boot environment editing tools available in the host OS, it would
>> be fairly trivial to overwrite the password variable - Unless, of course,
>> the host OS did not support that functionality.
>>
>> This feature may be usefull for devices where every part of the system
>> must be tightly controlled (medical devices, voting machines etc)
> 
> Well, in such devices you will typically disable interactive access at
> all.

Yes, but if you don't allow setting of environment variables from the host
OS, how can you change the settings if you need to

Sounds like it's not a 'completely ruled out' idea...

Regards,

Graeme

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

[Marek Vasut]

> Hi Wolfgang,
> 
> On 02/10/2012 10:38 PM, Wolfgang Denk wrote:
> > Dear Graeme Russ,
> > 
> > In message 
<CALButCLT2o=7QO4GbM0M5Tp3BYXPCpqr7Sx6WYH09JKcUdMFSA@mail.gmail.com> you wrote:
> >> As an adjunct to a recent discussion, I wonder if there would be much
> >> point in password protecting access to the U-Boot command line. The
> >> password could be saved in an environment variable as an MD-5 or SHA-256
> >> hash.
> > 
> > We already have such protection, even if it's very simplistic: see
> > doc/README.autoboot (search for CONFIG_AUTOBOOT_DELAY_STR,
> > CONFIG_AUTOBOOT_STOP_STR resp. "bootdelaykey" and "bootstopkey").
> 
> OK, so the thought of protecting the shell with a password has already
> happened...But the implementation is to hard-code the password in the
> U-Boot image or to have it unencrypted in the environment
> 
> I think we can agree that there is room for improvement :)
> 
> >> But I wonder if:
> >>  a) It's worth it, and;
> >>  b) If it would be secure anyway...
> >> 
> >> When U-Boot environment editing tools available in the host OS, it would
> >> be fairly trivial to overwrite the password variable - Unless, of
> >> course, the host OS did not support that functionality.
> >> 
> >> This feature may be usefull for devices where every part of the system
> >> must be tightly controlled (medical devices, voting machines etc)
> > 
> > Well, in such devices you will typically disable interactive access at
> > all.
> 
> Yes, but if you don't allow setting of environment variables from the host
> OS, how can you change the settings if you need to

You usually don't want to frob with ie. CPU speed of your Xray :-D

M

> 
> Sounds like it's not a 'completely ruled out' idea...
> 
> Regards,
> 
> Graeme
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Graeme Russ,

In message <4F3505F8.1070504@gmail.com> you wrote:
> 
> > We already have such protection, even if it's very simplistic: see
> > doc/README.autoboot (search for CONFIG_AUTOBOOT_DELAY_STR,
> > CONFIG_AUTOBOOT_STOP_STR resp. "bootdelaykey" and "bootstopkey").
> 
> OK, so the thought of protecting the shell with a password has already
> happened...But the implementation is to hard-code the password in the
> U-Boot image or to have it unencrypted in the environment
> 

It depends on the purpose.  Here the goal was more to prevent
unintentional interruption of the boot sequence by arbitrary line
noise, for example when the serial console port is connected to a
modem ...

> I think we can agree that there is room for improvement :)

Always, and everywhere.

> Yes, but if you don't allow setting of environment variables from the host
> OS, how can you change the settings if you need to

It depends on which interfaces you want to provide and how secure your
system must be.

If you provide some user interface which only allows to change a
welldefined set of variables (say, though some GUI, or web based),
then you can have both the "change settings" and the "be secure"
parts.

If someone has low-level access to the board he can probably always do
everything, it's just a matter of how easy it is.

> Sounds like it's not a 'completely ruled out' idea...

Not exactly ruled out.  It's more a question of how much effort versus
how much benefit.

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
The day-to-day travails of the IBM programmer are so amusing to  most
of us who are fortunate enough never to have been one - like watching
Charlie Chaplin trying to cook a shoe.

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

[Wolfgang Denk]

Dear Marek,

In message <201202101330.14119.marek.vasut@gmail.com> you wrote:
>
> > Yes, but if you don't allow setting of environment variables from the host
> > OS, how can you change the settings if you need to
> 
> You usually don't want to frob with ie. CPU speed of your Xray :-D

Medical devices that are based on U-Boot / Linux usually have hardware
based limitations on critical parameters.  You cannot always mount a
scratch monkey [1] ;-)

[1] http://www.catb.org/jargon/html/S/scratch-monkey.html


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
"In the long run, every program becomes rococo, and then rubble."
- Alan Perlis

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

[Frans Meulenbroeks]

Generally speaking there is a use case for a password.

E.g. if you deliver boards/systems with u-boot on it and you do not
want customers to enter u-boot (e.g. by accident or because they want
to hack the board), but you would allow authorized service personnel
to access the board.

For this case a secret password in the image would probably suffice
(guess it might help to have it encrypted in flash or store a hash or
so.
Of course is the password leaks the security is gone.

A password in env is more hackable. It would at least require no
access from the kernel to the section the env is in (so no userspace
tools and no /dev/mtd0 mapping to the whole flash).

Yet another alternative (probably solution specific, is to store the
passwd in a separate eeprom or so and make sure it is not accessible
from the kernel (not always trivial)).

Frans.

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

[Wolfgang Denk]

Dear Frans Meulenbroeks,

In message <CACW_hTbGtYCLK380-FnGT01132e+yQ0Hhw-54LFXh4mV7XTr2g@mail.gmail.com> you wrote:
> Generally speaking there is a use case for a password.

Of course there is.  The question is if the oot loader is the right
place for it.

> E.g. if you deliver boards/systems with u-boot on it and you do not
> want customers to enter u-boot (e.g. by accident or because they want
> to hack the board), but you would allow authorized service personnel
> to access the board.
> 
> For this case a secret password in the image would probably suffice
> (guess it might help to have it encrypted in flash or store a hash or
> so.
> Of course is the password leaks the security is gone.

Right.  And we don't have anything like login names or users or
priviledges in U-Boot, so all systems you ship would use the same
master password. And the source code is under GPL and visible to
everybody.  Guess how long your "security" lasts?

If you want security, then don;t allow access to U-Boot at all, and
run an OS.  There you can do fancy things, including password
protection.

> A password in env is more hackable. It would at least require no
> access from the kernel to the section the env is in (so no userspace
> tools and no /dev/mtd0 mapping to the whole flash).
> 
> Yet another alternative (probably solution specific, is to store the
> passwd in a separate eeprom or so and make sure it is not accessible
> from the kernel (not always trivial)).

Do you realize that you are already talking how to maintain this
"security" level in Linux?  Then also implement it there!  That's
where such stuff belongs to.

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
I paid too much for it, but its worth it.

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

[Mike Frysinger]

On Friday 10 February 2012 09:12:10 Frans Meulenbroeks wrote:
> E.g. if you deliver boards/systems with u-boot on it and you do not
> want customers to enter u-boot (e.g. by accident or because they want
> to hack the board), but you would allow authorized service personnel
> to access the board.

i've seen people in the past ship their boards with u-boot defaulting to 
silent mode and the autostop key set to a ctrl sequence.  that addresses 
pretty much addresses this.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120210/52652eac/attachment.pgp>

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

[Mike Frysinger]

On Friday 10 February 2012 15:29:05 Mike Frysinger wrote:
> On Friday 10 February 2012 09:12:10 Frans Meulenbroeks wrote:
> > E.g. if you deliver boards/systems with u-boot on it and you do not
> > want customers to enter u-boot (e.g. by accident or because they want
> > to hack the board), but you would allow authorized service personnel
> > to access the board.
> 
> i've seen people in the past ship their boards with u-boot defaulting to
> silent mode and the autostop key set to a ctrl sequence.  that addresses
> pretty much addresses this.

blah, i need to stop inline editing sentences.  "that pretty much addresses 
the needs here".

if you're concerned about people attacking the system, you need to be 
realistic and lay out exactly what you want to protect and why/how.  the best 
example in the embedded world i've seen of this so far is the ARM TrustZone 
whitepaper.  they're realistic and up front with what TrustZone does and does 
not protect against.

waving your hands around and saying "doing XXX is more secure and therefore we 
should do it" is theater.  i'm not against passwords or ASLR or anything else 
in u-boot, but like Wolfgang said, let's see the realistic plan.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120210/b6be31c4/attachment.pgp>

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

[Frans Meulenbroeks]

2012/2/10 Wolfgang Denk <wd@denx.de>:
> Dear Frans Meulenbroeks,
>
> In message <CACW_hTbGtYCLK380-FnGT01132e+yQ0Hhw-54LFXh4mV7XTr2g@mail.gmail.com> you wrote:
>> Generally speaking there is a use case for a password.
>
> Of course there is. ?The question is if the oot loader is the right
> place for it.
>
>> E.g. if you deliver boards/systems with u-boot on it and you do not
>> want customers to enter u-boot (e.g. by accident or because they want
>> to hack the board), but you would allow authorized service personnel
>> to access the board.
>>
>> For this case a secret password in the image would probably suffice
>> (guess it might help to have it encrypted in flash or store a hash or
>> so.
>> Of course is the password leaks the security is gone.
>
> Right. ?And we don't have anything like login names or users or
> priviledges in U-Boot, so all systems you ship would use the same
> master password. And the source code is under GPL and visible to
> everybody. ?Guess how long your "security" lasts?

True; forgot about the GPL.
>
> If you want security, then don;t allow access to U-Boot at all, and
> run an OS. ?There you can do fancy things, including password
> protection.

The issue is mainly that we would like a service engineer to upgrade
if for some reason the os goes into a not recoverable fault, without
an operator accidently (or on purpose) bumping into it
>
>> A password in env is more hackable. It would at least require no
>> access from the kernel to the section the env is in (so no userspace
>> tools and no /dev/mtd0 mapping to the whole flash).
>>
>> Yet another alternative (probably solution specific, is to store the
>> passwd in a separate eeprom or so and make sure it is not accessible
>> from the kernel (not always trivial)).
>
> Do you realize that you are already talking how to maintain this
> "security" level in Linux? ?Then also implement it there! ?That's
> where such stuff belongs to.
>
probably yes. my concern is mostly about being able to repair systems
where something is broken and the kernel does not come up as desired
but also does not crash and bring us back to u-boot (like what happens
if a crc is faulty).

What Mike suggests in a subsequent message of using is more or less
secret key is probably already enough for us.

Frans

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

[Wolfgang Denk]

Dear Frans,

In message <CACW_hTY7sv6q+Y9+ojkg2PNJ4GRt0rwKHAHzaSb2SGxYHrioRQ@mail.gmail.com> you wrote:
>
> > If you want security, then don;t allow access to U-Boot at all, and
> > run an OS.  There you can do fancy things, including password
> > protection.
> 
> The issue is mainly that we would like a service engineer to upgrade
> if for some reason the os goes into a not recoverable fault, without
> an operator accidently (or on purpose) bumping into it

This is a perfectly reasonable requirement. But it needs to be
designed in, but providing things like fall back to a previous
version, or to a recovery configuration.  U-Boot supports allthis, you
just have to use it.

Passwords are not a tool that would help here.

> > Do you realize that you are already talking how to maintain this
> > "security" level in Linux?  Then also implement it there!  That's
> > where such stuff belongs to.
> >
> probably yes. my concern is mostly about being able to repair systems
> where something is broken and the kernel does not come up as desired
> but also does not crash and bring us back to u-boot (like what happens
> if a crc is faulty).
> 
> What Mike suggests in a subsequent message of using is more or less
> secret key is probably already enough for us.

No.  What you are looking for is a reliable recovery for a failed
software update or an otherwise corrupted system. That's a completely
different topic - but it's standard techology, and nothing to worry
about.

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
COBOL is for morons.                                 -- E.W. Dijkstra

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

[Graeme Russ]

Hi Mike,

On 02/11/2012 07:37 AM, Mike Frysinger wrote:

> waving your hands around and saying "doing XXX is more secure and therefore we 
> should do it" is theater.  i'm not against passwords or ASLR or anything else 

Agreed - I've already said as much in the ASLR thread

> in u-boot, but like Wolfgang said, let's see the realistic plan.

Well I might get back to this later

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.

Physical access (JTAG) can be detected by 'warranty void if removed'
stickers, so I would not be so concerned in this senario

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

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

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

Regards,

Graeme

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

[Frans Meulenbroeks]

2012/2/11 Graeme Russ <graeme.russ@gmail.com>:
> Hi Mike,
>
> On 02/11/2012 07:37 AM, Mike Frysinger wrote:
>
>> waving your hands around and saying "doing XXX is more secure and therefore we
>> should do it" is theater. ?i'm not against passwords or ASLR or anything else
>
> Agreed - I've already said as much in the ASLR thread
>
>> in u-boot, but like Wolfgang said, let's see the realistic plan.
>
> Well I might get back to this later
>
> 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.
>
> Physical access (JTAG) can be detected by 'warranty void if removed'
> stickers, so I would not be so concerned in this senario
>
> 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
>
> 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
>
> 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...
>

Graeme, if you want to keep people outisde the bootloader in a
reasonably safe way and are developing your own hardware an option is
to put the password in e.g. an eeprom and do a compare in u-boot.
Of course a persistent hacker could retrieve the password but a casual
user will not be able to enter.
Having the password in eeprom makes that it is not disclosed with the
code, it can be changed etc. Just make sure users do not have easy
(sw) access to the device the password resides in, so e.g.disable
access one way or another.

One other way to prevent accidental access would be a jumper. If
present no access to u-boot possible at all, if not present access is
possible. And some stuff on it to view if it is tampered with.
(if the jumper raises or lowers a gpio device on an i2c chip this can
be easily detected in a u-boot script and depending on that action
could be taken).

My two cents.

Frans

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

[Wolfgang Denk]

Dear Graeme,

In message <4F35EBBF.3050106@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 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.

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

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
What is tolerance? -- it is the consequence of humanity. We  are  all
formed  of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature.                  - Voltaire

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

[Wolfgang Denk]

Dear Frans,

In message <CACW_hTYv179qWbQUiuv_qQbE_bLy9b_H-qpZSbcjkPio9-2yzg@mail.gmail.com> you wrote:
>
> Graeme, if you want to keep people outisde the bootloader in a
> reasonably safe way and are developing your own hardware an option is
> to put the password in e.g. an eeprom and do a compare in u-boot.
> Of course a persistent hacker could retrieve the password but a casual
> user will not be able to enter.

For a "casual user" the existing CONFIG_AUTOBOOT_KEYED feature is
usually sufficient.

A "persistent hacker" will not be kept out in either of these ways if
he has access to the U-Boot command line.  If needed, he will install
or otherwise run code that skips these steps.

> Having the password in eeprom makes that it is not disclosed with the
> code, it can be changed etc. Just make sure users do not have easy
> (sw) access to the device the password resides in, so e.g.disable
> access one way or another.

You will still publish the code that implements these restrrictions,
so guess how difficult it is to work around it?

> One other way to prevent accidental access would be a jumper. If
> present no access to u-boot possible at all, if not present access is
> possible. And some stuff on it to view if it is tampered with.
> (if the jumper raises or lowers a gpio device on an i2c chip this can
> be easily detected in a u-boot script and depending on that action
> could be taken).

None of this is actually adding any kid of "security" or "protection"
to a device.  

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
Horses just naturally have mohawk haircuts.

[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@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

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

[Graeme Russ]

Hi Frans,
On 02/11/2012 08:00 PM, Frans Meulenbroeks wrote:
> 
> Graeme, if you want to keep people outisde the bootloader in a
> reasonably safe way and are developing your own hardware an option is
> to put the password in e.g. an eeprom and do a compare in u-boot.
> Of course a persistent hacker could retrieve the password but a casual
> user will not be able to enter.
> Having the password in eeprom makes that it is not disclosed with the
> code, it can be changed etc. Just make sure users do not have easy
> (sw) access to the device the password resides in, so e.g.disable
> access one way or another.

The problem is when the 'super secret password' get out into the wild (I
suggest you google 'Stuxnet' - not bootloader related, but highlights the
flaws of 'security by obscurity')

> One other way to prevent accidental access would be a jumper. If
> present no access to u-boot possible at all, if not present access is
> possible. And some stuff on it to view if it is tampered with.
> (if the jumper raises or lowers a gpio device on an i2c chip this can
> be easily detected in a u-boot script and depending on that action
> could be taken).

Yes, a jumper is one idea to prevent command line access as it would
require physical alterations which can be easily detected (stickers for
example)

But what if there as some commands the end-user is safe to use and some
that only the manufacturer should use - Of course the argument would be
that the end-user commands should be in the OS and I would tend to agree

Regards,

Graeme

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

[Mike Frysinger]

On Sunday 12 February 2012 04:33:07 Graeme Russ wrote:
> Suitable encryption is already in U-Boot (we have SHA and MD5 libraries
> already)

these are hashing functions, not encryption routines
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120212/017f74a6/attachment.pgp>

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

[Wolfgang Denk]

Dear Graeme,

In message <4F378753.4070808@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.

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

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

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

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

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

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
Hello! I'm from outer space,  and I've made myself look like a signa-
ture.  While  you  are reading this, I'm having sex with your eyes. I
know it feels good to you, because you're smiling. I'm very horny, so
send me to someone else when you've had enough. Thanks!
                              Sincerely, A Stranger in a Strange Land

[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@denx.de> wrote:
> Dear Graeme,
>
> In message <4F378753.4070808@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

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

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButCJyfBxrKURaG-ytk767D4Nfc5b6sN6O7Bdx+KH2GCC2Kg@mail.gmail.com> you wrote:
> 
> > 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.

Well spotted.  And this is the very reason why I recommend doing these
things in Linux, and _not_ in the boot loader.

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

Not remove it, but don't give the user an interactive shell when he is
running in production mode.  You can then still use it in scripts, or
when you switch to test mode (which should be doen through a jumper or
hardware dongle or similar, as discussed previously).

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

password = key.  How are going to manage these?

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

You don't understand.

Adding security _always_ means removing certain "convenient" features.

Having a powerful, flexible tool that allows the user to do about
everything and defining a secure environment where a specific user
has only a well-defined set of capabilities are mutually exclusive by
definition.


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

Use Linux, then.

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

Ah!  So your problem is that you want to do inappropriate things
because your crappy, proprietary RTOS prevents you from doing the
rights things.

I'm sorry, but I don't commiserate with you about that.

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

It would be a totally wrong conclusion, though, to try to turn the
boot loader in a wannabe OS just because it is more useful and capable
than your RTOS.

If your RTOS does not stand to your requirements, then fix the cause
of the problem, i. e. use a more capable OS.

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

Agreed. Which is excatly why I prefer Free Software whenever it comes
to security, crypto-technology etc.

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
Little known fact about Middle Earth:   The Hobbits had a very sophi-
sticated computer network!   It was a Tolkien Ring...

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

[Graeme Russ]

Hi Wolfgang,

On 02/13/2012 06:31 PM, Wolfgang Denk wrote:

>> So basically you are suggesting to completely remove shell access in U-Boot
>> which is one thing that make U-Boot so attractive.
> 
> Not remove it, but don't give the user an interactive shell when he is
> running in production mode.  You can then still use it in scripts, or
> when you switch to test mode (which should be doen through a jumper or
> hardware dongle or similar, as discussed previously).

Ah, so there will still be a 'gate' beyond which access must be validated.
You are suggesting a hardware check of a GPIO pin or, if the hardware does
not provide for that, maybe a serial or USB dongle...

That is no less complex (and in the USB case actually much more complex)
than what I was suggesting - In the dongle case you need to read and
validate the dongle then flag to U-Boot that it is OK to enter command line

GPIO case is the same, you need to read the GPIO pin and if not set, skip
entering command line

Again, my suggestion was, prior to entering command line, require a
password to be entered - If the hash of the password matches a given
environment variable, do exactly what the GPIO or dongle read returned true
- enter unrestricted command line

>>> 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
> 
> password = key.  How are going to manage these?

I've said before, a hash of the password as an environment variable

>>> 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
> 
> You don't understand.
> 
> Adding security _always_ means removing certain "convenient" features.
> 
> Having a powerful, flexible tool that allows the user to do about
> everything and defining a secure environment where a specific user
> has only a well-defined set of capabilities are mutually exclusive by
> definition.

Well that (level based access to individual commands) was only a wild
speculation on the future. My initial thought was just a simple gate prior
to U-Boot getting to command line - Basically just a password hash
validation in place of the existing 'abort auto-boot string' compare which
is easily circumvented by obtaining the source code

>> 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 -
> 
> Use Linux, then.
> 
>> 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)
> 
> Ah!  So your problem is that you want to do inappropriate things
> because your crappy, proprietary RTOS prevents you from doing the
> rights things.

No, not me - I'm not in that game. I'm just playing devils advocate because
I know how these things work in the real world - GNU/Linux uptake is
pitifully low :(

> I'm sorry, but I don't commiserate with you about that.

Understood :)

> 
>> And if the OS you used does not have a command line, you have to implement
>> that on top - Often a non-trivial endeavour
> 
> It would be a totally wrong conclusion, though, to try to turn the
> boot loader in a wannabe OS just because it is more useful and capable
> than your RTOS.

There is no 'wannabe OS' about it - It is a simple 'enter a
string->hash->compare' if equal, drop to command line, if not, loop back

> If your RTOS does not stand to your requirements, then fix the cause
> of the problem, i. e. use a more capable OS.
> 
>> 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...
> 
> Agreed. Which is excatly why I prefer Free Software whenever it comes
> to security, crypto-technology etc.

100% Agree

Regards,

Graeme

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

[Wolfgang Denk]

Dear Graeme,

In message <4F38F91D.6070301@gmail.com> you wrote:
> 
> > Not remove it, but don't give the user an interactive shell when he is
> > running in production mode.  You can then still use it in scripts, or
> > when you switch to test mode (which should be doen through a jumper or
> > hardware dongle or similar, as discussed previously).
> 
> Ah, so there will still be a 'gate' beyond which access must be validated.
> You are suggesting a hardware check of a GPIO pin or, if the hardware does
> not provide for that, maybe a serial or USB dongle...

USB dongle is definitely on the far end, but why not - if you have
such a sort of S & M preferences ;-)

Normally a jumper or DIP switch would be used - which is trivial to
implement.

> GPIO case is the same, you need to read the GPIO pin and if not set, skip
> entering command line

Which is trivial.  Just implement the test in misc_init_r(), and use
this to set bootdelay to 0 or -1 or similar.

> Again, my suggestion was, prior to entering command line, require a
> password to be entered - If the hash of the password matches a given
> environment variable, do exactly what the GPIO or dongle read returned true
> - enter unrestricted command line

I understand your proposal, and actually we already have that!  See
the documentation in doc/README.autoboot 

But you were talking about security - guess how many of such systems
will all run with the very same password?  And guess how long it will
take until it is publicly known?

Even if you extend this feature to store only a hash of the password,
and compare the hashes, the fundamental problem will remain:  How can
you precent that the passwords get faster pblicly known than you can
change them?

What do you do in case the user forgets the password?  Will he have to
return his box for repair or even replacement?

Of will there be some additional "master password" which is only
known to your field circus engineers (and after a few days to all
hackers in the whole world)?


> > password = key.  How are going to manage these?
> 
> I've said before, a hash of the password as an environment variable

This does not answer how you intend to handle the obvious problems -
see above.


> Well that (level based access to individual commands) was only a wild
> speculation on the future. My initial thought was just a simple gate prior
> to U-Boot getting to command line - Basically just a password hash
> validation in place of the existing 'abort auto-boot string' compare which
> is easily circumvented by obtaining the source code

You trade one problem for another.  Guess how many users will call
service because they have forgotten their password settings?

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
"The glory of creation is in its infinite diversity." "And in the way
our differences combine to create meaning and beauty."
	-- Dr. Miranda Jones and Spock, "Is There in Truth No Beauty?",
	   stardate 5630.8