3
$\begingroup$

I'm working on an embedded device that is connected to a computer over an untrusted channel. According to my threat model I need authentication and encryption on the wire with perfect forward secrecy. Both endpoints have a pre-shared key and/or each other's authentic public keys, as well as secure random number generators (although not requiring a secure RNG on the device is a plus). All messages on the wire are fixed-length (16 bytes, i.e. 128 bits).

I'm looking for an existing cryptographic protocol satisfying these properties that would be reasonably simple to implement.

The "toy" protocol I've come up so far is performing an Elliptic-curve Diffie-Hellman key exchange (wrapped in AES-CCM with pre-shared key for authentication), then running a key derivation function on ECDH shared secret and using the result as session key for AES-CCM that encrypts and authenticates data. AES-CCM is used to authenticate ECDH because of limited amount of space code on the device, so I have to use as little primitives as possible.

But I don't want to use a protocol that I've just made up (for obvious reasons) and protocols like TLS, OTR and SSH are way too complex for use in embedded devices. Is there a simpler protocol that provides authentication and encryption with forward secrecy that I could use?

Update: to clarify, establishing a connection doesn't have to be fast, so I can afford a lot of computation. The only requirements for asymmetric crypto is keeping the keys short, hence elliptic-curve cryptography instead of discrete logarithms.

$\endgroup$
3
  • 1
    $\begingroup$ For better help I think we need to know how much public-key crypto "is allowed". Can you afford one signature, one (or more) verifications and one modular exponentiation per connection establishment? As for the primitives you may want to consider switching to EAX instead of CCM. And what is the part about TLS you don't like? The key-exchange? The record layer? $\endgroup$
    – SEJPM
    Aug 25, 2015 at 15:59
  • $\begingroup$ I've clarified the requirements for asymmetric crypto in the question. AS for TLS, implementing the entirety of TLS is an overkill, so I'd have to gut it and that's going to be yet-another-protocol-I-just-made-up. There's a lot of superfluous negotiation in connection establishment. Authentication is separate from encryption and uses 32-byte HMACs - (for 16-byte messages), swapping that for an AE mode for a cipher would save me a lot of trouble. TLS was designed for a whole different class of systems. If I'll have to adapt a protocol, perhaps there's a starting point closer to my use case? $\endgroup$
    – Shnatsel
    Aug 25, 2015 at 16:53
  • $\begingroup$ I think the best you can do is to use TLS' record layer protocol and combine this with a secure key-exchange. Refer to this answer for samples $\endgroup$
    – SEJPM
    Aug 25, 2015 at 19:06

1 Answer 1

2
$\begingroup$

I've finally found a solution - some variants of key ratcheting, e.g. the one used in SCIMP, provide perfect forward secrecy assuming an initial shared secret is established without any asymmetric crypto, and they don't even require a secure random number generator on any of the endpoints!

In this case all we need for an authenticated and encrypted protocol with perfect forward secrecy a symmetric cypher, an authenticated encryption mode for said cypher (e.g. EAX) and a hash. We can even ditch the RNG on the embedded device.

This is not a complete protocol, but gets us most of the way to one, and it's dramatically simpler both in the implementation and the number of required primitives than TLS.

The hard part is proper handling of message losses on the wire without opening up to downgrade attacks, but it's easier than correct custom implementations of asymmetric crypto.

Ironically, nobody I asked could tell me about using such key ratcheting for perfect forward secrecy. Our team has come up with the scheme on its own and only after that I've found it in literature.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.