[PATCH] Adding password protection to U-boot
frances.albanese at gmail.com
Tue Jul 8 16:55:00 CEST 2008
On Tue, Jul 8, 2008 at 3:00 PM, Werner Almesberger <werner at openmoko.org> wrote:
> If you just replace u-boot in NAND, getting rid of the password is
> trivial: just bring up u-boot from NOR and wipe out the environment
> or install a u-boot that doesn't ask for passwords.
> If you add the password check also to the u-boot in NOR but store
> the password in NAND, this would imply that recovery can be
> compromised, e.g., someone who gets hold of an unprotected device
> could just write a random password into NAND as a prank.
NAND environment can be accessed on Linux via MTD using root privileges.
It shouldn't be so difficult to write a tool to manage the NAND
partition and reset a password just in case.
If we assume that root is not the default user - as it should be in
the real world - the safety of such a tool relies solely on the
robustness of privilege separation.
> A secure mechanism could be implemented by replacing the NOR u-boot
> with one in which the user's password hash is hard-coded. But you'd
> need the debug board for installing that u-boot.
Yeah, too messy.
> Another possibility would be that each device ships from the factory
> with a hard-coded password to access the NOR. I'm not sure if this
> would be desirable as a universal feature.
Yeah, I don't think that people @ openmoko wants to flash a random
password for each device and put it into each box: the procedure
breaks the automated production and slows down all the chain, I guess.
> Also note that anyone who has a debug board can easily replace
> anything that's in NAND or NOR, so such a password protection would
> not be an effective deterrent against theft (chances are that a
> thief would only find out later anyway, so it's gone with or without
> the password) or more resourceful pranksters.
All systems are breakable sooner or later, we need just enough
time/resources to crack them. If the effort needed to break a system
discourages the not-enough motivated thief, spy or whatsoever another
point in security is scored.
The actual question is: how many debug boards are going to be sold ?
Could it be so easy to get one in the future, once NEO will be
> If you analyze your individual threat profile, you may very well be
> able to find a solution that suits you. So I think there can be a
> place for a protection that isn't perfect, as long as it's something
> a user installs individually.
I understand the need of having a reliable device, but this state of
the art issue is so interesting and relevant that I believe that all
the possible options haven't been evaluated yet.
More information about the openmoko-devel