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

From: Bill Cox <[email-masked]>
Date: Mon, 30 Nov 2015 18:07:19 -0800

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Nov 2015 19:06:51 -0800

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 <[email-masked]> 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.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 30 Nov 2015 20:10:58 -0700

> 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

---

From: Bill Cox <[email-masked]>
Date: Mon, 30 Nov 2015 19:17:36 -0800

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Nov 2015 19:53:58 -0800

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 <[email-masked]> wrote:

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

---

From: Bill Cox <[email-masked]>
Date: Mon, 30 Nov 2015 21:21:06 -0800

> (once close_notify has been exchanged, the traffic keys are

Yes.

> to depend on the transform.
>

Agreed.

> FWIW, in the specific case of HMAC,

I think it would not be hard to prove for HMAC/HKDF that this scheme has
similar defensive properties compared to the usual flow, with reasonable
assumptions about key generation.

However, the extra complexity in every TLS 1.3 implementation bothers me.
I worry that separating the read/write keys may not be worth it.  Did we
gain enough security to warrant the complexity?

Bill