Tell me more ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.
up vote 2 down vote favorite

for an embedded device I need to sign a 14-byte string and want to verify that string on the device.

Since there is already an AES-Library on the device, I thought about using the following scheme:

Use AES with a fixed IV and a fixed secret key to encrypt the following string:

"2byte Random Padding | 14byte data"

And send the 14byte data followed by the 16byte result of the encryption.

Is this scheme totally dumb?

Thanks!

Regards, Philipp

share|improve this question
1  
Isn't this completely vulnerable to replay attacks? Somebody can just eavesdrop on the 16-byte ciphertext and save it to prove they know the 14-byte string at any given time. And 2 bytes of random padding is far too small. You will need something better. – Thomas Jul 12 '12 at 7:43
This is supposed to be a signature. Which remains valid even if it is replayed. – Philipp T. Jul 12 '12 at 7:44
5  
Do you need public verification of the signature, or assume a secret key known only to the "signing" and verifying device(s)? In the later case, this is more academically called a Message Authentication Code. One suitable example would be CMAC, for any message size. Save for terminology, your scheme is OK. The padding can be fixed, which allows to truncate the MAC, and faster verification since AES decryption is more costly than encryption. – fgrieu Jul 12 '12 at 7:52
Yes, I need a MAC. CMAC looks like I could implement it. Thank you! – Philipp T. Jul 12 '12 at 10:40
2  
You want to distinguish "valid" 14-byte chunks from "invalid" 14-byte chunks where a chunk is "valid" if you have ever signed it? Is that a correct understanding of your problem? Do signers and validators have a shared secret? – David Schwartz Jul 12 '12 at 10:45
show 1 more comment

1 Answer

up vote 2 down vote

@fgrieu is right. I concur with the recommendation to use CMAC. That is a simpler, more general solution. Also, if space is at a premium, you can probably truncate the output of CMAC to 8 or 10 bytes, while still receiving adequate security.

One remaining vulnerability is that this scheme does not prevent an attacker from replaying, re-ordering, or deleting messages. If you send messages A,B,C,D, the attacker can arrange for the recipient to receive D,B,C,B,B (for instance). If you want to defend against that, you could use a sequence number (or possibly a timestamp).

Another vulnerability arises if you use this key for multiple connections. For instance, let's suppose Alice, Bob, and Carol share a single CMAC key. Then if Alice sends message M to Bob, the attacker can arrange to redirect the message to Carol and make Carol think that Alice sent M to her. One defense is to never reuse the same CMAC key (make it unique to a pair of endpoints and a direction). A different defense is to include the identity of the sender and the recipient in the input to CMAC, i.e., you compute T = CMAC(K, sender || recipient || message) and use T as the authentication tag. This solution does not increase the size of the packet, so it is essentially free.

share|improve this answer
This is exactly as I did it. I include the identity of the receiving device in the "signed" message. Replaying/Reordering does not matter for the protocol I have. – Philipp T. Jul 16 '12 at 7:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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