1

Trying to design some secure firmware here and running into a brick wall regarding the use of crypto-chips. We are considering using this one here: https://www.microchip.com/en-us/product/ATECC608B. All data on our RTL8720DN 2.4/5GHz chip is encrypted/decrypted using AES256 which is a big deal because we encrypt and save the customers home WiFi password on the device EEPROM. The issue that we are concerned about is that the IV and CBC keys are exposed in our program itself. The crypto-chip fixes that by coming pre-configured with the keys and, obviously, they are securely locked so that no one can get them out. Whenever we need to encrypt/decrypt something we just make a quick call to the crypto-chip to get the secure keys and we are good to go.

We are already using SSL/TLS communications through the customers home WiFi to our cloud servers, etc. so don't need the crypto-chip to help us with certificates.

Billion dollar question here: if a hacker breaks into a customers home and steals our device, can't they just decompile our code or even just flash their own code onto the device and "programmatically" extract the AES keys from the crypto-chip? That's basically what we do when we update our firmware via OTA. If that's the case, what's the difference between just leaving the keys in plain text in our program?

Mike
  • 113
  • 3

1 Answers1

3

If a hacker gets hold of your hardware, it is just a question of time and resources that the hacker has, before they can get your device key or certificate. And then, all data that is stored on the device, unless it is one-way encrypted, with no keys on the device to decrypt.
So, you will not be able to really do much about that wifi password, except to spend a bit of time/resources of the hacker. In fact, such vectors are a threat to home security and hence, many suggest that home owners take the trouble to put all the devices on the guest network. It is painful, but gets a degree of security.
But you have the device also uploading data to you after it gets on the wifi. The important thing is that if they do get that one device, they cannot then get access to or spoof your other devices using that key/certificate.
So, you will have to create device specific keys. They can be derived from some master key or be random. In case of certificates, they can (and should) have the same chain of authority but be individual device specific certificates.
In the case of IoT, there are provisions in the certificate, to put in a device serial number and then set policies at AWS so that a certificate cannot spoof another device serial number.
The hacker will probably be able to spoof the same device and upload data to your cloud to try to cause a DOS (or DDoS, depending on your security policies) attack or cause an upload of unreasonable amounts of valid-looking data and try to poison aggregate reports, etc.
You will have to consider those threats as well.
But, device specific keys are a start.

kalyanswaroop
  • 1,208
  • 5
  • 16