Allen, I was reading your email.. 2. If a USB device is used to contain a pre-boot key but with only one-factor authentication (possession), a la Vista Ultimate with BitLocker, then this cryptographically quite sound, and significantly better than using Windows authentication, BUT it assumes that the user will manage the USB device properly, and not lose it or have it stolen along with the. This is a dubious assertion, in my experience.
> This gap may be closed by using biometrics USB devices. We are manufacturers of Bioslimdisk, usb device coupled with fingerprint-recognition. Is it possible to contain a pre-boot key and provide two-factor authentication at pre-boot? Derrick Robert Jueneman wrote: > Allen, the answer depends upon how the pre-boot authentication works, > and there are four possibilities to consider: > > 1. If a hardware cryptographic token is used to provide two-factor > authentication at pre-boot (which we would certainly recommend, > regardless of the FDE vendor), then this is almost certainly more secure > than using the Windows certification. If the cryptographic keys are > sufficiently strong enough (e.g., ECC P-384) to protect the AES-256 key > that is used to protect the FDE, then this is certainly the best > approach, but only WinMagic SecureDoc and the SPYRUS Rosetta token > support this feature at present. If a CAC or PIV card is used, the > RSA-1024 key is potentially the weak link. > 2. If a USB device is used to contain a pre-boot key but with only > one-factor authentication (possession), a la Vista Ultimate with > BitLocker, then this cryptographically quite sound, and significantly > better than using Windows authentication, BUT it assumes that the user > will manage the USB device properly, and not lose it or have it stolen > along with the. This is a dubious assertion, in my experience. > 3. If pre-boot authentication depends upon a password only, with the > encrypted/obfuscated password stored on the disk where it could be > accessed by an off-line OS, then the answer is "it depends". Password > Based Encryption (PKCS#5)is at best 100 million times more resistant to > exhaustive search attack than a single round of AES or SHA-x, so that > amounts to about 27 bits. Add that to the number of bits of entropy in > the password, and compare that to the required crypto strength, and > you'll have your answer. > A. Ordinary English language has about 3.3 bits of entropy per > character, and coincidentally so do random numeric characters. So if > your password is you're a nine digit SSN or a 10-digit telephone number, > then that is 30 to 33 bits, plus 27, or 60-bits in total. That is a > long way from the 80-bit crypto NIST is demanding by 2008. > B. If a completely random password is generated or selected, > using all of the 96 characters available on the keyboard, that is about > 6.5 bits of entropy per character. So if you are using a completely > random 8-character password or PIN, then you might have the equivalent > of 52+27 = 79 bits -- almost good enough for next year, but nothing to > brag about. To be equal to the P-384 key, you would have to memorize 55 > completely random characters, and if all of your users can do that > without writing them down, your entire organization must be members of > MENSA. But shoulder-surfing and/or video taping would break even that. > 4. Pick up a copy of "Hacking for Dummies" in any bookstore. You will > see that Rainbow cracking tools can break most Windows passwords of less > than 15 characters in minutes, because of the long-standing flaw in the > Windows LAN Manager password. Most IT organizations, in our experience, > have NOT addressed that vulnerability, and certainly most users don't > use 15 character passwords. (Even if they did, we are talking about > hours or days of dedicated effort to break the password, not months.) > That is why I get so irate when I hear of yet another laptop theft, and > the organization affected puts out a soothing press release saying that > the risk is minimal -- they laptop was password protected. That just > confirms the fact that the organization is clueless about security. > > Bob > > Robert R. Jueneman > SPYRUS, Inc. > > > Message: 2 > Date: Tue, 09 Oct 2007 21:02:55 -0700 > From: Allen <[EMAIL PROTECTED]> > Subject: [FDE] Interesting question (at least to me ;->) > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi gang, > > Been thinking about modes of attack against FDE in Windoze and > came up with a question I can't seem to find a reasonable answer to. > > The are two modes of authentication to decrypt data on a sector > based encryption scheme as I understand it: > > 1. Pre-boot authentication - i.e, before the OS starts > 2. Post-boot authentication - i.e. after the OS starts > > Assuming that one was able to shoulder surf the user name and > password, but that the user was not listed as an administrator > and so has very limited rights to access the SAM or other > critical system files, which mode protects better against an > attack by using a USB key/LiveCD based *nix where the BIOS allows > booting from USB/CD ahead of the HD? > > Intuitively it seems to me that a post-boot authentication is > better because the specific OS that boots has the authentication > is within itself. It seems to me that a pre-boot authentication > could perhaps be defeated by allowing the sectors to be unlocked > by whatever OS boots, even if it was not the OS that was intended. > > Does this make sense? Large holes welcome. > > Best, > > Allen > > > _______________________________________________ > FDE mailing list > [email protected] > http://www.xml-dev.com/mailman/listinfo/fde > > _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
