/
IEEE 2030.5 Security Overview IEEE 2030.5 Security Overview

IEEE 2030.5 Security Overview - PowerPoint Presentation

magdactio
magdactio . @magdactio
Follow
349 views
Uploaded On 2020-06-30

IEEE 2030.5 Security Overview - PPT Presentation

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

security suite 2030 systems suite security systems 2030 ieee key 128 device certificate tls cipher kitu 2018 july root

Share:

Link:

Embed:

Download Presentation from below link

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.


Presentation Transcript

Slide1

IEEE 2030.5 Security Overview

July 24, 2018

Kitu Systems

1

Gordon Lum

Kitu Systems

Slide2

Agenda

Brief IEEE 2030.5 Overview

IEEE 2030.5 TLS Cipher SuiteIEEE 2030.5 Public Key Infrastructure (PKI)

July 24, 2018

Kitu Systems

2

Slide3

IEEE 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)

Slide4

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

Slide5

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

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

Slide6

Cipher 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

Slide7

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 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

Slide8

Cipher 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

Slide9

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 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

Slide10

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 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

Slide11

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 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

Slide12

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

Slide13

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.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

Slide14

Cipher 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

 

 

 

Slide15

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

Slide16

PKI: 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

Slide17

PKI: 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

Slide18

PKI: 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

Slide19

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

Slide20

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.

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

Slide21

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 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