X.509 & TLS

[FixedWire]

Client: "And we need you to securely write the firmware to the DUT using X.509"

I'm trying to get a better understanding on how to use X.509 certificates and deciding if the new TLS functionality is the best approach. The examples for using TLS are a bit sparse...

If someone could share their battle scars or provide suggestions it'd be appreciated.

btw, thank you Neil Pate for posting your code!

[Rolf Kalbermatter]

On 10/14/2020 at 3:23 PM, FixedWire said:

Client: "And we need you to securely write the firmware to the DUT using X.509"

I'm trying to get a better understanding on how to use X.509 certificates and deciding if the new TLS functionality is the best approach. The examples for using TLS are a bit sparse...

If someone could share their battle scars or provide suggestions it'd be appreciated.

btw, thank you Neil Pate for posting your code!

So is your link to the DUT over public internet or an internal network? If the first, the client may want to reconsider if that is the way to do firmware updates, if the second, someone seems to be utterly paranoid.

I don't think it is to useful to use the TLS functionality for this. This is on TCP/IP level an are you seriously doing firmware updates over TCP/IP? Or are you rather using HTTPS instead which could have been done with the HTTP(S) client functionality since about LabVIEW 2014 already.

If you need more specific control you might have to go with something like the Encryption Compendium instead. https://lvs-tools.co.uk/software/encryption-compendium-labview-library/

Edited October 15, 2020 by Rolf Kalbermatter

[ShaunR]

12 hours ago, Rolf Kalbermatter said:

So is your link to the DUT over public internet or an internal network? If the first, the client may want to reconsider if that is the way to do firmware updates, if the second, someone seems to be utterly paranoid.

This is quite a common requirement nowadays, especially within the IoT sphere. Many embedded devices come with libraries for what is called OTA (Over The Air). A multitude of devices are then monitored and configured (including software/firmware updates) via a web server. I wouldn't be surprised if the NI Systemlink uses something similar  (via either HTTPS or MQTT).

TLS is quite burdensome for constrained devices, specially if you have to put a webserver on the device to upload rather than using OTA libraries. 

To be honest. This isn't something I would use LabVIEW for. There are much better solutions available specifically for this purpose.

Edited October 16, 2020 by ShaunR

[Rolf Kalbermatter]

12 minutes ago, ShaunR said:

TLS is quite burdensome for constrained devices, specially if you have to put a webserver on the device to upload rather than using OTA libraries. 

How would you do HTTPS without TLS?

And it depends about use of LabVIEW. For a general in the field IoT application I wholeheartedly agree. Trying to build such a system in LabVIEW is going to be reinventing the wheel using a high end CAD tool while you can take ready made wheels from the shelf.

If it is however part of final step during inline testing of a product, with the whole test system controlled by LabVIEW, it may be useful, although calling a Python script would still most likely be much easier and maybe a few milliseconds slower than fully integrated in LabVIEW.

But then the specification sounds a little bit bogus. Rather than requiring that the firmware needs to be written securely to the device, it should simply state the protocol that the device can support. Security in a (hopefully) closed in house network really shouldn't be a concern, otherwise you have a lot more trouble to be concerned about than if the firmware is written securely to the device.

Edited October 16, 2020 by Rolf Kalbermatter

[ShaunR]

9 hours ago, Rolf Kalbermatter said:

How would you do HTTPS without TLS?

I wouldn't. HTTPS is just one protocol. I personally use secure websockets which is much better suited to this sort of thing IMO,  Most of these use TLS though and more recently I've been playing with DTLS. If I don't use those sorts of protocols then I use SSH but that's nothing to do with what the OP is asking as it doesn't use X.509 certs (which is,as you know, just a standardised certificate format).

9 hours ago, Rolf Kalbermatter said:

Rather than requiring that the firmware needs to be written securely to the device, it should simply state the protocol that the device can support.

I think that's just middle-management phrasing. I wouldn't be surprised if the device already supports this method of updating and they were told it uses X.509 certificates "for security".

but we diverge.....

The main thing to ascertain is whether Certificate Authority certs are required or if self-signed certificates can be used. They both allow "securely writing"; the difference is authenticity. This dictates whether things work out-of-the-box (in the same way as your web-browser works out-of-the-box) or you have to add pub key certs to root bundles. Personally I prefer self-certs for this sort of thing as it provides greater granularity for who can access the device,  I don't trust Certificate Authorities, and when IT get a whiff of you requiring company CA certs, they usually try to get involved. It really depends on whether you have control over the server though.

Edited October 16, 2020 by ShaunR

[Phillip Brooks]

On 10/16/2020 at 1:23 PM, ShaunR said:

...  I don't trust Certificate Authorities, and when IT get a whiff of you requiring company CA certs, they usually try to get involved.

😆

[ShaunR]

3 hours ago, Phillip Brooks said:

😆

You can't outsource security  If you understand that all TLS communications are interceptable by governments because of CA's, then you might also be reticent when dealing with some governments.

Edited October 19, 2020 by ShaunR

[FixedWire]

The LV TLS examples led me astray with the X.509. Mind numbing indeed but the DUT firmware needs to be written over Bluetooth. And that I can understand needs to be secured being a med tech device.

...of course IT is all over this right from the get-go.

So the real question is how to secure a BT connection with X.509? Or better yet, I'd like to provide the client with a solution that works on our end first.

[ShaunR]

30 minutes ago, FixedWire said:

The LV TLS examples led me astray with the X.509. Mind numbing indeed but the DUT firmware needs to be written over Bluetooth. And that I can understand needs to be secured being a med tech device.

...of course IT is all over this right from the get-go.

So the real question is how to secure a BT connection with X.509? Or better yet, I'd like to provide the client with a solution that works on our end first.

I don't think there is anything off-the-shelf, to my knowledge - Bluetooth has it's own encryption scheme. I think you are looking at using some existing TLS client/server implementation and replacing the underlying Socket connection with a Bluetooth connection.

 

Edit:

Thinking a little more. there may be another way. the caveat would be it would only work for RSA certs in this scenario,

There is an example of RSA Encrytion/Decryption.

You could load an x509 cert, extract the keys and use the encryption functions to encrypt the bluetooth data. This wouldn't handle the authentication but it's some of the way there. It might be possible to check the authenticity separately from the encryption but I'm not sure at the moment.

Edited October 19, 2020 by ShaunR

[Phillip Brooks]

18 minutes ago, ShaunR said:

You can't outsource security  If you understand that all TLS communications are interceptable by governments because of CA's, then you might also be reticent when dealing with some governments.

I completely understand and agree, it just seems a bit ironic that we can't trust certificate authorities; that is there reason for existing?

My company has a zero touch provisioning solution for deploying our hardware on public networks. I load our top level cert during test and then I'm done. This is done on a wired private LAN using SCP.

Throw in telephony requirements like Lawful Interception and it is amazing that these devices work at all... 

 

[ShaunR]

30 minutes ago, Phillip Brooks said:

I completely understand and agree, it just seems a bit ironic that we can't trust certificate authorities; that is there reason for existing?

It's a compromise between convenience and security and partially solves the "trust" issue by having really, really trustworthy organisations 

There have been other alternatives proposed but the "trust" issue has never really been solved adequately, to date. I trust me so my certificates are great (for me). The problem with that is then distribution. SSH. which is arguably the progenitor of modern TLS, got a lot of things very right. We haven't really moved on from that model except to make a whole new business sector for the key management.

Edited October 19, 2020 by ShaunR

[NEA1711]

@ShaunR & Philip Brooks ... (sorry for a very late response) ... and that's why we don't develop our solutions with any 3rd party dependencies - we don't trust anyone ... and our clients shouldn't trust us either - therefore they have to generate their own PK (no 'I') when installing and don't have to rely on any security solution based on x.509 and therefore no key management. Using x.509 only tells me you have the wrong security architecture and probably also a bunch of ignorant security / infrastructure people in your organisation :-)