1

We're in the final stages of launching a moderatley complex IoT solution, and unfortunately there's nothing resembling a security expert on board. But so far everything looks reasonably secured... everything except for the SD-cards in the distributed devices, that is, and I'm debating whether it is worth to encrypt them, or if it's wasted effort. Which is where I need advice from people more experienced than I am.

Basically, if somebody were to steal a device and/or its SD card, he'd have access to the following things:

A root CA certificate common to all devices that is used in a two-way handshake with an MQTT broker. A public and private key used for encrypting that communication, only used by the specific device. These two can be revoked as soon as we know that a device disappeared.

A root CA certificate common to all devices that is used in a two-way handshake with a VPN server, used for remote maintenance. A public and private key used for encrypting communication with the VPN, only used by the specific device and bound to its hostname. Again, these two can be revoked in a heartbeat without changing anything in the rest of the system.

A public SSH-key common to all devices used for remote maintenance.

As far as I understood things, the encryption keys for vpn and mqtt-broker are worthless once revoked, and the public SSH-key does not compromise the security of the other devices even if they share it. What I am unsure about are the CAs... From what I've read they are useless without the private key and valid encryption certificates, but I'd really like to be certain on that point.

Given the situation, what would you recommend? To encrypt or not to encrypt the SD-card? Since this is an already rather computation-heavy IoT solution running mostly on RasPis, I don't want to take the additional overhead of an encrypted partition unless security would really be compromised if somebody got a hold of it.

Improve this question

1 Answer 1

Reset to default
1

A public and private key used for encrypting that communication, only used by the specific device.

This suggests the private key is present on the devices as well. It has to be, otherwise decryption and signatures are not possible. It does pose a security major threat. Nothing stops someone from copying the private key, and together with the public key are worth a whole lot. Now, an attacker can sign new certificates, decrypt all traffic, alter data and so on.

Again, these two can be revoked in a heartbeat without changing anything in the rest of the system.

Revocation is no rescue and you should be careful relying on this alone. CRLs are (almost) never checked realtime, and can be blocked by an attacker. You'll have to setup the entire OCSP (stapling) infrastructure before you can put some trust in a revocation solution. Same is true for the VPN certificates, probably worse since an attack could easily gain access to the server as well, causing even more trouble.

Encryption can help you. For example you can encrypt the SD card, then decrypt the card once when mounted. The key is stored in memory, which is not without problems either, but prevents someone from removing the SD card and read the confidential data. Obviously this only works when the device itself is 'secure' and cannot be accessed via other ports.

As an additional security measure you could require a stapled OCSP response every so many bytes/hours/days. If this window expires without confirmation of the certificate still being valid, then destroy the private key and notify an administrator.

Improve this answer
7
  • >>Now, an attacker can sign new certificates -wouldn't he need the private key of the root CA for this? that is not present on the devices.
    – UncleBob
    Sep 6, 2016 at 12:13
  • @UncleBob I wasn't sure whether the CA private key was also on the SD card. If not, then probably not. However depending on the certificate extensions, the delegated certificate can be used as an intermediate certificate, essentially creating a certificate chain.
    – Yorick de Wid
    Sep 6, 2016 at 12:23
  • As mentioned, revocation is not a panacea as checking is easily blocked. Any time I see the phrase "public and private key exposed" for anything, that should be a bad sign. If it "doesn't matter" if they are compromised, why have public/private keys at all? If they do matter, the private key of anything should never be in the attacker's hands.
    – JesseM
    Sep 6, 2016 at 22:02
  • Basically, I thought it wouldn't matter because the private key is only valid for the specific device, and can be revoked server-side. When you say "checking is easily blocked", do you mean to say that an attacker can prevent a server from checking if his certificate has been revoked? That would seem strange to me, as the revocation list is only handled on the server side... still, stuff like this is why I asked the question, so thanks! I would appreciate it if you could explain that point a bit more, though.
    – UncleBob
    Sep 7, 2016 at 6:32
  • @UncleBob The certificate is revoked by a revocation list. This list must be downloaded by the client, and then compared with the key fingerprint in the local certificate store. If they match, the certificate will not be valid no more. However, nothing prevents an attacker from blocking the CRL download. OCSP is an alternative, but does have its own problems like MitM.
    – Yorick de Wid
    Sep 7, 2016 at 7:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .