0
$\begingroup$

I am designing a distributed system, composed by a set of physically distributed embedded devices (8 bit cores with less than 1 KB of RAM). The devices need to be able to authenticate the originator of the commands they receive, and for that purpose I chose HMAC.

Each device has a secret key, and a central server knows all of the keys (somewhat similar to a RADIUS server). When a user wants to send a command to a device, it first sends the message to the central server which will append the correct HMAC to it. The user then sends the authenticated message to device, the HMAC is sucessfully verified and the message processed.

My question: is it possible to update the secret key on the device using only this scheme? Since there is no encryption, the new key would be sent in plaintext. I was wandering if a secret sharing mechanism would work for this case.

Improve this question
$\endgroup$
2
  • 3
    $\begingroup$ It depends. What scenario you are trying to defend against? The problem is: it is certainly possible to update the secret key using only HMAC, but an eavesdropper who obtains all the key update messages and any discarded secret key at any point in time can always derive the current key; so there was no point in updating the key at all. $\endgroup$ – yyyyyyy Jan 14 '15 at 15:39
  • $\begingroup$ The initial secret is injected at factory, and that is the reason why I would like to change it once the device is installed in the field. Otherwise any 3rd party could authenticate messages for a device. How can the central server generate a new secret and send it to the device, using only authenticated plain text messages ? Is this even possible ? $\endgroup$ – ngoncalves Jan 15 '15 at 13:44
1
$\begingroup$

Does your embedded device have access to a random input source and a bidirectional channel?

If not, then there will only ever be as much entropy on the chip as you put on it to begin with, so there's no purpose in updating the key.

If so, then just do an authenticated key exchange and generate a new shared symmetric key occasionally. ECC is best for bandwidth starved devices and lattices are best for computation starved devices.

Improve this answer
$\endgroup$
5
  • $\begingroup$ No, the devices do not have a good source of entropy. I was thinking in generating the new key at the central server and then sending it to the device. But whatever I send, it would be in plain text since messages to the devices are only authenticated, not encrypted. $\endgroup$ – ngoncalves Jan 15 '15 at 12:41
  • $\begingroup$ What are lattices ? $\endgroup$ – ngoncalves Jan 15 '15 at 13:36
  • $\begingroup$ @ngoncalves In that case, there's no point in updating the key. A lattice-based cryptosystem is something like NTRU. $\endgroup$ – Bren2010 Jan 15 '15 at 16:47
  • $\begingroup$ I suspected that there was no point in updating the key, but kind of hopped to be wrong..... Thanks $\endgroup$ – ngoncalves Jan 15 '15 at 21:49
  • $\begingroup$ If even if "there will only ever be as much entropy on the chip as you put on it to begin with", providing forward-security would still be a "purpose in updating the key". $\;$ $\endgroup$ – user991 Jan 18 '15 at 16:37
0
$\begingroup$

When authenticity is provided, we can also provide confidentiality by using asymmetric cryptography. (Authenticity is needed for preventing MITM.) However, this seems to be rather cumbersome design with many round trips.

Improve this answer
$\endgroup$
0
$\begingroup$

(Fellow embedded systems engineer here, I feel your pain regarding resource constraints.)

Seems like this is exactly what Diffie Hellman key agreement is used for, which allows 2 parties to agree on a key while exhanging information in the clear. The big problem with "schoolbook" D-H key agreement is a man in the middle attack, so you want to authenticate communications in both directions.

The Station to Station protocol might be what you need. Normally you'd use public key crypto (certificates) for authentication, but I think that's beyond your device's capabilities. I believe there is a MAC variant of the protocol that relies on both parties using their shared secret (secret MAC key) to establish a new shared secret.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Thanks, I did not know about the STS protocol. My problem with asymetric cryptography is not so much the RAM used by the computations, NaCl seems to address this problem, but the need to process and manage certificates. This is a big pain to do even with unconstrained devices, let alone embedded ones. For now back to the drawing board, thinking about the security model again $\endgroup$ – ngoncalves Jan 20 '15 at 8:15

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.