4

I need some inputs for the scenario when the certificate expires which is stored on the embedded device on the network which is a client. Following is the explaination of the setup.

The setup explaination

  1. A device (client) is connected on the internet.
  2. We need to connect this device to the server
  3. Currently the server is supporting the SSL protocol
  4. We need to implement the SSL protocol on the device side
  5. Device will send the data to the server
  6. We can only access the server but not the device directly. Whatever data is received by the server from the device can be viewed on the server only.
  7. As stated in point no. 4, the data which is being flown between the server and the device should be made secured by using the SSL on the device side.
  8. Device does not have a web browser facility.

So the device (client) has to have a root CA certificate stored in its keystore. When it expires how to renew it...

Regards,

ssk

  • 2
    Update the device? Seems like the only option. – Deer Hunter Oct 1 '14 at 5:05
4

If I understand you right the device will only communicate with a single or few specific servers. In this case you should not rely on the public CA system, but instead roll your own:

  • If you have only a single server you can use a self-signed certificate and hard code the expected certificate in all devices (certificate pinning).
  • If you have multiple servers you might either use multiple self-signed certificates and deposit them all in each device. Or you might create your own CA and store it as the only trusted CA on the device. Then accept anything signed by this CA but nothing else.

In both cases you control the expiration times of the certificates yourself, so you can make them really long or skip verification of expiration at the device. Of course you need to tightly protect the private keys of the generate certificates and CA, but this would be the same too if you use the public CA system.

And unless you are able to upgrade the firmware on the device you should use crypto algorithms which will likely be strong enough for the expected life time of the device. If you instead are able to update the firmware make sure the upgrade process is secure (e.g. signed upgrades) because otherwise an attacker might just add its own firmware and circumvent your SSL protection by grabbing the data on the device before they get encrypted with SSL.

  • Thanks for your reply. We are planning to have a firmware upgrade feature. On the server side, it seems that already there is a third party CA who has issued a certificate (as per my understanding you call it a public CA). So might be we need to use the same root CA certificate on the device. And there might be 2 servers which will be used for testing which have self-signed certificates. The end points (multiple servers) for the device may be changed by sending a command to the device. So any input how to deal with this situation. – ssk Oct 4 '14 at 9:43
  • Since you have some self-signed certificates anyway I would recommend to use certificate pinning and only check the fingerprints of the public key in the peer certificate. You then don't need to worry about a simple renewal of the certificate, because the public key stays the same. Only if the public key changes (because it got compromised) you need to update the accepted fingerprints on the device. And any updates should of course be signed, with the public key to check the update on the device and the private key securely tucked away. – Steffen Ullrich Oct 4 '14 at 9:59
  • The servers which are having self-signed certificates will be used for testing purpose only. The main server has already got a a certificate which is issued by the third party CA ( I think it is from Verisign...not sure). On the actual field, device will be connected to main server. – ssk Oct 4 '14 at 10:11
  • Since the device will only communicate with a single server (or maybe few other servers for testing) it is more secure to accept only the fingerprints as described. The other option would be to mark only this single CA as trusted and only allow certificates from this CA for the specific hostname. But don't install all the 100s CA as trusted as the browser do, because each of these can issue a similar certificate to another party. – Steffen Ullrich Oct 4 '14 at 13:57

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.