LXI Network Security in Industrial Environments
undefined
L
X
I
S
e
c
u
r
i
t
y
O
v
e
r
v
i
e
w
F
e
b
r
u
a
r
y
2
0
1
9
Rev 1.91
A
g
e
n
d
a
•
Introduction & Overview Security Standards
•
LXI Communication Channels
•
Remote Control (HiSLIP)
•
Web Browser Interface
•
Encryption
•
PKI – Public Key Infrastructure
•
Certificates / Public & Private Keys / Encryption
•
Certificate Authorities (CAs)
•
Public Trust / Private Trust
•
LXI Security WG Proposals for Secure Communication
•
Questions & Feedback
I
n
t
r
o
d
u
c
t
i
o
n
–
L
X
I
S
e
c
u
r
i
t
y
•
Security is a critical attribute of industrial networks
•
Industry is giving a growing amount of attention to cybersecurity issues
•
LXI instruments are connected to company networks
•
This presentation gives a summary of the current state of the LXI
Security Working Group discussions and proposals for
–
Test Engineers setting up LXI based test systems
–
IT departments supervising the company network
•
We are soliciting feedback and proposals to make sure the LXI Security
WG covers all requirements
I
n
t
r
o
d
u
c
t
i
o
n
–
L
X
I
S
e
c
u
r
i
t
y
(
2
)
•
Levels of Risk Introduction
–
LXI instruments are connected to company networks
–
Depending on the test setup for the LXI instruments there are different levels of risk
introduction:
•
Benchtop (e.g. peer to peer connection) w/o connection to the company network
•
Test system setup with isolated subnet
•
Test system directly connected to company network
•
Test system with Internet connections (e.g. remote monitoring in the field)
Examples for test system configurations
E
x
a
m
p
l
e
•
Company XYZ using LXI
instruments from LXI
vendor A & B
•
LXI instruments
connected to the
company network
•
Test computer to control
LXI instruments
•
Test system developers
may have access too
I
m
p
o
r
t
a
n
c
e
o
f
N
e
t
w
o
r
k
S
e
c
u
r
i
t
y
•
Primary goals for security within industrial networks are:
–
C
o
n
f
i
d
e
n
t
i
a
l
i
t
y
:
D
a
t
a
t
r
a
n
s
p
o
r
t
e
d
i
n
t
h
e
n
e
t
w
o
r
k
c
a
n
n
o
t
b
e
r
e
a
d
b
y
a
n
y
o
n
e
b
u
t
t
h
e
i
n
t
e
n
d
e
d
r
e
c
i
p
i
e
n
t
–
I
n
t
e
g
r
i
t
y
:
A
n
y
m
e
s
s
a
g
e
r
e
c
e
i
v
e
d
i
s
c
o
n
f
i
r
m
e
d
t
o
b
e
e
x
a
c
t
l
y
t
h
e
m
e
s
s
a
g
e
t
h
a
t
w
a
s
s
e
n
t
,
w
/
o
a
d
d
i
t
i
o
n
s
,
d
e
l
e
t
i
o
n
s
o
r
m
o
d
i
f
i
c
a
t
i
o
n
s
o
f
t
h
e
c
o
n
t
e
n
t
–
A
u
t
h
e
n
t
i
c
i
t
y
:
A
m
e
s
s
a
g
e
t
h
a
t
c
l
a
i
m
s
t
o
b
e
f
r
o
m
a
g
i
v
e
n
s
o
u
r
c
e
i
s
,
i
n
f
a
c
t
,
f
r
o
m
t
h
a
t
s
o
u
r
c
e
.
A
u
t
h
o
r
i
z
a
t
i
o
n
i
s
a
n
o
t
h
e
r
i
m
p
o
r
t
a
n
t
a
s
p
e
c
t
-
b
o
t
h
,
a
u
t
h
e
n
t
i
c
a
t
i
o
n
a
n
d
a
u
t
h
o
r
i
z
a
t
i
o
n
r
e
q
u
i
r
e
a
s
t
r
o
n
g
d
e
v
i
c
e
i
d
e
n
t
i
t
y
O
v
e
r
v
i
e
w
I
n
d
u
s
t
r
i
a
l
S
e
c
u
r
i
t
y
S
t
a
n
d
a
r
d
s
•
Aerospace & Defense:
NIST:
Framework for Improving Critical Infrastructure Cybersecurity
NIST 800 SP Series
•
Industrial Automation & Control:
IEC 62443 standards (equivalent to ISA 99)
•
UL CAP: Underwriters Laboratories Cybersecurity Assurance Program
UL 2900 series of standards
•
IIC Industrial Internet Consortium:
Industrial Internet Security Framework IISF
•
OWASP:
Open Web Application Security Project – IoT:
Top Ten Application Risks
L
X
I
S
e
c
u
r
i
t
y
-
E
c
o
s
y
s
t
e
m
•
Areas:
–
IoT (Consumer Internet of Things)
–
IIoT (Industrial Internet of Things)
–
IT (Information Technology)
•
There are commonalities which LXI
instruments share with IoT, IIoT, IT
•
Observed commonalities:
–
Device security
–
Data security
–
Network security
•
Key principles: C.I.A.
–
Confidentiality
–
Integrity
–
Authenticity
L
X
I
C
o
m
m
u
n
i
c
a
t
i
o
n
C
h
a
n
n
e
l
s
Currently we use within LXI the following communication channels
•
Remote Control
–
SCPI based
–
TCP/IP: Socket / VXI-11 / HiSLIP
•
Web Browser Interface
–
HTTP
•
Ping, mDNS
•
To ensure secure communication between test computers and LXI
instruments encryption is required
–
TLS encryption
–
HTTPS (HTTP + TLS)
T
L
S
–
T
r
a
n
s
p
o
r
t
L
a
y
e
r
S
e
c
u
r
i
t
y
•
T
r
a
n
s
p
o
r
t
L
a
y
e
r
S
e
c
u
r
i
t
y
(
T
L
S
)
i
s
a
p
r
o
t
o
c
o
l
t
h
a
t
p
r
o
v
i
d
e
s
p
r
i
v
a
c
y
a
n
d
d
a
t
a
i
n
t
e
g
r
i
t
y
b
e
t
w
e
e
n
t
w
o
c
o
m
m
u
n
i
c
a
t
i
n
g
a
p
p
l
i
c
a
t
i
o
n
s
.
I
t
'
s
t
h
e
m
o
s
t
w
i
d
e
l
y
d
e
p
l
o
y
e
d
s
e
c
u
r
i
t
y
p
r
o
t
o
c
o
l
u
s
e
d
t
o
d
a
y
,
a
n
d
i
s
u
s
e
d
f
o
r
W
e
b
b
r
o
w
s
e
r
s
a
n
d
o
t
h
e
r
a
p
p
l
i
c
a
t
i
o
n
s
t
h
a
t
r
e
q
u
i
r
e
d
a
t
a
t
o
b
e
s
e
c
u
r
e
l
y
e
x
c
h
a
n
g
e
d
o
v
e
r
a
n
e
t
w
o
r
k
,
s
u
c
h
a
s
f
i
l
e
t
r
a
n
s
f
e
r
s
,
V
P
N
c
o
n
n
e
c
t
i
o
n
s
,
i
n
s
t
a
n
t
m
e
s
s
a
g
i
n
g
a
n
d
v
o
i
c
e
o
v
e
r
I
P
.
T
L
S
–
T
r
a
n
s
p
o
r
t
L
a
y
e
r
S
e
c
u
r
i
t
y
•
TLS evolved from the Secure Sockets Layer (SSL) protocol and has
largely superseded it. Key differences between SSL and TLS that make
TLS a more secure and efficient protocol are message authentication,
key material generation and the supported cipher suites, with TLS
supporting newer and more secure algorithms.
•
TLS is composed of two layers:
–
TLS Record Protocol
–
TLS Handshake Protocol
•
The Record Protocol provides connection security, while the
Handshake Protocol allows the server and client to authenticate each
other and to negotiate encryption algorithms and cryptographic keys
before any data is exchanged.
P
K
I
–
P
u
b
l
i
c
K
e
y
I
n
f
r
a
s
t
r
u
c
t
u
r
e
•
I
n
t
h
e
P
u
b
l
i
c
K
e
y
I
n
f
r
a
s
t
r
u
c
t
u
r
e
(
P
K
I
)
,
d
i
g
i
t
a
l
c
e
r
t
i
f
i
c
a
t
e
s
a
r
e
b
a
s
e
d
o
n
p
u
b
l
i
c
k
e
y
c
r
y
p
t
o
g
r
a
p
h
y
.
T
h
e
P
K
I
c
o
n
s
i
s
t
s
o
f
a
s
e
t
o
f
c
o
m
p
o
n
e
n
t
s
,
p
o
l
i
c
i
e
s
,
p
r
o
t
o
c
o
l
s
,
a
n
d
t
e
c
h
n
o
l
o
g
i
e
s
t
h
a
t
p
r
o
v
i
d
e
d
a
t
a
a
u
t
h
e
n
t
i
c
a
t
i
o
n
,
i
n
t
e
g
r
i
t
y
,
a
n
d
c
o
n
f
i
d
e
n
t
i
a
l
i
t
y
t
h
r
o
u
g
h
t
h
e
u
s
e
o
f
c
e
r
t
i
f
i
c
a
t
e
s
,
a
n
d
p
u
b
l
i
c
a
n
d
p
r
i
v
a
t
e
k
e
y
s
.
•
Data is protected by applying a hashing algorithm and signature
algorithm to the original message. A hashing algorithm is an intricate
mathematical algorithm which is applied to the message.
•
W
i
t
h
p
u
b
l
i
c
k
e
y
c
r
y
p
t
o
g
r
a
p
h
y
,
t
h
e
k
e
y
t
h
a
t
e
n
c
r
y
p
t
s
d
a
t
a
i
s
c
a
l
l
e
d
a
p
u
b
l
i
c
k
e
y
.
T
h
e
k
e
y
t
h
a
t
i
s
u
s
e
d
t
o
d
e
c
r
y
p
t
d
a
t
a
i
s
c
a
l
l
e
d
t
h
e
p
r
i
v
a
t
e
k
e
y
.
W
h
i
l
e
t
h
e
p
u
b
l
i
c
k
e
y
c
a
n
b
e
p
u
b
l
i
c
l
y
d
i
s
t
r
i
b
u
t
e
d
,
t
h
e
p
r
i
v
a
t
e
k
e
y
i
s
k
e
p
t
s
e
c
u
r
e
.
C
e
r
t
i
f
i
c
a
t
e
s
•
D
i
g
i
t
a
l
c
e
r
t
i
f
i
c
a
t
e
s
:
C
e
r
t
i
f
i
c
a
t
e
s
a
r
e
t
h
e
f
o
u
n
d
a
t
i
o
n
o
f
t
h
e
P
K
I
.
T
h
e
c
e
r
t
i
f
i
c
a
t
e
c
o
n
t
a
i
n
s
t
h
e
p
u
b
l
i
c
k
e
y
o
f
t
h
e
u
s
e
r
.
T
h
e
p
u
b
l
i
c
k
e
y
c
a
n
b
e
u
s
e
d
t
o
e
n
c
r
y
p
t
a
n
d
s
i
g
n
d
a
t
a
b
e
f
o
r
e
i
t
i
s
t
r
a
n
s
m
i
t
t
e
d
o
v
e
r
t
h
e
n
e
t
w
o
r
k
.
T
h
e
d
i
g
i
t
a
l
c
e
r
t
i
f
i
c
a
t
e
c
o
n
t
a
i
n
s
i
n
f
o
r
m
a
t
i
o
n
s
u
c
h
a
s
t
h
e
c
e
r
t
i
f
i
c
a
t
e
v
e
r
s
i
o
n
,
s
e
r
i
a
l
n
u
m
b
e
r
,
s
i
g
n
a
t
u
r
e
,
i
s
s
u
e
r
,
a
n
d
v
a
l
i
d
i
t
y
p
e
r
i
o
d
,
a
m
o
n
g
o
t
h
e
r
i
n
f
o
r
m
a
t
i
o
n
.
C
e
r
t
i
f
i
c
a
t
e
A
u
t
h
o
r
i
t
i
e
s
(
C
A
s
)
•
C
e
r
t
i
f
i
c
a
t
i
o
n
A
u
t
h
o
r
i
t
i
e
s
(
C
A
s
)
:
A
C
e
r
t
i
f
i
c
a
t
e
A
u
t
h
o
r
i
t
y
(
C
A
)
i
s
a
t
r
u
s
t
e
d
e
n
t
i
t
y
t
h
a
t
g
e
n
e
r
a
t
e
s
a
n
d
v
a
l
i
d
a
t
e
s
d
i
g
i
t
a
l
c
e
r
t
i
f
i
c
a
t
e
s
t
o
u
s
e
r
s
,
c
o
m
p
u
t
e
r
s
,
a
p
p
l
i
c
a
t
i
o
n
s
,
a
n
d
s
e
r
v
i
c
e
s
.
T
h
e
C
A
a
d
d
s
i
t
s
o
w
n
s
i
g
n
a
t
u
r
e
t
o
t
h
e
p
u
b
l
i
c
k
e
y
o
f
t
h
e
c
l
i
e
n
t
.
T
h
i
s
e
s
s
e
n
t
i
a
l
l
y
i
n
d
i
c
a
t
e
s
t
h
a
t
t
h
e
p
u
b
l
i
c
k
e
y
c
a
n
b
e
c
o
n
s
i
d
e
r
e
d
v
a
l
i
d
,
b
y
t
h
o
s
e
p
a
r
t
i
e
s
t
h
a
t
t
r
u
s
t
t
h
e
C
A
.
•
CAs can be setup in a hierarchical structure, and define a CA trust
model. In the CA hierarchy, you would define root CAs, intermediate
CAs and leaf CAs. Users that trust the root CA would automatically
trust all subordinate CAs beneath the root CA, which received
certificates from the particular root CA.
A
u
t
h
e
n
t
i
c
a
t
i
o
n
&
E
n
c
r
y
p
t
i
o
n
•
Client – Server Authentication
–
Client verifies server identify via certificate
•
Exchanging keys for encryption
T
L
S
–
S
e
c
u
r
e
C
o
m
m
u
n
i
c
a
t
i
o
n
Client issues secure session request
Client authenticates certificate against list of known CAs
Client generates random symmetric key and
encrypts it using the server’s public key
Client and server now both know the symmetric key and
encrypt data using this key for duration of session
Server sends certificate containing
server’s public key
T
L
S
E
n
c
r
y
p
t
i
o
n
u
s
i
n
g
P
K
I
•
In order to prevent man-in-the-middle attacks, the public keys
exchanged in the TLS handshake must be
certified
•
Usually, this is achieved by using X.509 certificates (SSL certificates)
where 3rd party trust authorities (CAs) cryptographically bind
identities
to
public keys
X
.
5
0
9
C
e
r
t
i
f
i
c
a
t
e
s
•
In TLS with X.509 certificates, the communication peer is identified via
its DNS name (e.g. oscilloscope3.company-net.com) and/or its IP
address (e.g. 192.168.0.4).
•
For LXI devices, the IP address can change if the device is connected
to a different network.
This requires an update of the DNS entries.
A
u
t
h
o
r
i
z
a
t
i
o
n
•
Encryption of the communication channel is only the first step.
•
Users authorized for using SCPI remote commands must identify
themselves by providing a username and password or other
authentication mechanisms.
I
E
E
E
8
0
2
.
1
A
R
S
e
c
u
r
e
D
e
v
i
c
e
I
d
e
n
t
i
t
y
•
IEEE 802.1AR provides cryptographically bound, unique identifiers for
devices (DevIDs), which are composed of a secure device identifier
secret and a secure device identifier credential.
•
This standard uses options provided by X.509 specifications.
•
I
E
E
E
8
0
2
.
1
A
R
a
d
d
r
e
s
s
e
s
t
h
e
m
a
n
a
g
e
m
e
n
t
a
n
d
u
s
e
o
f
a
s
i
n
g
l
e
I
D
e
v
I
D
(
I
D
e
v
I
D
,
a
n
I
n
i
t
i
a
l
D
e
v
i
c
e
I
d
e
n
t
i
f
i
e
r
)
a
n
d
m
u
l
t
i
p
l
e
L
D
e
v
I
D
s
c
e
r
t
i
f
i
c
a
t
e
s
(
L
D
e
v
I
D
,
a
s
u
b
s
e
q
u
e
n
t
L
o
c
a
l
l
y
S
i
g
n
i
f
i
c
a
n
t
D
e
v
i
c
e
I
d
e
n
t
i
f
i
e
r
d
e
r
i
v
e
d
f
r
o
m
t
h
e
I
D
e
v
I
D
)
.
•
LDevIDs are bound to the IDevID in a way that makes it impossible for
them to be transferred to a device with a different IDevID without
knowledge of the private key used to effect the cryptographic binding.
I
E
E
E
8
0
2
.
1
A
R
–
L
X
I
A
d
o
p
t
i
o
n
•
DevIDs can be controlled by the vendor of the LXI device (IDevID) during
the manufacturing process or by the end-user (LDevIDs) via a
provisioning server.
•
The IDevID certificate is also known as the “birth certificate” - used to
identify the LXI device (serial #, model, vendor). This is typically the first
certificate on the LXI device and generated during manufacturing.
•
LDevIDs can incorporate, and fully protect, additional information like
hostname and IP address of the LXI device for the DNS entries.
•
Both, IDevIDs and LDevIDs are X.509 based certificates.
•
IDevIDs are based on private root (“LXI Root CA”), LDevIDs are based on
public root (Public CA).
C
e
r
t
i
f
i
c
a
t
e
s
f
o
r
L
X
I
D
e
v
i
c
e
s
•
Certs used for Remote Control (SCPI):
–
IDevID (“LXI Root CA”) certificates with identity attributes such as:
Serial Number, Product Family, LXI Vendor
,
LXIDeviceDomain
–
Standardized by LXI Consortium
–
Root of Trust: Root CA - LXI Device Vendor - Instrument
–
Deployment: Installation by LXI vendor (factory)
–
“Infinite” lifetime
•
Certs for Web Browser Interface:
–
LDevID (X.509 certificate) derived from the IDevID of the LXI device
–
Problem: IP address of the LXI device may change
–
Solution: Update the DNS entries (IP address) via provisioning
server
P
r
i
v
a
t
e
T
r
u
s
t
:
S
e
c
u
r
e
C
o
m
m
u
n
i
c
a
t
i
o
n
s
Optional: Private Vendor ICA for companies that require one
•
Cert format
based on
IEEE802.1AR / X.509
•
IDevID
•
Cert validity unlimited
•
Metadata included in cert:
Device serial #, Model, Vendor
P
r
i
v
a
t
e
/
P
u
b
l
i
c
T
r
u
s
t
P
u
b
l
i
c
T
r
u
s
t
:
S
e
c
u
r
e
W
e
b
S
e
r
v
e
r
s
•
Cert format X.509
•
LDevID
•
Maximum cert validity: 12 month
L
X
I
S
e
c
u
r
i
t
y
W
G
P
r
o
p
o
s
a
l
s
•
Remote Control (SCPI):
–
Private trust model based on IDevIDs (LXI certs)
–
HiSLIP 2.0 which supports secure communication with TLS
–
Allows identification, authorization and encryption
•
Web Browser Interface
–
Public trust model based on LDevIDs (X.509 certs)
–
Whenever the LXI device needs a LDevID for secure web server access
(either nor present as in the initial state or the current LDevID is expired or
revoked) it gets a new LDevID from the provisioning server
–
Whenever the LXI device gets a new IP address it has to assign and re-
configure the host name (FQDN) to the new IP address and update the
DNS entries via the provisioning server
–
Allows secure web server access
R
e
m
o
t
e
C
o
n
t
r
o
l
w
i
t
h
H
i
S
L
I
P
2
.
0
•
HiSLIP 2.0 supports secure communication with TLS 1.2
(and future protocol versions e.g. TLS 1.3)
•
HiSLIP 2.0 uses still IANA port 4880
•
Still using VISA resource string “tcpip::<hostname>::hislip<server>” to
meet compatibility
•
Introduce new security levels configured on the LXI device:
H
i
S
L
I
P
S
e
c
u
r
i
t
y
L
e
v
e
l
s
P
e
r
m
i
s
s
i
v
e
On level “Permissive” (Encryption is optional, client authentication is not
required) the instrument supports both HiSLIP 1.0 and HiSLIP 2.0 clients
and doesn’t require a TLS connection.
The user of the instrument may choose this mode for the following
reasons:
•
The client application or VISA application does not support HiSLIP 2.0.
•
The user wants to inspect/debug the connection traffic with tools e.g.
Wireshark
•
The user wants to avoid performance loss by encryption
•
By switching off encryption the user may accept the vulnerability of
man-in-the-middle attacks
•
A client can switch off encryption after successful authentication by
VI_ATTR_HISLIP_SECURITY=(NONE, ENCRYPTED)
H
i
S
L
I
P
S
e
c
u
r
i
t
y
L
e
v
e
l
s
S
e
r
v
e
r
A
u
t
h
e
n
t
i
c
a
t
i
o
n
O
n
l
y
In this level the encryption is mandatory, client authentication is not
required. The purpose of this is to authenticate the server, encrypt the
connection when any client is allowed to access.
The instrument only accepts HiSLIP connections with protocol
versions >= V 2.0.
•
Version negotiation (< 2.0) with legacy VISA client is blocked
•
VISA client and instrument always use a TLS connection
•
This level is implemented with an anonymous authentication
H
i
S
L
I
P
S
e
c
u
r
i
t
y
L
e
v
e
l
s
M
u
t
u
a
l
A
u
t
h
e
n
t
i
c
a
t
i
o
n
The owner of the device may choose this mode within an untrustworthy
environment:
•
Authentication of the server is required
•
Only authorized clients are allowed to connect
•
Only encrypted conversation is allowed
•
Clients are not allowed to switch off encryption
This level is available for peer-to-peer secure communication between LXI
devices
H
i
S
L
I
P
A
u
t
h
e
n
t
i
c
a
t
i
o
n
C
r
e
d
e
n
t
i
a
l
M
a
n
a
g
e
m
e
n
t
•
Authentication Mechanisms supported:
–
ANONYMOUS
–
GSSAPI (Kerberos)
–
NTLM (Windows Login)
–
PLAIN (Username/Password)
•
VISA Security Extensions
–
New security attributes
–
Credential management from OS
W
e
b
B
r
o
w
s
e
r
I
n
t
e
r
f
a
c
e
S
e
c
u
r
e
W
e
b
B
r
o
w
s
e
r
I
n
t
e
r
f
a
c
e
•
Secure web server access is based on HTTPS connections
•
Public trust model – LDevIDs (X.509 certs)
•
Whenever the LXI device needs a LDevID for secure web browser
access (either nor present as in the initial state or the current LDevID is
expired or revoked) it requests a LDevID via the provisioning server
(Internet access required)
•
Whenever the LXI device gets a new IP address it has to assign and
re-configure the host name (FQDN) to the new IP address and update
the DNS entries via the provisioning server (Internet access required)
X
.
5
0
9
P
r
o
v
i
s
i
o
n
i
n
g
S
e
r
v
e
r
I
D
e
v
I
D
I
D
e
v
I
D
S
e
c
u
r
e
W
e
b
B
r
o
w
s
e
r
C
o
n
n
e
c
t
i
o
n
(
1
)
P
r
e
-
r
e
q
u
i
s
i
t
e
s
:
•
LXI Vendor:
IDevID (LXI Cert) installed on the LXI device
•
Customer/User:
Proxy settings for company network
Internet access
S
e
c
u
r
e
W
e
b
B
r
o
w
s
e
r
C
o
n
n
e
c
t
i
o
n
(
2
)
S
e
q
u
e
n
c
e
(
S
t
e
p
1
)
:
•
LXI device:
–
Generate RSA key
–
Request X.509 certificate for the new key via company proxy server –
Internet from the Provisioning Server using the IDevID (LXI Cert) for
authentication/authorization
–
Communication to Provisioning Server encrypted (TLS) using the IDevID
(LXI Cert)
•
Provisioning server:
–
Authorize request from LXI device based on IDevID (LXI Cert)
–
Communication to LXI device encrypted
–
Provide signed LDevID (X.509 certificate) to LXI device
X
.
5
0
9
P
r
o
v
i
s
i
o
n
i
n
g
S
e
r
v
e
r
I
D
e
v
I
D
R
e
q
u
e
s
t
L
D
e
v
I
D
(
X
.
5
0
9
C
e
r
t
)
I
D
e
v
I
D
X
.
5
0
9
P
r
o
v
i
s
i
o
n
i
n
g
S
e
r
v
e
r
I
D
e
v
I
D
S
e
n
d
L
D
e
v
I
D
(
X
.
5
0
9
C
e
r
t
)
I
D
e
v
I
D
S
e
c
u
r
e
W
e
b
B
r
o
w
s
e
r
C
o
n
n
e
c
t
i
o
n
(
3
)
S
e
q
u
e
n
c
e
(
S
t
e
p
2
)
:
•
LXI device:
–
Store signed LDevID (X.509 certificate) and install it on internal web server
–
Update DNS entries: Hostname (FQDN) and new IP address
S
e
q
u
e
n
c
e
(
S
t
e
p
3
)
:
•
Test computer:
–
Connect to LXI device via web browser (using host name)
–
Request https connection / encryption
•
LXI device:
–
Setup encrypted (https) web server connection to test computer
S
c
r
e
e
n
s
h
o
t
s
I
P
A
d
d
r
e
s
s
C
h
a
n
g
e
I
P
A
d
d
r
e
s
s
c
h
a
n
g
e
:
•
Whenever the LXI device gets a new IP address it has to assign and
re-configure the host name (FQDN) to the new IP address and update
the DNS entries via the provisioning server (Internet access required)
D
N
S
S
e
t
t
i
n
g
s
&
R
e
v
o
c
a
t
i
o
n
C
h
e
c
k
D
N
S
s
e
t
t
i
n
g
s
:
•
H
o
s
t
n
a
m
e
(
F
Q
D
N
)
i
s
a
L
X
I
v
e
n
d
o
r
s
p
e
c
i
f
i
c
c
u
s
t
o
m
d
o
m
a
i
n
n
a
m
e
(
D
e
v
i
c
e
s
e
r
i
a
l
#
,
m
o
d
e
l
,
v
e
n
d
o
r
,
L
X
I
D
e
v
i
c
e
D
o
m
a
i
n
)
“
L
X
I
D
e
v
i
c
e
D
o
m
a
i
n
”
i
s
c
o
m
m
o
n
t
o
a
l
l
L
X
I
d
e
v
i
c
e
s
:
l
x
i
d
e
v
i
c
e
s
.
o
r
g
R
e
v
o
c
a
t
i
o
n
/
R
e
n
e
w
a
l
C
h
e
c
k
s
:
•
IDevID revocation will be checked each time the LXI device connects to
the provisioning server (OCSP)
•
LDevID revocation will be checked by the web browser based on web
browser policy
L
o
c
a
l
N
e
t
w
o
r
k
w
/
o
I
n
t
e
r
n
e
t
A
c
c
e
s
s
C
e
r
t
i
f
i
c
a
t
e
s
i
s
s
u
e
d
b
y
c
o
m
p
a
n
y
i
n
t
e
r
n
a
l
C
A
(
p
r
i
v
a
t
e
r
o
o
t
)
:
•
Certificate is issued by customer PKI
•
Install the certificate on the LXI device(s):
Certificate (plus private key) is uploaded to the LXI device (REST,
SCEP (Simple Certificate Enrollment Protocol) or CMP (Certificate
Management Protocol) and user authentication/authorization)
•
Install the root CA certificate on client systems (web browser(s) of the
test computer)
S
e
l
f
-
s
i
g
n
e
d
c
e
r
t
i
f
i
c
a
t
e
s
:
•
LXI Device creates self-signed certificate on demand
•
Download certificate from device and install it manually in web
browser(s) of the test computer
L
X
I
S
e
c
u
r
i
t
y
–
Q
u
e
s
t
i
o
n
s
We are soliciting feedback and proposals to make sure the LXI
Security WG covers all requirements
S
e
n
d
y
o
u
c
o
m
m
e
n
t
s
a
n
d
q
u
e
s
t
i
o
n
s
t
o
t
h
e
f
o
l
l
o
w
i
n
g
e
m
a
i
l
a
d
d
r
e
s
s
:
L
X
I
S
e
c
u
r
i
t
y
W
G
LXI Security Overview provides insights into the critical attribute of security in industrial networks, focusing on LXI instruments connected to company networks. The presentation covers security standards, communication channels, encryption, PKI, certificates, and proposals for secure communication. It emphasizes the importance of network security in ensuring confidentiality, integrity, authenticity, and authorization within industrial setups.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
LXI Security Overview February 2019 Rev 1.91 www.lxistandard.org Use the connection you already know!
Agenda Introduction & Overview Security Standards LXI Communication Channels Remote Control (HiSLIP) Web Browser Interface Encryption PKI Public Key Infrastructure Certificates / Public & Private Keys / Encryption Certificate Authorities (CAs) Public Trust / Private Trust LXI Security WG Proposals for Secure Communication Questions & Feedback www.lxistandard.org Use the connection you already know!
Introduction LXI Security Security is a critical attribute of industrial networks Industry is giving a growing amount of attention to cybersecurity issues LXI instruments are connected to company networks This presentation gives a summary of the current state of the LXI Security Working Group discussions and proposals for Test Engineers setting up LXI based test systems IT departments supervising the company network We are soliciting feedback and proposals to make sure the LXI Security WG covers all requirements www.lxistandard.org Use the connection you already know!
Introduction LXI Security (2) Levels of Risk Introduction LXI instruments are connected to company networks Depending on the test setup for the LXI instruments there are different levels of risk introduction: Benchtop (e.g. peer to peer connection) w/o connection to the company network Test system setup with isolated subnet Test system directly connected to company network Test system with Internet connections (e.g. remote monitoring in the field) Examples for test system configurations www.lxistandard.org Use the connection you already know!
Example Company XYZ using LXI instruments from LXI vendor A & B Company XYZ LXI instruments connected to the company network Vendor A Test computer to control LXI instruments Vendor B Test system developers may have access too www.lxistandard.org Use the connection you already know!
Importance of Network Security Primary goals for security within industrial networks are: Confidentiality: Data transported in the network cannot be read by anyone but the intended recipient Integrity: Any message received is confirmed to be exactly the message that was sent, w/o additions, deletions or modifications of the content Authenticity: A message that claims to be from a given source is, in fact, from that source. Authorization is another important aspect - both, authentication and authorization require a strong device identity www.lxistandard.org Use the connection you already know!
Overview Industrial Security Standards Aerospace & Defense: NIST: Framework for Improving Critical Infrastructure Cybersecurity NIST 800 SP Series Industrial Automation & Control: IEC 62443 standards (equivalent to ISA 99) UL CAP: Underwriters Laboratories Cybersecurity Assurance Program UL 2900 series of standards IIC Industrial Internet Consortium: Industrial Internet Security Framework IISF OWASP: Open Web Application Security Project IoT: Top Ten Application Risks www.lxistandard.org Use the connection you already know!
LXI Security - Ecosystem Areas: IoT (Consumer Internet of Things) IIoT (Industrial Internet of Things) IT (Information Technology) There are commonalities which LXI instruments share with IoT, IIoT, IT Key principles: C.I.A. Confidentiality Integrity Authenticity Observed commonalities: Device security Data security Network security www.lxistandard.org Use the connection you already know!
LXI Communication Channels Currently we use within LXI the following communication channels Remote Control SCPI based TCP/IP: Socket / VXI-11 / HiSLIP Web Browser Interface HTTP Ping, mDNS To ensure secure communication between test computers and LXI instruments encryption is required TLS encryption HTTPS (HTTP + TLS) www.lxistandard.org Use the connection you already know!
TLS Transport Layer Security Transport Layer Security (TLS) is a protocol that provides privacy and data integrity between two communicating applications. It's the most widely deployed security protocol used today, and is used for Web browsers and other applications that require data to be securely exchanged over a network, such as file transfers, VPN connections, instant messaging and voice over IP. www.lxistandard.org Use the connection you already know!
TLS Transport Layer Security TLS evolved from the Secure Sockets Layer (SSL) protocol and has largely superseded it. Key differences between SSL and TLS that make TLS a more secure and efficient protocol are message authentication, key material generation and the supported cipher suites, with TLS supporting newer and more secure algorithms. TLS is composed of two layers: TLS Record Protocol TLS Handshake Protocol The Record Protocol provides connection security, while the Handshake Protocol allows the server and client to authenticate each other and to negotiate encryption algorithms and cryptographic keys before any data is exchanged. www.lxistandard.org Use the connection you already know!
PKI Public Key Infrastructure In the Public Key Infrastructure (PKI), digital certificates are based on public key cryptography. The PKI consists of a set of components, policies, protocols, and technologies that provide data authentication, integrity, and confidentiality through the use of certificates, and public and private keys. Data is protected by applying a hashing algorithm and signature algorithm to the original message. A hashing algorithm is an intricate mathematical algorithm which is applied to the message. With public key cryptography, the key that encrypts data is called a public key. The key that is used to decrypt data is called the private key. While the public key can be publicly distributed, the private key is kept secure. www.lxistandard.org Use the connection you already know!
Certificates Digital certificates: Certificates are the foundation of the PKI. The certificate contains the public key of the user. The public key can be used to encrypt and sign data before it is transmitted over the network. The digital certificate contains information such as the certificate version, serial number, signature, issuer, and validity period, among other information. www.lxistandard.org Use the connection you already know!
Certificate Authorities (CAs) Certification Authorities (CAs): A Certificate Authority (CA) is a trusted entity that generates and validates digital certificates to users, computers, applications, and services. The CA adds its own signature to the public key of the client. This essentially indicates that the public key can be considered valid, by those parties that trust the CA. CAs can be setup in a hierarchical structure, and define a CA trust model. In the CA hierarchy, you would define root CAs, intermediate CAs and leaf CAs. Users that trust the root CA would automatically trust all subordinate CAs beneath the root CA, which received certificates from the particular root CA. www.lxistandard.org Use the connection you already know!
Authentication & Encryption Client Server Authentication Client verifies server identify via certificate Exchanging keys for encryption www.lxistandard.org Use the connection you already know!
TLS Secure Communication Client issues secure session request Server sends certificate containing server s public key Client authenticates certificate against list of known CAs Client generates random symmetric key and encrypts it using the server s public key Client and server now both know the symmetric key and encrypt data using this key for duration of session www.lxistandard.org Use the connection you already know!
TLS Encryption using PKI In order to prevent man-in-the-middle attacks, the public keys exchanged in the TLS handshake must be certified Usually, this is achieved by using X.509 certificates (SSL certificates) where 3rd party trust authorities (CAs) cryptographically bind identities to public keys www.lxistandard.org Use the connection you already know!
X.509 Certificates In TLS with X.509 certificates, the communication peer is identified via its DNS name (e.g. oscilloscope3.company-net.com) and/or its IP address (e.g. 192.168.0.4). For LXI devices, the IP address can change if the device is connected to a different network. This requires an update of the DNS entries. www.lxistandard.org Use the connection you already know!
Authorization Encryption of the communication channel is only the first step. Users authorized for using SCPI remote commands must identify themselves by providing a username and password or other authentication mechanisms. www.lxistandard.org Use the connection you already know!
IEEE 802.1AR Secure Device Identity IEEE 802.1AR provides cryptographically bound, unique identifiers for devices (DevIDs), which are composed of a secure device identifier secret and a secure device identifier credential. This standard uses options provided by X.509 specifications. IEEE802.1AR addresses the management and use of a single IDevID (IDevID, an Initial Device Identifier) and multiple LDevIDs certificates (LDevID, a subsequent Locally Significant Device Identifier derived from the IDevID). LDevIDs are bound to the IDevID in a way that makes it impossible for them to be transferred to a device with a different IDevID without knowledge of the private key used to effect the cryptographic binding. www.lxistandard.org Use the connection you already know!
IEEE 802.1AR LXI Adoption DevIDs can be controlled by the vendor of the LXI device (IDevID) during the manufacturing process or by the end-user (LDevIDs) via a provisioning server. The IDevID certificate is also known as the birth certificate - used to identify the LXI device (serial #, model, vendor). This is typically the first certificate on the LXI device and generated during manufacturing. LDevIDs can incorporate, and fully protect, additional information like hostname and IP address of the LXI device for the DNS entries. Both, IDevIDs and LDevIDs are X.509 based certificates. IDevIDs are based on private root ( LXI Root CA ), LDevIDs are based on public root (Public CA). www.lxistandard.org Use the connection you already know!
Certificates for LXI Devices Certs used for Remote Control (SCPI): IDevID ( LXI Root CA ) certificates with identity attributes such as: Serial Number, Product Family, LXI Vendor, LXIDeviceDomain Standardized by LXI Consortium Root of Trust: Root CA - LXI Device Vendor - Instrument Deployment: Installation by LXI vendor (factory) Infinite lifetime Certs for Web Browser Interface: LDevID (X.509 certificate) derived from the IDevID of the LXI device Problem: IP address of the LXI device may change Solution: Update the DNS entries (IP address) via provisioning server www.lxistandard.org Use the connection you already know!
Private / Public Trust Public Trust: Secure Web Servers Private Trust: Secure Communications LXI Root CA Public Root CA LXI Intermediate CA Provisioning Server ICA LXI Vendor CA(s) LXI IDevID Cert Vendor IDevID Cert LXI LDevID Cert Optional: Private Vendor ICA for companies that require one Cert format based on IEEE802.1AR / X.509 IDevID Cert validity unlimited Metadata included in cert: Device serial #, Model, Vendor Cert format X.509 LDevID Maximum cert validity: 12 month www.lxistandard.org Use the connection you already know!
LXI Security WG Proposals Remote Control (SCPI): Private trust model based on IDevIDs (LXI certs) HiSLIP 2.0 which supports secure communication with TLS Allows identification, authorization and encryption Web Browser Interface Public trust model based on LDevIDs (X.509 certs) Whenever the LXI device needs a LDevID for secure web server access (either nor present as in the initial state or the current LDevID is expired or revoked) it gets a new LDevID from the provisioning server Whenever the LXI device gets a new IP address it has to assign and re- configure the host name (FQDN) to the new IP address and update the DNS entries via the provisioning server Allows secure web server access www.lxistandard.org Use the connection you already know!
Remote Control with HiSLIP 2.0 HiSLIP 2.0 supports secure communication with TLS 1.2 (and future protocol versions e.g. TLS 1.3) HiSLIP 2.0 uses still IANA port 4880 Still using VISA resource string tcpip::<hostname>::hislip<server> to meet compatibility Introduce new security levels configured on the LXI device: Encryption (implies server authentication) Optional Not supported Permissive, allows fallback to HiSLIP 1 Mandatory Mutual authentication Not authenticated secure connection On Off Client authentication required www.lxistandard.org Use the connection you already know!
HiSLIP Security Levels Permissive On level Permissive (Encryption is optional, client authentication is not required) the instrument supports both HiSLIP 1.0 and HiSLIP 2.0 clients and doesn t require a TLS connection. The user of the instrument may choose this mode for the following reasons: The client application or VISA application does not support HiSLIP 2.0. The user wants to inspect/debug the connection traffic with tools e.g. Wireshark The user wants to avoid performance loss by encryption By switching off encryption the user may accept the vulnerability of man-in-the-middle attacks A client can switch off encryption after successful authentication by VI_ATTR_HISLIP_SECURITY=(NONE, ENCRYPTED) www.lxistandard.org Use the connection you already know!
HiSLIP Security Levels Server Authentication Only In this level the encryption is mandatory, client authentication is not required. The purpose of this is to authenticate the server, encrypt the connection when any client is allowed to access. The instrument only accepts HiSLIP connections with protocol versions >= V 2.0. Version negotiation (< 2.0) with legacy VISA client is blocked VISA client and instrument always use a TLS connection This level is implemented with an anonymous authentication www.lxistandard.org Use the connection you already know!
HiSLIP Security Levels Mutual Authentication The owner of the device may choose this mode within an untrustworthy environment: Authentication of the server is required Only authorized clients are allowed to connect Only encrypted conversation is allowed Clients are not allowed to switch off encryption This level is available for peer-to-peer secure communication between LXI devices www.lxistandard.org Use the connection you already know!
HiSLIP Authentication Credential Management Authentication Mechanisms supported: ANONYMOUS GSSAPI (Kerberos) NTLM (Windows Login) PLAIN (Username/Password) VISA Security Extensions New security attributes Credential management from OS www.lxistandard.org Use the connection you already know!
Web Browser Interface Secure Web Browser Interface Secure web server access is based on HTTPS connections Public trust model LDevIDs (X.509 certs) Whenever the LXI device needs a LDevID for secure web browser access (either nor present as in the initial state or the current LDevID is expired or revoked) it requests a LDevID via the provisioning server (Internet access required) Whenever the LXI device gets a new IP address it has to assign and re-configure the host name (FQDN) to the new IP address and update the DNS entries via the provisioning server (Internet access required) www.lxistandard.org Use the connection you already know!
X.509 Provisioning Server Company Network Proxy Server Company Firewall X.509 Certificate (LDevIDs) Provisioning Server IDevID IDevID www.lxistandard.org Use the connection you already know!
Secure Web Browser Connection (1) Pre-requisites: LXI Vendor: IDevID (LXI Cert) installed on the LXI device Customer/User: Proxy settings for company network Internet access www.lxistandard.org Use the connection you already know!
Secure Web Browser Connection (2) Sequence (Step 1): LXI device: Generate RSA key Request X.509 certificate for the new key via company proxy server Internet from the Provisioning Server using the IDevID (LXI Cert) for authentication/authorization Communication to Provisioning Server encrypted (TLS) using the IDevID (LXI Cert) Provisioning server: Authorize request from LXI device based on IDevID (LXI Cert) Communication to LXI device encrypted Provide signed LDevID (X.509 certificate) to LXI device www.lxistandard.org Use the connection you already know!
X.509 Provisioning Server Company Network Proxy Server Company Firewall Request LDevID (X.509 Cert) LDevID (X.509 Certificate) Provisioning Server IDevID IDevID www.lxistandard.org Use the connection you already know!
X.509 Provisioning Server Company Network Proxy Server Company Firewall Send LDevID (X.509 Cert) LDevID (X.509 Certificate) Provisioning Server IDevID IDevID www.lxistandard.org Use the connection you already know!
Secure Web Browser Connection (3) Sequence (Step 2): LXI device: Store signed LDevID (X.509 certificate) and install it on internal web server Update DNS entries: Hostname (FQDN) and new IP address Sequence (Step 3): Test computer: Connect to LXI device via web browser (using host name) Request https connection / encryption LXI device: Setup encrypted (https) web server connection to test computer www.lxistandard.org Use the connection you already know!
Screenshots www.lxistandard.org Use the connection you already know!
IP Address Change IP Address change: Whenever the LXI device gets a new IP address it has to assign and re-configure the host name (FQDN) to the new IP address and update the DNS entries via the provisioning server (Internet access required) www.lxistandard.org Use the connection you already know!
DNS Settings & Revocation Check DNS settings: Host name (FQDN) is a LXI vendor specific custom domain name (Device serial #, model, vendor, LXIDeviceDomain) LXIDeviceDomain is common to all LXI devices: lxidevices.org Revocation / Renewal Checks: IDevID revocation will be checked each time the LXI device connects to the provisioning server (OCSP) LDevID revocation will be checked by the web browser based on web browser policy www.lxistandard.org Use the connection you already know!
Local Network w/o Internet Access Certificates issued by company internal CA (private root): Certificate is issued by customer PKI Install the certificate on the LXI device(s): Certificate (plus private key) is uploaded to the LXI device (REST, SCEP (Simple Certificate Enrollment Protocol) or CMP (Certificate Management Protocol) and user authentication/authorization) Install the root CA certificate on client systems (web browser(s) of the test computer) Self-signed certificates: LXI Device creates self-signed certificate on demand Download certificate from device and install it manually in web browser(s) of the test computer www.lxistandard.org Use the connection you already know!
LXI Security Questions We are soliciting feedback and proposals to make sure the LXI Security WG covers all requirements Send you comments and questions to the following email address: LXI Security WG www.lxistandard.org Use the connection you already know!
