GitLab

Currently there is no test case which checks if IoTivity can properly accept a DTLS handshake using an Identity Certificate generated based on a CSR retrieved from /oic/sec/csr. The CR 2722 is going to cover this scenario in existing test case CT1.7.4.4:

Step 1:         CTT establishes an authenticated session with IUT
Step 2:         CTT performs a RETRIEVE on IUT /oic/sec/csr to check the Certificate Signing Request property.
Step 3:         CTT generates and signs a new certificate based on the contents of the CSR.
Step 4:         CTT performs an UPDATE on IUT /oic/sec/cred to store the certificate chain
(the newly generated certificate and CRED_CTT_CA as a chain)
.
Step 5:         CTT performs a RETRIEVE on IUT /oic/sec/cred to retrieve the certificate chain.
Step 6:         CTT establishes a new secure session using CRED_CERT_CTT.
The credential created in Step 3 is signed by the CTT's Root CA, which is installed on the IUT with "credusage": "oic.sec.cred.trustca" prior to Step 1.
New checks:
Check 5:       The IUT shall successfully establish the DTLS handshake in Step 6.
Check 6:       The certificate presented by the IUT during the DTLS handshake in Step 6 shall be the same certificate that the CTT generated in Step 3.
 
A draft implementation has been prepared. It can be installed in the latest CTT Bangkok release:

• Esure the CTT is
• not
• running
• Open directory "Configuration\OCF\TestCases" in the CTT installation (usually located in "C:\Program Files (x86)\OCF Conformance Test Tool")
• Replace the original Security_CT1_7_4_4.py file with this one:
  The IoTivity (master) fails the updated test case. The CTT is unable to establish a DTLS connection is the new Step 6. Both new checks fail:

4.155s 15:56:38 INFO: Opening secure connection using certificate with CN=uuid:22222222-3333-4444-5555-248577617171
4.164s 15:56:38 DEBUG: DTLS Certificate Client: Initializing session. Advertised cipher suites: C0AE
4.164s 15:56:38 DEBUG: DTLS Certificate Client: -> Client Hello, sequence=0, length=100
4.166s 15:56:38 DEBUG: DTLS Certificate Client: Alert handshake_failure(40) was received
4.183s 15:56:38 INFO: Could not open secure connection using certificate. Handshake failure reason handshake_failure (40)
4.183s 15:56:38 DEBUG: Starting verification with ID:"CT1.7.4.4_Check_5"...
4.185s 15:56:38 ERROR: CT1.7.4.4_Check_5: A secure session was not established
4.187s 15:56:38 DEBUG: Verification with ID:"CT1.7.4.4_Check_5" ended with result: FAILED
4.187s 15:56:38 DEBUG: Starting verification with ID:"CT1.7.4.4_Check_6"...
4.191s 15:56:38 ERROR: CT1.7.4.4_Check_6: The Server did not present a certificate during the DTLS handshake
4.191s 15:56:38 DEBUG: Verification with ID:"CT1.7.4.4_Check_6" ended with result: FAILED

 
Analysis of CTT and IoTivity logs (
) shows that:

• In Step 2 when the IUT is handling a request to /oic/sec/csr, a new credential gets added into /oic/sec/cred automatiacally. It has "credusage": "oic.sec.cred.cert" (Identity certificate) and "credtype": 4 (Asymmetric signing key:

{
    "credid": 4,
    "subjectuuid": "12345678-1234-1234-1234-123456789012",
    "credtype": 4,
    "publicdata": {
        "encoding": "oic.sec.encoding.der",
        "data": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7e9yN6lUpdzvaqVfHttO6J9jDN3rKk3FV1v-xwMbmLaX5AulVd2tCagQNeHZqQZ9yuad6-H_Ct4kBL946wfJ2g"
    },
    "credusage": "oic.sec.cred.cert"
},

• In Step 4 the CTT signs the CSR and provisions a credential with "credusage": "oic.sec.cred.cert" and "credtype": 8 (Asymmetric signing key with certificate).
   
• In Step 6 the CTT tries to establish a secure certificate connection, but the IUT does not respond to Client Hello. In the logs I've found an error indicating that IoTivity has a problem with a (private?) key for the certificate:

56:49.110 [0;32mDEBUG[0m: OIC_SRM_CREDL:LOG: ============================================================
56:49.110 [0;32mDEBUG[0m: OIC_SRM_CREDL: Out GetOwnCert
56:49.110 [0;32mDEBUG[0m: OIC_SRM_CREDL: In GetPrimaryCertKey
56:49.110 [0;35mWARNING[0m: OIC_SRM_CREDL: Key for PRIMARY_CERT not found
56:49.110 [0;32mDEBUG[0m: OIC_SRM_CREDL: Out GetPrimaryCertKey
56:49.110 [0;35mWARNING[0m: OIC_SRM_PKIX_INTERFACE: GetPkixInfo: empty key
56:49.110 [0;32mDEBUG[0m: OIC_SRM_CREDL: In GetCaCert
56:49.110 [0;32mDEBUG[0m: OIC_SRM_CREDL: oic.sec.cred.trustca found
56:49.110 [0;32mDEBUG[0m: OIC_SRM_CREDL:LOG: ==== Cert being returned ===================================

56:49.110 [0;32mDEBUG[0m: OIC_PARSE_CHAIN: In ParseChain
56:49.110 [0;32mDEBUG[0m: OIC_PARSE_CHAIN: ParseChain successfully parsed 2 certificates
56:49.110 [0;32mDEBUG[0m: OIC_PARSE_CHAIN: Out ParseChain
56:49.110 [0;35mWARNING[0m: OIC_CA_NET_SSL: Key parsing error

56:49.110 [0;32mDEBUG[0m: MBED_TLS: trying ciphersuite: TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8
56:49.110 [0;32mDEBUG[0m: MBED_TLS: ciphersuite requires certificate
56:49.110 [0;32mDEBUG[0m: MBED_TLS: server has no certificate
56:49.110 [0;32mDEBUG[0m: MBED_TLS: ciphersuite mismatch: no suitable certificate
56:49.110 [0;32mDEBUG[0m: MBED_TLS: got ciphersuites in common, but none of them usable
56:49.110 [0;32mDEBUG[0m: MBED_TLS: => send alert message
56:49.110 [0;32mDEBUG[0m: MBED_TLS: => write record

 
 
 

---

JIRA migration meta data

• JIRA Issue ID: IOT-3259
• Reporter: krzysztof.j.wlodarczyk
• Assignee: krzysztof.j.wlodarczyk
• Creator: krzysztof.j.wlodarczyk
• Created at: 2019-01-24T00:42:25.000-0800
• Found in Version: master
• Fix in Version: None
• Issue Severity: Major
• Reproducibility: Always (100%)
• Operating System: None
• Hardware/ OEM Platform: ubuntu
• External URL: None
• Bugzilla ID: None
• Product: None
• Status: Resolved
• Components: Security
• Priority: P1
• Due Date: None
• Issue Type: Bug
  END of JIRA migration meta data

---