Re: [PATCH 0/6] Intel Secure Guard Extensions

[Andy Lutomirski <luto@amacapital.net>]

On Tue, Apr 26, 2016 at 12:41 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote:
>> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
>> >> Intel(R) SGX is a set of CPU instructions that can be used by
>> >> applications to set aside private regions of code and data.  The code
>> >> outside the enclave is disallowed to access the memory inside the
>> >> enclave by the CPU access control.
>> >>
>> >> The firmware uses PRMRR registers to reserve an area of physical memory
>> >> called Enclave Page Cache (EPC). There is a hardware unit in the
>> >> processor called Memory Encryption Engine. The MEE encrypts and decrypts
>> >> the EPC pages as they enter and leave the processor package.
>> >
>> > What are non-evil use cases for this?
>>
>> Storing your ssh private key encrypted such that even someone who
>> completely compromises your system can't get the actual private key
>
> Well, if someone gets root on my system, he can get my ssh private
> key.... right?
>
> So, you can use this to prevent "cold boot" attacks? (You know,
> stealing machine, liquid nitrogen, moving DIMMs to different machine
> to read them?) Ok. That's non-evil.

Preventing cold boot attacks is really just icing on the cake.  The
real point of this is to allow you to run an "enclave".  An SGX
enclave has unencrypted code but gets access to a key that only it can
access.  It could use that key to unwrap your ssh private key and sign
with it without ever revealing the unwrapped key.  No one, not even
root, can read enclave memory once the enclave is initialized and gets
access to its personalized key.  The point of the memory encryption
engine to to prevent even cold boot attacks from being used to read
enclave memory.

This could probably be used for evil, but I think the evil uses are
outweighed by the good uses.

>
> Is there reason not to enable this for whole RAM if the hw can do it?

The HW can't, at least not in the current implementation.  Also, the
metadata has considerable overhead (no clue whether there's a
performance hit, but there's certainly a memory usage hit).

>
>> out.  Using this in conjunction with an RPMB device to make it Rather
>> Difficult (tm) for third parties to decrypt your disk even if you
>> password has low entropy.  There are plenty more.
>
> I'm not sure what RPMB is, but I don't think you can make it too hard
> to decrypt my disk if my password has low entropy. ... And I don't see
> how encrypting RAM helps there.

Replay Protected Memory Block.  It's a device that allows someone to
write to it and confirm that the write happened and the old contents
is no longer available.  You could use it to implement an enclave that
checks a password for your disk but only allows you to try a certain
number of times.

There are some hints in the whitepapers that such a mechanism might be
present on existing Skylake chipsets.  I'm not really sure.

>
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



-- 
Andy Lutomirski
AMA Capital Management, LLC