Thanks Robert & Simon, however it appears that I was not clear enough in my thinking and explaining.
The first assumption was that it was *not* a two factor authentication - I was going to think about that after I had the base case worked out. The next assumption is that something like a TPM or other chip based authentication system was in use but it was just using Password Based authentication. Input username, input password (even a _very_ long one that Rainbow tables won't work for), the embedded (?) code checks against whatever is local - not LDAP or other net based system as this is a machine that is just sitting in the lap of the thief - and since you input the right combo, the system lets you boot the opportunistic OS. I.e., before the OS boots it asks for username and password, then, if you get it right, it allows the *first* OS that the BIOS points to, i.e., one that is on a CD - like Knoppix - or one that is on a USB key - like Slax - before it searches for the OS on the HD. If this were the case, could the non-native OS - i.e., not located on the HD - read the sector based FDE? Thanks, Allen 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
