Crypto implementation for public use (was: RE[2]: Storing an encryption key in CMOS)

["Vladimir B. Kropotov" <slyman2000 () mail ru>]

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
----------------------------------------------------------------------------