IEEE 2030 5 Security Overview Gordon Lum Kitu

IEEE 2030. 5 Security Overview Gordon Lum Kitu Systems July 24, 2018 Kitu Systems 1

Agenda Brief IEEE 2030. 5 Overview IEEE 2030. 5 TLS Cipher Suite IEEE 2030. 5 Public Key Infrastructure (PKI) July 24, 2018 Kitu Systems 2

IEEE 2030. 5 High-Level Overview What is IEEE 2030. 5 • • • An Application Layer Protocol for Smart Energy Communications Based on IEC 61968 Common Information Model (CIM) Uses a Client – Server architecture Uses HTTP over TCP/IP (both IPv 4 and IPv 6) Uses XML/EXI payload using a schema based on the IEC 61968 UML Uses RESTful model of interaction (GET, PUT, POST, DELETE) Uses TLS for point to point security between Client and Server IEEE 2030. 5 is part of the NIST/SGIP Catalog of Standards CSIP uses the IEEE 2030. 5 security model User Application Layer Presentation Layer Transport Layer Network Layer Link Layer Physical Layer July 24, 2018 Kitu Systems IEEE 2030. 5 (XML Schema) HTTP(S) m. DNS TCP UDP IPv 4, IPv 6 Ethernet (802. 3) MAC Wired, Wireless, Powerline 3

IEEE 2030. 5 High-Level Overview What is the Status of IEEE 2030. 5 • • • Initial “S 0” version of IEEE 2030. 5 approved in 2013. Updated “S 1” version of IEEE 2030. 5 has been approved and is awaiting official publication, which should be imminent. A new IEEE Project Authorization Request (PAR) has been approved as a vehicle for addressing the next round of updates. What changed between S 0 and S 1? • • July 24, 2018 Main changes were to additional support for DER functionality – specifically to support all aspects of IEEE 1547 and CA Rule 21, phases 1, 2, and 3. No major changes to the IEEE 2030. 5 Security Model Kitu Systems 4

IEEE 2030. 5 TLS Cipher Suite Mandates the use of a single cipher suite that provides a security level of 128 bits • The level of security is measured in bits as defined in NIST SP 800 -57 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 TLS 1. 2 July 24, 2018 Key Exchange Algorithm Signature Authentication Algorithm Bulk Encryption Algorithm Message Authentication Algorithm Elliptic-Curve Diffie-Hellman Ephemeral Elliptic-Curve Digital Signature Algorithm AES-128 (128 -bit blocks) (128 -bit keys) Counter with CBC-MAC AEAD Algorithm Kitu Systems 5

Cipher Suite: TLS Details Mandates the use of TLS version 1. 2 • Prevents protocol downgrade attacks Mandates the use of the single cipher suite • • Prevents weak cipher downgrade attacks Promotes interoperability Supports Mutual Authentication of the Server and Client • Both the Server and Client have certificates that are exchanged and authenticated during the TLS Handshake No requirement to support Session Resumption or Session Tickets • • Mar 14, 2018 These options allow the Server and Client to negotiate the re-use of the Master Secret generated from a previous session, thus avoiding the computationally expensive public key operations needed to generate a new Master Secret. But either can be negotiated during the TLS Handshake if both sides support it. Most current implementations support Session Resumption. Kitu Systems Proprietary 6

Cipher Suite: Key Exchange Details Purpose of the Key Exchange Algorithm is for both sides to agree on a secure traffic encryption key Uses Elliptic Curve Diffie-Hellman Key Agreement • • • The elliptic curve variation of the Diffie-Hellman key agreement algorithm is used to derive a shared Master Secret The security of ECDH is based on the elliptic curve analog of the discrete-log problem Uses the well-known NIST P-256 (also known as secp 256 r 1 and prime 256 v 1) The P-256 curve provides 128 bits of security One advantage of ECC over RSA is the key size for a given security strength is much smaller. For example, to provide a security strength of 128 bits, ECC requires a key size of 256 bits whereas RSA requires 3072 bits. The are efficient software and hardware solutions for implementing public key operations using the P-256 curve Uses the “Ephemeral” variation to provide Perfect Forward Secrecy • • • July 24, 2018 The final E in ECDHE stands for “ephemeral” Instead of using its permanent public/private keypair to generate the Master Secret, each endpoint generates a temporary “ephemeral” keypair for generating the Master Secret for this session. If the permanent public/private keypair is compromised, the attacker still cannot decode past sessions because the Master Secret was based on ephemeral keys, not the compromised permanent key Kitu Systems 7

Cipher Suite: Signature Algorithm Details Uses Elliptic Curve Digital Signature Algorithm • • • July 24, 2018 The elliptic curve variation of the Digital Signature Algorithm for authentication The security of ECDSA is based on the elliptic curve analog of the discrete-log problem Uses the well-known NIST P-256 (also known as secp 256 r 1 and prime 256 v 1) The P-256 curve provides 128 bits of security One advantage of ECC over RSA is the key size for a given security strength is much smaller. For example, to provide a security strength of 128 bits, ECC requires a key size of 256 bits whereas RSA requires 3072 bits. The are efficient software and hardware solutions for implementing public key operations using the P-256 curve Kitu Systems 8

Cipher Suite: Bulk Encryption Algorithm Uses AES-128 as the Bulk Encryption Algorithm The encryption key and initialization vector for AES-128 is derived from perform SHA-256 hashes over the Master Secret generated from the ECDHE key agreement algorithm AES-128 is used to encrypt all application traffic after successfully completing the TLS Handshake AES-128 provides 128 bits of security SHA-256, which is used to hash the Master Secret, provides 128 bits of security There are efficient hardware and software solutions for implementing AES-128 July 24, 2018 Kitu Systems 9

Cipher Suite: Message Authentication Algorithm Uses Counter mode with CBC-MAC (CCM) as the combined Encryption and Message Authentication algorithm CCM belongs to the class of AEAD (Authenticated Encryption with Additional Data) algorithms that perform encryption and message authentication in one algorithm The current school of thought in the security world is that AEAD algorithms provide better security than independently encrypting and then authenticating a message Uses AES-128 as the underlying encryption algorithm There are efficient hardware and software solutions for implementing CCM. Most Zig. Bee devices have hardware support for CCM. July 24, 2018 Kitu Systems 10

Cipher Suite: Background Why was the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite chosen in 2013? • Desire to comply with the NSA Suite B recommendations in effect at that time What is NSA Suite B? • • • The United States government published CNSSP-15 (2012) – guidelines for "NSA Suite B Cryptography" Defines cryptographic algorithm policy for national security systems (NSS) Defines a timeline for their adoption and implementation What were the NSA Suite B recommendations in 2013? • • • Defined two levels of security o SECRET – equivalent to 128 bits of security o TOP SECRET – equivalent to roughly 192 bits of security Exclusive use of ECC for public key algorithms. National security systems were to transition away from RSA and only use ECC. Use of AEAD authentication algorithms IEEE 2030. 5 chose the cipher suite to comply with NSA Suite B recommendations at the SECRET level July 24, 2018 Kitu Systems 11

Cipher Suite: Looking Forward – Is the Cipher Suite Still Good? Changes in NSA Suite B since 2013 • • CNSS Advisory Memorandum Information Assurance 02 -15 (July 2015) rescinded CNSSP-15 (2012) Suite B recommendations. Purported reason was the potential of Quantum Computing made NSA rethink their recommendations. NSA wants to pursue the use of Quantum Computing resistant algorithms. However, no new QC-resistant algorithms were proposed. What are the NSS recommendations today? • • • CNSSP-15 (2016) formally adopted the contents of the Advisory Memorandum which rescinded CNSSP-15 (2012) Removes the SECRET category Allows the continued use of RSA (with appropriate key sizes). This was done in recognition that there are still large number of legacy systems using RSA Recommends that if you are transitioning based on the original Suite B recommendations, you should continue to do so. Future systems should use QC-resistant algorithms that will be specified in a future memorandum Should the IEEE 2030. 5 Cipher Suite change because of the new NSS recommendations? • July 24, 2018 OPINION: I think the original NSA Suite B is still good practice, and is not in conflict with the new recommendations, so the choice of cipher suites is still as valid today as it was in 2013 Kitu Systems 12

Cipher Suite: Looking Forward – Is the Cipher Suite Still Good? TLS 1. 3 • • • TLS 1. 3 was recently approved and will eventually replace TLS 1. 2 One of the goals of TLS 1. 3 was to remove all the insecure algorithms present in TLS 1. 2 and earlier (e. g. SHA-1, MD 5, DES, RC 4, etc. ) All approved algorithms in TLS 1. 3 have Perfect Forward Secrecy All approved authentication algorithms in TLS 1. 3 use an AEAD algorithm TLS 1. 3 directly supports ECC and RSA The IEEE 2030. 5 Cipher Suite complies with all the security features used in TLS 1. 3 July 24, 2018 Kitu Systems 13

Cipher Suite: Looking Forward – Is 128 bits of Security Still Good? Is 128 bits of security still good in 2018? • • Yes, see comparison chart There are no known weaknesses to AES-128 or ECC with the P-256 curve Comparison with Financial Industry Requirements • Bits of Security ≤ 56 80 The Payment Card Industry (PCI) Standard version 2 (2014) requires a security strength of 112 bits to secure financial transactions 112 128 192 256 July 24, 2018 Kitu Systems Cipher Algorithm DES 2 L-TDES RSA 1024 ECC 160 3 L-TDEA RSA 2048 ECC 224 AES-128 RSA 3072 ECC 256 AES-192 RSA 7680 ECC 384 AES-256 RSA 15360 ECC 512 PCI 2. 0 Compliant Suite B SECRET Suite B TOP SECRET CNSS 02 -15 14

IEEE 2030. 5 Public Key Infrastructure (PKI) Basic PKI Assumptions • • • There exists an IEEE 2030. 5 compliant Root Certificate Authority (Root CA) The Root CA and/or subordinate CA’s issue device certificates All IEEE 2030. 5 devices have a device certificate issued by a valid CA All IEEE 2030. 5 devices have a copy of the Root CA public key o This key is obtained out of band (e. g. directly from the Root CA or other trusted source) o This key is used to validate the certificate chain exchanged during the TLS Handshake The device certificates are used for mutual authentication of the client and server during the TLS Handshake These device certificates are used for identity-based Access Control to server resources o The Long Form Device Identifier (LFDI) and the Short Form Device Identifier (SFDI) that are used in some function sets are based on a SHA-256 hash of the device’s certificate July 24, 2018 Kitu Systems 15

PKI: Certificate Authority Infrastructure Options Option 1 – Root CA issues Device Certificates • • • July 24, 2018 The Root CA is the top node in the chain The Root CA directly issues device certificates o The device certificates are signed by the Root CA This option is not recommended for production. The Root CA private key should be well protected and rarely used. However, if the private key is used for device certificate signing, then it is more exposed and subject to compromise. Kitu Systems 16

PKI: Certificate Authority Infrastructure Options Option 2 – Root CA authorizes an Issuing CA to issue Device Certificates • • • July 24, 2018 The Root CA is the top node in the chain The Manufacturer Issuing CA is authorized by the Root CA o The MICA’s certificate is signed by the Root CA The MICA issues device certificates o The device certificates are signed by the MICA Kitu Systems 17

PKI: Certificate Authority Infrastructure Options Option 3 – Root CA authorizes a Manufacturer CA which authorizes an Issuing CA to issue Device Certificates • • July 24, 2018 The Root CA is the top node in the chain The Manufacturer CA (MCA) is authorized by the Root CA o The MCA’s certificate is signed by the Root CA The MCA authorizes the MICA issues device certificates o The MICA certificates are signed by the MCA The MICA issues device certificates o The device certificates are signed by the MICA Kitu Systems 18

PKI: Access Control is purely based on identity (i. e. the device certificate) Role-Based Access Controls (e. g. user, installer, operator, administrator, etc. ) can be supported if the Server can map an identity (i. e. device certificate) to a roll (e. g. administrator) and provide the access controls base on the roll. In theory, every server resource can have its own Access Control List. In practice, Access is usually granted to a device on a function set by function set basis. Access Control is Optional – there is an entire chapter in the specification showing how Access Control could be done, but it is purely informative, not normative July 24, 2018 Kitu Systems 19

PKI: Certificate Format and Properties Certificates use the standard X. 509 format The IEEE 2030. 5 specification details that must and must not be present. All certificates in the PKI (i. e. the Root CA, MICA, and device certificates) have indefinite lifetimes • • • Technically, the “Validity: Not After” is “ 99991231235959 Z” Think of a device certificate as a “birth certificate”, not a “driver’s license” The device certificate provides identity authentication. It does not guarantee authorization. Why do certificates have indefinite lifetimes? • • July 24, 2018 Some devices are expected to have very long lifetimes of 10 years or more. There is no good way of replacing expired certificates in the field. Verifying a certificate has not expired implies the checker has access of a trusted time source. o In many cases, there are no trusted time sources available or access to the internet o Even if there is a time source, it may not be sync’d to actual real time. Kitu Systems 20

PKI: Certificate Revocation IEEE 2030. 5 prohibits the use of Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP) • • CA’s are do not run CRL or OCSP servers Devices do not check CRL or OCSP servers to validate certificates Even though the CRL and OCSP are explicitly precluded from the PKI, servers and clients can implement their own methods of certificate validation. For example, there is noting to preclude the use of certificate blacklists or whitelists. If a certificate becomes suspect, it can be “retired” (i. e. not used any more), but not “revoked” Why was CRL and OCSP precluded? • • • CRL and OCSP imply the availability of CRL/OCSP servers on the internet. There is no guarantee that IEEE 2030. 5 devices have access to the internet. OPINION: There are no service level guarantees for the reliability, availability, and usefulness of the CRL/OCSP servers. OPINION: It is unclear if adding the CRL/OCSP infrastructure improves or degrades overall security (i. e. does the benefits of CRL/OCSP outweigh the costs? ) July 24, 2018 Kitu Systems 21