Hello,
I've unfortunately missed your talk because I missed the announcement.

I'd like to talk with you about your talk and another approch of securing FDE systems I am thinking about.

Please call 9164 or visit me at top level near Gentoo/Debian, next to the stairs at the table left of the red floor.

If you look at the currently available solutions there is the current best practice to "lock" cryptovolumes before exposing them to risky situations and the industry "solution" proposed by the Trusted Computing Group to have hardware that does some kind of initialisation of the memory modules when power is switched on. The rough principle of Juergens proposal seems to fit somewhere in between, showing some similarity of concept to both forementioned older solutions. Juergens concept still requires something you could describe as a locking procedure to switch to protected mode - as with the current best practice procedure. The only difference of the new locking procedure being, that it is more easily reverseable by legitimate users which arguably gives you some improvement in terms of convenience. That's all, it seems; no magic bullet ("the solution") in that. Still, I very much appreciate to have some semi-protection while being in suspend-to-RAM mode (- meaning it might be considerable to turn str back on again!.). So - thanks for your work so far, keep it up!

Daniel,

sorry, I didn't get a chance to come by. If you write me an e-mail (jpabel@akkaya.de) then I'll get back to you - I am eager to hear about your idea.

Juergen

mibmib,

problem at hand is that best-practices aren't all that practical. If everybody "locked" their FDE component (for example by fully suspending the system) in risky situations then Cold-Boot-Attacks would have never gotten the attention they did. They did get the attention because the real life diverts from best-practices.

With respect to your remarks for the lack of a locking procedure I would like to point out that frozencache is supposed to get activated (automatically) whenever the screen gets locked. Conversely, if the screenlock is successfully unlocked then frozencache is supposed to get deactivated. Thus, the screenlock implements the locking procedure - or did I misunderstand your comment?

Thank you for your feedback!

Juergen

All of those "solutions" keep missing the most important point: Disk encryption software decrypts data to RAM and the data stays there until you power off the computer.

Why? Because text editors, image viewers, spread sheet editors, video players and any other common software does NOT wipe the data. It deallocates the memory and the data stays there!

So even if you protect the key, the sensitive data is still there in RAM unencrypted!

The only solution that works is: Prevent the attacker from gaining physical or admin access to a computer while encrypted volumes are opened.

And I even did not mention states when the programs are actually working with the data! The sensitive data is unencrypted in RAM.

If you want to prevent the attacker from getting your sensitive data, stay away from these snake-oil solutions, that only induce a false sense of security.

Dear Anonymous Reader,

actually, IMHO the most important point is that physical access to a "running" computer with FDE should not yield access to the entire encrypted disk. That some unencrypted data will be exposed by means of cold-boot attack is secondary (albeit not negliable).

In theory, there's a simple solution: suspend (not stand-by) or power-down your system any time it's potentially exposed to physical access. However, we all know that's a very impractical best-practise advice. It's this specific "gap" that FrozenCache tries to address. Nothing more.

Juergen