At the beginning of October 2018, the LXI consortium published the so-called LXI Reference Design Version 1.4. With the reference implementation, many companies have begun 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 various measuring instruments 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 units, etc. to be integrated into the measurement scenario and connected to the control computer to be programmed for the measurement process. Previously, the approaches were based on the IEC bus (GPIB or IEEE488), but this restricted interchangeability, flexibility and expandability. Since Ethernet is widely used both in PCs and in industry, the LAN interface offered an alternative to a standardized bus system. For this reason, leading measurement technology companies have decided to establish a standard based on Ethernet networks. To implement 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 from the measurement technology industry worldwide 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.
Besides the continuous improvements of the LXI reference design, the regular bug fixes and the integration of new functions, the consortium is working on an extended function called LXI Security. Cybersecurity issues are an important issue in the industry, so the industry is paying close attention to 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 must 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 field monitoring. 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 integral part of an LXI device configuration capability. The current standard requires an HTTP web server to run that has no encryption at all. In addition to these two main topics, ping, mDNS, and LAN events are also topics that will need to be addressed by an upcoming advanced LXI Security feature.
The working group intends to go two different ways 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 web browser interface uses the public trust model, which is based on locally significant device identifiers (LDevIDs, X.509 certificates, 12 month lifetime) and is derived from the IDevID. However, the IP addresses and hostname of the LXI devices change during their lifetime, rendering 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 hostname to the new IP address and update the DNS settings. Once this is complete, secure web server access (https) is available. The revocation of these certificates is verified when the LXI device connects to the provisioning server.
This approach raises the question of the different scenarios that the group needs to consider because not all of the scenarios mentioned above have Internet access to connect to a provisioning server. Some options have been identified for the scenario without Internet access. One option would be to install the provisioning server within the local network to request new LDevIDs. This may require support from IT. Another option would be to use self-signed certificates where the certificate would need to be installed on both the LXI device and the test computer’s web browser.
The private trust model based on IDevIDs (IEEE802.1AR, unlimited lifetime) is used to remotely control measurement instruments. The required metadata such as the device ID model and manufacturer name are in the modified certificate format. HiSLIP 2.0 is also required to support secure communication with TLS, addressing identification, authorization, and encryption. HiSLIP 2.0 continues to use the IANA port 4880 and the current VISA resource string for backward compatibility, but new security levels need to be introduced. The working group has identified three levels.
First, it will be necessary to disable the security feature with HiSLIP for backward compatibility reasons. This is the case when a new device communicates with a client or VISA application that does not support HiSLIP 2.0. There are also other reasons. These include debugging network traffic or avoiding performance loss due to encryption. Second, there might be a mode that checks authentication. This could be useful in a trusted environment. Here, the device may start with a TLS connection, but after successful authentication, encryption can be disabled. Finally, a mode that requires encryption will be necessary. All devices must authenticate. If a device tries to communicate without encryption, the connection must be terminated after successful authentication.
Self-certification is a recurring theme in the LXI consortium as several leading companies want to certify their equipment themselves. This is already common with other standards. LXI’s policy so far is that a vendor must take its device to a certified test house to have it certified as an LXI-compliant device. Until now, this made sense because the current LXI test suite requires certain hardware for the tests. The LXI Test Suite software requires a certain amount of know-how in order to operate it. The consortium is confident to overcome these hurdles with the TSEP-Kerberos. This is a software and hardware solution that checks the LXI functionality of measurement and test equipment. It contains the necessary hardware and significantly reduces the LXI know-how required to certify a device. Most tests are fully automated, others partially automated with step-by-step instructions of the manual test sections.
However, the consortium does not want to give up complete control over the certification process. Therefore, it is required that a company has at least one device certified by an LXI test house. This is intended to protect the LXI standard in the future, as customers are accustomed to with LXI-compliant products. The concept of self-certification is to be adopted at the upcoming Meeting & PlugFest.
Author /editor: David Courtney / Hendrik Härter