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

[Ilari Liusvaara <[e-mail]>]

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