I am working on an IOT device that sends data to the server after authenticating itself to the server. Is there a way to safely store my device's credentials for logging onto the main server and sending data to it.

The IOT device can be physically compromised, and the data that I need to store on the device is IP address of the server, identification key for the device and private key for asymmetric encryption. From what I have researched, it is possible to retrieve this information from memory if stored in plain text but if I encrypt it, it still requires me to store the encryption key somewhere since the device has to work without human intervention. Are there any solutions for this?

One solution I found is storing keys and credentials on TPM, but I still have this doubt that somewhere in the process, will the data be available in plain text and can be read using memory dump of the ram? Because to connect TPM to my MPU, there must be buses involved and whenever I send data for encryption into the TPM, it will still be available in the buses.

  • Take a look at the questions in the "Related" section: security.stackexchange.com/questions/20294/…
    – schroeder
    Mar 23 '19 at 22:25
  • This is a common chicken and egg problem. There is no perfect solution, but some mitigation may be possible - but that is dependent on how much intervantion is practical at runtime, the availability of the device (is it expected to be always connected / always powered on) and what the threat model is.
    – symcbean
    Mar 23 '19 at 22:39
  • The device always stays connected, but if turned off will attempt to reconnect the next time it is turned on. And also, how is this an egg chicken problem, since the TPM can counter the issue. I'm just researching on deeper level, if the TPM do fail? Idk how to define the thread model, I'm just curious to know how can data be still extracted out during active running of the device when the data travels from cpu to TPM for encryption with some sort of key, can the data be intercepted on the bus? This might seem hypothetical, but I want to know at which level defending is impossible Mar 23 '19 at 23:24
  • it highly depends on the MCU, some have trusted stores and firmware encryption, some (most) don't.
    – dandavis
    Mar 26 '19 at 17:23

From your question I understand that your IOT device need to store some sensitive information. To prevent adversaries who have physical access to these systems from obtaining the information is multifold. It would be a combination of physical security controls as well as system level controls.

  1. Sensitive information in memory -

By memory, I am considering volatile memory - ie; RAM. It would be virtually impossible for you to prevent the sensitive information from being in memory in clear text because your client program would need the data in clear text. However the possibility if accessing the data from memory is pretty limited if you aren't opening up any other vulnerable interface which would provide some sort of shell like interactive access to the device itself.

  1. Sensitive information in filesystem -

There are three potential ways a user can obtain the information.

  • By reversing the firmware package
  • By dumping firmware from the device using any open test interface like JTAG
  • By using SPI or similar interfaces to read on board flash storage

All three can be resolved by encrypting the respective storage. First two by encrypting the firmware and by leveraging a solution similar to FDE. Read more in TPM. A hardware fuse which limits access to the trusted module also would be required to resolve your issue.


if you say your device can get physically compromised, the actions necessary to protect your assets are strongly dependent on what is the possible consequence of them leaked.

For example, if every device has a unique access to the server, restricting the access for the devices might be enough to secure the server instance. E.g. my untrusted surveillance camera may only save data to the ftp, but not receive or delete any.

Furthermore it highly depends on the "attractiveness" of a hack. Though it's nice hacking a bluetooth speaker, I guess no one will put too much work in it. Sames goes for electronic locks. If it takes 4 hours to defeat it, that might still be too long in plain sight. It's different if all implementations share a flaw, like a common encryption key.

If you are looking to defend against a skilled attacker, then you also need to make sure that sensitive data cannot be tapped. The traces to an external TPM can be probed and then you read the keys in plaintext (cf. https://pulsesecurity.co.nz/articles/TPM-sniffing)

Further, in my opinion very valuable, reading about hardware attacks you will find here: https://www.cl.cam.ac.uk/~sps32/#publications

Please feel free to go more in detail with you application or write me a PM then we can narrow down you choices.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.