I have a system where a resource-constrained device has to send 16 bytes. It has its ECC key pair, and a peer's Public ECC Key. We're using the p256 curve. The device also has an AES-128 hardware implementation, so we want to take advantage of that when possible. I only need confidentiality for the payload. Integrity and proof of origin are handled by other components of the system.

I've come up with my own scheme for this, bit it seems much more simple than the example implementations that I've looked at.

  1. The device generates the Shared Secret using the peer Public Key and its own Private Key.
  2. The device generates 16 random bytes.
  3. The 32-byte Shared Secret is run through AES128-CMAC using the 16 random bytes as a key.
  4. The output of the CMAC is used as the key for AES, with the 16-byte payload used as plaintext input.
  5. The device sends its own Public Key, the 16 random bytes, and the 16 ciphertext bytes.

The two irregularities in this scheme I can think of are that:

  • The 16 random bytes kept public. This should be okay, since the CMAC output cannot be determined without the Shared Secret.
  • The payload is used as the "raw" input to AES. This should be okay, since the key is unique, and the input is small, so patterns can never emerge in the output as in typical ECB mode.

Are there vulnerabilities to this scheme? My concern comes from the fact that other protocols like that used for Bluetooth's "LE Secure Connections" are much more complicated, such as using many more inputs to the CMAC portion. I suspect that this has to do with the goal of establishing keys to use for more plaintext than 16 bytes.

  • 3
    $\begingroup$ You have not stated your security goals w.r.t. the 16-byte payload: do you need integrity+proof of origin, or confidentiality, or both? $\endgroup$ – fgrieu Jul 11 '19 at 16:38
  • $\begingroup$ Uniqueness of the key does not mean that the output of AES is unique, it just means that it is indistinguishable from random. But in that case the birthday bounds should be taken into consideration. $\endgroup$ – Maarten Bodewes Jul 11 '19 at 17:44
  • $\begingroup$ @fgrieu Question edited. $\endgroup$ – Sarkreth Jul 12 '19 at 1:36
  • $\begingroup$ @MaartenBodewes Both the key and plaintext are secret, so shouldn't the attacker have no way to take advantage of the birthday paradox moreso than with any other AES128-derived algorithm? $\endgroup$ – Sarkreth Jul 12 '19 at 1:39
  • $\begingroup$ Sure, but it depends on the algorithm if the birthday paradox applies at all. $\endgroup$ – Maarten Bodewes Jul 12 '19 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.