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

Aleksey Volkov Thu, 03 Jan 2019 01:27:07 -0800

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

_._,_._,_

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

Reply via email to