July 24 2018 Kitu Systems 1 Gordon Lum Kitu Systems Agenda Brief IEEE 20305 Overview IEEE 20305 TLS Cipher Suite IEEE 20305 Public Key Infrastructure PKI July 24 2018 Kitu Systems 2 ID: 789913
Download The PPT/PDF document "IEEE 2030.5 Security Overview" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
IEEE 2030.5 Security Overview
July 24, 2018
Kitu Systems
1
Gordon Lum
Kitu Systems
Slide2Agenda
Brief IEEE 2030.5 Overview
IEEE 2030.5 TLS Cipher SuiteIEEE 2030.5 Public Key Infrastructure (PKI)
July 24, 2018
Kitu Systems
2
Slide3IEEE 2030.5 High-Level Overview
What is IEEE 2030.5
An Application Layer Protocol for Smart Energy CommunicationsBased on IEC 61968 Common Information Model (CIM) Uses a Client – Server architectureUses HTTP over TCP/IP (both IPv4 and IPv6)
Uses XML/EXI payload using a schema based on the IEC 61968 UMLUses RESTful model of interaction (GET, PUT, POST, DELETE)Uses TLS for point to point security between Client and ServerIEEE 2030.5 is part of the NIST/SGIP Catalog of Standards
CSIP uses the IEEE 2030.5 security model
July 24, 2018
Kitu Systems
3
Wired, Wireless, Powerline
Ethernet (802.3) MAC
IPv4, IPv6
TCP
UDP
User Application
Physical Layer
Link Layer
Network Layer
Transport Layer
Presentation Layer
Application Layer
HTTP(S)
mDNS
IEEE 2030.5 (XML Schema)
Slide4IEEE 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
Slide5IEEE 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
July 24, 2018
Kitu Systems
5
TLS
_
ECDH
E
_
ECDSA
_WITH_
AES_128
_
CCM_8
Key Exchange Algorithm
Elliptic-CurveDiffie-HellmanEphemeral
Signature Authentication Algorithm
Elliptic-CurveDigital Signature Algorithm
Bulk Encryption AlgorithmAES-128(128-bit blocks)
(128-bit keys)Message Authentication Algorithm
Counter with CBC-MAC
AEAD Algorithm
TLS 1.2
Slide6Cipher Suite: TLS Details
Mandates the use of TLS version 1.2
Prevents protocol downgrade attacksMandates the use of the single cipher suitePrevents weak cipher downgrade attacks
Promotes interoperabilitySupports Mutual Authentication of the Server and Client Both the Server and Client have certificates that are exchanged and authenticated during the TLS HandshakeNo 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
Slide7Cipher 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 SecretThe security of ECDH is based on the elliptic curve analog of the discrete-log problemUses 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 ECDH
E
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, 2018Kitu Systems
7
Slide8Cipher Suite: Signature Algorithm Details
Uses Elliptic Curve Digital Signature Algorithm
The elliptic curve variation of the Digital Signature Algorithm for authenticationThe security of ECDSA is based on the elliptic curve analog of the discrete-log problemUses the well-known NIST P-256 (also known as secp256r1 and prime256v1)
The P-256 curve provides 128 bits of securityOne 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
Slide9Cipher 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 HandshakeAES-128 provides 128 bits of securitySHA-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
Slide10Cipher 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 messageUses AES-128 as the underlying encryption algorithmThere are efficient hardware and software solutions for implementing CCM. Most ZigBee devices have hardware support for CCM.
July 24, 2018
Kitu Systems
10
Slide11Cipher 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 timeWhat 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 implementationWhat were the NSA Suite B recommendations in 2013?Defined two levels of security
SECRET – equivalent to 128 bits of security
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
Slide12Cipher 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
Slide13Cipher Suite: Looking Forward – Is the Cipher Suite Still Good?
TLS 1.3
TLS 1.3 was recently approved and will eventually replace TLS 1.2One 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 RSAThe IEEE 2030.5 Cipher Suite complies with all the security features used in TLS 1.3
July 24, 2018
Kitu Systems
13
Slide14Cipher Suite: Looking Forward – Is 128 bits of Security Still Good?
Is 128 bits of security still good in 2018?
Yes, see comparison chartThere are no known weaknesses to AES-128 or ECC with the P-256 curveComparison with Financial Industry Requirements
The Payment Card Industry (PCI) Standard version 2 (2014) requires a security strength of 112 bits to secure financial transactions
July 24, 2018
Kitu Systems
14
Bits of
Security
Cipher Algorithm
PCI 2.0
Compliant
Suite B
SECRET
Suite B
TOP SECRET
CNSS
02-15
≤ 56
DES
80
2L-TDES
RSA 1024
ECC 160
112
3L-TDEA
RSA 2048
ECC 224
128
AES-128
RSA 3072
ECC 256
192
AES-192
RSA 7680
ECC 384
256
AES-256
RSA 15360
ECC 512
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 certificatesAll 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 keyThis key is obtained out of band (e.g. directly from the Root CA or other trusted source)This key is used to validate the certificate chain exchanged during the TLS HandshakeThe 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
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
Slide16PKI: Certificate Authority Infrastructure Options
Option 1 – Root CA issues Device Certificates
The Root CA is the top node in the chainThe Root CA directly issues device certificatesThe 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.
July 24, 2018
Kitu Systems
16
Slide17PKI: Certificate Authority Infrastructure Options
Option 2 – Root CA authorizes an Issuing CA to issue Device Certificates
The Root CA is the top node in the chainThe Manufacturer Issuing CA is authorized by the Root CAThe MICA’s certificate is signed by the Root CA
The MICA issues device certificatesThe device certificates are signed by the MICA
July 24, 2018
Kitu Systems
17
Slide18PKI: Certificate Authority Infrastructure Options
Option 3 – Root CA authorizes a Manufacturer CA which authorizes an Issuing CA to issue Device Certificates
The Root CA is the top node in the chainThe Manufacturer CA (MCA) is authorized by the Root CAThe MCA’s certificate is signed by the Root CA
The MCA authorizes the MICA issues device certificatesThe MICA certificates are signed by the MCAThe MICA issues device certificatesThe device certificates are signed by the MICA
July 24, 2018
Kitu Systems
18
Slide19PKI: 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
Slide20PKI: 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.
In many cases, there are no trusted time sources available or access to the internet
Even if there is a time source, it may not be sync’d to actual real time.
July 24, 2018
Kitu Systems
20
Slide21PKI: 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 serversDevices 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