Re: [dev] Certificate-based credential (DTLS fails to find cipher suite)

[Aleksey Volkov]

Khaled,   Important addition: for the root certificate you need to use "oic.sec.cred.trustca" value credUsage field instead of "oic.sec.cred.mfgtrustca", since cipher suite list formed by trustca certificates. "oic.sec.cred.mfgcert" and "oic.sec.cred.mfgtrustca" types used only at the otm process, and will never used then for authentication by default.     Best regards, Aleksey Volkov   --------- Original Message --------- Sender : Khaled Elsayed <khaledi...@gmail.com> Date : 2019-01-03 12:13 (GMT+2) Title : Re: Re: [dev] Certificate-based credential (DTLS fails to find cipher suite)   Thanks again. Will retry using 'oic.sec.cred.cert'. Was using "credusage": "oic.sec.cred.mfgcert" for the client own certificate and intermediate certificate and "credusage": "oic.sec.cred.mfgtrustca" for the peer certificate. I guess you meant oic.sec.cred.cert in place of the oic.sec.cred.mfgcert but the oic.sec.cred.mfgtrustca should remain the same as this is what is used to verify the peer certificate.  I attach the client and server .json files. For simplicity, I am assuming a pre-provisioned server here. As mentioned earlier no problem in getting the server provisioned via provisioningclient (of course the json file doxm entry is different for that case).  I will retry and share the logs if that change still does not work. Best regards, Khaled On Thu, Jan 3, 2019 at 11:26 AM Oleksiy Volkov <a.vol...@samsung.com> wrote:   ...Also, credUsage type must be 'oic.sec.cred.cert'...     Best regards, Aleksey Volkov   --------- Original Message --------- Sender : Oleksiy Volkov <a.vol...@samsung.com> Staff Engineer/Security Certification Part /SRK/Samsung Electronics Date : 2019-01-03 11:16 (GMT+2) Title : Re: [dev] Certificate-based credential (DTLS fails to find cipher suite)     Hi Khaled,   InitManufacturerCipherSuiteList callback used at the one step of the mfg otm process. In all other cases (yours also) should be used InitCipherSuiteList as g_getCredentialTypesCallback (Please check SRMInitSecureResources function). According to your log, InitCipherSuiteList is called successfully, so it's normal behavior, and there are no other issues than the lack of credentials. Could you share full log from the beginning and dat file of yours 3rd client, please?   Best regards, Aleksey Volkov   --------- Original Message --------- Sender : Khaled Elsayed <khaledi...@gmail.com> Date : 2019-01-02 23:44 (GMT+2) Title : Re: Re: [dev] Certificate-based credential (DTLS fails to find cipher suite)   Hi Aleksey, Thanks for taking a close look at the log. You are absolutely right about the observation that InitCiherSuite comes back empty handed. The credentials are perfect and have credtype=8 and I check that the .dat files are read correctly by both the client and server codes. There is a bug in the code either in the function SetupCipher or initialization of callbacks before invoking SetupCipher. It will not work currently as is. I will report this via jira. Here is why: In  SetupCipher, I  added some logs for g_caSslContext->cipherFlag[0] and g_caSslContext->cipherFlag[1] both are false after calling g_getCredentialTypesCallback(g_caSslContext->cipherFlag, deviceId); So, it will not be able to find any ciphersuite. There is a need to properly initialize the g_getCredentialTypesCallback to use the mfg_cert callback functions. Something like what is done in the function OTMSetOTCallback in ownershiptransfermanager.c where it calls PrepareMCertificateCallback to set the callbacks in case it identifies a certificate-based credential. There must be something like this before SetupCipher is called, otherwise no certificates will work. I tried to add some similar code to the function below but got all types of linking errors as I am not really into scons/sconscript :)  OCStackResult PrepareMCertificateCallback(OTMContext_t *otmCtx) {     OIC_LOG(INFO, TAG, "IN PrepareMCertificateCallback");     if (!otmCtx || !otmCtx->selectedDeviceInfo)     {         return OC_STACK_INVALID_PARAM;     }     if (CA_STATUS_OK != CAregisterPkixInfoHandler(GetManufacturerPkixInfo))     {         OIC_LOG(ERROR, TAG, "Failed to register PkixInfohandler");         return OC_STACK_ERROR;     }     if (CA_STATUS_OK != CAregisterIdentityHandler(NULL))     {         OIC_LOG(ERROR, TAG, "Failed to register IdentityHandler");         return OC_STACK_ERROR;     }     if (CA_STATUS_OK != CAregisterGetCredentialTypesHandler(InitManufacturerCipherSuiteList))     {         OIC_LOG(ERROR, TAG, "Failed to register CredentialTypesHandler");         return OC_STACK_ERROR;     }     OIC_LOG(INFO, TAG, "OUT PrepareMCertificateCallback");     return OC_STACK_OK; } On Wed, Jan 2, 2019 at 3:46 PM Oleksiy Volkov <a.vol...@samsung.com> wrote: Hi Khaled,   I noticed that in your log between the lines  'In InitCipherSuiteListInternal' & 'Out InitCipherSuiteListInternal' there are no any messages. This may indicate that there are no suitable credentials in the cred resource, or they have the wrong type value. (As I understand it should be the SIGNED_ASYMMETRIC_KEY type credential for your case). So, please check your dat file for necessary credential. entries.     Best regards, Aleksey Volkov   --------- Original Message --------- Sender : Khaled Elsayed <kha...@ieee.org> Date : 2019-01-02 13:22 (GMT+2) Title : Re: [dev] Certificate-based credential (DTLS fails to find cipher suite)   Thanks Aleksey. For sure I am using OC_CLIENT_SERVER mode. My code is based on ~/iotivity/examples/OCFSecure which already took core of this in the client.cpp code.  On Fri, Dec 28, 2018 at 1:40 PM Oleksiy Volkov <a.vol...@samsung.com> wrote: Hi Khaled,   maybe you use 'client only' (OC_CLIENT) mode instead of 'client-server' (OC_CLIENT_SERVER) to initialize the Iotivity stack.   Best regards, Aleksey Volkov   --------- Original Message --------- Sender : Khaled Elsayed <kha...@ieee.org> Date : 2018-12-10 18:54 (GMT+2) Title : Re: [dev] Certificate-based credential (DTLS fails to find cipher suite)   Hi Gregg, No unfortunately. I will have a second look today but If I could not, I will proceed using the non-certificate based shared key credential supporting a limited number of clients for the time being.  On Sun, Dec 9, 2018 at 11:18 PM Gregg Reynolds <d...@mobileink.com> wrote: Did you ever get this figured out? I've seen "No ciphersuites configured" but sadly don't remember how I resolved it. G On Wed, Dec 5, 2018, 9:34 AM Khaled Elsayed <khaledi...@gmail.com wrote: Hi, I am trying to get certificate-based credential management to work between a provisioned server and a client. So, I worked a bit more with the provisionclient and sampleserver_mfg. I created new certificates via the crtgenerator application. I configured the json files with the new certificates and private keys for both application. The provisioning worked. This is the good news proving that these certificates and json files do work.  The bad news is if I want to apply the certificate based authentication/credntial in other examples not including provisioning, it does not work. I use the sample client and server in the examples/OCFSecure folder. The client and server initiate properly and reads the cred/certificates correctly. However, when the client attempts to issues a GET request over coaps, it fails.  Obviously there is something that needs to be invoked to associate the client and server so that they use the certificates to calculate the shared symmetric encryption key. This seems to occur when the provisioningclient starts to access the /doxm resource in the sampleserver_mfg. I could see that in the log but I cannot figure out how to make the OCFSecure client/server start the certificate exchange process.  Here is the log. It complains  No ciphersuites configured (see below) although they are to start DTLS handshake (InitiateTlsHandshake is being invoked). So, what procedure should be invoked to create a cipher between the two endpoints using the certificates before reaching to the point they exchange coaps payloads. Thanks for any pointers.  48:53.275 INFO: OIC_CA_MSG_HANDLE: CASendUnicastData type : 1 48:53.275 DEBUG: OIC_CA_INF_CTR: unicast message to adapter 48:53.275 DEBUG: OIC_UQUEUE: Queue Count : 1 48:53.275 INFO: OIC_CA_PRTCL_MSG: adapter value of CoAP/TCP is 1 48:53.275 DEBUG: OIC_CA_RETRANS: sent pdu, msgtype=1, msgid=60490 48:53.275 DEBUG: OIC_CA_RETRANS: not supported message type 48:53.275 DEBUG: OIC_CA_MSG_HANDLE: CADestroyData IN 48:53.275 DEBUG: OIC_CA_MSG_HANDLE: CADestroyData OUT 48:53.275 DEBUG: OIC_CA_QING: wait.. 48:53.275 DEBUG: OIC_CA_QING: wake up.. 48:53.275 DEBUG: OIC_CA_IP_ADAP: DTLS encrypt called 48:53.275 DEBUG: OIC_CA_NET_SSL: In CAencryptSsl 48:53.275 DEBUG: OIC_CA_NET_SSL: Port 39115 48:53.275 DEBUG: OIC_CA_NET_SSL: Data to be encrypted dataLen [30] 48:53.275 DEBUG: OIC_CA_NET_SSL: In GetSslPeer 48:53.275 DEBUG: OIC_CA_NET_SSL: Return NULL 48:53.275 DEBUG: OIC_CA_NET_SSL: Out GetSslPeer 48:53.279 DEBUG: OIC_CA_NET_SSL: In InitiateTlsHandshake 48:53.279 DEBUG: OIC_CA_NET_SSL: In NewSslEndPoint 48:53.279 DEBUG: MBED_TLS: set_timer to 0 ms 48:53.279 DEBUG: OIC_CA_NET_SSL: New [client role] endpoint added [10.0.0.2:39115] 48:53.279 DEBUG: OIC_CA_NET_SSL: Out NewSslEndPoint 48:53.279 DEBUG: OIC_CA_NET_SSL: In SetupCipher 48:53.279 DEBUG: OIC_SRM_PKIX_INTERFACE: In InitCipherSuiteList 48:53.279 DEBUG: OIC_SRM_CREDL: In InitCipherSuiteListInternal 48:53.279 DEBUG: OIC_SRM_CREDL: Out InitCipherSuiteListInternal 48:53.279 DEBUG: OIC_SRM_PKIX_INTERFACE: Out InitCipherSuiteList 48:53.279 DEBUG: OIC_CA_NET_SSL: Supported ciphersuites: 48:53.279 ERROR: OIC_CA_NET_SSL: No ciphersuites configured, secure connections will fail 48:53.279 DEBUG: OIC_CA_NET_SSL: Out SetupCipher 48:53.279 ERROR: OIC_CA_NET_SSL: Failed to set up cipher 48:53.279 DEBUG: OIC_CA_NET_SSL: In DeleteSslEndPoint On Tue, Nov 27, 2018 at 9:16 AM Khaled Elsayed <khaledi...@gmail.com> wrote: Thanks Mats for the pointer. Very handy tool.  Nicely done Rami.  Khaled On Mon, Nov 26, 2018 at 5:21 PM Mats Wichmann <m...@wichmann.us> wrote: On 11/26/18 7:53 AM, Khaled Elsayed wrote: > Hi Nathan > > Just wanted to confirm that json2cbor from iotivity-2.0.0 and latest master > both fail when an ACE contains a roletype entry. > > For the provisioning client example, is there anyway to inspect the .dat > files that are modified after the provisioning is performed? Something like > a cbor2json if there is such a tool. > > Thanks > > Khaled https://github.com/alshafi/iotivity-tool should be able to do this - it converts in both directions.                           _._,_._,_ Links: You receive all messages sent to this group. View/Reply Online (#10122) | Reply To Sender | Reply To Group | Mute This Topic | New Topic Your Subscription | Contact Group Owner | Unsubscribe [arch...@mail-archive.com] _._,_._,_

client.cred.json
Description: Binary data

server.cred.json
Description: Binary data