3
$\begingroup$

I have an embedded system with AES-128 implemented in hardware. There is very little flash/RAM and the (8-bit) CPU runs relatively slowly. Public key crypto isn't a viable option. This system is connected to the Internet and can have one or more unique AES keys programmed at manufacture.

Are there any standard protocols for securing a TCP socket using pre-shared symmetric keys?

Is it enough to just use a pre-shared key for AES-CBC over TCP? Is there a benefit to exchanging a unique session key (eg. AKEP2/Needham-Schroeder)

Thanks.

|improve this question
$\endgroup$
  • $\begingroup$ You'll need to be careful about using IVs and MACs correctly. Plain AES-CBC is vulnerable to active attacks. $\endgroup$ – CodesInChaos Jun 19 '12 at 16:05
  • $\begingroup$ Do your embedded devices have access to a good entropy source? Can you generate reliable nonces? $\endgroup$ – CodesInChaos Jun 19 '12 at 16:07
  • $\begingroup$ Yes, I have a hardware radio - so I have a good source of random noise $\endgroup$ – Toby Jaffey Jun 19 '12 at 16:07
  • $\begingroup$ Can you give numbers for very little flash/RAM? $\endgroup$ – CodesInChaos Jun 19 '12 at 16:12
  • $\begingroup$ 4KB RAM, 32KB flash (half that to allow for the OS and network stack) $\endgroup$ – Toby Jaffey Jun 19 '12 at 16:14
5
$\begingroup$

I know of two standard protocols that support AES encryption without public key cryptography getting involved:

  • With TLS, we have RFC4279, and in particular, the ciphersuite TLS_PSK_WITH_AES_128_CBC_SHA. Now, the two sides don't literally have preconfigured AES keys; instead, they have preshared premaster secrets; the AES (and HMAC-SHA1) keys are derived from the premaster secret in the standard way. No public key cryptography is involved.

  • With IPSec, we have RFC4301, and in particular, "manual keys" (which are exactly that, preconfigured symmetric keys)

If both work for you, I'd advise you to use the TLS option; it is probably more work (as you'll need to deal with the session setup messages); however, support for TLS is more command, and it does mean that the keys actually change over time (while with IPSec manual keys, the keys are fixed; if they are ever leaked, you are dead).

You could, of course, design your own protocol, however I'd strongly advise you to stick with protocols designed by people who knew what they are doing.

|improve this answer
$\endgroup$
  • $\begingroup$ "keys actually change over time" How does that work? I don't remember anything of that kind being in non ephermal suites. $\endgroup$ – CodesInChaos Jun 19 '12 at 16:16
  • 1
    $\begingroup$ @CodeInChaos: Well, whenever you reboot and negotiate a fresh TLS connection, you'll exchange fresh nonces; the keys are derived from the premaster secret (which is constant in this case) and the nonces (which aren't) $\endgroup$ – poncho Jun 19 '12 at 16:19
  • 1
    $\begingroup$ @Toby Jaffey: try to make sure each device has a unique key (else penetrating one device breaks them all); if all the devices talk to a central point, you can use "diversified keys" (that's the standard name for Smart Cards), where each key is obtained from a master key and the serial number of the device, using a procedure which, in the case of AES-128, can be as simple as encryption of the SN using the Master Key; the central server keeps the Master Key, and can re-generate the diversified device keys. $\endgroup$ – fgrieu Jun 19 '12 at 18:15
2
$\begingroup$

I would say the real standard here for TCP is TLS with a PSK ciphersuite. Given you have AES-128 in hardware and PK is not an option, you probably would want the TLS_PSK_WITH_AES_128_CBC_SHA ciphersuite (there are additional options which can use certificates for authentication or DH for forward security with AES but seems like these are non-starters).

TLS-PSK also seems very convenient because any 'big' boxes your system talks to can use off the shelf software to communicate.

RFC 4279 is the standard reference. OpenSSL, GnuTLS, CyaSSL and several other SSL/TLS implementations support PSK (though in any case you'll likely have to hack in support for your AES hardware).

|improve this answer
$\endgroup$
  • $\begingroup$ Most SSL libraries are rather big. He'll need a specialized embedded SSL library. $\endgroup$ – CodesInChaos Jun 19 '12 at 16:17
  • $\begingroup$ Probably so, which is why I mentioned CyaSSL which is designed for embedded. There is also MatrixSSL which also supports PSK. $\endgroup$ – Jack Lloyd Jun 19 '12 at 16:19
  • $\begingroup$ FWIW, I've had success with axTLS doing RSA+MD5+AES (BSD licensed, C, very little use of dynamic memory) on ARM Cortex-M3 targets with 64KB+ RAM. $\endgroup$ – Toby Jaffey Jun 19 '12 at 19:27

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.