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?

Stereoblind
  • 11
  • 1
  • Is there a MAC? If not, it's probably vulnerable to trivial CBC padding oracle attacks. – Z.T. Nov 09 '16 at 02: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 09 '16 at 04: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 09 '16 at 04: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 09 '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 09 '16 at 19:28
  • Replay protection is simply an RNG on initialization of the connection. The device will send over this number and the host must comply with the next number thereafter. It seems to me that I should begin modifying the IV and key, but under what circumstance? To answer your questions though, I believe they all have the same success/failure string attached to them. Incorrect decryption is a different kind of failure than failure to decrypt/invalid JSON. Bad padding will just be ruled as a failure to decrypt. It simply blinks when data is being sent in/out of it. – Stereoblind Nov 10 '16 at 17:31

0 Answers0