The Implementation of COAP security

Mohamed Yassine Garali Innov Alliance Tech

Embedded Software Engineer IAT.
mohamedyassine.garali@ia-tech.net ia@tech.net

1. CoAP Communication
CoAP uses the Client-Server communication model where nodes send requests and receive
responses from other nodes.

2. CoAP Messages
These define the type of CoAP packets and deal with UDP. The CoAP standard defines four different
types of Messages:

- Confirmable Message (CON)

- Non-Confirmable Message (NON)
- Acknowledgment Message (ACK)
- Reset Message (RST)
 3. CoAP Request/Response
The Messages can contain a request, response, or maybe empty.

- CoAP standard defines four Request methods - GET, PUT, POST, and DELETE.
- CoAP standard defines Response code 2.xx for success, 4.xx for client error, and 5.xx for
server error.
- Unique 0-8 byte Tokens are used for identifying, mapping request and response much the
same way Message-IDs are used to identify messages and map ACKs.

4. CoAP Security
The CoAP standard does not specify any authentication mechanism. It relies on DTLS to provide
protocol-level security. The standard defines four security modes for devices.

- NoSec: This means there is no protocol-level security i.e. DTLS is disabled.

- PreSharedKey: In this mode, DTLS is enabled and the device has a list of pre-shared keys
with each key including a list of which nodes it can be used to communicate with.
- RawPublicKey: In this mode, DTLS is enabled and the device has an asymmetric key pair
without any certificate. The key is validated using an OOB (Out-of-bound) mechanism
- Certificate: In this mode, DTLS is enabled and the device has an asymmetric key pair along
with an X.509 certificate that is signed by a common and trusted Root CA.

4.1. Datagram Transport Layer Security DTLS

A datagram is a kind of telegram with digital data: as a data packet, it contains sufficient
information to find its own route to the correct destination without a prior connection between
the sender and the receiver. This makes the connection unreliable: the sender cannot determine
whether his message has been received, while the recipient does not know whether the packets
have arrived in the correct order.
The User Datagram Protocol UDP – using which messages can be sent without a connection – is
mainly used when fast data transfer and short response times are more important than
reliability. Consider, for example, situations in which data may be lost because new data
immediately follows and replaces old data, such as in video streaming or gaming. DTLS is
designed in such a way that packages do not get lost or arrive in the wrong order.

4.2. Certificate
Digital certificates, also known as identity certificates or public key certificates are digital files
that are used to certify the ownership of a public key. DTLS certificates are a type of digital
certificate, issued by a Certificate Authority (CA). The CA signs the certificate, certifying that they
have verified that it belongs to the owners of the domain name which is the subject of the
certificate.

DTLS certificates usually contain the following information:

- The subject domain name

- The subject organization
- The name of the issuing CA
- Additional or alternative subject domain names, including subdomains, if any
- Issue date
- Expiry date
- The public key (The private key, however, is a secret.)
- The digital signature by the CA
 4.3. Security generation
4.3.1. Installation of Openssl
To generate a certificate, we must follow the steps:

1) Install Dependencies: The first step, before we can compile the OpenSSL library from
source, is to install some package dependencies including the 'build-essential' package on
Ubuntu.

sudo apt update

sudo apt install build-essential checkinstall zlib1g-dev -y

Download OpenSSL: Go to the '/usr/local/src' directory and download the OpenSSL source
code using wget. If you use openssl 1.0 version then do the next command else change
openssl-1.0.2o to openssl-1.1.1s.

wget https://www.openssl.org/source/openssl-1.1.1s.tar.gz

Now create /opt/openssl directory:

sudo mkdir /opt/openssl

Run the following commands to install Openssl.

sudo tar xfvz ~/Downloads/openssl-1.1.1s.tar.gz --directory /opt/openssl

Export LD_LIBRARY_PATH environment variable with the following value:

export LD_LIBRARY_PATH=/opt/openssl/lib

Issue the config commands:

cd /opt/openssl/openssl-1.1.1b

sudo ./config --prefix=/opt/openssl --openssldir=/opt/openssl/ssl

Next, issue make commands:

sudo make

sudo make test

sudo make install

Rename earlier version openssl to openssl.old

sudo mv openssl openssl.old

Openssl needs to set PATH environment variables which is to be set as shown below.

Create a file called openssl.sh under /etc/profile.d/ directory.

sudo touch /etc/profile.d/openssl.sh

sudo vi /etc/profile.d/openssl.sh

Add the following contents:

#!/bin/sh

export PATH=/opt/openssl/bin:${PATH}

export LD_LIBRARY_PATH=/opt/openssl/lib:${LD_LIBRARY_PATH}

Save and close the file. Make it executable using the following command.

sudo chmod +x /etc/profile.d/openssl.sh

Then, set the environment variables permanently by running the following command:

source /etc/profile.d/openssl.sh

4.3.2. Generate the key

Two different types of keys are supported: RSA and EC (elliptic curve).

 Generating a private RSA key

Generate an RSA private key, of size 2048, and output it to a file named key.pem:

openssl genrsa -out key.pem 2048

Extract the public key from the key pair, which can be used in a certificate:

openssl rsa -in key.pem -outform PEM -pubout -out public.pem

 Generating a private EC key

Generate an EC private key, of size 256, and output it to a file named key.pem:

openssl ecparam -name prime256v1 -genkey -noout -out key.pem

Extract the public key from the key pair, which can be used in a certificate:

openssl ec -in key.pem -pubout -out public.pem

 4.3.3. Certificate creation
Generate certificate: Create a certificate-signing request (CSR) with a private key. A CSR
contains details about location, organization, and FQDN (Fully Qualified Domain Name). To do
this Use the following command to generate the self-signed EC based private key and x509
certificate. The command is based on the openssl tool.

Prepare the key to generate the certificate, Send the CSR to the trusted CA authority. We must
now create a ca-certificate with the keys and update it.

sudo openssl req -new -sha256 -key key.pem -nodes -out host.csr

sudo openssl req -x509 -in host.csr -key key.pem -sha256 -days 1096 -nodes -out cert.pem

sudo cp /home/"user"/cert.pem /usr/local/share/ca-certificates

sudo update-ca-certificates

 .key files are generally the private key, used by the server to encrypt and package data for
verification by clients.
 .pem files are generally the public key, used by the client to verify and decrypt data sent by
servers. PEM files could also be encoded private keys, so check the content if you're not sure.
 .cert or .crt files are the signed certificates -- basically the "magic" that allows certain sites to
be marked as trustworthy by a third party.
 .csr is a certificate-signing request, a challenge used by a trusted third party to verify the
ownership of a keypair without having direct access to the private key.

Finally, Copy the CA-certificates in the same place of the certificate and key and convert it from
ca-certificates.crt to ca-certificates.pem.

sudo cp /etc/ssl/ca-certificates.crt /home/iat

sudo openssl x509 -in ca-certificates.crt -out ca-certificates.pem -outform PEM

4.4. Encryption
When the CoAP library was built, it will have been compiled using a specific underlying TLS
implementation type (e.g. OpenSSL, GnuTLS, TinyDTLS or noTLS). When the CoAP library is linked into
an application, it is possible that the application needs to dynamically determine whether DTLS or TLS
is supported.

The DTLS is allowed to be use with the port 5684. Therefore, we can change it manually in
Coap_MainJob or automatically with the PDU.h.

If DTLS is going to be used for encrypting the network traffic, then the DTLS information for Pre-
Shared Keys (PSK) or Public Key Infrastructure (PKI) needs to be configured before any network traffic
starts to flow.

For Servers, this has to be done before the Endpoint is created, for Clients; this is done during the
Client Session set up.
For Servers, all the encryption information is held internally by the DTLS Context level and the CoAP
Context level as the Server is listening for new incoming traffic based on the Endpoint definition. The
DTLS and CoAP session will not be built until the new traffic starts.

In principle the set-up sequence for CoAP Servers looks like

coap_new_context()

coap_context_set_pki_root_cas() - if the root CAs need to be updated and PKI

coap_context_set_pki() and/or coap_context_set_psk() - if encryption is required

coap_new_endpoint ()

To activate the Openssl library, there is a flag named HAVE-OPENSSL in coap-config.h that is forced
to zero to disable the security. Turn it to one.

For Clients, all the encryption information can be held at the TLS Context and CoAP Context levels, or
usually at the TLS Session and CoAP Session levels. If defined at the Context level, then when Sessions
are created, they will inherit the Context definitions, unless they have separately been defined for
the Session level, in which case the Session version will get used. Typically, the information will be
configured at the Session level for Clients.

In principle the set-up sequence for CoAP Clients looks like

coap_new_context()

coap_context_set_pki_root_cas() - if the root CAs need to be updated and PKI

coap_new_client_session(), coap_new_client_session_pki() or
coap_new_client_session_psk()

Multiple client sessions are supported per Context.

Due to the nature of TLS, there are Callbacks that are invoked as the TLS session negotiates
encryption algorithms, encryption keys etc. Where possible, the CoAP layer handles all this
automatically based on different configuration options passed in by the coap_*_pki() functions.

For PSK setup, the required information needs to be provided in the setup calls with no application
Callbacks required. Both the Client and Server have to provide a PSK. The Server must have a Hint
defined and the Client must have an Identity defined.

For PKI setup, if the CoAP library PKI configuration options do not handle a specific requirement as
defined by the available options, then an application defined Callback can called to do the additional
specific checks.

CoAP library will add in the defined Certificate, Private Key and CA Certificate into the TLS
environment. The CA Certificate is also added in to the list of valid CAs for Certificate checking.

The internal Callbacks (and optionally the Application Callback) will then check the required
information as defined in the coap_dtls_pki_t described below.

typedef struct coap_dtls_pki_t {

uint8_t version;

/* Options to enable different TLS functionality in libcoap */

 uint8_t verify_peer_cert;

uint8_t require_peer_cert; /* 1 if peer cert is required */

uint8_t allow_self_signed; /* 1 if self-signed certs are allowed */

uint8_t allow_expired_certs; /* 1 if expired certs are allowed */

uint8_t cert_chain_validation; /* 1 if to check cert_chain_verify_depth */

uint8_t cert_chain_verify_depth; /* recommended depth is 3 */

uint8_t check_cert_revocation; /* 1 if revocation checks wanted */

uint8_t allow_no_crl; /* 1 ignore if CRL not there */

uint8_t allow_expired_crl; /* 1 if expired crl is allowed */

uint8_t reserved [6]; /* Reserved - must be set to 0 for future compatibility */

coap_dtls_cn_callback_t validate_cn_call_back;

void *cn_call_back_arg; /* Passed in to the CN call-back function */

coap_dtls_sni_callback_t validate_sni_call_back;

void *sni_call_back_arg; /* Passed in to the sni call-back function */

coap_dtls_security_setup_t additional_tls_setup_call_back;

Char* client_sni;

coap_dtls_key_t pki_key; /* PKI key definition */

} coap_dtls_pki_t;

 Key Type Definition

typedef enum coap_pki_key_t {

COAP_PKI_KEY_PEM, /* PEM type information */

COAP_PKI_KEY_ASN1, /* ASN1 type information */

} coap_pki_key_t;

Key type defines the format that the certificates / keys are provided in. This can be
COAP_PKI_KEY_PEM or COAP_PKI_KEY_ASN1.

 PEM Key Definitions

typedef struct coap_pki_key_pem_t {

const char *ca_file; /* File location of Common CA in PEM format */

const char *public_cert; /* File location of Public Cert in PEM format */

const char *private_key; /* File location of Private Key in PEM format */

} coap_pki_key_pem_t;
Key.pem.ca_file points to the CA File location on disk, which will be in PEM format, or NULL. This
file should only contain one CA (who signed the Public Certificate) as this is passed from the
server to the client when requesting the client’s certificate. This certificate is also added into the
valid root CAs list if not already present.

Key.pem.public_cert points to the Public Certificate location on disk, which will be in PEM
format.

Key.pem.private_key points to the Private Key location on disk, which will be in PEM format. This
file cannot be password protected.

To activate the security, the server must have the key and the certificate and sometime the ca-
certificates but the client must have only the ca-certificates. Those files will be integrated to
the server as local files in /files/temps and they will be added as path in the makefile of the
project.

The last step that the software development kit SDK must implement openssl 1.1 version or later,
because the DTLS security is added to 1.1.1 version.