Introduction for Certificate-based Key Management

Design based on Provisioning Tool

2015.07.21Samsung Electronics Software R&D Center

Contents- Terminology

- Bacground

- How to approach

- CKM(Certificate-based Key Management) Architecture Overview for

Provisioning Management

- Entities Definition

- Certificate Issuing Operation Overview

- Device Certificate Issuing Sequence Flow

- Device Certificate Credentials Transfer Sequence Flow

- CRL Issuing Operation Overview

- CRL Generation Sequence Flow

- CRL Transfer Sequence Flow w/ SRM

Terminology

• In this project, we have defined terminology to avoid confusion of Certifi-cate Authority (CA) and Connectivity Abstraction (CA) in IoTivity.

• Term definitions– CKM : Certificate based Key Management– CKMInfo : Certificate based Key Management Information– CK Manager : Certificate based Key Manager

• Notice– In some cases of naming, especially internal modules of CKM, Certificate Author-

ity(CA) term could be used if one has meaning of Certificate Authority(CA) term itself or compound noun.

– e.g., “CACertificate” => Certificate Authority’s Certificate

Background

• OIC security requirement

1) Configuration and management approach to support certificate operation.(one of credTypes in OIC spec)

2) Very compact X.509 certificate format to cover from thin to rich devices in IoT environment.

3) Efficient anc concise operation policy to introduce certificate trust hierachy into OIC domain

• OIC security spec should meet multi-level things’ requirement (rich to thin de-

vices)

1) Light weight X.509 Certificate & Crypto Algorithm Spec

2) Tiny Certificate Encoder and Parser

3) Light weight certificate Management

• Basic use cases for OIC Certificate credential

1) Certificate issue use case

- Certificate Key Manager has CA function and generate/deliver device’s certificate.

2) Revocation of Certificate use case

- The revocation event may be managed by Certificate Key Manager.

Thin Rich

OICKey Mgmt domain

How to approach

• Light-Weight Management Scheme

The scheme is based on the delivery of mgmt messages over a DTLS secure channel through the CoAP GET/POST Methods by OIC transfer format.

GET /oic/res/crt ? deviceID = uuid

POST /oic/sec/crt

{ "crt": " der encoded device's certificate in base64", "kty": "EC", "crv": "P-256", "x": "base64 encoded x position of elliptic curv", "y": "base64 encoded y position of elliptic curv"}

DTLS

As for certificate mgmt protocol simplified scheme should be preferred to typical in OIC spec:

• Protocol : CoAP GET,POST Methods• Transport : DTLS• Format : Json *• Cert. Request: Supported by provisioning service• Revocation Query: Two-sided driven *• Cert. Status: CRL with serial numbers of revoked certificates *

• Compact Certificate Profile & ECC algorithm

Ciphersuite( TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 )[Well-known public Certificate over

1KB][Compact Certificate 292 Bytes]

Architecture & Entities

Application

RI

Connectivity Abstraction Layer

CKM Architecture Overview for Provisioning Tool

DTLS Adapter

DTLS

SVRdb

Provision-ingdb

SecureResourceManager

.CKMInfo

.CACert

.Template Store

CKM Data-base

Interface

ASN.1 Encoder

Certificate Generator

Certificate Key Man-ager

Provisioning Manager

CRL Generator.cred

.crl

Entities Definition Provisioning Manager- This handles security management of owned devices.- When performing security management role, this provides credentials and ACL to the owned devices. - In case of Provisioning Tool driven, this requests CK Manager to issue a device’s certificate.- This provide interface to transfer certificate credentials(device certficate,CA chains,CRLs). Provisioning db - Stores CKMinfo, Contains serial number, CA’s subject name, public/private key, issued history…etc for CKMinfo- Use Persistent Storage Interface(PSI) like SRM SVR database interface- Template Store : Request properties and options, certificate parameters, identity attributes , encoding format option SVR db - ‘crl’ resource is newly defined and certification revocation list will be maintained.

- Certificate and private key will be included into ‘public data’ property and ‘private data’ for each one in ‘cred’ resource. Ctypto Module(use microECC module)- Uses CA's private key, Crypto Algorithms for signing, message authentication, etc. CKM(Certificate-based Key Manager)- Directs message flow between CKM Database, Crypto Module and DER Encoder components for CA operation.

• ASN.1 Encoder - Encodes X.509 certificate profile in DER format, Encodes CRL profile in DER format

• Certificate Generator - Initializes CA’s certificate , generate device’s certificate or according to the CMP message.

• CRL Generator - Initializes CRL structure , generate CRLs, according to the CMP message.

• CKM(Certificate-based Key Management) Database Interface - This is the abstract interfaces to select SVR or Provisioning db, CRLs resource is located in SVR, CKMInfo and Template

is located in Provisioning db.

*CKM : Certificate-based Key Management*CK : Certificate-based Key*CA : Certificate Authority

Certificate Issuing

Certificate Issuing Operation Overview

Provisioning Tool Driven

Message sequence

Module-based sequence

Device Certificate Generation Sequence Flow

Provisioning Tool Driven

Device Certificate Credentials Transfer Sequence Flow

Profile Message - PUT /oic/sec/cred[{“credid”: “”, “sub”: “…”, “credtype”: “credential type”, “privKey”: “device’s private key”, “pubKey”: “CA’s public key”, “crt”: “certificate chain included devise’s certifi-

cate”}]

Provisioning Tool Driven

CRL Issuing

CRL Issuing Operation Overview Provisioning Tool Driven

Message sequence

Module-based sequence

CRL Generation Sequence Flow

Provisioning Tool Driven

CRL Transfer Sequence Flow w/ SRM (1/2)

Provisioning Manager

CKM Database Interface

CrlResource

CKMGetCRL ()

GetCRL ()

OicSecCrl_t* binCrl

Persistent Stor-age Interface

(PSI)SVR DB

SRM Sub-Module

CrlResource.c

CK Manager

GetCRL ()

OicSecCrl_t* binCrl

Provisioning Manager will try to send CoAPs message to server(thing)=> Refer to next slide.

Modules for CRL virtual resource

* CrlResource.c source file should be created newly See the CredResource.c as a reference

BinToCredJSON (binCrl)

Json string of crl

Json string for crl

CrlResource.c

OicSecCrl_t structure should be definede.g. OicSecCrl_t includes Issuer, { SerialNo, Timestamp }

Profile Message- PUT /oic/sec/crl [{“issuer”:”…”,”tupdate”:”…”,rcrts”{“sn”:”serial no.”,”time”:”timestamp”},{“sn”,”serial no.”,”time”:” time-

stamp”},…}}]

CRL Transfer Sequence Flow w/ SRM (2/2)

Provisioning Manager

Connection Abstract

(CA)SRM RI layerCK Manager

Connection Abstract

(CA)

Provisioning Tool on Client Server on Thin deviceDTLS Channel

OCDoResource (“/oic/sec/crl”, PUT, payload, …)Send CoAP messagevia DTLS channel

Write to tinyDTLS

Called registered callback by tinyDTLS

SRMRequestHandler ()

CheckPermission (subjecId, Uri)

If access is allowed, call HandleCARequest ()

Handle Request

CRLEntityHandler ()

JSONToCrlBin() & SetCRL()

CrlResource.c

OCDoResponse ()

CASendResponse ()Write to tinyDTLS ()

Called registered callback by tinyDTLS

Done generating JSON payload=> Refer to previous slide.

Return success

We should use OCDoResource() API of OC Core

* CrlResource.c file should be created newly

These functions should be provided in CrlResource.c