[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

[Wolfgang Denk]

Dear Graeme Russ,

Post by Graeme Russ
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").

Post by Graeme Russ
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

[Graeme Russ]

Hi Wolfgang,

Post by Wolfgang Denk
Dear Graeme Russ,

Post by Graeme Russ
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 :)

Post by Wolfgang Denk

Post by Graeme Russ
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

[Marek Vasut]

Post by Graeme Russ
Hi Wolfgang,

Post by Wolfgang Denk
Dear Graeme Russ,
In message

Post by Graeme Russ
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 :)

Post by Wolfgang Denk

Post by Graeme Russ
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

Post by Graeme Russ
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

[Wolfgang Denk]

Dear Marek,

Post by Marek Vasut

Post by Graeme Russ
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

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

[Wolfgang Denk]

Dear Frans Meulenbroeks,

Post by Frans Meulenbroeks
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.

Post by Frans Meulenbroeks
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.

Post by Frans Meulenbroeks
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

[Frans Meulenbroeks]

Post by Wolfgang Denk
Dear Frans Meulenbroeks,

Post by Frans Meulenbroeks
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.

Post by Frans Meulenbroeks
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.

Post by Wolfgang Denk
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

Post by Wolfgang Denk

Post by Frans Meulenbroeks
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

[Wolfgang Denk]

Dear Frans,

Post by Frans Meulenbroeks

Post by Wolfgang Denk
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.

Post by Frans Meulenbroeks

Post by Wolfgang Denk
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

[Mike Frysinger]

Post by Frans Meulenbroeks
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>

[Mike Frysinger]

Post by Mike Frysinger

Post by Frans Meulenbroeks
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>

[Graeme Russ]

Hi Mike,

Post by Mike Frysinger
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

Post by Mike Frysinger
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

[Frans Meulenbroeks]

Post by Graeme Russ
Hi Mike,

Post by Mike Frysinger
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

Post by Mike Frysinger
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

[Wolfgang Denk]

Dear Frans,

Post by Frans Meulenbroeks
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.

Post by Frans Meulenbroeks
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?

Post by Frans Meulenbroeks
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

[Graeme Russ]

Hi Frans,

Post by Frans Meulenbroeks
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')

Post by Frans Meulenbroeks
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

[Wolfgang Denk]

Dear Graeme,

Post by Graeme Russ
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.

Post by Graeme Russ
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.

Post by Graeme Russ
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.

Post by Graeme Russ
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

[Graeme Russ]

Hi Wolfgang,

Post by Wolfgang Denk
Dear Graeme,

Post by Graeme Russ
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 :)

Post by Wolfgang Denk

Post by Graeme Russ
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.

Post by Graeme Russ
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...

Post by Wolfgang Denk

Post by Graeme Russ
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

[Mike Frysinger]

Post by Graeme Russ
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>

[Wolfgang Denk]

Dear Graeme,

Post by Graeme Russ

Post by Wolfgang Denk
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.

Post by Graeme Russ
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/

Post by Graeme Russ
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.

Post by Graeme Russ

Post by Wolfgang Denk
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.

Post by Graeme Russ
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.

Post by Graeme Russ
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

[Graeme Russ]

Hi Wolfgang,

Post by Wolfgang Denk
Dear Graeme,

Post by Graeme Russ

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.

Post by Wolfgang Denk

Post by Graeme Russ
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.

Post by Wolfgang Denk

Post by Graeme Russ
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

Post by Wolfgang Denk

Post by Graeme Russ

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

Post by Wolfgang Denk

Post by Graeme Russ
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

Post by Wolfgang Denk

Post by Graeme Russ
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

[Wolfgang Denk]

Dear Graeme Russ,

Post by Graeme Russ

Post by Wolfgang Denk
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.

Post by Graeme Russ

Post by Wolfgang Denk
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).

Post by Graeme Russ

Post by Wolfgang Denk
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?

Post by Graeme Russ

Post by Wolfgang Denk
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.

Post by Graeme Russ
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.

Post by Graeme Russ
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.

Post by Graeme Russ
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.

Post by Graeme Russ
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

[Graeme Russ]

Hi Wolfgang,

Post by Wolfgang Denk

Post by Graeme Russ
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

Post by Wolfgang Denk

Post by Graeme Russ

Post by Wolfgang Denk
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

Post by Wolfgang Denk

Post by Graeme Russ

Post by Wolfgang Denk
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

Post by Wolfgang Denk

Post by Graeme Russ
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.

Post by Graeme Russ
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 :(

Post by Wolfgang Denk
I'm sorry, but I don't commiserate with you about that.

Understood :)

Post by Wolfgang Denk

Post by Graeme Russ
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

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

Post by Graeme Russ
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

[Wolfgang Denk]

Dear Graeme,

Post by Graeme Russ

Post by Wolfgang Denk
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.

Post by Graeme Russ
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.

Post by Graeme Russ
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)?

Post by Graeme Russ

Post by Wolfgang Denk
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.

Post by Graeme Russ
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

[Wolfgang Denk]

Dear Graeme Russ,

Post by Graeme Russ

Post by Wolfgang Denk
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 ...

Post by Graeme Russ
I think we can agree that there is room for improvement :)

Always, and everywhere.

Post by Graeme Russ
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.

Post by Graeme Russ
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