Security Basics mailing list archives
Crypto implementation for public use (was: RE[2]: Storing an encryption key in CMOS)
From: "Vladimir B. Kropotov" <slyman2000 () mail ru>
Date: Wed, 17 Mar 2004 12:24:12 +0300
Hello List! /********Original message at the end****/ VBK> Software that running is running under OS <=> OS can manage that software VBK> <=> If you interact like part of OS you can get anything you want including VBK> passwords and unencrypted sensetive data.
Not in case of MS EFS, where the data is stored encrypted, and the encryption key is itself encrypted with a user's password. No password - no data, no matter how deep you are, even if you're in ring 0.
Ring 0, Ring 3 IS abstraction.... Rings, Fields and Number theory IS cryptography To decrypt any data OS must store UNECRYPTED KEY in memory <=> if you in ring 0 you can read that memory. EFS IS abstraction too.... Your security always depends on security expert experience and ammount of your money that you can spend on it. VBK> I think you can find 16 bytes = 128 bit for your key.....
THe solution is up for the vendors, I suppose.
VBK> If you really wanna use strong filesystem encryption, you must use some VBK> kind of hardware addon that implement that encryption instead implement that VBK> encryption using software. And in any case KEYS and DATA must be separated.
The hardware addon must be perishable (i.e. it's storage's contents must be destroyed should the system get compromised).
Hardware addon must directrly interact with PC hardware without any intermediate layer. In that case it will be robust ehough. Partly that's terrific idea if Vendor Community will be able to implement it.... Regards, Vladimir B. Kropotov P.S. If you have any thoughts about subj. feel free to mail me directly. 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 * * * * * * * * * * * * * * * * --------------------------------------------------------------------------- Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off any course! All of our class sizes are guaranteed to be 10 students or less to facilitate one-on-one interaction with one of our expert instructors. Attend a course taught by an expert instructor with years of in-the-field pen testing experience in our state of the art hacking lab. Master the skills of an Ethical Hacker to better assess the security of your organization. Visit us at: http://www.infosecinstitute.com/courses/ethical_hacking_training.html ----------------------------------------------------------------------------
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)