With the LXI standard, suitable measuring devices can communicate via Ethernet. The consortium is currently working on LXI Security. But there will also be self-certified measuring devices in the future. An overview.
At the beginning of October 2018, the LXI consortium published the LXI reference design version 1.4. With the reference implementation, many companies have started to adopt the LXI standard in their devices. How did an LXI standard come about? At the beginning of the millennium, it became increasingly important to connect different measuring devices to a test system as easily as possible. This became necessary in order to achieve different test scenarios and test procedures in distributed systems.
The complex LXI technology required more and more different measuring devices such as generators, analyzers, switching devices, etc. to be integrated into the measurement scenario and connected to the control computer to be programmed for the measurement process. Until now, the approaches have been based on the IEC bus (GPIB or IEEE488), but this limits interchangeability, flexibility and expandability. As Ethernet is widely used both in PCs and in industry, the LAN interface offered an alternative for a standardized bus system. For this reason, leading measurement technology companies have decided to establish a standard based on Ethernet networks. In order to realize such a company, a non-profit consortium was founded in 2004 to produce the LXI standard (LAN eXtensions for Instrumentation). Today, more than 50 companies worldwide from the measurement technology sector are represented in this consortium. These include Keysight, Pickering and Rohde & Schwarz as strategic members. More than 3800 devices from 43 member companies are LXI-certified.
The current activities of the LXI consortium
In addition to continuous improvements to the LXI reference design, regular bug fixes and the integration of new features, the consortium is working on an enhanced feature called LXI Security. Cybersecurity issues are a major topic in the industry, so the industry is looking closely at this critical attribute within networks. Another hot topic is the possibility of self-certification in the near future.
LXI Security has its own working group within the consortium to consider the risks of LXI-relevant security breaches on LXI devices. The group needs to consider the different scenarios for which LXI instruments may be used. The test systems can be isolated networks or even a peer-to-peer connection, but LXI instruments are often connected directly to corporate networks or even to the Internet for remote monitoring in the field. Crucial are the remote control connections, which are mainly SCPI-based TCP/IP connections such as HiSLIP and VXI-11, but also the web browser interface, which is an essential part of an LXI device configuration option. The current standard requires an HTTP web server to be running that has no encryption at all. In addition to these two main topics, ping, mDNS and LAN events are also topics that must be addressed by an upcoming extended LXI Security function.
The working group intends to take two different approaches for the remote control connection and the web browser interface, but both approaches are based on certificates. However, this requires an Initial Device Identifier (IDevID) to be installed on the device.
The problem with a changed IP address
For the web browser interface, the public trust model is used, which is based on locally significant device identifiers (LDevIDs, X.509 certificates, 12-month lifespan) and is derived from the IDevID. However, the IP addresses and the host name of the LXI devices change during their lifetime, making the LDevID invalid. Therefore, a provisioning server is required to request a new LDevID when its IP address changes. The device must assign and reconfigure the host name to the new IP address and update the DNS settings. Once this has been completed, secure web server access (https) is available. The revocation of these certificates is checked when the LXI device establishes a connection to the provisioning server.
This approach leads to the question of the different scenarios that the group needs to consider, as not all of the scenarios mentioned above have Internet access to connect to a provisioning server. A number of options were identified for the scenario without Internet access. One option would be to install the provisioning server within the local network to request new LDevIDs. The IT department may need to provide support here. Another option would be to use self-signed certificates, where the certificate would have to be installed both on the LXI device and in the web browser of the test computer.
Control measuring devices remotely
The private trust model based on IDevIDs (IEEE802.1AR, unlimited lifetime) is used so that measuring devices can be controlled remotely. The required metadata such as the device ID model and the manufacturer name can be found in the modified certificate format. HiSLIP 2.0 is also required, which supports secure communication with TLS and therefore addresses the issues of identification, authorization and encryption. HiSLIP 2.0 continues to use the IANA port 4880 and the currently known VISA resource string for backward compatibility, but new security levels must be introduced. The working group has identified three levels.
Initially, it will be necessary to be able to deactivate the security feature with HiSLIP for reasons of downward compatibility. This is the case when a new device communicates with a client or a VISA application that does not support HiSLIP 2.0. There are also other reasons. This includes debugging network traffic or avoiding a loss of performance due to encryption. Secondly, there could be a mode that checks the authentication. This could be useful in a trustworthy environment. Here, the device may start with a TLS connection, but encryption can be deactivated after successful authentication. Finally, a mode will be required that makes encryption mandatory. All devices must authenticate themselves. If a device attempts to communicate without encryption, the connection must be terminated after successful authentication.
Self-certify measuring devices in future
Self-certification is a recurring theme in the LXI consortium, as several leading companies want to self-certify their devices. This is already common practice with other standards. The LXI guideline to date is that a supplier must bring its device to a certified test house in order to have it certified as an LXI-compliant device. Previously, this made sense, as the current LXI test suite requires certain hardware for the tests. The LXI Test Suite software requires a certain amount of know-how to operate it. The consortium is confident of overcoming these hurdles with the TSEP Kerberos. This is a software and hardware solution that checks the LXI functionality of measuring and test devices. It contains the necessary hardware and significantly reduces the LXI know-how required to certify a device. Most tests are fully automated, others are partially automated with step-by-step instructions for the manual test sections.
However, the consortium does not want to give up complete control over the certification process. It is therefore required that a company has at least one device that has been certified by an LXI test house. The aim is to protect the LXI standard in future, as customers are accustomed to with LXI-compliant products. The self-certification concept is to be adopted at the upcoming Meeting & PlugFest.
Author / Editor: David Courtney / Hendrik Härter
