0

I am working on remote light control system. The devices/controllers are like raspberry pi sized units running embedded programs to accept commands from a management application running on remote web-server. The devices are deployed in the field (street) and connected to internet via GPRS & Ethernet.

There are hundreds of such devices not having host-name and their IP is not static. So SSL certificates may not be possible here???.

Does the "shared secrete" approach works best here? but then distributing these keys to already existing devices would be challenging as it cannot be done over insecure OTA.

3

The design requirements of your system are not fully clear to me. But I will assume in the following that you have full control over the setup and that this setup has only the following requirements:

  • secure connection between devices and central management server
  • central management must be able to send commands to devices at any time
  • IP address for the devices are dynamic and not known to the management server up front, i.e. the device must somehow announce itself to the server initially.

There are several options to implement this, like

  • Create a VPN between the devices and the management system. This can be done for example with IPSec or OpenVPN and with some variations with SSH too. Within this VPN the devices can have a fixed private IP address thus addressing a device from the server is no problem. And TLS is not needed since the VPN already protects the connections against attackers outside the VPN.
  • Create a TLS connection from the device to the management system which requires only a certificate on the side of the management system. This TLS connection can then be used with a custom protocol to communicate between server and client. Depending on the setup and restrictions because of firewalls it might be useful to not create a simple TLS connection directly on top of TCP but use secure WebSockets for the bidirectional connection. Still, only a certificate on the server side is needed which is trusted by the client.

These setups are similar in that the secure connection (i.e. VPN tunnel or TLS) is initiated from the client, since the client IP address is dynamic and the management system has a static IP or at least a static hostname. It might be useful to add some authentication of the client to this because you don't want that some attacker connects to your management system.

One way would be to create your own PKI with your own CA and issue a unique certificate for each device. The subject of this certificate can be some device-id which you can use to identify the device. These client side certificates could be used for authentication in the VPN or as client certificates in the TLS connection. And, if a certificate got compromised (i.e. someone hacked the device) you can simply centrally block access with this certificate in your management system.

  • Steffen, you once again beat me by seconds;) – Tobi Nary Oct 26 '17 at 16:57
  • VPN may not be feasible option because the devices use public SIM (not M2M SIM) to connect to management server via GPRS , so I prefer to use standard PKI based TLS. Is it OK to have our own root CA to sign all device specific certs? or do we need an intermediate CA as well? – user1493834 Oct 28 '17 at 16:27
  • @user1493834: I'm not sure why using VPN should not be possible with public SIM: a VPN only needs data transfer, same as TLS does (there are also TLS based VPNs). Anyway, intermediate certificates are not strictly required. They are usually used to restrict the risk by restricting root CA operations which involve the CA's private key. This should not be a problem if you only sign 100 certificates in total but it might be a problem if you need to sign 100 certificates each hour. – Steffen Ullrich Oct 28 '17 at 22:56
1

There are hundreds of such devices not having host-name and their IP is not static. So SSL certificates may not be possible here???

Remember: before trying to figure out any security solutions, start with determining your threat profile. What attacks are you trying to prevent?

I would guess that one of the major ones is to prevent an attacker from pretending to be the control server and successfully sending commands to the controllers. For this, then, you want the devices to be able to authenticate the server, and that requires a certificate on the server side, not on the devices - either a traditional HTTPS (or HTTPS-like, if you're using a different protocol) setup if the clients initiate a connection to the server, or a client-side certificate if the server is initiating a connection to the devices.

  • I meant we cannot have SSL certificate for device authentication. The devices also initiate connection to the server. – user1493834 Oct 27 '17 at 15:32
1

There are hundreds of such devices not having host-name and their IP is not static. So SSL certificates may not be possible here???.

SSL client authentication certificates can be issued without a DNS resolvable name or fixed IP addresses. The server does not have to be configured to use DNS to verify them.

As Stephan suggested, standing up your own PKI for this system seems like the right approach. Unless your organization already has their own PKI, this can be as simple* as using OpenSSL to generate your own self-signed certificate, then using that CA certificate to sign all your server and client certificates. You'll have to install the custom CA certificate as a Trusted Root certificate in each of the servers and clients. (If these are part of a closed ecosystem, consider removing any trusted root certificates that the clients don't need.)

You will probably have an inventory of the devices as part of running your organization. Whatever ID is assigned to them, that would probably be appropriate to set in the DN of the certificates. But you certainly don't have to do that either, especially if you don't want to put your internal name on your certificates. Instead, you can pre-generate a large pile of certificates in advance, and hand them out to new clients when they register with you. Then keep track of the certificate ID and the client ID it was issued to, and use that relationship for granting client permissions. This keeps your issuing CA safely offline from the system that registers your clients.

If your organization has a PKI already, consult with them. They should assign an Organizational Unit reserved strictly to your devices. You can then have your server verify the client certificates have the OU valid only for your devices. That way, other groups in your org won't be able to issue certificates to rogue/unknown devices.

Remember, once devices are out in the field they can possibly be stolen, tampered with, and/or disassembled. Don't place any more trust in the client certificates than you need to. Don't allow these same device certificates to grant administrative permissions on the server. And if a device goes missing, invalidate its certificate quickly.

* I apologize for using the word "simple" in conjunction with PKI.

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.