Date post: | 14-Mar-2018 |
Category: |
Documents |
Upload: | vuongthuan |
View: | 378 times |
Download: | 28 times |
device
languagemessagespecification
IEC 62056 DLMS/COSEM seminar
Cryptographic security
EUW 2014, Amsterdam
Győző Kmethy, DLMS UA, President
Victoria Varjú, DLMS UA, Support manager Bas Roelofsen, DNV GL, Consultant
DLMS seminar EUW 2014 – Security 1
device
languagemessagespecification
Agenda
DLMS seminar EUW 2014 – Security 2
• 13:00 Registration • 13:30 DLMS/COSEM overview • 14:00 COSEM model news • 15:00 Coffee break • 15:30 DLMS services news • 16:00 Security extensions • 16:30 DLMS/COSEM communication profiles • 16:45 DLMS projects and interoperability testing • 17:00 Tools, demo, quiz • 17:15 Q/A • 17:30 End of the program
device
languagemessagespecification
Security – what’s new?
Possibilities to cryptographically protect messages and data further extended: That is:
• COSEM data and xDLMS message protection client-server / third party-server • xDLMS message protection client-server already in use
• Public key algorithms • Elliptic curve digital signature ECDSA • Elliptic curve Diffie-Hellman ECDH key agreement
• Two key sizes: symmetric 128 / 256 bit, asymmetric P-256 / P-384 curves • Interoperability by using NSA Suite B algorithms
• New general protection services that can be applied in a layered manner to any xDLMS APDU
• General-Ciphering • General-Signing
DLMS seminar EUW 2014 – Security 3
device
languagemessagespecification
Privacy and security • Why to protect?
– privacy of consumers to be respected – smart metering becomes critical infrastructure
• What to protect? – sensitive data e.g. consumption, debt, parameters – critical commands e.g. supply control, parameter activation – security key establishment – firmware upgrade – Physical protection of data in storage is out of the Scope
• Where to protect? – COSEM model and application layer level:
• end-to-end security • allows selective application of security • media independent
– lower protocol layers may provide also security: e.g. TLS , PRIME PLC, G3-PLC –
• How to protect? – security algorithms: NSA Suite B / FIPS / NIST
DLMS seminar EUW 2014 – Security 4
device
languagemessagespecification
Summary of security requirements
• Authentication of communicating partners • Controlling access rights depending on the role of the client • End-to-end security between third party and server • Protection of COSEM data and xDLMS messages • Multi-level protection applied / verified by different entities • Configurable security suites (what algorithms?) and policies (what
protection?) • Only approved security algorithms: NSA suite B, NIST, FIPS
• Well defined key management • Security logs and alerts • Physical security (out of scope of DLMS/COSEM)
DLMS seminar EUW 2014 – Security 5
device
languagemessagespecification
DLMS/COSEM security toolbox
• Authentication of communicating partners – client only (LLS, Low Level Security authentication) – client / server (HLS, High Level Security authentication)
• Access rights – Client’s rights to access COSEM object attributes and methods, depending
on its role
• DLMS message and COSEM data security – Authenticity, integrity, confidentiality
• Key management • Security event logs
DLMS seminar EUW 2014 – Security 6
device
languagemessagespecification
Security context
Determines the rules for applying / verifying security
• Security suite: set of cryptographic algorithms – Symmetric key: AES-GCM, AES Key Wrap – Public key: Elliptic Curve Digital Signature, EC Diffie-Hellman Key Agreement
• Security policy: protection to be applied to messages (generally, i.e. for all requests and all responses)
• Access rights – read / write /execute – protection to be applied to request and response on attribute / method level
• Security material: symmetric and asymmetric keys, initialization vectors, nonces
• DLMS/COSEM provides the necessary security tools
• Security suites and policies have to be selected according to the project needs
DLMS seminar EUW 2014 – Security 7
device
languagemessagespecification
DLMS/COSEM security suites
• DLMS/COSEM uses security algorithms selected by NSA (National Security Agency) Suite B, using approved FIPS / NIST standards
DLMS seminar EUW 2014 – Security 8
device
languagemessagespecification
Security implementation
• Association objects control access rights • Security setup objects control security suite&policy and manage keys • Data protection objects manage COSEM data protection
• Association Control Service Element (ACSE) controls contexts
• Application context • LN or SN referencing • ciphered / unciphered APDUs
• Authentication mechanism • LLS / HLS authentication
•xDLMS context: list of services, use of dedicated key
COSEM application process
Association object
Security setup obejcts
Application obejcts
DLMS/COSEM application layer
ACSE xDLMS ASE Security
context
Lower layers
(Protected) APDUs
Service response + security options
Service request+ security status
Verify / remove / apply protection
DLMS seminar EUW 2014 – Security 9
device
languagemessagespecification
Application Association
+ + +
Multi-stage protection
Identification
& Authenti-
cation
Security policy
Access rights Data
protection
• Identification and 1 way / 2 way authentication of partners • Security policy: sets general message protection requirements
• combination of authentication, encryption and digital signature on requests and responses
• Access rights: sets local (attribute / method level) message protection requirements
• Protection has to meet the stronger requirement set by policy and access rights • Data protection: protection requirements of attribute values, method invocation
and return parameters
DLMS seminar EUW 2014 – Security 10
device
languagemessagespecification
Security policy
Security policy
Access rights
Protecting DLMS messages and COSEM data
COSEM object
Atribute #1
Methods
Atribute #n Atribute #2
COSEM object
Atribute #1
Methods
Atribute #n Atribute #2
COSEM object
Attribute #1
Methods
Attribute #n Attribute #2 Access
rights
Data protection
params
Read / Write attribute COSEM data
Head
end
syst
em
Invoke method COSEM data
Read / Write attribute COSEM data
Invoke method COSEM data
Server Identification and authentication Client
Data protection object
protection_buffer
get_protected_attrs.
protection_obj_list
protection_params_get
set_protected attrs.
invoke _protected_ method
required_protection protection_params_get
Identification & Authenti-
cation
11
device
languagemessagespecification
Authentication security
Server
LLS Secret
Client LLS secret
Server
HLS secret (S)
Client CtoS
StoC
f(StoC)
f(CtoS)
HLS secret (S)
• Authentication: verifying the claimed identity of the partners before data exchange
• identification elements: system title, client user id, secrets, Service Access Point (SAP) • Authentication procedures
– no security: „public” access, no identification takes place – LLS, Low Level Security authentication: server identifies client by password – HLS, High Level Security authentication: mutual identification
• exchange challenges • exchange result of processing the challenge using different algorithms
• Different Associations may use different Authentication mechanisms • All Association events may be logged in Event logs
The relationship between the authentication and data exchange phase is shown on the next slide
DLMS seminar EUW 2014 – Security 12
device
languagemessagespecification
DLMS seminar EUW 2014 – Security 13
Phase 2:Message exchange
DLMS/COSEM Client DLMS/COSEM Server
COSEM-OPEN request (Client_SAP, Server_SAP, (System_Title), (Certificate), (Client_User_Id), proposed contexts)
COSEM-OPEN response (Client_SAP, Server_SAP, (System_Title), (Certificate), negotiated contexts)
Check proposed /Apply negotiated
contexts
No security (lowest level security)
authentication
COSEM-OPEN request (Client_SAP, Server_SAP, (System_Title), (Certificate), (Client_User_Id), Password, proposed
contexts)Low Level Security (LLS) authentication:
Password in AARQ
COSEM-OPEN request (Client_SAP, Server_SAP, (System_Title), (Certificate), (Client_User_id), CtoS, proposed contexts)
COSEM-OPEN response (Client_SAP, Server_SAP, (System_Title), (Certificate), StoC, negotiated contexts)
High Level Security (HLS) authentication:
Pass 1: CtoS in AARQPass 2: StoC in AARE
Pass 3: Send f(StoC)Pass 4: Receive f(CtoS)
Response to challenge: f (StoC)
Response to challenge: f (CtoS)
Unprotected or protected DLMS service request(s)
Unprotected or protected DLMS service response(s)
COSEM-RELEASE request (Client_SAP, Server_SAP)
COSEM-RELEASE response (Client_SAP, Server_SAP)
Application Associations (AAs) pre-configured in Server: Application context, Authentication mechanism, xDLMS context, Access rights, Security context
Release contexts
Check proposed /Apply negotiated
contexts
Check proposed /Apply negotiated
contexts
Phase 3:AA release
Phase 1:AA establishment
COSEM-OPEN response (Client_SAP, Server_SAP, (System_Title), (Certificate), negotiated contexts)
Invoke reply_to_HLS_authentication method of current “Association” object.The messages may be cryptographically protected.
device
languagemessagespecification
Telephone GSM
PLC Internet xDxy
Meter
Door Keeper
Associations Registers Profiles Clock Activity
Calendar
“Utility A” device Associations Registers Profiles Clock
W
Activity Calendar Associations Registers Profiles Clock Activity
Calendar Associations Registers Profiles Clock
R
Activity Calendar Associations Registers Profiles Clock Activity
Calendar
Associations Registers
“meter operator” device
Meter Operator
Utility A Utility A Utility A
Utility B
Associations Profiles Clock
“Utility B” device
Access control: object_list and access rights
• Managed by Association LN / Association SN objects
• Object_list provides the list of COSEM objects, their attributes and methods visible in the given Association
• Access_rights determine the cryptographic protection required DLMS seminar EUW 2014 – Security 14
device
languagemessagespecification
Message (APDU) protection
• Cryptographic protection to messages – xDLMS APDUs – during transport ‒ authentication to ensure authenticity (legitimate
source) and integrity of messages ‒ encryption to ensure confidentiality ‒ authenticated encryption to provide both ‒ digital signature: authentication and non-repudiation ‒ these can be applied in any combination, separately on
the requests and the responses
DLMS seminar EUW 2014 – Security 15
device
languagemessagespecification
Message protection
xDLMS message
xDLMS message Auth. code Auth
Encrypted xDLMS message Encr
Plain xDLMS message Signature Sig
Encrypted xDLMS message Auth. code Auth+Encr
• Protection determined by • security policy: sets general message protection requirements • access rights: sets local, COSEM object attribute / method level
protection requirements • the stronger requirement applies • protection can be applied independently on requests and responses
DLMS seminar EUW 2014 – Security 16
device
languagemessagespecification
AES-GCM ciphering and compression
17
AES Galois / Counter mode
authenticated encryption
AES Galois / Counter mode
authenticated decryption
EK EK
Ciphertext
T
(C) Information T
IC
IC
IC
Reconstructed information
Encryption only
(C) Information
Authentication only
Authenticated encryption
(C) Information
AAD = SC II AK
AAD = SC II AK II (C) Information
C
Fail
AT C T
P P
SC
SC
SC
ICSys-T ICSys-T
Ciphered Information: Encryption only
Security Control byte, SC
Ciphered Information: Encryption + Authentication
Ciphered Information: Authentication only
(C) Information: Compressed information A = AAD P = PlaintextAK =Authentication key SC = Security control byteC = Ciphertext SH = SC II IC Security headerEK = Encryption key Sys-T = System title (originator)IC = Invocation counter T = Authentication tag IV = Sys-T II IC Initialization vector
Information to be protected
Additional Authenticated Data AAD (Associated data) contains:- Authentication only: SC II AK II (C) Information;- Encryption only: Null- Authenticated encryption: SC II AK - In the case of the general-ciphering service, AAD contains additional elements as well.
IV IV
AAD = nullSC-E: bit 5=1
SC-AE: bit 4, 5=1
SC-A: bit 4=1
AAD = SC II AK
AAD = SC II AK II (C) Information
AAD = null
A
Ciphertext
SC-C: bit 7=1Compression Compression
Compressed information
Decompression
(C) Information
SH
device
languagemessagespecification
Service specific ciphering
DLMS seminar EUW 2014 – Security 18
AuthtagSC-A Inv.
Ctr
Security context: Security suite - Security policy - Access rights - Security material
Unprotected APDU
SC-E Inv. Ctr
AuthtagSC-AE Inv.
Ctr
Encrypted APDU(Ciphertext)
APDU to be protected Ciphered APDU
Authentication only
Symmetric key encryption and authentication
Encrpyted APDU(Ciphertext)
Len
Len
Len
Encryption only
Authenticated encryption
OCTET STRING
OCTET STRING
OCTET STRING
Tag
Tag
Tag
Security Header
Security Header
Security Header
Security Control byte, SC
C = Compression appliedA = Authentication appliedE = Encryption applied
• Most xDLMS APDUs have plain and ciphered variants • Use pre-established global or dedicated keys • Client-server only • ACCESS and Data-Notification APDUs do not have these: general protection is used
device
languagemessagespecification
General-glo and general-ded ciphering
DLMS seminar EUW 2014 – Security 19
Authtag
SC-A /SC-CA
Inv. Ctr
Security context:Security suite - Security policy - Access rights Security material
SC-C
SC-E /SC-CE
Inv.Ctr
Authtag
SC-EA /SC-CEA
Inv. Ctr
Compressed APDU
ciphered-content
Compression only
(Compression and)Authentication only
Compression Symmetric key encryption and authentication
Len
Len
Len
OCTET STRING
Len
(Compression and)Encryption only
(Compression and)Authenticated encryption
Tag ciphered-content
OCTET STRING
OCTET STRING
OCTET STRING
system-title
APDU to be protected
(Compressed) Unprotected APDU
(Compressed and) encrypted APDU (Ciphertext)
(Compressed and) encrypted APDU (Ciphertext)
Security Header
Security Header
Security Header
Security Control byte, SC
C = Compression appliedA = Authentication appliedE = Encryption applied
• Can be applied on any xDLMS APDU
• Use pre-established global or dedicated keys
• Client-server only
• Compression is also available
device
languagemessagespecification
General-ciphering
20
Security context:Security suite - Security policy - Access rights
Security material
APDU to be protected ciphered-contentCompressionSymmetric key encryption and authentication
Tag ciphered-contenttransaction-id originator-system-title
recipient-system-title date-time other-
information key-info
Authtag
SC-A /SC-CA
Inv. Ctr
SC-N /SC-C
SC-E /SC-CE
Inv.Ctr
Authtag
SC-EA /SC-CEA
Inv. Ctr
(Compression and)No protection
(Compression and)Authentication only
Len
Len
Len
OCTET STRING
Len
(Compression and)Encryption only
(Compression and)Authenticated encryption
OCTET STRING
OCTET STRING
OCTET STRING
(Compressed) Unprotected APDU
(Compressed and) encrypted APDU (Ciphertext)
(Compressed and) encrypted APDU (Ciphertext)
Security Header
Security Header
Security Header
(Compressed) Unprotected APDU
Security Control byte, SC
N = No protection appliedC = Compression appliedA = Authentication appliedE = Encryption applied
All fields are A-XDR encoded OCTET STRINGs.The length and the value of each field is included in the AAD.
• Can be applied on any xDLMS APDU
• Use pre-established or transaction keys
• Client-server or third party-server
• Compression is also available
device
languagemessagespecification
General-signing
Elliptic curve digital signature algorithm
Security context:Security suite - Security policy - Access rights
Security material
content
Tag contenttransaction-id originator-system-title
recipient-system-title date-time other-
information signature
Additional fields
Additional fields
All fields are A-XDR encoded OCTET STRINGs.The length and the value of each field contribute to the signature.
• Can be applied on any xDLMS APDU
• Client-server or third party-server
device
languagemessagespecification
Cryptographic protection of COSEM data
• Use case: critical data have to be kept secret to the client (HES)
• Re-uses the solutions for protecting xDLMS messages on the COSEM object level
DLMS seminar EUW 2014 – Security 22
device
languagemessagespecification
Use of Data protection object
DLMS seminar EUW 2014 – Security 23
Target COSEM object attributes and methods“Data protection” object
COSEM attribute {class_id, …}COSEM attribute {class_id, …}
COSEM attribute {class_id, …}
COSEM attribute{class_id, logical_name, attribute _index, data_index, restriction}
COSEM attribute{class_id, logical_name, attribute _index, data_index, restriction}
1. logical_name
2. protection_buffer
3. protection_object_list
4. protection_parameters_get
6. required_protection
1. get_protected_attributes
2. set_protected_attributes
3. invoke_protected_method
COSEM attribute{class_id, logical_name, attribute_
index, data_index, restriction}
COSEM method {class_id, logical_name,
method_index}
Push
Capture to “Profile generic”
protection_parameters_get is used to apply protection when protection_buffer is read.
protection_parameters_set is used to remove protection when protection_buffer is written.
protection_object_list references attributes the values of which are captured to or written from protection_buffer.
.req {object_list, protection_param’s}.res {protection_param’s, protected Data}
.req {object_list, protection_param’s, prot. Data}.res {action_result}
.req {object_method, prot._param’s, prot. Data}res. {protection_param’s, protected Data}
COSEM attribute {class_id, …}COSEM attribute {class_id, …}
COSEM attribute {class_id, …}
required_protection stipulates minimum protection level when methods are invoked
APDUs carrying service invocations to access attributes and methods of “Data protection” are protected as stipulated by the access rights and by “Security setup” security_suite and security_policy.Master key and Certificates are held by “Security setup”.
.req {protected Data}.res {data-access-result}
.req {}.res {protected Data}
Remote readRemote write
Remote method invocation
When data protection is not required, attributes and methods are accessed directly with (protected) service requests.
Methods can be invoked by scripts if no return parameters are provided (e.g. Set)
5. protection_parameters_set
device
languagemessagespecification
Data protection example
DLMS seminar EUW 2014 – Security 24
device
languagemessagespecification
DLMS/COSEM E2E security
• Any combination of authentication (integrity), encryption (Confidentiality), digital signature (Non-repudiation)
• Protection can be applied in a layered fashion by market participant, client, server
DLMS seminar EUW 2014 – Security 25
device
languagemessagespecification
DLMS seminar EUW 2014 – Security 26
xDLMS/COSEM client (Head End System)
ρ acts as broker for TP or on its own
ρ (pre-)establishes AAs
ρ can verify / remove protection applied by TP or server
ρ may apply its own protection
Protection client - server
Protection TP - server
Attribute / method related services
Third Party (TP)xDLMS/COSEM client
user
ρ xDLMS/COSEM aware
ρ Uses a client-server AAs according to its role
ρ Can apply protection
ρ Can verify / remove protection applied by server and/or client
xDLMS/COSEM server(meter)
ρ AAs determine access rights
ρ Security setup objects determine security suite and policy
ρ Protection has to satisfy both security policy and access rights
ρ Access rights and security policy can be independently defined for requests and responses
ρ Can verify / remove and apply protection from and to client and TP
Protection TP - client
Application Association (AA)
Protection TP - server
Protection TP - server
Protection TP - client
Long messages are sent in blocks
Messages TP - client may bexDLMS messages or other, e.g. web services
Scenarios for using general protection services
Protection TP - server
Attribute / method related services Attribute / method related services
Attribute / method related services
Attribute / method related services
Data Protected Data
Layered end-to-end protection of COSEM data and xDLMS messages
Protection client - server
Data Protected Data
Data Protected Data
device
languagemessagespecification
Symmetric key and their management
DLMS seminar EUW 2014 – Security 27
Key type Purpose Key establishment Use
Master key, KEK 1)
Key Encrypting Key (KEK) for : - (new) master key; - global encryption or
authentication keys; - ephemeral encryption
keys.
Out of band
Can be identified as the KEK in general-ciphering APDUs between client-server, see Table 21
Key wrap
Key agreement 3)
Global unicast encryption key, GUEK 2)
Block cipher key for unicast - xDLMS APDUs and / or - COSEM Data
Key wrap - service-specific global ciphering APDU client-server
- general-glo-ciphering APDU client-server
- general-ciphering APDU client-server - “Data protection” object protection
parameters
Key agreement 3)
Global broadcast encryption key, GBEK 2)
Block cipher key for broadcast - xDLMS APDUs and / or - COSEM Data
Key wrap
(Global) Authentication key, GAK 2)
Part of AAD to the ciphering process of xDLMS APDUs and / or COSEM data
Key wrap All APDUs between client-server and third party-server Key agreement 3)
Dedicated key (unicast)
Block cipher key of unicast xDLMS APDUs, within an established AA
Key transport in xDLMS Initiate.request APDU
- service-specific dedicated ciphering APDU client-server
- general-ded-ciphering APDU client-server during the lifetime of an AA
Ephemeral encryption key
Block cipher key for: - xDLMS APDUs and/or - COSEM data
Key wrap - general-ciphering APDU client-server - “Data protection” object protection
parameters
Block cipher key for: - xDLMS APDUs and/or - COSEM data
Key agreement 4)
- general-ciphering APDU client-server or third-party server
- “Data protection” object protection parameters
device
languagemessagespecification
Management of symmetric keys (example)
• Encryption keys: • Global key: used in several sessions (AAs); unicast - broadcast
• global unicast key encrypts dedicated key
• Dedicated key: used in a single session (AA), then destroyed • Authentication key (optional with GCM)
• Global, unicast and broadcast • Master key: pre-established, used only to wrap global keys
1290 1290
1290 Concentrator
DCS
DLMS seminar EUW 2014 – Security 28
device
languagemessagespecification
Asymmetric keys and their use
DLMS seminar EUW 2014 – Security 29
Digital signature Key type Signatory Verifier Use
Digital signature key pair
Private key Public key
Signatory uses private key to compute digital signature: - on a xDLMS APDUs; and/ or - on COSEM data; or - on an ephemeral public key agreement key. Verifier uses public key to verify digital signature - on a xDLMS APDUs; and/or - on COSEM data; or - on an ephemeral public key agreement key received. Key agreement
Key type Party U Party V Use
Ephemeral key agreement key pair
Private key Public key
Private key Public key
In the case of the Ephemeral Unified Model C(2e, 0s, ECC CDH) scheme both parties have an ephemeral key pair. In the case of the One-Pass Diffie-Hellman C(1e, 1s, ECC CDH) scheme only party U has an ephemeral key pair.
Static key agreement key pair
Private key Public key
Private key Public key
In the case of the One-Pass Diffie-Hellman C(1e, 1s, ECC CDH) scheme only party V has a static key pair. In the case of the Static Unified Model, C(0e, 2s, ECC CDH) scheme both the party U and party V have a static key pair.
device
languagemessagespecification
Security - summary
Protection applied on COSEM objects and DLMS message level
Multi-stage, multi-layer protection End-to-end security, media independent Protection on lower layer can be applied Symmetric key and public key algorithms based on NSA
Suite B
DLMS seminar EUW 2014 – Security 30