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
