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 <[email protected]> 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 <[email protected]>
>
> *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 <[email protected]>
> 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 <[email protected]>
>>
>> *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 <[email protected]> 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 <[email protected] 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 <[email protected]>
>>>> wrote:
>>>>
>>>>> Thanks Mats for the pointer. Very handy tool. Nicely done Rami.
>>>>>
>>>>> Khaled
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 26, 2018 at 5:21 PM Mats Wichmann <[email protected]>
>>>>> 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 (#10115):
https://lists.iotivity.org/g/iotivity-dev/message/10115
Mute This Topic: https://lists.iotivity.org/mt/28611921/21656
Group Owner: [email protected]
Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
201901021546615_2OJWTEAC
Description: Binary data
