Securing Constraint Application Protocol now
$30-250 USD
Paid on delivery
[url removed, login to view] Constraint Application Protocol:
The CoAP specification proposes the utilization of Datagram Transport Layer Security(DTLS) or Internet Protocol Security (IPSec) to accomplish data origin authentication, replay protection, integrity and encryption for coap messages. CoAP specification defines four security modes: NoSec, PreSharedKey, RawPublicKey and Certificate except NoSec all other modes uses DTLS security.
NoSec: DTLS is disabled and security mechanisms are implemented by lower layer protocols like IPSec Encapsulating Security Payload. This mode assumes that security is not provided or in the CoAP transmitted message.
PreSharedKey (DTLS enabled): In this mode, symmetric keys are provided to client and server before the start of DTLS handshake. The exchange of these keys occurs in the previous phase called Provisioning Phase where devices configured. Applications can use one key per device or one key for a group of devices. PSK ciphersuite TLS_PSK_WITH_AES_128_CCM_8 is specified mandatory for CoAP. This mode is suitable for devices that are unable to employ the public key cryptography. It also consumes a small amount of computational resources and bandwidth which is very suitable for constraint environments.
RawPublicKey (DTLS enabled): In this mode, the device has an asymmetric key pair, an identity calculated from the public key, and a list of identities of the nodes that can communicate with it. This list is also configured in the Provisioning Phase. It is the mandatory mode for devices that require authentication based on public key. The devices are programmed with pre-provisioned list of keys so that devices can initiate a DTLS session without certificate.
Certificate (DTLS enabled): The device has an asymmetric key pair with a [url removed, login to view] certificate. The CoAP defines the TLS ECDHE ECDSA WITH AES 128 CCM 8 ciphersuite when using DTLS with Certificates. The certificates must be signed with ECDSA using secp256r1, and the signature must use SHA-256. supports authentication based on public key and application that participate in certification chain. The assumption of this mode is that security infrastructure is available. Devices that include asymmetric key and have unknown [url removed, login to view] certificates can be validated using the certificate mode an
Project ID: #12590998
