5
$\begingroup$

I am evaluating the use of TLS 1.2 for a low powered embedded environment.

After looking at RFC 7925 (TLS for IoT) I was wondering if the combination of

  • the TLS_PSK_WITH_AES_128_CCM_8 cipher suite (RFC 6655)
  • and the TLS False Start extension (RFC 7918)

is

  1. possible / compatible and
  2. has additional security implications beyond those already imposed by the use of a TLS_PSK_* cipher suite.

Section 21 of RFC 7925 mentions several conditions for using TLS False Start. However, TLS_PSK_* cipher suites are not mentioned specifically.

$\endgroup$
7
$\begingroup$

There is no real problem with applying "false start" to PSK cipher suites. The "false start" thing is about beginning to use the negotiated key to encrypt data before having confirmation (with the Finished message) that the peer really agreed on the same key. In that sense, the peer authentication is still implicit at that point. This is not a worry for "normal" cipher suites. (Note: it might be a problem with SRP, though.)

If you want to target low-power embedded systems, you might want to use the ChaCha20+Poly1305 cipher suites (RFC 7905) which are a lot lighter than AES (especially AES/CCM, which invokes the AES encryption routine twice for each block). If you still stick to AES, and AES/GCM can also be lighter.

Also, while PSK is light (no asymmetric crypto), it has its own issues, namely the need for a shared secret, which is not the easiest thing to deploy; you might want to consider using a non-PSK system with a certificate. If the constrained system is the client, then RSA key exchange involves only public key encryption on the client, and that's lightweight, because RSA public key operations use the public exponent, which is short. Alternatively, some elliptic curves can be light enough for an embedded CPU.

Shameless plug: consider BearSSL. It's not yet ready for production use (in that I have still not made extensive automated verifications against a fuzzing SSL/TLS implementation) but can give a taste of what is doable. On a 48 MHz Cortex-M0+, my C code can do an EC point multiplication in about half a second (half that value if using Curve25519).

$\endgroup$
  • $\begingroup$ Thank you for your comprehensive answer. AES is about the only hardware (HSM) accelerated operation which is why I was considering CCM. But the other ones (including asymmetric crypto) will be tested as well. I especially like ChaCha20-Poly1305. However, I do not expect them to perform well enough. BearSSL looks like a promising project. I will have a look at the source when I have the time. $\endgroup$ – inorik Jan 23 '17 at 21:39

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.