0

How can I best prevent, that critical commandos (e.g. open garage door) from an IoT device are being reverse engineered from the firmware? Is the following list complete / do you spot any errors? Any comments?

  • Encrypt firmware patches for the device, that are available for download - cost: little – security: high
  • activate the fuse lock bit on the device - cost: none – security: ?
  • code obfuscation – cost: little – security: little
  • HDD encryption – cost: medium – security: high
  • (AES) encryption of data (device commands) at rest – cost: little - security: high
  • JTAG fuse – cost: medium – security: high – con: device isn’t updatable anymore
  • JTAG password – cost: low – security: ?
  • hiding UART interface on the PCB – cost: medium – security: low
onGESOnEGa
  • 3
  • 1
  • 1
    I'm not clear on your scenario. Are you worried about someone hacking the firmware of your IoT device, or are you trying to sell an IoT device and are worried about end users hacking it from firmware? – Conor Mancone Oct 24 '20 at 13:55
  • 2
    Also, since this will undoubtedly come up regardless of the answer, [what is your threat model?](https://security.stackexchange.com/questions/225012/what-is-a-threat-model-and-how-do-i-make-one). Asking "how do I stop firmware hacks?" is like asking "how do I stop my website from being hacked?" It is far too broad and varies wildly depending on what specific threats you are considering – Conor Mancone Oct 24 '20 at 13:56
  • 1
    Without a threat model, there is no basis for "best" or to be able to assess the effectiveness of the security of any of your items. – schroeder Oct 24 '20 at 14:57

1 Answers1

2

How can I best prevent, that critical commandos (e.g. open garage door) from an IoT device are being reverse engineered from the firmware? Is the following list complete / do you spot any errors? Any comments?

Don't try to prevent it. Accept that an attacker understands your protocol, but ensure that the protocol is safe, even when the attacker knows the protocol. This is known as Kerchoff's principle.

Even if your app and firmware is perfect, and impossible to reverse engineer, the attacker can listen to the communication in some way. If it's RF, a cheap SDR will let an attacker listen. If it's TCP/IP it's even simpler.

Focus on securing secrets, not code or protocols.

Mistakes like this is exactly what makes bad IoT security; the same key is used everywhere, because the firmware is hard to read... One break, and poof, your security is gone. If you have a good protocol, publication of your source code will not matter to the security of your system. It may make your business more difficult by revealing trade secrets, but it should not affect security.

vidarlo
  • 12,850
  • 2
  • 35
  • 47