Comment from Erik Hjelmvik
Time: June 12, 2007, 3:39 pm

Great Podcast, thanks Dale and Grant!

A couple of weeks back when I read the Committee Draft for Vote (CDV) for the 62351-5 standard (which covers DNP3 and IEC 60870-5-104 which is more common outside the US) I reacted in the same way as Dale did. I.e. I thought it was good that they had focused on authentication and data integrity rather than confidentiality, but I couldn’t really understand why they had chosen to use challenge-response!

Using a challenge-response has a number of drawbacks:

1. Three messages, instead of just one, have to be sent across the network in order to perform a command. This adds a lot of latency which really isn’t popular in the automation world.

2. The challenge-response generates a lot of extra traffic on the network. This isn’t popular either.

3. The device (PLC, RTU or simular) becoms vulnerable to denial of service attacks since an attacker could easily flood the device with requests for which the device has to send challanges and wait for responses.

4. Implementing a challenge-response functionality requires a rather complicated state machine since the device can be in a lot of different states depending on whether a challenge is sent and what type of answer is given to the challange. This topic is however covered to some extent in the 62351 standard, but it is clear that it would be a lot simpler if some other solution for authentication was choosen.

So what would I suggest? Well I would have appended a signed (encrypted) hash of message+nonce at the end of the packet (maybe togeather with the IP of the sender, but this might not always be a good idea depending on NAT etc.).
This is something like the “Aggressive mode” but not quite… The agressive mode still requires that some sort of challenge has been received previously. It also has a VERY predictable “nonce” value since it just adds “1″ to the previous value.

I do however believe that the IEC TC 57 Working Group 15 have thought about why not to just simply sign the sent ASDU, so I guess there is something I’ve missed.
So if you know why challenge-response is used as the default solution instead of a normal signature please provide a good answer here on this blog.

PS. At least some of us asset owners are interrested in securing the SCADA and Control Systems by using an end-to-end security solution like this.

Comment from Jake Brodsky
Time: June 13, 2007, 12:17 pm

Erik, you are pretty much reinventing the Aggressive Mode that Grant and Dale spoke of. The challenge response methods here are used to prevent replay attacks. When you stray from that paradigm the chances of a replay attack getting through increase.

Dale, we really do have to get together some time and swap a few war stories over beer…

Comment from Erik Hjelmvik
Time: June 15, 2007, 5:09 am

Yes you are right Jake, what I suggest is something similar to Aggressive Mode.

My main point is that the Aggressive Mode (or similar method using HMAC with state information or cryptographic nonce) is secure enough. Using the challenge-responce scheme adds extra complexity, latency and network traffic without adding any considerable security. It also makes the attack surface of the RTU implementation larger, i.e. more possible vulnerabilities.

Therefore I think that the challenge-response part shouldn’t be in the standard at all, or maybe just optional. The Aggresive Mode shall be the standard way of authenticating the user and data in Secure DNP3 / IEC 62351-5.

However I would be happy to be proven wrong, i.e if someone can show that using challenge-response provides a considerable better level of security than the Aggressive Mode.

A side-note is that I also agree with Dale that implementing TLS (SSL 3.1) shouldn’t be mandatory for TCP based protocols. Especially since the main purpose of using TLS is to provide confidentiality (which isn’t really a big issue here). In order to provide authentication using TLS one has to use a Certificate Authority (CA). This adds a dependency on an extra system (the CA) and therefore affects the availability in a negative way.

Comment from Dale Peterson
Time: June 15, 2007, 7:57 am

Eric - great, substantive comments in this post. We need to get you over here for S4 2008.

Secure DNP3 is not exactly how I would have designed it, and based on the limited information in your comments I believe you and I would be on the same page for the ‘ideal’ protocol.

That said, I really take my hat off to the Secure DNP3, IEC 62351-5 team. When you compare their efforts to AGA-12, Secure ICCP, or even the first pass on OPC UA security (they have made some significant improvements and I need to dive into this sometime soon), it is dramatically better. I believe Secure DNP3 is the first control system security protocol that actually addresses the control systems security requirements.

Jake - I’ll see you at Joe Weiss’s event in August.

Comment from Erik Hjelmvik
Time: June 15, 2007, 8:40 am

Dale, I will be at Joe Weiss’s “Control Systems Cyber Security Conference” in Knoxwille as well. I will in fact hold a presentation on “Security Assessment of 3rd Party Vendor Remote Access” two hours after your honeypot-presentation.

I also think the IEC 62351 effort is really great since it will provide a solution for end-to-end security for the control system communication.