[OLPC-devel] Secure BIOS on the OLPC
John R. Hogerhuis
jhoger at pobox.com
Sun Aug 27 18:56:38 EDT 2006
On Sun, 2006-08-27 at 17:11 -0400, Ivan Krstić wrote:
> [This is important, and your comments are requested -- please read.]
let it be understood that you asked :-)
<<SNIP>>
> I argue that this solution is deeply flawed for three reasons:
>
> * while it stops a worm-type attack, it does nothing against phishing,
> where the kids will be convinced to hold the buttons down while a
> malicious BIOS gets flashed
>
There can be no technical solutions to phishing, it's a problem of
educating the users to follow the school systems AUP.
Kids are also physically unprevented from setting their books afire,
torching their school building, or taking a sledgehammer to their OLPC.
I think a hammer (or egads, a soldering iron) would do much more to
prevent desired operation of the machine than that an OLPC can be loaded
by the local admin with alternative firmware. Why should either
considered an issue?
> * it allows any BIOS to be flashed, so long as the keys are pressed,
> when in reality there's no direct need to support non-OLPC BIOSes
>
That's a feature not a bug. "Unsupported" does not mean "physically not
permitted." Is there a requirement somewhere that the OLPC should be
immune to its owners loading alternative software? My understanding has
been the opposite.
If loading new software is not allowed simply setting the school policy
to "not allowed" and not running as root should be sufficient.
> * it requires the kids' cooperation for legitimate upgrades, which means
> the kids suddenly need to distinguish between legitimate and
> illegitimate upgrades, or fall prey to phishing
>
Upgrading of firmware should always require the users explicit assent.
The BIOS just has to be "that good" before release that automatic
upgrades are generally not required. It's too dangerous to allow
automatic upgrades of the firmware, cryptographically signed or not. Do
you know of any devices that upgrade their firmware without consent
unless the *local* admin has explicitly chosen to enable that? I'd guess
they are few and far between. If anything, maybe cable boxes and DVRs.
OLPCs are not TVs.
But I'll admit that OLPC is a different animal. It will have a more
complex firmware than most others by virtue of embedding Linux which is,
by virtue of that complexity, *NOT* bulletproof.
<<SNIP>>
> Voila. This is now a completely secure BIOS solution which requires no
> TPM,
Such hubris! I have a soldering iron that says you're wrong, but hey
maybe soldering irons are not all that common.
In general I'd recommend not succumbing to the temptation to lock down
the machine from its local admin. Preventing completely remote upgrades
of the basic firmware of the machine should be considered sufficient
security for the BIOS. Don't view the user as the enemy. They are not,
in fact they are the ones we have no choice but to trust since they
control the physical security of the machine.
If anything, you might disable some portions of the official OLPC
operating system, set up outbound firewall retrictions, tattle to the
admin, etc. until a required firmware upgrade is performed by the user,
to protect other machines on the network, or simply to punish the user
for non-compliance.
-- John.
More information about the Devel
mailing list