SCHWEITZER ENGINEERING LABORATORIES, INC. 2350 NE Hopkins Court + Pullman, WA 99163-5603. USA Tel: +1509.332.1890 - Fax: +1.509.332.7990 @ www.selinc.com + info@selinc.com SEL-3045 Security Policy Schweitzer Engineering Laboratories, Inc. Version: 2.0 Copyright 2009-2013 Schweitzer Engineering Laboratories, Inc. May be reproduced only in its original entirety [without revision]. SEL-3045 Security Policy Contents 1 Definitions and Acronyms 2 References 3 Module Overview 3.1 SSCP... 3.2 SEAP... 3.3 Security Leve 4 Modes of Operation 4.1 FIPS Approved Mode of Operation 4.2 Approved and Allowed Algorithms. 5 Ports and Interfaces 5.1 Physical Port: 5.2 Logical Ports 6 Identification and Authentication Policy 6.1 Assumption of Roles..... 7 Access Control Policy 7.1 Roles and Services . 7.2 Definition of Critical Security Parameters (CSPs)... 7.3 Definition of Public Keys... 7.4 Definition of CSPs Modes of Access 8 Operational Environment 9 Security Rules … 10 Physical Security Policy. 10.1 Physical Security Mechanisms 10.2 Operator Required Actions .... 11 Mitigation of Other Attacks Policy ... SEL-3045 Security Policy Page 2 of 20 SEL-3045 Security Policy Tables Table 1: Module Security Level Specification. Table 2: FIPS Approved Algorithms Used in Current Module Table 3: FIPS Allowed Algorithms Used in Current Module.. ‚7 Table 4: Non-Callable Functions Present in Current Module Table 5: Physical Ports Table 6: Logical Ports Table 7: Dorado Pins and FIPS 140-2 Ports and Interfaces Table 8: Roles Table 9: Identity Authentication Mechanism Table 10: Roles and Service Matrix Table 11: CSPs Table 12: Public Keys........... Table 13: CSP Access Rights within Roles & Services Figures Figure 1: Image of the Cryptographic Module Figure 2: Point to Point Network Figure 3: Point to Multipoint Network Figure 4: Module Block Diagram SEL-3045 Security Policy Page 3 of 20 (SEL) SEL-3045 Security Policy 1 Definitions and Acronyms ABI - Asynchronous Bus Interface SCADA - Supervisory Control And Data Acquisition SEAP — SEL Encryption and Authentication Protocol SSCP — Secure SCADA Communication Protocol USB - Universal Serial Bus 2 References “Secure SCADA Communication Protocol Specification” 3 Module Overview The Schweitzer Engineering Laboratories, Inc. SEL-3045 (hereafter referred to as the module) is a multi-chip standalone cryptographic module encased in a hard, opaque, tamper evident PCMCIA style case. The cryptographic boundary is the entire module. No components are excluded from the cryptographic boundary. The module is a cryptographic protocol daughter card designed to reside in a host device to secure its data on a particular communication network. The SEL-3045 implements the SSCP specification to protect the data in transit. The SEL-3045 is designed to protect devices that send and receive critical, sensitive data such as electric power revenue meters, protective relays, Programming Logic Controllers (PLC), Remote Terminal Units (RTU), and SCADA equipment from unauthorized access, control, monitoring, and malicious attack. The module provides a plaintext port to connect to a device that requires data protection (e.g. the SCADA unit, RTU, or a computer). The cryptotext port connects to a distrusted channel (e.g. a modem connected to a leased phone line or network connection device) where it can communicate with a remote module to provide a secure channel over an insecure network. The configuration of hardware and firmware for this validation is: Hardware: v1.0 Firmware: R100, R101 SEL-3045 Security Policy Page 4 of 20 SEL-3045 Security Policy Figure 1: Image of the Cryptographic Module a Modem ‘SeL-205 ec Figure 2: Point to Point Network seLaus Remote oy u Client ans Figure 3: Point to Multipoint Network SEL-3045 Security Policy Page 5 of 20 SEL-3045 Security Policy 3.1 SSCP The Secure SCADA Communications Protocol (SSCP) secures serial control system communication through the use of symmetric key cryptography. The module uses SSCP to communicate with remote modules. The SSCP secures control system network communications by encapsulating the original message within a header and authenticator. In order to ensure perfect forward secrecy, each pair of communicating devices utilizes a secured Diffie-Hellman key agreement method to establish a session and generate ample cryptographic key material for session authentication and encryption keys. During the session negotiation, a static encryption key is used to secure portions of the Diffie-Hellman key agreement and an authentication key is used to authenticate remote modules. The Diffie-Hellman key agreement establishes two symmetric authentication session keys which are used to provide message authenticity of network data. An additional set of symmetric encryption keys can be used for optional network data encryption. The cryptographic authentication key of the message recipient is used to create an un-transmitted nonce that provides a unique value for each packet. The cryptographic authentication key of the message originator is used by a secure hash algorithm to calculate a hashed message authentication code based upon the header, nonce, and original message. 3.2 SEAP The SEAP protocol secures the operator communication channel with strong message encryption and authentication. SEAP allows operators to securely log into the module to input configuration items (e.g. CSPs) and view status. Each operator has a static AES encryption key, HMAC authentication key, user name, and password. These parameters uniquely identify each operator. The encryption key provides confidentiality during the session negotiation process. The authentication key provides authentication during the session negotiation process. During the session negotiation process, the user name and password are securely provided to the module to authenticate the operator and assign appropriate access privileges. Session encryption and authentication keys are transported by the module and are used to provide confidentiality and authenticity of each frame for the remainder of the session. These keys are transported encrypted using AES CBC and the operator’s AES encryption key. 3.3 Security Level The cryptographic module meets the overall requirements applicable to Level 2 security of FIPS 140-2. Table 1: Module Security Level Specification Security Requirements Section LOC | Cryptographic Module Specification 3 Module Ports and Interfaces 2 Roles, Services and Authentication 3 [Finite State Model 2 Physical Security 2 (Operational Environment N/A (Cryptographic Key Management 2 SEL-3045 Security Policy Page 6 of 20 (SEL) SEL-3045 Security Policy IEMVEMC 3 Self-Tests [Design Assurance Mitigation of Other Attacks N/A 4 Modes of Operation 4.1 FIPS Approved Mode of Operation The module only provides a FIPS Approved mode of operation, comprising all services described in this document. The module will enter FIPS Approved mode following successful power up initialization. The view status command can be used by an operator to verify that the firmware version number matches the FIPS Approved firmware version listed in this document. The operator may inspect the module label to verify the hardware version matches the FIPS Approved hardware version listed in this document. 4.2 Approved and Allowed Algorithms The cryptographic module supports the following FIPS Approved algorithms. Table 2: FIPS Approved Algorithms Used in Current Module FIPS Approved Algorithm Validation Number AES 1272 Modes: ECB, CBC, CTR (Key Sizes: 128/256 bits) SHS 1170 Modes: SHA-1, SHA-256 DSA 412 Modes: Signature Verification (Mod 1024, SHA-1) RNG 710 Modes: FIPS 186-2 General Purpose ( x-Original, SHA-1) HMAC 739 Modes: SHA1, SHA-256 (Key Sizes: KS] N} =] >] NI =] >] NI] EZ] AN = Create a management session Change non-CSP configuration View non CSP configuration Change CSP configuration View status and event logs Clear status and event logs Upgrade firmware Zeroize Close management session Operator Session Authentication Key Create a management session Change non-CSP configuration View non CSP configuration Change CSP configuration View status and event logs Clear status and event logs Upgrade firmware Zeroize Close management session RNG State N/A N/A SEL-3045 Security Policy Page 17 of 20 SEL-3045 Security Policy N/A N/A RNG Seed Key Upgrade firmware FW Upgrade Encryption Key Upgrade firmware Change CSP configuration Remote Network Device Master Encryption Key[s] Create SSCP session Zeroize Change CSP configuration Remote Network Device Master Authentication Key[s] Create SSCP session Zeroize Create SSCP session Remote Network Device Session Encryption Encoding Key[s] Encode plaintext messages Zeroize Create SSCP session Remote Network Device Session Encryption Decoding Key[s] Decode SSCP messages Zeroize Create SSCP session Remote Network Device Session Authentication Encoding Key[s] Encode plaintext messages Zeroize Create SSCP session Remote Network Device Session Authentication Decoding Key[s] Decode SSCP messages Zeroize Create SSCP session Remote Network Device Diffie-Hellman Key Agreement Private Key[s] Create SSCP session Create SSCP session Upgrade firmware =| | N| »| Q| N| #| Q| N| »| ol NI] x] ol NI A] OJ N] A] EI] NI] | <=] =] A] NI OO FW Upgrade Authentication Key Upgrade firmware 8 Operational Environment The FIPS 140-2 Area 6 Operational Environment requirements are not applicable because SEL-3045 loes not contain a modifiable operational environment. 9 Security Rules This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-2 Level 3 module. SEL-3045 Security Policy Page 18 of 20 (SEL) SEL-3045 Security Policy 1. The cryptographic module shall provide four distinct operator roles. These are the Administrator, User, and the Cryptographic Officer, and Network roles. 2. The cryptographic module shall provide identity-based authentication. 3. The cryptographic module shall clear previous authentications on power cycle. 4. When the module has not been placed in a valid role, the operator shall not have access to any cryptographic services. 5. The cryptographic module shall perform the following tests A. Power up Self-Tests 1. Cryptographic algorithm tests DSA Verify Known Answer Test SHA-1 Known Answer Test SHA-256 Known Answer Test HMAC-SHA-1 Known Answer Test HMAC-SHA-256 Known Answer Test RNG Known Answer Test g. AES Encrypt and Decrypt Known Answer Test 2. Firmware Integrity Test a. A 32-bit CRC is calculated over the program image. If the calculated CRC value does not match the value in NV memory, the module declares a failure and disables itself. pepoges B. Critical Functions Tests 1. Runtime volatile memory tests a. Read and write tests are performed on the memory. This continuously checks the memory address space during runtime. If an error is detected, the device declares a failure and disables itself. 2. Settings integrity test a. A 32-bit CRC is calculated over the settings image. If the calculated CRC value does not match the value in NV memory, the device declares a failure and disables itself. C. Conditional Self-Tests 1. Continuous Random Number Generator Tests a. One test compares the last 32 bit NDRNG output with the current 32 bit NDRNG output. If the two values are equal the module declares a failure and disables itself. b. A second test compares the last 512 bit RNG output with the current 512 bit RNG output. If the two values are equal the module declares a failure and disables itself. 2. Firmware Load Test a. The module verifies a DSA digital signature when loading firmware. 6. The operator shall be capable of commanding the module to perform the power-up self-test by cycling power or resetting the module. 7. Power-up self tests do not require any operator action. 8. Data output shall be inhibited during key generation, self-tests, zeroization, and error states. SEL-3045 Security Policy Page 19 of 20 (SEL) SEL-3045 Security Policy 9. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. 10. The module ensures that the seed and seed key inputs to the Approved RNG are not equal. 11. There are no restrictions on which keys or CSPs are zeroized by the zeroization service. 12. The module does not support concurrent operators. 13. The module does not support a maintenance interface or role. 14. The module does not support manual key entry. 15. The module does not have any external input/output devices used for entry/output of data. 16. The module shall not support a bypass capability. 17. The module does not enter or output plaintext CSPs. 18. The module does not output intermediate key values. 10 Physical Security Policy 10.1 Physical Security Mechanisms The cryptographic module includes the following physical security mechanisms: ¢ Production-grade components e Hard potting material encapsulation of multiple chip circuitry enclosure with removal and/or penetration attempts causing serious damage ¢ Hard metallic composite enclosure comprises the cryptographic boundary 10.2 Operator Required Actions The operator is required to periodically inspect the enclosure for tamper evidence. 11 Mitigation of Other Attacks Policy The module has not been designed to mitigate any attacks outside of the scope of FIPS 140-2. SEL-3045 Security Policy Page 20 of 20