Re:TRESOR Runs Encryption Securely Outside RAM
by barrkel on Friday September 27, 2013 @09:55AM
(#6457007)
Debug register access is not necessarily as optimized as access to (e.g.) L1 cache.
Re:TRESOR Runs Encryption Securely Outside RAM
by Tomdarkness on Friday September 27, 2013 @09:56AM
(#6457012)
There is no application, it is a kernel patch.
Re:TRESOR Runs Encryption Securely Outside RAM
by dmm on Friday September 27, 2013 @09:53AM
(#6456989)
Even if all of the AES state is kept in cache, the data to be encrypted would still have to be copied from ram or disk, right?
Re:TRESOR Runs Encryption Securely Outside RAM
by mindstab on Friday September 27, 2013 @09:56AM
(#6457011)
yeah but you can have an encrypted disk, encrypted ram, not so much.
Re:TRESOR Runs Encryption Securely Outside RAM
by sweis on Friday September 27, 2013 @04:43PM
(#6459425)
Hi. PrivateCore has implemented encrypted RAM as part of a secure hypervisor. Our product is currently in a private beta, but you can check out our website at: http://www.privatecore.com.
We gave a talk on some of the vulnerabilities and mitigations at CanSecWest this year: http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.p...
Re:TRESOR Runs Encryption Securely Outside RAM
by jacquesm on Friday September 27, 2013 @10:03AM
(#6457047)
OpenBSD will get you halfway there, it at least encrypts (if you switch it on) the virtual memory.
Re:TRESOR Runs Encryption Securely Outside RAM
by dobbsbob on Friday September 27, 2013 @01:05PM
(#6458020)
OpenBSD does this by default. It also now directly boots cryptodisks eliminating the need to create a /boot partition and carry it around if you're concerned about evil maid attacks, though I would imagine a camera or keyboard hardware keyloggers would defeat that pretty easily
Re:TRESOR Runs Encryption Securely Outside RAM
by tedunangst on Friday September 27, 2013 @02:46PM
(#6458750)
The boot loader is still on the disk, unencrypted.
Re:TRESOR Runs Encryption Securely Outside RAM
by Nanzikambe on Saturday September 28, 2013 @01:49AM
(#6461079)
That's what removable media is for
Re:TRESOR Runs Encryption Securely Outside RAM
by dobbsbob on Friday September 27, 2013 @03:27PM
(#6458968)
derp, /root correction
Re:TRESOR Runs Encryption Securely Outside RAM
by m_eiman on Friday September 27, 2013 @11:13AM
(#6457380)
As does OSX. Probably Windows too? There has to be a registry setting to tweak, somewhere.
Re:TRESOR Runs Encryption Securely Outside RAM
by mikeash on Friday September 27, 2013 @11:12AM
(#6457374)
If you stream the data in from disk (e.g. read 1kB, encrypt 1kB, read 1kB, encrypt 1kB) then a cold boot attack only recovers one small chunk of data. Whereas if your keys are in RAM then a cold boot attack can recover the keys which can then be used to decrypt your entire hard drive.
Re:TRESOR Runs Encryption Securely Outside RAM
by DennisP on Friday September 27, 2013 @09:51AM
(#6456981)
Hm. Maybe Linux should fold this into the kernel.
Re:TRESOR Runs Encryption Securely Outside RAM
by barrkel on Friday September 27, 2013 @09:56AM
(#6457010)
Debug registers are only accessible in Ring 0. I haven't looked at the implementation described, but I'd be surprised if it isn't a kernel module or something equivalent.
Re:TRESOR Runs Encryption Securely Outside RAM
by joe_bleau on Friday September 27, 2013 @11:24AM
(#6457453)
Are they available to a JTAG probe? I've not looked at a modern motherboard in ages, but I wouldn't be too surprised to find unpopulated JTAG pads near the CPU.
Re:TRESOR Runs Encryption Securely Outside RAM
by mzs on Friday September 27, 2013 @01:10PM
(#6458074)
Only boundary scan on Intel.
Re:TRESOR Runs Encryption Securely Outside RAM
by zerohp on Friday September 27, 2013 @11:32AM
(#6457489)
I don't think x86 uses JTAG.
Re:TRESOR Runs Encryption Securely Outside RAM
by joe_bleau on Friday September 27, 2013 @12:15PM
(#6457719)
Why not? Even if it doesn't use JTAG for debug, it almost certainly would need it for boundary scan. I just checked volume 1 of the Intel i7 processor family datasheet, and it does show a JTAG port.
Also what happens if the scheduler moves the application out of running state?