8

In the home automation scenario, smart gateway can bridge the many smart devices with Internet. In many cases, a server's public certificate is stored in the embedded system's ROM during manufacturing.

For example, in case of AlertMe gateway, each gateway device is manufactured with a unique ID. In addition, it also holds the public certificate of the AlertMe servers in ROM. On first boot, the gateway device generates a random RSA key pair, connects to the AlertMe servers, verifies the server’s identity (using the ROM public certificate), and gives the server its random public key.

My question is, since in the SSL/TLS connection the server will send its certificate to the gateway, why does the gateway have to store a public certificate in the ROM, before its first boot. If, like what it says, it is for the verification purpose, how does the gateway verify the server's identity? Does it just compare the gateway's certificate in the ROM with server's certificate sent at SSL handshake? Can't the embedded system contact the CA, to verify the identity of the server?

Moreover, on first boot, gateway will generate RSA key pair, and then the certificate. Where is the safest place in the Linux based gateway/embedded system to store the key?

Improve this question

2 Answers 2

Reset to default
7

For your question why the server certificate is saved in the ROM:

The saved certificate is checked against the certificate sent back by the server. This is a correct assumption from you. Therefore only one server is trusted at this moment.

You ask why the device does not simple connect to a CA. This would be another way to work. But even then the CA root certificate must be embedded in the ROM. This is needed because else how would you connect to the CA? You need also SSL/TLS to connect to the CA because else all the PKI would be senseless. So at least one certificate must be embedded in ROM.

Improve this answer
1
  • 1
    As a slight side node: embedded developers are, in general, terrible at security. I did a whole presentation at a security conference on some of the more egregious stuff I've seen. If you're adopting an embedded device that will sit in a privileged position in your network, or that will hold sensitive information, make sure you get it independently tested, and ensure that you place appropriate secondary controls (e.g. a hardware firewall) between it and your internal network.
    – Polynomial
    Jun 21, 2013 at 8:26
4

All the business about certificates is about one unique goal: to make sure that the peer's public key is the right one. If a device can know "innately" (i.e. from ROM) the server's public key, so much the better; the device does not even have to look at the certificate that the server sent. A more generic but more complex model is when the device knows a "root" CA public key, and performs X.509 certificate validation. That's what happens with basic PC: the OS and/or browser comes with a set of a priori known root CA public keys, and every certificate is validated from these root CA.

However you put it, the device must start somewhere. Trust does not materialize out of thin air; it is transported though signatures, from knowledge of the signer's public key to that which has been signed. There must be some initial trust, which, for a device, is its ROM. This is called, appropriately, a trust anchor. Making the intended server's public key the trust anchor is the least flexible model (because this prevent the server from ever changing its public key, lest the new key not be accepted by existing devices), but also the simplest (the client's certificate decoding code won't have any bug if the client does not even try to decode any certificate).

As for private key storage, the device will put it where it can. Most devices don't have much choice: that key must be generated onboard (so it cannot go in ROM) and must resist poweroff (so it cannot stay in RAM only). This points to some EEPROM or Flash chip. Regardless of where it is stored, it must be readable from the device software, so if that software gets hacked in, the key is toast.

Devices with strong security requirements (e.g. payment terminals) will often embed a tamper-resistant chip which will commit digital suicide if a break-in is detected (a small static RAM chip with a lithium battery, always on). That kind of storage does nothing against logical intrusions, but it at least prevents key theft from physical attacks.

Improve this answer

You must log in to answer this question.

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