|
Does Verizon's Voyager stack up to the iPhone? |
|
|
5 IT skills that won't boost your salary
[1,407]
Women 4 times more likely than men to cough up personal info
[589]
Japan's 10 funniest tech-related commercials [Videos]
[407]
Throwing away a promo CD is "unauthorized distribution"?
[1,265]
Adults too quick to dismiss educational video games
[682]
Attack of the iPhone clones [Slideshow]
[578]
10 things IT needs to know about AJAX
[1,258]
This Year's 25 Geekiest 25th Anniversaries [Slideshow]
[409]
|
|
Not as trivial as it sounds
At first look, my reaction was the same as Mark's - that this is both an obvious and impractical weakness.
However, consider the technical implication here, that the key is stored as plaintext somewhere in RAM for significantly long periods of time. In systems I designed, we were always careful to keep the key ciphered in RAM, then basically disabled interrupts or controlled caching, pulled the key into processor cache, used it, then re-encrypted it before it could be flushed to external RAM. We cascaded and covered keys in various ways as well to increase the difficulty of someone getting the keys to the keys. The window of opportunity to have it laying around afterwards, therefore, is very small.
That being said, I feel the disk encryption systems mentioned are working within design specs, and doing what they are designed to do; that being to keep your data reasonably safe in the event of a HW theft.
So let's agree that as an actual attack, the tool mentioned is impractical, and an academic exercise.
Buuut - what about systems that help you wake up faster from sleep by keeping RAM active, or saving RAM to disk to restore operating state? Would not the key be less ephemeral in these cases?? Would not the tool have very real, practical uses there? Something to think about.