We have been wanting to setup Ignition based HMIs in the field. We currently use Ignition Vision in a control room. When a person uses Ignition in a control room, the operator has to login and therefore we know that persons identity.
With field HMIs, we would prefer an easier login method (PIN code style, auto login,etc) however we don’t want these screens to be available on the main control room computers or elsewhere.
With IP Address security, how is the address relayed to the gateway? Does the gateway use the IP address of the connection OR is the IP address relayed by the client?
a) If the gateway uses the IP address of the connection, then I would assume that if clients were behind a NAT, then the NAT address would be used.
How do you securely identify clients? I have seen where options can be placed in a config file but that could be easily copied?
b) If the IP address is sent to the gateway from the client(outside of the connection), does it send all IP addresses that are associated with the network interfaces?
In this case, how do you prevent someone from creating the same IP address on their own computer(not default gateway) and essentially faking the gateway that their computer is permitted when it should be denied.
c) Does anyone else use any other means to positively identify a client?
PKI Certificates? Or other special identifiers that can’t easily be copied?
d) Does anyone use separate gateways for HMI screens security even if the load wouldn’t necessarily warrant a different gateway?
The connection. The gateway can optionally derive the hostname if not behind a NAT, and the local infrastructure does rDNS.
You don't.
In Vision, I like to have the client send the MAC address of the interface it is using to connect to the gateway. This works even behind a NAT, but requires all projects to have a client startup script that determines it and sends it to the gateway. The same procedure can also yield the client origin IP address behind a NAT. Forging this behavior is non-trivial.
In Perspective, the best you can do is work with the device ID in the session, which is somewhat trustworthy in the mobile apps and/or Perspective workstation. Also subject to forgery, but not trivially. If the connection is not behind a NAT, the IP address is your second best choice. But trivial to spoof or manually override.
You simply cannot trust just a browser. Sorry.
Arguably, you cannot trust any computing device that doesn't have locked bootloader, OS, and application. Network security can only be established when there is a trusted device and application on both ends.
IMNSHO, Vision still has the most reliable ability to uniquely identify client machines.
Thanks for the note. I’ll probably end up opting for IP and maybe MAC but I wanted to think through it now more as an bit more more as an exercise.
I looked into some options and I’m looking into a challenge-response system using the Yubikey (in challenge response mode, without needing to touch the gold button). Since the Yubikey is a physical device, it will limit its use to 1 computer on the floor. The downside to this is that it requires use of the SDK/shell program to initiate the key but at least I could probably store results in text files to make it easy to grab from a Vision client. It appears the Vision client can’t return information from a shell command.
Challenge-Response using Yubikey (Vision Client, not tested)
a)Gateway sends random challenge to Client. Gateway stores expected response.
Secret Key is previously stored in Gateway.
Client calculates response using Yubikey in CR mode (via external shell program that can trigger the Yubikey automatically). It stores it in a file.
Vision Client reads the file and sends the response back to the Gateway.
Gateway compares its response with the Client Response.
If both match, then authenticate Ignition client.
If it fails, deny the client.
Alternatives
It’s unclear to me whether there is a semi-protected method for storing the secret on the computer itself that is visible to Ignition but not to the user to avoid the use of the Yubikey/external programs. Jython appears to support HMAC-SHA1 if there was a secure way to store the key so that it couldn’t be easily copied to other computers. For example, it would be nice if Vision could access a secret itself but the end user could not.
There might be other derivatives of this approach.
Java can also use pkcs11 in most environments (I use it this was to sign my modules with a cert in a yubikey) if the proper smartcard drivers are installed. OpenSC in Linux works for me. One of the four standard key slots on a yubikey doesn’t require a PIN.