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.

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

2 Answers 2

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.

$\endgroup$
3
  • $\begingroup$ "keys actually change over time" How does that work? I don't remember anything of that kind being in non ephermal suites. $\endgroup$ Jun 19, 2012 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, 2012 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, 2012 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).

$\endgroup$
3
  • $\begingroup$ Most SSL libraries are rather big. He'll need a specialized embedded SSL library. $\endgroup$ Jun 19, 2012 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, 2012 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$ Jun 19, 2012 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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