Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

[Ilari Liusvaara]

On Mon, Nov 30, 2015 at 06:07:19PM -0800, Bill Cox wrote:
> I don't think even I agree with this idea, but I'll put it out there anyway.
> 
> We're seeing some new secure computing modes in ARM and Intel processors.
> Arm has TEE, and Intel has SGX.  Both modes basically run at the same speed
> as the CPU... in theory.
> 
> There are potential benefits to securing the read/write session keys in
> these modes.  For example, if malware is doing evil things over your
> connections, when you remove the malware or close your laptop, the
> encryption keys are out of reach, and the connections go dead.  Otherwise,
> malware might export the keys where they could be used to resume a session,
> for example, enabling an attacker to continue doing evil.  This is possible
> today over TLS 1.2, even when using Client Certificates.
> 
> However, there are overhead costs for moving data in/out of these execution
> zones, and overhead when switching back and forth.  Execution speed is a
> little slower in these modes for various reasons.  For maximum speed, I
> might want a separate HMAC/HKDF key besides the read/write keys.  That way,
> I keep just the HMAC/HKDF key in a secure execution zone, and only have to
> do one small operation with it per AEAD call per TLS record.
> 
> This is just a dumb efficiency hack.  I hate leaving either speed or
> security on the table if I can have both :)  However, complexity harms
> security, so even I don't really think this is a good idea.  Is there
> anyone who feels even more strongly about speed than me?

If you want absolute maximum speed without handling encryption in the
secure module, you would essentially need the secure module to MAC the
data second time (one can repurpose any AEAD ciphers as a MAC).

(Hmm... why does this remind me of "key escrow"?... :-) )

The reason for this is that even the fastest hash-based MAC that is even
remotely secure (Blake2b native MAC) loses in speed to both main TLS 1.3
AEADs (doing full authenticated encryption).

You can't shorten things either, because the MACs in main TLS 1.3
AEADs are not designed to offer any security against attacker knowing the
keys. And as said, schemes that allow shortening are relatively slow.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

[Tony Arcieri]

On Mon, Nov 30, 2015 at 7:07 PM, Bill Cox  wrote:

> However, there are overhead costs for moving data in/out of these
> execution zones, and overhead when switching back and forth.  Execution
> speed is a little slower in these modes for various reasons.  For maximum
> speed, I might want a separate HMAC/HKDF key besides the read/write keys.
> That way, I keep just the HMAC/HKDF key in a secure execution zone, and
> only have to do one small operation with it per AEAD call per TLS record.
>

Have you measured the overhead of performing just the private key
operations of TLS using a key stored in an SGX enclave versus the same
operations outside an SGX enclave? I'd be curious what the actual
performance impact is.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

[Eric Rescorla]

Hi Bill,

I am sorry, but I do not understand what you are proposing. Do you think
you could try restating the computation you have in mind, perhaps by
providing an equation that explains the construct?

Thanks,
-Ekr


On Mon, Nov 30, 2015 at 6:07 PM, Bill Cox  wrote:

> I don't think even I agree with this idea, but I'll put it out there
> anyway.
>
> We're seeing some new secure computing modes in ARM and Intel processors.
> Arm has TEE, and Intel has SGX.  Both modes basically run at the same speed
> as the CPU... in theory.
>
> There are potential benefits to securing the read/write session keys in
> these modes.  For example, if malware is doing evil things over your
> connections, when you remove the malware or close your laptop, the
> encryption keys are out of reach, and the connections go dead.  Otherwise,
> malware might export the keys where they could be used to resume a session,
> for example, enabling an attacker to continue doing evil.  This is possible
> today over TLS 1.2, even when using Client Certificates.
>
> However, there are overhead costs for moving data in/out of these
> execution zones, and overhead when switching back and forth.  Execution
> speed is a little slower in these modes for various reasons.  For maximum
> speed, I might want a separate HMAC/HKDF key besides the read/write keys.
> That way, I keep just the HMAC/HKDF key in a secure execution zone, and
> only have to do one small operation with it per AEAD call per TLS record.
>
> This is just a dumb efficiency hack.  I hate leaving either speed or
> security on the table if I can have both :)  However, complexity harms
> security, so even I don't really think this is a good idea.  Is there
> anyone who feels even more strongly about speed than me?
>
> Bill
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

[Eric Rescorla]

Ah, I see what you mean. Thanks for explaining.

So, if I understand correctly, your threat model is that you want to
prevent an attacker who obtains the traffic keys from injecting
new traffic during the plausible lifetime of the connection
(once close_notify has been exchanged, the traffic keys are
useless).

Whether this is possible or not with a given AEAD transform seems
to depend on the transform. FWIW, in the specific case of HMAC,
because the key \xor pad fills an entire digest block, you might imagine
storing the state of the outer compression function after the first block
in the hardware module. I am not aware of any analysis that shows
that this is safe and it very likely is not as strong as having the
entire HMAC key in the module, but it might (or might not) be better
than nothing.

-Ekr


On Mon, Nov 30, 2015 at 7:17 PM, Bill Cox  wrote:

> On Mon, Nov 30, 2015 at 7:06 PM, Eric Rescorla  wrote:
>
>> Hi Bill,
>>
>> I am sorry, but I do not understand what you are proposing. Do you think
>> you could try restating the computation you have in mind, perhaps by
>> providing an equation that explains the construct?
>>
>
> Sure.  I'll stick to HMAC, which is more widely understood.  We do
> encrypt-them-mac using the write key.  The inner SHA-256 consumes the
> entire ciphertext, and at the end, the outer SHA-256 is applied.
>
> This hack would use a different key for the outer SHA-256.  This way, it
> is only used to hash a single block.
>
> Quite a hack, right :)
>
> Bill
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls