powerpoint 프레젠테이션ants.mju.ac.kr/2015fall/61850/iec 62351(1)… · ppt file · web...

IEC 62351Power systems management and

associated information exchange –Data and communications security

Myongji univ.Sugwon Hong

Scope of IEC 63251• The scope of the IEC 62351 series is information

security for power system control operations. • The primary objective is to

– Undertake the development of standards for security of the communication protocols defined by IEC TC 57, specifically the IEC 60870-5 series, the IEC 60870-6 series, the IEC 61850 series, the IEC 61970 series, and the IEC 61968 series.

– Undertake the development of standards and/or technical reports on end-to-end security issues.

2

IEC TC 57 standardization activities for security

• In 1997 IEC TC57 established AdHoc WG6, recognizing the necessity for security for TC57 protocols.

• In 2003, as a result, TC57 AdHoc WG 6 published TR 62210.– It proposed to establish WG 15 to security standards

including DNP.• WG 15

– ”Power system control and associated communication – Data and communication security”

– Scope and goal:• Undertake the development of standards for security of the

communication protocols defined by the IEC TC57.• Undertake the development of standards and/or technical

reports on end-to-end security issues.”– In 2007, Published IEC 62351, Parts 1-7 as final documents

3

IEC TC 57 protocols• IEC 60870-5• IEC 60870-5 derivative (DNP 3.0)• IEC 60870-6(TASE.2 or ICCP)• IEC 61850• IEC 61334(DLMS)– a standard for low-speed reliable power

line comm. by electricity meters, water meters and SCADA.

4

Status of IEC 62351 Parts(1)(2014. 9)

5

IEC 62351 Part Released Activities (by May 2014) Planned ReleaseIEC/TS 62351-1: Introduction 2007 -IEC/TS 62351-2: Glossary of terms 2008 Review Report pending Pending

IEC/TS 62351-3: Security for profiles including TCP/IP

2007 Ed. 2: Responses to Comments on CDV being developed

Submitted as CDV by Dec 2012, FDIS Dec 2013, IS Ed. 2 by 2014?

IEC/TS 62351-4: Security for profiles including MMS

2007 Starting Edition 2After amendment process was rejected, the decision was made to start Edition 2

Comments on Q rec’d Dec 2013 Ed. 2: CD 6/2015, CDV 3/2016, FDIS

6/2016, IS Jun 2017IEC/TS 62351-5: Security for IEC 60870-5 and derivatives

2009 Ed. 2 released April 2013 TS Released April 2013Possible clarifications

IEC/TS 62351-6: Security for IEC 61850 profiles: GOOSE & SV

2007 Ed. 2 planed: Updates underway, based on security requirements in IEC 61850-90-5

RR to be issued mid-2014, to be released in parallel with Part 4

6

IEC/TS 62351-7: Objects for Network Management

2010 Working on Ed. 2: Responded to comments on RR changing TS to IS

CD 9/2014, CDV 6/2015, FDIS 3/2016, IS 9/2016

IEC/TS 62351-8: Role-Based Access Control : RBAC

2011 Working on Ed. 2: Discussions on developing categories of roles

Planning IS in 2014/15 after TR 90-1 issued

IEC/TS 62351-9: Key Management

Pending Working on Ed. 1: 1st CD issued August 2013; Responses submitted Feb 2014. 2nd CD planned

2nd CD August 2014, CDV in (early) 2015 and IS in (late) 2015

IEC/TR 62351-10:Security Architecture

2012 TR published Oct 2012No further work planed.

Done

IEC/TS 62351-11:Security for XML Files

Pending Working on Ed. 1: Developing CD for WG15 review by May 2014

CD 6/2014, CDV 2/2015, FDIS 12/2015, IS 6/2016

PWI: Resiliency and Security for power systems with DER

DC Pending

Need broader review by WG17 & 21 before submittal as TR as 62351-12

Review in WG17 and WG21, Circulated in WG19 early 2014

PWI: Conformance Testing for IEC 62351

NWIP Pending

Pending Pending

PWI: IEC 62351-90-1: Guidelines for Using Part 8 RBAC

TR Pending

Work in progress Pending

Status of IEC 62351 Parts(2)(2014. 9)

Security threats and requirements

7

requirements threats

Confidentiality( 기밀성 ) Unauthorized access to message contents(information)

Integrity( 무결성 ) Unauthorized modification of contents, message replay

Availability( 가용성 ) Denial of service(performance degradation)

Authentication ( 인증 ) Spoofing(message falsification, source falsification)Unauthorized access

Authorization ( 인가 ) Unauthorized access to system resources

Non-repudiation( 부인 봉쇄 )

Denial of action that took placeClain of action that did not take place

8

security solutions• IEC 62351 에서는 새로운 보안 알고리즘을 만드는 것이

아니라 현재 IT 에서 공인된 보안 알고리즘 ( 프로토콜 )들을 주어진 요구사항을 만족시킬 수 있는 최적의 solution 을 찾는다 .

9

requirements Security measuresconfidentiality encryptionintegrity HMAC, Digital Signatureavailability (IDS, firewall)authentication

HMAC, Digital Signature

Non-repudiation

HMAC, Digital Signature

authorization Access authorization

KS security algorithms

10

category algorithm Reference standardCypto algorithm SEED(KISA)

ARIA (NIS)KS X 1213-1TTAS.KO-12.0004/R1

Hash function SHA-2HAS-160

FIPS 180-3TTAS.KO-12.0011/R2

MAC HMAC FIPS 198-1Random number generation

KCDSA PRNGTTAS, KO-12.001/R1

NSA Suite B algorithms

11자료 : Cisco

IEC 61850 services

12

TC57 protocols and IEC 62351

13

IEC 62351-3

14

Purpose• to provide end-to-end transport security for

the communications between software applications.

• Rather than re-inventing the wheel, it specifies the use of TLS which is commonly used over the Internet for secure interactions, covering authentication, confidentiality, and integrity.

• describes the mandatory and optional parameters and settings for TLS that should be used for utility operations.

15

IEC 62351-3• provides security for any profile that includes

TCP/IP. – IEC 61850 over TCP/IP– IEC 60870-5 part 104 (DNP over TCP/IP)– ICCP

• Scope of protection– eavesdropping– Man-in-the-middle attack(message authentication)– Spoofing (node authentication)– Replay attack– Not DoS

16

Some of key aspects• Use TLS 1.0 or higher (which is equivalent to Secure Sockets

Layer (SSL) 3.1).• Transparent key re-negotiation based upon time and number of

packets, so that lightly loaded networks do not lose certification over long time periods, since most connections are long term. Both time and number are configurable, but the recommended parameters are time (10 min) and number of packets (5 000).

• The entity that was connected to is responsible for key negotiation. This avoids protocol deadlocking.

• Standardization for support for at least one common cipher suite, AES.

• Specification of TLS message authentication to avoid spoof and replay.

• Can request small certificates to minimize the burden.

17

Security measures• TLS– obliged to use encryption– MAC– Certificate support

• Scope

18

threats measures(TLS)eavesdropping encryptionspoofing(Man-in-the-middle)

Node authentication(Message authentication

replay Message athenticationDoS No support

TLS and TCP/IP

Application

TCP

IP

General application

HTTP

TSL

TCP

IP

Application based on TLS

19

TSL procedure• Handshake: A client authenticate a server and

they exchange values needed to compute keys.• Key derivation: A client and server compute

keys using the values they share during exchange.

• Data transmission: data is segmented into records and each encrypted record is sent with MAC.

• termination: Special messages to securely close connection

20

21

SSL Handshake ProtocolClient server

client_helloserver_hellocertificate

server_key_exchangecertificate_requestserver_hello_donecertificate

client_key_exchangecertificate_verify

change_cipher_specfinished

change_cipher_specfinished

Phase 1

Phase 2

Phase 3

Phase 4Blue: optinal messages

Handshake (1)goal1. Server authentication2. Negotiation of crypto algorithms3. Key establishment4. Client authentication (option)

22

Handshake (2)1. C -> S: crypto algorithms list, client nonce (Rc)2. S -> C: chosen algorithm + certificate + server

nonce (Rs)3. C: verify certificate, extract a server’s public key,

generate pre_master_secret(PMS), send PMS encrypted by a server’s public key.

4. C and S: compute encryption and MAC keys by using PMS and nonces.

5. C: send all handshake messages with MAC. 6. S: send all handshake messages with MAC.

23

Key computation• Not desirable to use a single key.– Use different keys for encryption and MAC.

• 4 keys:– Kc = client’s encryption key(symmetric key)– Mc = client’s MAC key– Ks = server’s encryption key(symmetric key)– Ms = server’s MAC key

24

IEC 62351-4

25

IEC 62351-4• Provide security for profiles that include MMS

(Manufacturing Message Specification) (ISO 9506) including TASE.2(ICCP) and IEC 61850.

• Security attacks– unauthorized access to information– unauthorized modification (tampering) or theft of

information– Man-in-the-middle– Message replay

26

Security measure• TLS– authentication– confidentiality– data integrity– non-repudiation

• allows both secure and non-secure profiles to be used simultaneously, so that not all systems need to be upgraded with the security measures at the same time.

27

IEC 62351-5

28

IEC 62351-5• Provide two different solutions for the serial

version(IEC 60870-5-101) and for the networked version (IEC 60870-5-104 and derivatives such as DNP over TCP/IP)

• provides application layer authentication which protects against spoofing, replay, modification, and some denial of service attacks.

• does not include encryption, so it does not protect against eavesdropping, traffic analysis, or repudiation.

29

Security measures• Networked version (TCP/IP)

– Utilized the same measures described in IED 62351-3– TLS

• Serial version– used with communications media that can only

support low bit rates or with field equipment that is compute-constrained.

– Provide simple authentication mechanism– Encryption is not mandatory.– Similar to the Secure DNP3

30

Secure DNP3• Developed by DNP User group– Similar to IEC 62351-5(cooperated work by IEC

and DNP UG)– Published in 2008

• goal– Authentication and message integrity

• Prove that messages are sent from trusted(authorized) users

• Prove that messages are not modified– Low overhead– Remote key management

31

Security measures• Based on Challenge-Handshake

Authentication Protocol (RFC 1994)– Challenge-Response mode

• To prove the source(sender) authentication and message integrity, utilize the Hashed Message Authentication Method(HMAC)

32

Challenge-response• When a node receives a message which is

considered to be critical, it requires authentication.(challenge)

• The challenged node sends a random value and a sequence number with the hash value computed with them.

• The challenge node verify the message authenticity by computing the hash value.

33

Initialization

Key challenge seq numUser number

HMAC algorithmpseudorandom challenge data

Master Field station

Key statusKey wrap algorithm(AES-128)

User number

34

Challenge-response

non-critical message

standard protocol response

critical message

authentication challenge

authentication reply

standard protocol response

challenge seq numUser numberHMAC algorithm

pseudorandom challenge datachallenge seq num

User numberHMAC value

responder challenger

35

Aggressive mode• Avoid doing challenge every time, so simplify

the challenge-response procedure.• Even in this case, at least one challenge must

be done.– afterward the same challenge value is kept using.

• The node that sends a critical message sends a rand value, a sequence number, and a session key with the hash value to be computed.– A sequence number is generated by a master

station.

36

Aggressive modenon-critical message

standard protocol response

critical message

authentication challenge

authentication reply

standard protocol response

responder challenger

critical message

standard protocol response37

Key management• Two keys– Session key

• Used to compute HMAC• Updated periodically(10-15min interval, data transmission

occurs every 2 sec in SCADA)• When send an updated session key, the key is encrypted by

an update key.– Update key

• Every node have this key permenently.• pre-shared at each node.• If any node loses this key, it must be reinstalled. (headache)

38

Session key update

Session key change

Session key status

challenge seq numUser numberHMAC value

Master Field station

Key challenge seq numUser number

HMAC algorithmpseudorandom challenge data

Key status (OK)Key wrap algorithm(AES-128)

39

IEC 62351-6

40

IEC 62351-6• The target is the security for real-time

messages (GOOSE, SMV) delivered in the substation LAN.

• characteristics of three messages

41

SMV GOOSE MMSPDU size ~1,500 ~1,500 >30,000Response delay <4ms <4ms nonemulticast connectionless connectionles

sConnection-oriented

X.509 certificate No No Yesencryption No Yes if >4ms YesDetection of mal-message

Yes Yes Yes

Main characteristics• The main goal is authentication.

– To provide source authentication and messag integrity at every node.

• Do not require encryption– Hard to implement the encryption in processing

GOOSE and SMV messages within 4ms and providing multicast at the same time.

• Backward compatibility– Non-secure devices may disregard the security

part of the GOOSE/SMV message.

42

Security measure• MAC– HMAC (SHA256)– or digital signature (RSA)

43

Hash function• A function H( ) inputs a

message of arbitrary lengh and outputs a shorter, fixed message stream.

• H( ) : many-to-1 function• H( ) is called “hash

function.”• The output of the hash

function is often called “message digest.”

• Requirements for hash function:– Easy to compute– one-way: not possible to

compute m from H(m)– Collision avoidance: not

possible to compute m and m’ such as H(m) = H(m’) 인 m 과 m’

– Output value should be random.

large message

mH: HashFunction

H(m)

44

Standard hash functions• MD5 (RFC 1321) – Widely used– 4 steps, 128-bit message digest

• SHA-1– US standard [NIST, FIPS PUB 180-1]– 160-bit message digest

• SHA-2– These days, SHA-2 becomes mandatory in

Korea.

45

HMACm

essa

ge

H( )

s

mes

sage

mes

sage

s

H( )

compare

s = shared secret

• Authenticate a sender• Prove message integrity• No encryption !• Also called “keyed hash”• Notation: MDm = H(s||m) ; send m||MDm

46

HMAC (RFC 2104)• Widely used MAC standards• Any hash function can be used such

as MD5 and SHA-1.• Application example: OSPF

– Attach types• Message insertion (spoofing)• Message elimination• Message modification

– How can a router confirm that the message to be received is true?

47

large message

mH: Hashfunction H(m)

digitalsignature(encrypt)

Bob’s private

key K B-

+

Bob sends a message with digital signature.

Alice verify the sender authenticity and message integrity by digital signature.

KB(H(m))-

encrypted msg digest

KB(H(m))-

encrypted msg digest

large message

m

H: Hashfunction

H(m)

digitalsignature(decrypt)

H(m)

Bob’s public

key K B+

equal ?

Digital signature(public key encryp + hash)

48

62851-6 message extension

49

(IEC)

62351-6 problems• When digital signature is used, how

do we implement RSA?– SW/FPGA/ASIC – Hard to meet 4ms delay

• Also problem of the certificate use• interoperability– Backward compatibility

50