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.
- The device generates the Shared Secret using the peer Public Key and its own Private Key.
- The device generates 16 random bytes.
- The 32-byte Shared Secret is run through AES128-CMAC using the 16 random bytes as a key.
- The output of the CMAC is used as the key for AES, with the 16-byte payload used as plaintext input.
- 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.