Signing 14 bytes of data 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
@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.