By Dale Peterson, Digitial Bond Inc.
THE AGA 12 STANDARD specifies a serial link encryption and authentication protocol for SCADA field communications. Why is this protocol different than other security protocols? This protocol must address low latency requirements in SCADA field communications; it must be SCADA protocol aware to extract and use the SCADA address; and it must pass modem commands through in the clear.
The meat of the standard is in Part 2, and the latest draft is available at the GTI web site. After reviewing the May 12, 2005, we identifed two major open questions or issues.
Management has been the downfall of many encryption systems. What works in a prototype deployment of four units becomes completely impractical in a system with 100's of units. The AGA 12 standard actually has two major managment challenges that are unspecified in the standard and not addressed yet by the handful of vendors developing products.
In a typical scenario a control center will have a few encryptors and each protected field site will have an encryptor. Any pair of encryptors that communicate require a unique key pair for a "static session" per the AGA 12 standard. The static sessions are then used to securely set up dynamic sessions, and this setup includes the crypto key parameters in the ciphersuite field.
Take a simple example with two encryptors in the control center and an encryptor at each of the 50 field sites. There would be a requirement to generate and load 100 unique key pairs, 50 in each control center encryptor and two in each field encryptor. As the standard exists today this is would all happen manually. Now imagine there is a small change in the network. If a unit needs to be added or replaced at the control center, you will need to generate and properly load a new key in each of the 50 field units. And remember, each field unit would have a unique key and these keys are random 256-bit values, which are not the easiest things to type in manually.
This is very similar to the ANSI X9.17 key management standard that was widely used in banking in the '80s and early '90s. The key pair in the static session is similar to the X9.17 key encryption key that was used to exchange data encryption keys similar to the dynamic session keys. It was completely unworkable with manual entry, so a management system was required. Having worked for two companies that had X9.17 management systems, I can tell you that after many man years of engineering the management systems worked but not well. The level of complexity made the management systems very expensive and the end users unhappy.
Fortunately, with the advent of public key technology this is all unnecessary. The concept of manually loaded unique key pairs is out. Encryption units are issued pubic key certificates from a trusted certificate authority. The units then use these certificates to perform a public key exchange to negotiate a key, such as the static session key, often using the Diffie Hellman algorithm.
If a new encryption unit is added, the unit is issued a certificate and no re-keying is required in any other encryption unit. SCADA networks have the added implementation advantage that they are closed networks. Every unit that will communicate securely on the SCADA network is approved by an entity in advance and will be issued a certificate, unlike in e-commerce where you never know who will hit your website.
In discussions with GTI I learned that they been thinking about adding this type of layer on top of the static sessions. Practically speaking, this added layer will either be designed in the standard to facillitate interoperability or left to the vendors to accomplish. In any case, we would never recommend moving past a prototype test into a production deployment of the encryptors without this key management.
To be fair, this management has been unnecessary since there have been no encryptors to manage. The contract with Mykrotronx to develop a product along with other vendors efforts to develop AGA products requires an urgent effort to develop appropriate key management.
While key management has technical solutions to eliminate the requirement for a sophisticated management solution, there is no simple technical solution for managing the address table.
The address table maps SCADA addresses to a SCADA Cryptographic Module (SCM), or encryptor, that protects the address. When a poll or some other SCADA protocol message is sent, the originating SCM must look at the message and extract the SCADA address from the message. The originating SCM looks at its address table and determines what destination SCM protects that address. It then establishes a dynamic session with the destination SCM and sends the message securely, most likely through an encrypted and authenticated tunnel.
Each SCM will have an address table. Each control center SCM will need to know the SCADA addresses behind each of the 50 field site SCM’s. Each of the field site SCM’s will need to know the SCADA addresses behind the two control center SCM’s. And if any field site SCM’s communicate with each other, and this happens in larger SCADA systems, they will need to know the SCM / SCADA address mappings for all communicating field sites.
Entering the address table once is a lot of work in even a medium size SCADA network, but management becomes even more important when changes occur. What if a new HMI or control server is added in the control center? The address table for each of the 50 field sites would need to be updated. What if a new PLC is deployed? A SCM loses the address table? A new field site is deployed? While the networks don’t change frequently, even infrequent changes can require a number of address table changes.