I have an embedded system with AES-128 implemented in hardware. There is very li

Question

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.

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.