Test System Security

cancel
Showing results for 
Search instead for 
Did you mean: 

Network Streams are not secure-by-default

Hi everyone,

 

In many of our customer and industrial applications, we rely heavily on Network Streams for high-throughput, lossless data communication between host PCs, RT targets (cRIO/PXI), and distributed applications. However, with the upcoming CRA coming into full effect, we are facing strict requirements regarding security-by-design and secure-by-default. Any network communication on products with digital elements placed on the European market must be secured, and unencrypted data streams over open network interfaces will no longer be compliant.

Currently, the Network Streams VIs (and the underlying LogosXT protocol) do not offer any native way to secure the data stream using TLS or any form of encryption. While LabVIEW has introduced native TLS VIs for raw TCP/IP, these cannot be easily wrapped around Network Streams due to their closed implementation.

Are there any roadmap plans to upgrade the Network Streams library (or LogosXT) to support TLS/SSL natively?

Message 1 of 7
(734 Views)

Thank you for posting this important topic. You are correct, Network Streams do not provide an option for encryption. We are looking at how to best provide encrypted data transfer in LabVIEW, including perhaps adding this to Network Streams, but right now we have not committed to an option - we are still researching.

 

The easiest way to implement encrypted communication today is with the Encryption Compendium for LabVIEW from LVS Tools.  This tool provides a variety of encryption algorithms, and provides tools for doing encrypted data transfer in LabVIEW. They provide options for TCP (TLS), UDP (DTLS), and SSH data streaming. These aren't LabVIEW specific. I've been testing this set of tools in LabVIEW and I am impressed  - I'm finding it very easy to use. 

 

Another option is gRPC, a protocol we've been using more at NI. We recently added TLS support to gRPC - see the manual at https://github.com/ni/grpc-device#ni-tls-config-integration

 

I'll keep working with our engineers to explore what's possible with Network Streams.

0 Kudos
Message 2 of 7
(673 Views)

Thank you for your reply,

 

We know that there are other options like gRPC which we already use. But we are also still maintaining a lot of software that already uses the network streams, software which we still make releases for. These integrations are not easily or without a fair amount of extra work changed to a whole new communication protocol.

 

I hope there is still a future for Network Streams, otherwise if not, this would be a perfect project to open source.

0 Kudos
Message 3 of 7
(587 Views)

HI Bas,

 

I'm not sure if this would be an acceptable solution but an alternative would be to use WireGuard to encrypt your data automatically.

 

This is is done "outside" of your LV application, I'm not sure if this meets CRA requirements though.

 

We've managed to installed WireGuard on NILRT 20+ I think

 

Best of luck,

Vincent Carpentier, CLA, CPI
Neosoft Technologies/PVI Systems
NI Gold SI Partner in Canada and the US
www.neosoft.ca
www.pvisys.com
DQMH Trusted Advisor
0 Kudos
Message 4 of 7
(568 Views)

That's not really a solution for our problem as we use Network Streams to dynamically connect to multiple devices where only the controller applications would know the IP of the devices or it would look for the devices via mDNS or the LabVIEW discover RT devices. and the controller applications could run on any machine, not just a fixed server machine. which means you need to constantly update the wireguard tunnels to connect to the correct devices.

0 Kudos
Message 5 of 7
(554 Views)

@Vincent_Carpentier wrote:

HI Bas,

 

I'm not sure if this would be an acceptable solution but an alternative would be to use WireGuard to encrypt your data automatically.

 

This is is done "outside" of your LV application, I'm not sure if this meets CRA requirements though.

 

We've managed to installed WireGuard on NILRT 20+ I think

 

Best of luck,


Tunnelling through SSH would be another similar solution. 

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 6 of 7
(535 Views)

I've been talking with the LabVIEW developers. Good news - they are working to add TLS encryption to LabVIEW Shared Variables, Network Streams, and Scan Engine APIs. I don't have any other details, but it is good to hear that they are actively working to add this to an upcoming release of LabVIEW. I'll post more here as soon as I learn about it. 

 

If you are looking for something you can use today for encrypted network communication, I highly recommend you look at Encryption Compendium for LabVIEW

0 Kudos
Message 7 of 7
(253 Views)