Storing an encryption key in CMOS
From: Alexander Lukyanenko (sashman_at_ua.fm)
Date: Thu, 4 Mar 2004 22:22:38 +0200 To: email@example.com
While replacing a faulty CMOS battery, I came upon an idea:
what if we store a file encryption key in the NVRAM chip (in the very
same place, where the BIOS settings, among with the BIOS password, are
stored). Imagine the (hardly, but still possible) case:
the system boot is locked by a BIOS password. Now (imagination, again), our system gets stolen. In order to gain
access to the system, a cracker will have to bypass the BIOS security
in order to boot it at all or to boot from a custom boot media
(knoppix, various OS rescue modes et cetera). He'll probably have to
zero-out the CMOS by pulling a battery out. And here the magic comes
in. Along with the BIOS password, system time and various settings,
our crypto key goes to the void. That means the cracker won't be able
to decrypt the files in a reasonable time.
The key is used to encrypt files at the filesystem level (i.e. MS EFS)
or at the application level (i.e. Gnu PG or PGP). The key retrieval
method would (unfortunately) be vendor-specific.
Also, the key must be backed up as usual (just for the above-mentioned
case of a dying battery :p )
Why do the system boot must be passworded (==you'll need to enter a
password every time you power up the system)?
Because, in case of a ``hardware compromise'', the attacker will be
able to hook his/her/its :) own HDD and access the NVRAM (the very
same way the application would access the encryption key).
This approach only adds a layer of security against a specific kind
attack, and the major drawbacks of it are:
1) boot time password (the boot password is good for single user
systems, because most kinds of BIOSes provide only one or two
passwords, having many people sharing same password is not good.
Also, most users would find it annoying to type one password, then
wait for the OS to load, then login with a username and another
2) online compromise (the system gets hacked while being up and
3) physical examination of the CMOS chip (i.e. pull the chip out,
while keeping it powered from an external source and plug it into a
programmer and voila: you have the NVRAM)
4) the NVRAM memory has <very> limited size, so the length of key will
be also limited.
5) the key has to be stored in RAM and can possibly be swapped to
disk/dumped along with the core dump in case of a system or
This concept is intended as an added layer of security; it does not
guarantee 100% protection (as no method does), but can provide a good
line of defence against a more-than-causal snooper.
It might be particularily interesting to laptop vendors.
I haven't heard of such technologies, so please don't beat me if
something similar already exists; all comments are welcome.
* * * * * * * * * * * * * * *
* Alexander V. Lukyanenko *
* ma1lt0: sashman ua fm *
* ICQ# : 86195208 *
* Phone : +380 44 458 07 23 *
* OpenPGP key ID: 75EC057C *
* NIC : SASH4-UANIC *
* * * * * * * * * * * * * * *
- application/pgp-signature attachment: stored