powerpoint 프레젠테이션ants.mju.ac.kr/2015fall/61850/iec 62351(1)… · ppt file · web...
TRANSCRIPT
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