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

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 <waywardgeek@google.com> 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
>
>