1. Introduction for Certificate-based Key Management Design based on Provisioning Tool 2015.07.21 Samsung Electronics Software R&D Center

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

3. Terminology In this project, we have defined terminology to avoid confusion of Certificate 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 Authority(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

4. 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 devices) 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 OIC Key Mgmt domain

5. 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]

6. Architecture & Entities

7. Application RI Connectivity Abstraction Layer CKM Architecture Overview for Provisioning Tool DTLS Adapter DTLS SVR db Provisioning db Secure Resource Manager.CKMInfo.CACert.Template Store CKM Database Interface ASN.1 Encoder Certificate Generator Certificate Key Manager Provisioning Manager CRL Generator.cred.crl

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

9. Certificate Issuing

10. Certificate Issuing Operation Overview Provisioning Tool Driven Message sequence Module-based sequence

11. Device Certificate Generation Sequence Flow Provisioning Tool Driven

12. 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 certificate”}] Provisioning Tool Driven

13. CRL Issuing

14. CRL Issuing Operation Overview Provisioning Tool Driven Message sequence Module-based sequence

15. CRL Generation Sequence Flow Provisioning Tool Driven

16. CRL Transfer Sequence Flow w/ SRM (1/2) Provisioning Manager CKM Database Interface CrlResource CKMGetCRL () GetCRL () OicSecCrl_t* binCrl Persistent Storage 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 defined e.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”:” timestamp”},…}}]

17. CRL Transfer Sequence Flow w/ SRM (2/2) Provisioning Manager Connection Abstract (CA) SRMRI layerCK Manager Connection Abstract (CA) Provisioning Tool on ClientServer on Thin device DTLS Channel OCDoResource (“/oic/sec/crl”, PUT, payload, …) Send CoAP message via 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