Storing an encryption key in CMOS

From: Alexander Lukyanenko (
Date: 03/04/04

  • Next message: Rosenhan, David: "RE: 802.1x and PEAP"
    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
    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
       application crash.

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


  • Next message: Rosenhan, David: "RE: 802.1x and PEAP"