Secure DNP3
From SCADApedia
Secure DNP3 adds user and device authentication as well as data integrity protection to the DNP3 protocol. Secure DNP3 is a bi-directional protocol that provides protection between master stations (HMI, control servers) and outstations (PLC's, RTU's, IED's).
Contents |
Authentication Scenarios
Authentication takes place in four scenarios:
- Initialization: When a master station initiates a DNP3 session with an outstation, Secure DNP3 will authenticate both the master station and outstation are who they claim to be to prevent spoofing, replay, hijacking and other attacks. A unique session key is generated and exchanged using pre-shared keys during this initialization
- Periodic: The master station and outstation will verify again they are who they claim to be to prevent hijacking and other attacks. The default is a periodic authentication every 20 minutes and the maximum is authentication every hour. A new session key is generated and exchanged during this periodic update.
- Critical Function Code Requests: Critical requests including writes (function code 2), selects (FC 3), operates (FC 4), direct operates (FC 5, 6), cold and warm restarts (FC 13, 14), initialize, start and stop application (FC 15, 16, 17), enable and disable unsolicited response (FC 20, 21), record current time (FC 24), authenticate file (FC 29), and activate configuration (FC 31).
- Implementation Specific: vendors can implement authentication requirements for other function codes or allow end users to select function codes that require authentication via Secure DNP3.
Application Layer
While the DNP3 protocol specifies the data link, transport and application layer, Secure DNP3 only modifies DNP3 at the application layer. Secure DNP3 works the same whether it is DNP3 over TCP/IP, UDP/IP, or serial and DNP3 can be secured in hybrid networks such as TCP/IP to serial communications through a communications gateway.
Challenge/Response
The main mode of operation is challenge / response. For example when a master station issues a request with a function code that requires authentication, the outstation will not immediately process the request and issue a response. Instead the outstation will issue an authentication challenge (function code 0x83) that includes random data that changes with each challenge. The master station responds to the challenge with a HMAC,as specified in IEC 9798-4, that includes the random data and the session key. The outstation also has the session key and can verify the HMAC in the response is correct.
The challenge / response is depicted in the diagram below.
Secure DNP3 also supports a master station challenging a response, regular or unsolicited, from an outstation to identify attacks to provide false data to the control center or other critical applications.
Aggressive Mode
Aggressive mode eliminates much of the delay and overhead of the challenge/response in the normal Secure DNP3 mode at the risk of replay if external replay prevention is not in place. In Aggressive Mode, the master station will add an authentication response to the protocol request for function codes that are known to require authentication.
The random number that is typically provided in the authentication challenge is created by the master station, hence the risk of replay if external replay protection is not provided. Aggressive mode still requires a challenge/response for initialization and periodically. The simplified packet flow is depicted in the diagram below.
Cryptography
The committee that developed the Secure DNP3 specification relied on existing, vetted crypto protocols. The authentication protocol used is a Keyed Hashing for Message Authentication (HMAC), as specified in IEC 9798-4, that creates the equivalent of a secure checksum. The HMAC calculation requires message data, challenge data, and a secret key. Since only the sender and intended recipient have all three components, only they are able to calculate or verify the HMAC.
The HMAC verifies data integrity of the message data because if any bit is altered in the message, either maliciously or through communication error, the HMAC calculated by the recipient will not match the HMAC sent in the message.
While Secure DNP3 is primarily an authentication protocol, there is a requirement that DNP3 over TCP/IP implement TLS encryption per the IEC 62351-3 specification.
Key Management
The data and user authentication provided in Secure DNP3 requires the two communicating parties to have the same secret key. Secure DNP3 defines a two level key management scheme.
Level 1 is a pre-shared key that is distributed securely in an unspecified manner to a master station and outstation. In early versions and for small systems this is likely to be a manual distribution of the pre-shared keys. An automated key management system that would include the distribution of pre-shared keys may be developed in the future.
Level 2 is a session key that is securely distributed using the pre-shared key. A new session key is created and exchanged at initialization and periodically. The session key is then used for authenticating individual requests and responses until it is updated.
New Function Codes
A set of new function codes were specified to support Secure DNP3.
| Function Code | Description |
|---|---|
| 0x20 | Authentication Request |
| 0x21 | Authentication Reply |
| 0x22 | Authentication Error |
| 0x83 | Authentication Challenge |
| 0x84 | Unsolicited Authentication Challenge |
These function codes, and in fact the protocol, could be used to add security to other standard and proprietary control system protocols.
In addition to the new function codes, Secure DNP3 also specifies additional use of other function codes such as adding aggressive mode authentication responses to existing request function codes, key status information in 0x81 responses, and key change messages to the 0x02 write function code.
Relation to IEC 62351
Secure DNP3 is almost identical to IEC 62351-5, and this was by design of the two committees that worked together closely.
Status
Version 1.0 of the Secure DNP3 specification was released on 3 Feb 2007.
Beta sites and pilot deployments are likely to occur late in 2007. Product availability by first mover vendors is likely to occur in 2008.
