I had a chance to talk with Grant Gilchrist of Enernex at Distributech about the efforts to add security to DNP3. This is an effort of the DNP Forum and others through IEC TC57 WG15. The six part draft standard is 62351.

• Part 5 of the standard will provide authentication and integrity at a minimum. This protection is provided at the application layer and therefore will be present for both serial and TCP/IP DNP3. New objects, such as challenge, response, and key change, are being added to existing function codes to support the exchange of the required security information.
• The application layer security involves hashing a message, date/time, challenge, and a key. Actually, I’m a bit unclear whether the request/response message is in the hash. It should be. Since the key is only known to the communicating pair, only that pair can create and verify the hash.
• Certain function codes will be labeled Critical. Critical function codes will be secured with this application layer protection. There also is a performance enhancing aggressive mode where a challenge is reused. This is acceptable if the date/time or some other parameter changes and replay is detected.
• Key management is always THE ISSUE. It is here as well. The plan is to distribute a unique top level key pair to each coummnicating pair. So if N units communicate there (N-1)! key pairs must be created and manually distributed. These top level key pairs can then exchange session keys over the network. This is the old banking ANSI X9.17 approach from the 80’s and early 90’s. It is a nightmare even with sophisticated management systems. It baffles me why the SCADA Security community continues to propose this already failed system. Maybe because it is easy to explain and specify, but the implementation is another matter in all but the smallest networks.
• Part 3 of the standard specifies security at the IP layer. This is basically SSL/TLS. I’ve blogged in the past that I’m not crazy about this, but since there is protection at the application layer it is less of a concern except for the real possibility that we will see the continued increase of web servers in field devices. Part 3 will also apply to securing ICCP.

I would really like to see the option of using public key for the top level key or at least not precluded by the standard. Think of this. If a system/key at the control center needs to be added or changed, the proposed key management will require a manual rekey of all units in the field. In the public key mode it would only require a new certificate in the one unit in the control center. Public key may not be practical for serial systems, but DNP3 over TCP/IP is expanding and probably where security is needed more.

All the same arguments against public key, bandwidth and computing power, were made in the banking world. In the end, what fueled the acceptance was the private key systems were unmanageable, and I say this as someone who worked for two companies that spent man decades developing and selling private key management systems in that market.

All and all there is a lot of positive action here. Security at the application layer, message integrity and identifying critical functions are great. The standard is moving forward and is scheduled to be out in late 2006/early 2007.