[U-Boot] Password protection of U-Boot command line
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
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
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
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
participants (5)
-
Frans Meulenbroeks -
Graeme Russ -
Marek Vasut -
Mike Frysinger -
Wolfgang Denk