Implementing GridTrust
Shown in Figure 1 is an example of how GridTrust may be utilized in a network involving a Vendor and a Utility. The Vendor or (more likely) Utility will provide update files to various devices as required. GridTrust compromises (1) Interfacing Devices which provide protection to existing devices, and (2) Native Devices which provide protection integrated with the production of a new device. In the standard operation, all GridTrust devices are supplied with public keys for both the Vendor and the Utility. When the Vendor produces a software update, the Vendor signs the update binary with their private key and supplies the source code, binary, and signature to the Utility. The Utility then separately approves the source code, (optionally) compiles the source code, and signs the binary with the Utility’s private key. When an update occurs, the devices are supplied with the update binary and the signatures from both the Vendor and the Utility.
Shown in Figure 2 is a small example of how GridTrust may be employed at a Utility. The GridTrust server is integrated with the Utility’s network operation center. A GridTrust Native Device is located in a substation equipment shed, providing update authentication for a temperature sensor. A GridTrust Interfacing Device is located in the substation yard providing update authentication for a legacy power protection relay connected to a high-voltage power distribution circuit breaker.
When performing an update, the files can be either supplied remotely via the GridTrust server, or supplied locally via an SSH session through the worker laptop. Both scenarios require final update approval by the GridTrust Server.
The following links discuss how each component of the GridTrust example in Figure 2 is accomplished:
GridTrust Interfacing Device Setup
Note: We do not discuss how to set up routers / switches. It is assumed the server, native device, and interface device have been assigned IPv4 addresses and are on the same network.