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 User Application • Based on IEC 61968 Common Information Model (CIM)

• Uses a Client – Server architecture Application Layer IEEE 2030.5 (XML Schema) • Uses HTTP over TCP/IP (both IPv4 and IPv6) • Uses XML/EXI payload using a schema based on the IEC 61968 UML Presentation Layer HTTP(S) mDNS • Uses RESTful model of interaction (GET, PUT, POST, DELETE) TCP UDP • Uses TLS for point to point security between Client and Server Transport Layer • IEEE 2030.5 is part of the NIST/SGIP Catalog of Standards Network Layer IPv4, IPv6 • CSIP uses the IEEE 2030.5 security model Link Layer Ethernet (802.3) MAC

Physical Layer Wired, Wireless, Powerline

July 24, 2018 Kitu Systems 3 IEEE 2030.5 High-Level Overview

What is the Status of IEEE 2030.5 • Initial “S0” version of IEEE 2030.5 approved in 2013. • Updated “S1” 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 S0 and S1? • Main changes were to add 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

July 24, 2018 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 Key Exchange Signature Bulk Encryption Message Authentication Algorithm Authentication Algorithm Algorithm Algorithm

Elliptic-Curve Elliptic-Curve AES-128 Counter with CBC-MAC Diffie-Hellman Digital Signature (128-bit blocks) AEAD Algorithm Ephemeral Algorithm (128-bit keys)

July 24, 2018 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 • 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.

Mar 14, 2018 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 secp256r1 and prime256v1) • 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 • 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

July 24, 2018 Kitu Systems 7 Cipher Suite: Signature Algorithm Details

Uses Elliptic Curve Digital Signature Algorithm • 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 secp256r1 and prime256v1) • 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

July 24, 2018 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 ZigBee 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? • 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

July 24, 2018 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, MD5, DES, RC4, 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 Bits of Cipher PCI 2.0 Suite B Suite B CNSS • There are no known weaknesses to AES-128 or ECC Security Algorithm Compliant SECRET TOP SECRET 02-15 with the P-256 curve ≤ 56 DES 2L-TDES 80 RSA 1024 ü Comparison with Financial Industry Requirements ECC 160 • The Payment Card Industry (PCI) Standard version 2 3L-TDEA ü (2014) requires a security strength of 112 bits to 112 RSA 2048 ü secure financial transactions ECC 224 ü AES-128 ü ü 128 RSA 3072 ü ü ECC 256 ü ü AES-192 ü 192 RSA 7680 ü ECC 384 ü ü ü AES-256 ü ü ü 256 RSA 15360 ü ECC 512 ü

July 24, 2018 Kitu Systems 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 Root Certificate Authority • The Root CA is the top node in the chain Subject : Root CA • The Root CA directly issues device certificates Issuer : Root CA 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 Device Certificate key is used for device certificate signing, then it is more exposed and Subject : blank Issuer : Root CA subject to compromise.

July 24, 2018 Kitu Systems 16 PKI: Certificate Authority Infrastructure Options

Option 2 – Root CA authorizes an Issuing CA to issue Device Certificates Root Certificate Authority Subject : Root CA • The Root CA is the top node in the chain Issuer : Root CA • 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 Manufacturer Issuing CA Subject : MICA o The device certificates are signed by the MICA Issuer : Root CA

Device Certificate Subject : blank Issuer : MICA

July 24, 2018 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 Root Certificate Authority Subject : Root CA • The Root CA is the top node in the chain Issuer : Root CA • 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 Manufacturer CA Subject : MCA o The MICA certificates are signed by the MCA Issuer : Root CA • The MICA issues device certificates o The device certificates are signed by the MICA Manufacturer Issuing CA Subject : MICA Issuer : MCA

Device Certificate Subject : blank Issuer : MICA

July 24, 2018 Kitu Systems 18 PKI: Access Control

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, MCA, MICA, and device certificates) have indefinite lifetimes • Technically, the “Validity: Not After” is “99991231235959Z” • 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? • 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.

July 24, 2018 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