CoAP Secure CLI Example

[hugzy123]

Hi,

I'm running into some issues testing the CoAP Secure (CoAPS) functionality on the nRF "Thread: CLI" example".  I have attempted to use both pre-shared key (pskc) and the default x509 certificate as authentication types, but both are producing errors, albeit slightly different ones. The "pskc" authentication fails when executing the "ot coaps connect" command and returns Error 7 "Invalid Args". On the other hand, the x509 authentication processes the "connect" command, but disconnects instantly.

I've been following the "OpenThread- CoAPS Example" documentation. I can run the standard "OpenThread CoAP" example without authentication ok.

Example Set up

HW : 2x nrf52840 DK 
nrf connect SDK : Tried v2.2.0 and v2.1.0

Instructions thread set up

1. Flash both Dev kits with Thread: CLI" example
2. Connect both dev kits to the same thread network, using commands ot channel, ot panid, ot networkkey, ot ifconfig up, ot thread start
3. run ot ipaddr on the Server node to get Server the ip address
4. ping Server ip address from the Client node to confirm connection over Thread

Authentication type pskc

1. Set server and client node authentication  psk* using command 

   ot coaps set psk 123 pskid
   

2. run CoAP server on Node 1
   

   ot coaps start
   ot coaps resource test-resource

3. run CoAP client on Node 2
   

   ot coaps start
ot coaps connect <peer-ip6-address>

After running the connect command I get the InvalidArgs error. 

Authentication type x509

1. Tell Server and client to use the default certificate for authentication
   ot coaps x509
2. run CoAp server on Node 1
   ot coaps resource test-resource
3. run CoAP client on Node 2 
   ot coaps start
   ot coaps connect <peer-ip6-address>
   
4. CoAP client fails to connect and returns;
   coaps disconnected

Is there anything I am doing wrong here?

Thank you,

[Sigurd Hellesvik]

I polled our developers on this, and they said:

This is under investigation by one of the engineers. He was able to confirm the issue but hasn't found the root cause yet.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Here is an update:

"

The issue is not solved yet, but we're getting closer.

One thing that should be done is setting hostname of the server device. Cli sample's default certificate has Common Name set as "PXC3.E75-100A", which is the expected hostname of a device using it. 

Another discovered issue is that the ciphersuite used by the cli app by default is untested and not recommended. Disabling MBEDTLS_KEY_EXCHANGE_ECJPAKE_ENABLED config and setting MBEDTLS_SSL_CIPHERSUITES to ECDHE_ECDSA_WITH_AES_128_CCM8 fixes one of the issues.

"

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Here is a workaround for now:

"

The original error is a tls handshake failure caused by selection of incorrect ciphersuite by the server (MBEDTLS_TLS_ECJPAKE_WITH_AES_128_CCM_8 instead of MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8).

It's possible to make x509 usable by disabling ECJPAKE ciphersuite (CONFIG_MBEDTLS_KEY_EXCHANGE_ECJPAKE_ENABLED=n) and raising mbedtls heap size (CONFIG_MBEDTLS_HEAP_SIZE=15200) - disabling ECJPAKE will result in openthread compilation error, as some files stop being included, which results in undeclared symbols. This can be solved by #ifdef guarding erroneous lines.

This, however, is a workaround - openthread relies on ECJPAKE for some functionalities (like commissioning). Those functionalities will fail after disabling the ciphersuite.

"

Regards,
Sigurd Hellesvik

[hugzy123]

Hi Sigurd,

Thanks for the update. We're using authentication with PSK instead for now, we'll migrate to using certificates when there's a full solution available in the future.

Regards,