0

I am working on a commercial device (custom hardware with firmware and embedded software) that includes a Linux OS and will run in an unsecured network environment connected via Ethernet. It will be vulnerable to various attacks. We have performed a security risk assessment and scored risks.

I'm interested in controls for limiting access to the device which cover these two main scenarios.

1) My company sends service technicians to upload software, retrieve logs, and troubleshoot problems. The servicing is performed infrequently (e.g. once a year) using software that my company controls. The software is not updated very frequently e.g. once a year. The software runs an individual laptop. The security is limited somewhat whereby if the laptop is stolen and credentials are obtained then the access is compromised.

2) There is a need for a very small number of third-party applications (e.g. less than 10) to interface in read-only manner to retrieve data from the device to enable business integration.

The approach I'm considering is with client certificates where the device is the server and the software apps in (1) and (2) are the clients. This takes me down the path of whether to go with an internal CA or a private root and intermediate CA. This raises some questions such as:

  • How many unique certificates to issue
  • Expiry times of the certificates
  • Using Certificate Revocation Lists (CRL)

The question I have is whether there is an alternative approach to using client certificates which solves (1) and (2)?

sdbol
  • 123
  • 2

1 Answers1

0

Certificates are a good solution

The device will have a server certificate issued by a CA (either root or intermediate). It can trust client certificates issued by the same CA (or another subCA of the rootCA). When using certificates you are right there are two things to care about:

  1. Runtime of the device certificate and
  2. the runtime of the CRL.

If the device has ethernet access over an untrusted network this is great. The device can fetch updates of the CRL. And as the CRL is signed by the trusted CA, it does not matter, that the network is untrusted, since the CRL is trusted and can not be modified.

I think this is probably the best solution. One day you need to

  1. renew the device certificate and
  2. the root certficiate.

Alternate approach easily ends up in a PKI

Well, to address requirement (1) you could create an easy VPN (like tinc) between the devices and the laptops. But as you pointed out, if the laptop is stolen, you need to have a process to exclude the laptop from the VPN. This might be cumbersome.

But in fact you also have to verify that the CRL gets updated and is fetched by the device, if a laptop is stolen...

As far as requirement (2) is concerned: You could also try to work with API keys or assymmetric API keys. But if an API key is compromised, you need to invalidate this API key. And finally you end up rebuilding a PKI.

Online?

However, if the device has a reliable (Availability) network connection you could run a central management. Using this central management you could block symmetric API keys of 3rd-party Applications and you could block service personell and you could invalidate VPN keys... So yes, if you have reliable network connection you probably could do all this without the hassle of certficates which expire...

cornelinux
  • 2,023
  • 8
  • 11
  • It's interesting that all paths seem to lead back to PKI. The only follow up question I have is that the device may not always be connected to the network? I'm not sure if this changes anything? – sdbol Feb 17 '17 at 08:03
  • The device should be able to fetch a CRL "every now an then". Of course if a laptop was compromized and the certifitcate is revoked and the CRL is not fetched by the device then the laptop can still connect. But this is why you also have user access? – cornelinux Feb 17 '17 at 11:56
  • Also if the device does not have network connection for a long time and the last fetched CRL expired, then the laptop can not connect to the device. – cornelinux Feb 17 '17 at 11:57
  • So the choice of the CRL expiry is quite important here. That's a good point I hadn't considered properly until now. – sdbol Feb 19 '17 at 04:42