
TRESOR Runs Encryption Securely Outside RAM - jgrahamc
http://www1.informatik.uni-erlangen.de/tresor
======
jws
This keeps the AES keys in some x86 debug registers so they never appear in
RAM and can't be accessed after a reboot.

~~~
codex
Why not keep the keys in a TPM and pull them into "real" registers whenever
the kernel context switches into a specially flagged AES decode thread, and
zero them when context switching away?

~~~
EthanHeilman
Here is an NSA slide where the NSA talks about exploiting Trusted Computing
Platforms for intelligence[1].

The German government believes that the TPM is backdoored and a danger to
security[2].

1:
[http://www.nytimes.com/interactive/2013/09/05/us/documents-r...](http://www.nytimes.com/interactive/2013/09/05/us/documents-
reveal-nsa-campaign-against-encryption.html?_r=0)

2: [http://www.techweekeurope.co.uk/news/microsoft-seeks-calm-
on...](http://www.techweekeurope.co.uk/news/microsoft-seeks-calm-on-german-
security-panic-over-windows-8-125702)

~~~
codex
If you can't trust the TPM, can you trust Intel's debug registers to be
secure?

Long term I suspect that this kind of thing will use Intel's Software Guard
Extensions (SGX), which creates a trusted enclave of code and data that not
even the kernel nor the hypervisor can access.

~~~
andyjohnson0
A couple of interesting articles on SGX:

[http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-
on...](http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on-intels-
upcoming-software.html)

[http://theinvisiblethings.blogspot.co.uk/2013/09/thoughts-
on...](http://theinvisiblethings.blogspot.co.uk/2013/09/thoughts-on-intels-
upcoming-software.html)

~~~
codex
The second article is quite alarming. Don't run any code in an enclave which
you didn't compile yourself! One may not even be able to use a virtual machine
to peer inside an enclave by emulating SGX: the software could demand a valid
public key stored uniquely in every Intel chip and signed by Intel's private
key, which a hypervisor would not have.

------
sweis
TRESOR still leaves all the code and data exposed in memory. You can modify
the code that's being executed in order to divulge the contents of the debug
registers.

We're working on solving the malicious device and cold boot problem at
PrivateCore. To do so, we're encrypting all of main memory and keeping
plaintext state in the L3 cache.

Here's a resource page with links to the TRESOR paper and other resources:
[http://privatecore.com/resources-overview/physical-memory-
at...](http://privatecore.com/resources-overview/physical-memory-attacks/)

~~~
ris
Where's the source?

Or are you expecting us to trust your proprietary nonfree software without
ever seeing it?

Good luck with that.

------
dobbsbob
Didn't DDR3 ram basically make cold boot attacks obsolete? They don't hold any
voltage when you power down long enough to even freeze the chips

~~~
MichaelGG
Interesting, that sounds correct:

[http://www1.cs.fau.de/filepool/projects/coldboot/fares_coldb...](http://www1.cs.fau.de/filepool/projects/coldboot/fares_coldboot.pdf)

Even with cooling they weren't able to recover. However, a warm reboot, would
still work. Speculating, but some laptops might have a way to force a reboot
like some machines have a reset button. That'd at least restart the system,
although proper BIOS config should prevent that from being useful.

~~~
sigstoat
hm, it looks to me like they just cover the sorts of temperatures you see in
refrigerators.

any idea if work has been done on cryogenic temperatures?

------
jdjb
Shouldn't this also be a really fast implementation since there isn't even the
delay required to move items into/out of ram?

Also what happens if the scheduler moves the application out of running state?

~~~
dmm
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?

~~~
mindstab
yeah but you can have an encrypted disk, encrypted ram, not so much.

~~~
jacquesm
OpenBSD will get you halfway there, it at least encrypts (if you switch it on)
the virtual memory.

~~~
dobbsbob
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

~~~
tedunangst
The boot loader is still on the disk, unencrypted.

~~~
Nanzikambe
That's what removable media is for

------
shredfvz
In the AUR: [https://aur.archlinux.org/packages/linux-lts-
tresor/](https://aur.archlinux.org/packages/linux-lts-tresor/)

------
rthomas6
I'm not very knowledgeable about x86, but why do they have to use the debug
registers if they're slower? I know in GCC you can mark registers as "do not
touch" when you write assembly in C. Why not use more general purpose
registers?

~~~
mikeash
Because the idea is to run it in kernel mode with arbitrary other software
running on the computer. Asking other software to pretty please don't touch
these specific registers isn't going to work, because there's no way to
enforce that. The debug registers are perfect because they can only be
accessed from kernel mode, not userland.

------
jnt
And to avoid keyloggers being installed when the machine is powered of, see
STARK[1] from the same uni.

[1] [http://www1.informatik.uni-erlangen.de/stark](http://www1.informatik.uni-
erlangen.de/stark)

------
ape4
Now thats paranoid ;)

~~~
keyme
Not really... I've seen a demonstration where a Truecrypt (or something
similar) encrypted laptop is stolen. The machine is locked, but still powered
on (very reasonable. You locked your machine and left your desk). This
basically means that the AES key is in RAM.

The attacker/thief cools down the RAM with liquid nitrogen (to slow the
discharge), inserts a bootable CD with a special tool to dump physical RAM on
bootup, and quickly cycles the laptop battery (causing a cold boot).

Since the RAM is not zeroed on bootup, the "old" bits stay pretty much as they
were (thanks to the cooling).

IIRC this allowed an attacker recovery of the key with a very high probability
of success.

~~~
BWStearns
While everything you say is true, it would seem paranoid in many cases. I
don't know how many neighborhood electronics fencers have liquid nitrogen
laying around or the computer savvy to pull this kind of stuff.

If someone is after me who is using this methodology then I have seriously
pissed off the wrong people. While you could argue that it's only paranoia if
the object of preparation is not possible, I would say that you're at least
one leg over the fence into paranoia-land if you're prepping against a cold-
boot and don't have any nation state or corporate espionage level enemies.

~~~
abecedarius
LN2 is cheap. If undergrads can make LN2 ice cream, they can use it for
cracking too.

~~~
aroch
One of the nice things about OSX and Filevault2 is that you can force the key
to be destroyed on suspend:

    
    
         destroyfvkeyonstandby - Destroy File Vault Key when going
         to standby mode. By default File vault keys are retained
         even when system goes to standby. If the keys are
         destroyed, user will be prompted to enter the password 
        while coming out of standby mode.(value: 1 - Destroy, 0 -
         Retain)

~~~
anologwintermut
One of the other nice things about OSX is the feds may already have your
key[0], so if you manage to get your computer back from them after that
confiscate it, it won't have cracks in it from the extreme cold.

[0][http://www.nosuchcon.org/talks/D1_02_Alex_Ninjas_and_Harry_P...](http://www.nosuchcon.org/talks/D1_02_Alex_Ninjas_and_Harry_Potter.pdf)

~~~
aroch
SMCs are present in nearly all Intel systems...They could very well store your
truecrypt keys too

~~~
anologwintermut
SMCs are not the problem. The problem is code in OSX could put your key there
in a way that someone could dump it.

Of course, since FileVault is not open source, we have no way of knowing if it
does this. Is this paranoid? Perhaps, but if you are worried about cold boot
attacks you should be worried about this as well.

You might also be worried about some strange design decisions in FileVault
such as the fact that it uses public key cryptography[0] for what ought to
just be symmetric disk encryption. While not a red flag,it is a bit strange.

[0][http://deimos3.apple.com/WebObjects/Core.woa/FeedEnclosure/u...](http://deimos3.apple.com/WebObjects/Core.woa/FeedEnclosure/utah.edu.1380568002.01381129957.14368733217/enclosure.pdf)

------
kephra
/me sings, "Another one bites the Dust"

Error

The website encountered an unexpected error. Please try again later.

Error message

PDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111) in lock_may_be_available()
(line 167 of /var/www/i1/includes/lock.inc).

It looks as Drupal is not suited to stand a HN-DDoS, of 70 points (7000
visitors estimate) in 3 hours.

