IEC 62056 DLMS/COSEM seminar Cryptographic · PDF fileIEC 62056 DLMS/COSEM seminar . Cryptographic security. ... Unprotected or protected DLMS service response(s) COSEM-RELEASE request

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


Agenda


• 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


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


device


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


device


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)


device


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


device


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


device


DLMS/COSEM security suites

• DLMS/COSEM uses security algorithms selected by NSA (National Security Agency) Suite B, using approved FIPS / NIST standards


device


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


device


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


device


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


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


device



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


contexts


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


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


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


device


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


device


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


Service specific ciphering


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


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


General-glo and general-ded ciphering


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)


Security Header

Security Header

Security Header


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


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




Security Header

Security Header

Security Header



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.


• Use pre-established or transaction keys

• Client-server or third party-server

• Compression is also available

device


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.


• Client-server or third party-server

device


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


device


Use of Data protection object


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


Data protection example


device


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


device



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


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


Symmetric key and their management


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


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


device


Asymmetric keys and their use


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



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



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


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


Documents

IEC 62056 DLMS/COSEM seminar Cryptographic · PDF fileIEC 62056 DLMS/COSEM seminar . Cryptographic security. ... Unprotected or protected DLMS service response(s) COSEM-RELEASE request