Security Basics mailing list archives
Storing an encryption key in CMOS
From: Alexander Lukyanenko <sashman () ua fm>
Date: Thu, 4 Mar 2004 22:22:38 +0200
Hello people. 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 password); 2) online compromise (the system gets hacked while being up and running); 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 application crash. CONCLUSION: 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 * * * * * * * * * * * * * * * *
Attachment:
_bin
Description:
Current thread:
- Storing an encryption key in CMOS Alexander Lukyanenko (Mar 04)
- Re: Storing an encryption key in CMOS Vladimir B. Kropotov (Mar 08)
- Re[2]: Storing an encryption key in CMOS Alexander Lukyanenko (Mar 09)
- Crypto implementation for public use (was: RE[2]: Storing an encryption key in CMOS) Vladimir B. Kropotov (Mar 17)
- Re[2]: Storing an encryption key in CMOS Alexander Lukyanenko (Mar 09)
- Re: Storing an encryption key in CMOS Vladimir B. Kropotov (Mar 08)