+ cypherpunks

http://en.wikipedia.org/wiki/TRESOR - Keys are stored in debug or SSE registers and never leave the CPU. Use of AES-NI gives you solid performance. [side-channel DPA/timing etc vulnerable, though :(]

That + trusted boot + dm-verity & FDE. Delicious. [Add Xen bare-metal & qubes-esque setup.]

I've never seen TRESOR work, that might be a fun side-project for someone.

-Travis

On Tue, Feb 10, 2015 at 11:00 PM, grarpamp <grarpamp@gmail.com> wrote:
> But yeah, monitoring the environment is a solid idea, as is CPU <-> RAM
> encrypted pipeline.

Someone was talking about this before, maybe in context of VM's.
Yet it really only works if after cold boot the key held in core for those
address segments luckily happens to be among the nonrecoverable
bits of ram. Who has researched those odds? Though defense in depth
is always good.

Another way is to introduce a simple XOR hardware mask between
the cpu and ram, keyed via some external token, wrist fob, etc.
Unlikely computer makers respond to little demand for that. And
like AMT you certainly don't want it in your "Intel" chipset.

Today you might be able to patch a kernel to switch over post bootloader
and consider its address space to now be that provided by an external
block device (sata/usb), which could then be such an encrypted mini
pluggable in the open hardware spirit of the usb RNG devices. It is the
ram, so you don't need a long term key there, random generated per boot
use is fine. Then you have moved keying issues to a smaller, manageable,
quickly blackenable device, like crushing its silicon with a thumbpress.

>> 1) program to notice his magic bracelet is not near
>> 2) program to notice that vid cam is not a head but a chaotic scene

Oh noes, my user's fitbit indicates ballistic heartrate / excess
g forces... blacken keys!... :-)

Support more drunken ideas, btc: 1k2VQNW47wJDmsLCd2xkSjY28twKRah63



--



--
Twitter | LinkedIn | GitHub | TravisBiehn.com | Google Plus