11

I'm looking at possible options to build a secure channel between multiple embedded devices with limited cryptography capabilities and an HTTP server (It could be some sort of web service).

1. Context

The devices only supports HTTP, some Symmetric-Key Algorithm and some Hashes Function via a development framework on the devices. Unfortunately SSL/TLS is not supported and thus is not an option here.

At boot time the devices contact the HTTP server in order to retrieve their specific configuration. I do have complete control over the devices before they are sent in the wild.

Some of the threats identified are:

  • Download of a malicious configuration file.
  • Download of the wrong configuration file (from another device).
  • Multiple Download of the same configuration file.
  • Eavesdropping of the configuration file by an unauthorized third party.
  • Fraudulent access to the HTTP server (not necessarily relevant here).

The process of retrieving the configuration file should ideally happen only one time. Once the configuration file is downloaded access to the HTTP server will be discarded for that particular device.

2. Proposal

Since I can load a temporary shared secret on the devices before dropping them in the wild, I was thinking of using keyed-HMAC (Hash Message Authentication Code) to authenticate the device without having to send the secret key on the wire. Something similar to the AWS API authentication design and use the unique serial number of the device as Key ID.

Once authenticated the device is granted access to a resource, in this case the configuration file. In order to mitigate some of the threats identified the configuration file must be encrypted and signed(?) during transfer.

For this purpose I was thinking of using an authenticated encryption mode.

I can only use AES256 in CBC mode and HMAC-SHA256. Other "proper" authenticated encryption algorithm are not available within the framework.

3. Questions

Does it make sense?

In order to avoid adding complexity on something complex enough is it an option to use the pre-loaded shared secret as a key for the HMAC function and the shared secret Hash as Encryption Key for the AES encryption?

Does it allow the mitigation of the identified threats under that particular scenario?

Can the process be simplified and keep its security properties?

3. Resources

How to choose an Authenticated Encryption mode

Authenticated Encryption and how not to get caught chasing a coyote

Authenticating Requests Using the AWS REST API

Designing a Secure REST (Web) API without OAuth

Why can't I use the same key for encryption and MAC?

Community
  • 1
Moustache
  • 646
  • 5
  • 9
  • You could make a hash. Then hash the hashes. Then hash the hashes hashes so you have hashes inside your hashes. Then use a symmetric key algorithm. Just a thought, but I remember how AES/DES (if I remember correctly through CS class) work through repetitions, which that would be. – cutrightjm Jun 19 '13 at 04:18

1 Answers1

7

Both server and client know something secret, thus they can trust that there communication isn't being altered in route. Effectively, using a connection via the shared key between them is like using SSL without the hand shake. Normally SSL would use asymmetric cryptography to a) validate one or more parties in the communication and b) establish a shared key for communication.

You, however, are able to establish the trust in part a prior to releasing the device since both are in your possession. Provided the key on the device is not compromised (which is the primary weakness depending on usage) then if a device is able to communicate in a way that decrypts, correctly, the message originated from the device. So thus you only have to worry about replay attacks, but any simple mechanism could stop that (for example a counter or timestamp to avoid reuse or use of an older message than the current one.)

AJ Henderson
  • 41,896
  • 5
  • 63
  • 110
  • I'm pretty confident the use of KEYED-HMAC in this context (No SSL/TLS available) is a good solution to authenticate the devices, however I'm not sure about the use of the shared secret key twice. As a secret key for the HMAC, and a second time using the hash of the secret key as a key for the AES encryption. Best practices I have read about [(How to choose an Authenticated Encryption mode)](http://blog.cryptographyengineering.com/2012/05/how-to-choose-authenticated-encryption.html) usually recommend to use two separate keys, which is the case here but with a bit of a twist. – Moustache Jun 19 '13 at 09:43
  • Also, reply attacks might not be a problem here since request are only send one time. After a device successfully retrieve its configuration the access to the configuration is disabled. However I do agree it is in other circumstances an important point to keep in mind. – Moustache Jun 19 '13 at 09:56
  • 1
    @Moustache - you can use an HMAC if you like, but as long as you can safely verify that a replay is not taking place, the encryption itself verifies that the sender and recipient are only the authorized devices (thus providing authentication.) The XML Encryption vulnerability had to do with the server disclosing if small parts were valid from what I got from a quick read, which doesn't appear to be relevant here. Also, his rule 2 seems pretty unsupported and seems more paranoia related. Note that he confirms these only matter if the server is replying, opening a chosen cyphertext attack. – AJ Henderson Jun 19 '13 at 13:43