1

I was recently assigned the task of testing a new hardware device which communicates with a JSON API over UDP.

For some reason or another, it was decided that AES-CBC-128 should be used to encrypt the traffic. I believe this was to prevent someone from creating their own software/script that interfaces with this board (which is proprietary) by obfuscating the API. The party responsible for the board from what I understand has accommodated for replay and man-in-the-middle attacks.

Otherwise, the encryption is enabled in production where we can set the cipher key and the initialized vector being used. Ultimately the computer along with all the connected devices will be shipped with the encryption enabled to a client. It makes me wary that this methodology means that the key is set and never changed.

My plan was to store this key locally in an encrypted file on the local filesystem. Is there any problem with this? As it is blatantly obvious - I am no expert at security. The computer shipped with the product will be on an active network as well. The lack of authentication worries me as well. Will such a thing be necessary here?

  • Is there a MAC? If not, it's probably vulnerable to trivial CBC padding oracle attacks. – Z.T. Nov 9 '16 at 2:47
  • No. I do not believe so. There is simply a randomized number decided upon the open connection and any subsequent messages count upwards. I believe this is to prevent replays. Nothing to validate the integrity of the message or its authenticity. Is there any reason to believe that someone would be able to know if it is AES over the channel? – Stereoblind Nov 9 '16 at 4:13
  • Can you give more details about the protocol? Describe a full communication session. Is the key hardcoded on the device? Is IV random or hardcoded like the key? Do communication sessions require multiple packets? Are packets acknowledged? Etc. – Z.T. Nov 9 '16 at 4:49
  • Yeah so I open the port over UDP, encrypt the JSON, and then send it to the device over ethernet. The key and the IV are modifiable but are hardcoded for testing purposes. The device sends back an encrypted response which I use the same key and IV to decrypt. A packet is sent with the desired command, and is acknowledged, but that acknowledgement is not required for the command to be executed. It is more of a peace of mind than anything. Thanks for the reply btw. – Stereoblind Nov 9 '16 at 18:16
  • If the IV is hardcoded the encryption is completely deterministic. How does replay protection work? Can anyone seeing only the network traffic see a difference between: 1) packet was decrypted and deserialized correctly, 2) decrypted but json error and 3) bad padding? What if I also see the device? Does it do something like blink a led upon processing a good command? – Z.T. Nov 9 '16 at 19:28

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.