As said at the end of the Q&A, it needs a hardwaredevice for full security (whatever "full" means). But, cant the CPU just be this piece of hardware? I haven't a clue about the complexity of adding new features to a CPU, but it definitly would be a nice feature if intel&Co would add a special cache-mode in which b) only code allready in cache can be executed and b) no flush to ram is allowed if not done from the code allready in cache and c) no reading of the contents of the cache is allowed via JTAG or whatsoever and d) on CPU-reboot, all cache-areas in this mode are wiped.

The idea is, if you could put the password-asking software (from the lock-screen) fully in cache and the CPU only accepts code allready in cache, you could bring the cpu in some kind of locked mode, guarding the keys and all.

But of course, no other processes would have the ability to run in the background while this mode is switched on...

Marcus,

yes, a) through d) would be nice to have. However, I have a different oppinion regarding to your last statement: other tasks/code segments could execute...as long they won't impact the state of the cache (the CPU would have to enforce this).

Given the complexity of such an endeavor in X86 with respect to backwards compatibility, I presume that (if at all) it'll be a new "feature" in X86 CPUs that provide a secure location for key material.

Jürgen

I have to admit, this is very naive, but cant you just ask Intel & Co to implement such a feature? They could advertise this as their new big security feature :)

Regarding other tasks: Yes, one could still run them, but what happens if the task wants to read from disk? I/O-Block until the user does a re-login? What does your software do in this case?

Marcus,

I haven't thought about contacting Intel/AMD directly, but I guess I'll give it a shot. Regarding other tasks: this is a matter of implementation - on Linux/dm-crypt, all encryption is handled by kcryptd - a kernel thread spawned by the dm-crypt kernel module. The data used by kcryptd would of course need to be locked into the cache as you described in your initial comment. Thus, disk I/O would still be possible under said conditions.

Jürgen

But then again, you have a security tradeoff: If you allow other tasks to ask kcryptd (running in cache) to give them some decrypted data, then an attacker with physical access could surely swap this task in ram against an task which just asks for the whole disk. kcryptd would need some way to distinguish between legitimate tasks and an task injected from an physical attacker. I don't think that this can be implemented in a foolproof way under the precondition, that you cant trust any I/O or the ram. Maybe one could write an heuristic which blocks may be legitimated accessed and which may be not. But that doesnt sound very secure. And even than, kcryptd cant verify, that it's actually operating on the data some task has (legitimatedly) asked for. The attacker could just give the contents of an other disk block to kcryptd.

True. From my point of view the only difference is that it's been proven that cold-boot-attacks can be used to extract data/keys from RAM while (I am not aware of any) no research has shown that one can inject data/tasks into RAM using cold-boot style attacks. However, there's still the DMA/firewire attack - but that can be secure separately.

Well, but one also has to make sure that the attacker cant temper with the physical databus. And such attacks are actually happening: The first PS3-Hack for instance or the hack of the Nindendo Wii as presented on 25C3 both manipulated the very signal lanes.

An attacker capable and willing to use stuff like Cold Boot Attacks may also be able to hack the hardware itself. Especially since the attacker can take the running computer with him thanks to some special power device which hold the power while you unplug the PC and plug it in a battery.

Agreed.

However, that surpasses what frozencache can ever accomplish. I like you thinking big, though.

Jürgen

Hi Jürgen,


are you so sure, that frozencache cant accomplish that? Well, it might be too complicated for a simple lock-screen (because there are just to much background processes) but what about a suspend-to-ram like situation? And even in a simple lock-screen-Situation: It may be possible to prefetch needed files befor going into locked mode. This would of course be the job of the running task, but I think that it may be possible...

Marcus