Re: [H] Breaking Disk Encryption
I'm not surprised, check out the IronKey though. Ben Ruset wrote: > Be careful with the so-called "hardware" encryption devices. It turns > out that some of them aren't really quite good: > > http://www.heise-online.co.uk/security/Enclosed-but-not-encrypted--/features/110136 > > > j maccraw wrote: >> >> Bottom line is time has come for *affordable*, faster, >> dedicated hardware solutions to be made available. Either in the form of >> TPM's in motherboards, storage devices, host controllers, or even inline >> black boxes between device & host using a tamper-proof hardware >> solution. A >> solution like the IronKey USB flash drive has between it's USB >> interface & flash >> RAM. Give me a bunch of those modules in the form of SATA go-betweens >> & programmable >> hardware security token I'd have all my SATA drives encrypted! > > Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [H] Breaking Disk Encryption
I seriously doubt anyone is saying you can crack AES *WITHOUT* access to the keys or a serious flaw in the implementation there of. This article is about a flaw where the keys are in RAM in the clear. Flushing the keys when the system goes into a locked or suspend state (while halting processes that need access to the encrypted data) and forcing the keys to be re-entered externally on resume would remove this vulnerability completely. Hardware *is* the solution if you understand the flaws of using general purpose computers to run encryption software vs. dedicated hardware doing it. Then factor in as you said, an external factor like a token or certificate that is separate from the PC. Without RAM to be accessed, there locally is no key to be found by forensics. As to if someone can get to the other component needed to decrypt is another discussion completely and moot if that component can be destroyed. A completely encrypted system is not debuggable because by definition nothing is "in the clear". Sure you can "read" it's RAM while tweaking it's input ports trying to discern what it's keys are based on injecting known values but asymmetrical is supposed to mean even with encryption key, source plain data & resulting encrypted data it's not going to reveal the decryption key. Look into the IronKey drive I was mentioning & you'll understand it would be damn hard to get at where the keys are "to connect debuggers" & still be able to retrieve keys nor a still working module. That module as a SATA go-between would mean your not getting into the drive without whatever component unlocks the encryption module. Even with "flawed" TC on a Powered down system, no trace keydata on the HDD, no get in short of brute force (AES? TwoFish? much luck!) FBI or not. Only option would be "water boarding" and that's not going to produce results if the keys were on a component and destroyed vs. being a password you can force out of a subject. Mesdaq, Ali wrote: > Hardware is not really the solution. The problem is layered but the main > problem here is physical security. If you have a system and all of its > components to encrypt and decrypt are right there in one piece and > people can connect debuggers to it or analyze it they could break > anything you do. But if the system is not complete without something > else like a private key that needs to be retrieved remotely then you > have some extra security. Then you can control the process by seeing if > physical security is compromised you just don't send that private key > and the system is incomplete. For true secure solutions you need to > layer, then separate, then control access to each layer and component. > So in the case of hard drive encryption if an FBI person gets your drive > and you can bet they can find out everything on it if they care enough. > > Security is really just a level of comfort you can deal with. EVERYTHING > can be compromised in some way. > Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [H] Breaking Disk Encryption
Hardware is not really the solution. The problem is layered but the main problem here is physical security. If you have a system and all of its components to encrypt and decrypt are right there in one piece and people can connect debuggers to it or analyze it they could break anything you do. But if the system is not complete without something else like a private key that needs to be retrieved remotely then you have some extra security. Then you can control the process by seeing if physical security is compromised you just don't send that private key and the system is incomplete. For true secure solutions you need to layer, then separate, then control access to each layer and component. So in the case of hard drive encryption if an FBI person gets your drive and you can bet they can find out everything on it if they care enough. Security is really just a level of comfort you can deal with. EVERYTHING can be compromised in some way. Thanks, -- Ali Mesdaq (CISSP, GIAC-GREM) Security Researcher II Websense Security Labs http://www.WebsenseSecurityLabs.com -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of j maccraw Sent: Friday, February 22, 2008 2:24 AM To: hardware@hardwaregroup.com Subject: Re: [H] Breaking Disk Encryption Nice find Ali! sorry this long, by I feel passionate about this... Yet another disturbing insight into how exploitable the modern PC is. To be fair, peaking into RAM of running systems has been PoC'd more than a few times (as have a countermeasure or 2) all useless against a fully unpowered system. Scary to have powered vs. not redefined though! When I 1st started toying 10+ years ago with Norton Your Eyes Only, E4M & later DriveCrypt it seemed the biggest issue after what cipher, what app, was OS swapping RAM to disk either pagefile or for hibernation. Yet for for years Crypto experts like Bruce Schneier and others have been saying that no matter what, using general purpose computers to run encryption software is flawed & exploitable. It would seem that ultimately noting short of both full RAM & storage encryption is going to prevent a running system from having it's brains sucked out & scrutinized. We know of attempts with M$ XBOX, HDCP, or HD-DVD/BluRay to secure against scrutiny. While they are seeing varying degrees of success locking US out very little is coming in the form of letting us lock THEM out. Obviously it's possible to build systems that once set-in-motion, encrypt and continue to run leaving no "keys" in ram to sniff since only the system knows what it's using to crypt/decrypt like Colossus & Guardian talking to each other in a language only they knew! Until then, on running systems, manual user intervention is needed where auto-dismount is not practical. Passwords/phrases must die, keys must be tied to a secure physical token so that removing it means there are no keys. Removal of token should trigger memory wiping so keydata is not cached. Some of this must already exist? I won't even go into EFS, it's default lame option of obscuring the master keys in the registry, or the fact that mode 3 only works with floppies! Now any system that can be suspended has got to be easier to protect IMHO. If RAM sniffing an issue, then OTFE software needs to add key flush on on suspend followed by re-authentication to retrieve keys from external source (read not on the PC's RAM, HDD, SDD) on resume rather use RAM cached copies. Don't know how easy that is to tie in, but I assume under the current model apps have to wait for storage drivers to come back online after suspend anyway so I imagine it how this hole gets closed. Personally I'd like to have a encrypted hibernation file tied to a physical token for "plug & boot" authentication. Bottom line is time has come for *affordable*, faster, dedicated hardware solutions to be made available. Either in the form of TPM's in motherboards, storage devices, host controllers, or even inline black boxes between device & host using a tamper-proof hardware solution. A solution like the IronKey USB flash drive has between it's USB interface & flash RAM. Give me a bunch of those modules in the form of SATA go-betweens & programmable hardware security token I'd have all my SATA drives encrypted! Mesdaq, Ali wrote: > Interesting read for those into disk encryption > > http://www.news.com/8301-13578_3-9876060-38.html > > Thanks, > -- > Ali Mesdaq (CISSP, GIAC-GREM) > Security Researcher II > Websense Security Labs > http://www.WebsenseSecurityLabs.com > -- > > > Protected by Websense Messaging Security -- www.websense.com > > Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [H] Breaking Disk Encryption
Be careful with the so-called "hardware" encryption devices. It turns out that some of them aren't really quite good: http://www.heise-online.co.uk/security/Enclosed-but-not-encrypted--/features/110136 j maccraw wrote: Bottom line is time has come for *affordable*, faster, dedicated hardware solutions to be made available. Either in the form of TPM's in motherboards, storage devices, host controllers, or even inline black boxes between device & host using a tamper-proof hardware solution. A solution like the IronKey USB flash drive has between it's USB interface & flash RAM. Give me a bunch of those modules in the form of SATA go-betweens & programmable hardware security token I'd have all my SATA drives encrypted!
Re: [H] Breaking Disk Encryption
Nice find Ali! sorry this long, by I feel passionate about this... Yet another disturbing insight into how exploitable the modern PC is. To be fair, peaking into RAM of running systems has been PoC'd more than a few times (as have a countermeasure or 2) all useless against a fully unpowered system. Scary to have powered vs. not redefined though! When I 1st started toying 10+ years ago with Norton Your Eyes Only, E4M & later DriveCrypt it seemed the biggest issue after what cipher, what app, was OS swapping RAM to disk either pagefile or for hibernation. Yet for for years Crypto experts like Bruce Schneier and others have been saying that no matter what, using general purpose computers to run encryption software is flawed & exploitable. It would seem that ultimately noting short of both full RAM & storage encryption is going to prevent a running system from having it's brains sucked out & scrutinized. We know of attempts with M$ XBOX, HDCP, or HD-DVD/BluRay to secure against scrutiny. While they are seeing varying degrees of success locking US out very little is coming in the form of letting us lock THEM out. Obviously it's possible to build systems that once set-in-motion, encrypt and continue to run leaving no "keys" in ram to sniff since only the system knows what it's using to crypt/decrypt like Colossus & Guardian talking to each other in a language only they knew! Until then, on running systems, manual user intervention is needed where auto-dismount is not practical. Passwords/phrases must die, keys must be tied to a secure physical token so that removing it means there are no keys. Removal of token should trigger memory wiping so keydata is not cached. Some of this must already exist? I won't even go into EFS, it's default lame option of obscuring the master keys in the registry, or the fact that mode 3 only works with floppies! Now any system that can be suspended has got to be easier to protect IMHO. If RAM sniffing an issue, then OTFE software needs to add key flush on on suspend followed by re-authentication to retrieve keys from external source (read not on the PC's RAM, HDD, SDD) on resume rather use RAM cached copies. Don't know how easy that is to tie in, but I assume under the current model apps have to wait for storage drivers to come back online after suspend anyway so I imagine it how this hole gets closed. Personally I'd like to have a encrypted hibernation file tied to a physical token for "plug & boot" authentication. Bottom line is time has come for *affordable*, faster, dedicated hardware solutions to be made available. Either in the form of TPM's in motherboards, storage devices, host controllers, or even inline black boxes between device & host using a tamper-proof hardware solution. A solution like the IronKey USB flash drive has between it's USB interface & flash RAM. Give me a bunch of those modules in the form of SATA go-betweens & programmable hardware security token I'd have all my SATA drives encrypted! Mesdaq, Ali wrote: > Interesting read for those into disk encryption > > http://www.news.com/8301-13578_3-9876060-38.html > > Thanks, > -- > Ali Mesdaq (CISSP, GIAC-GREM) > Security Researcher II > Websense Security Labs > http://www.WebsenseSecurityLabs.com > -- > > > Protected by Websense Messaging Security -- www.websense.com > > Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
[H] Breaking Disk Encryption
Interesting read for those into disk encryption http://www.news.com/8301-13578_3-9876060-38.html Thanks, -- Ali Mesdaq (CISSP, GIAC-GREM) Security Researcher II Websense Security Labs http://www.WebsenseSecurityLabs.com -- Protected by Websense Messaging Security -- www.websense.com
