9. Sécurisation de CoAP

Cette section définit la liaison DTLS pour CoAP.

Pendant la phase de provisionnement, un dispositif CoAP reçoit les informations de sécurité dont il a besoin, y compris le matériel de clé et les listes de contrôle d'accès. Cette spécification définit le provisionnement pour le mode RawPublicKey à la Section 9.1.3.2.1. À la fin de la phase de provisionnement, le dispositif se trouvera dans l'un des quatre modes de sécurité avec les informations suivantes pour le mode considéré. Les modes NoSec et RawPublicKey sont obligatoires à implémenter pour cette spécification.

NoSec : Il n'y a pas de sécurité au niveau du protocole (DTLS est désactivé). Des techniques alternatives permettant de fournir une sécurité de couche inférieure DEVRAIENT être utilisées lorsque cela est approprié. L'utilisation d'IPsec est discutée dans [IPsec-CoAP]. Certaines couches de liaison utilisées avec des nœuds contraints fournissent également une sécurité de couche de liaison, qui peut être appropriée avec une gestion de clés adéquate.

PreSharedKey : DTLS est activé, il existe une liste de clés pré-partagées [RFC4279], et chaque clé inclut une liste des nœuds avec lesquels elle peut être utilisée pour communiquer, comme décrit à la Section 9.1.3.1. À l'extrême, il peut y avoir une clé pour chaque nœud avec lequel ce nœud CoAP doit communiquer (rapport nœud/clé de 1:1). Inversement, si plus de deux entités partagent une clé pré-partagée spécifique, cette clé permet uniquement aux entités de s'authentifier en tant que membre de ce groupe et non en tant que pair spécifique.

RawPublicKey : DTLS est activé et le dispositif possède une paire de clés asymétriques sans certificat (une clé publique brute) qui est validée à l'aide d'un mécanisme hors bande [RFC7250], comme décrit à la Section 9.1.3.2. Le dispositif possède également une identité calculée à partir de la clé publique et une liste d'identités des nœuds avec lesquels il peut communiquer.

Certificate : DTLS est activé et le dispositif possède une paire de clés asymétriques avec un certificat X.509 [RFC5280] qui le lie à son sujet et qui est signé par une racine de confiance commune, comme décrit à la Section 9.1.3.3. Le dispositif possède également une liste d'ancres de confiance racines pouvant être utilisées pour valider un certificat.

Dans le mode "NoSec", le système envoie simplement les paquets sur UDP normal au-dessus d'IP, ce qui est indiqué par le schéma "coap" et le port CoAP par défaut. Le système n'est sécurisé qu'en empêchant les attaquants de pouvoir envoyer ou recevoir des paquets depuis le réseau avec les nœuds CoAP ; voir la Section 11.5 pour une complication supplémentaire de cette approche.

Les trois autres modes de sécurité sont obtenus à l'aide de DTLS et sont indiqués par le schéma "coaps" et le port CoAP par défaut sécurisé par DTLS. Le résultat est une association de sécurité qui peut être utilisée pour authentifier (dans les limites du modèle de sécurité) et, sur la base de cette authentification, autoriser le partenaire de communication. CoAP lui-même ne fournit pas de primitives de protocole pour l'authentification ou l'autorisation ; lorsque cela est requis, cela peut être fourni soit par la sécurité de communication (c'est-à-dire IPsec ou DTLS), soit par la sécurité d'objet (au sein de la charge utile). Les dispositifs qui exigent une autorisation pour certaines opérations sont censés exiger l'une de ces deux formes de sécurité. Nécessairement, lorsqu'un intermédiaire est impliqué, la sécurité de communication ne fonctionne que si cet intermédiaire fait partie des relations de confiance. CoAP ne fournit pas de moyen de transmettre à d'autres intermédiaires ou serveurs d'origine les différents niveaux d'autorisation qu'un client peut avoir avec un intermédiaire -- il peut donc être nécessaire d'effectuer toute l'autorisation au niveau du premier intermédiaire.

9.1. CoAP sécurisé par DTLS

Tout comme HTTP est sécurisé à l'aide de Transport Layer Security (TLS) au-dessus de TCP, CoAP est sécurisé à l'aide de Datagram TLS (DTLS) [RFC6347] au-dessus d'UDP (voir la Figure 13). Cette section définit la liaison de CoAP à DTLS, ainsi que les configurations minimales obligatoires à implémenter appropriées pour les environnements contraints. La liaison est définie par une série de deltas par rapport au CoAP en unicast. En pratique, DTLS est TLS avec des fonctionnalités ajoutées pour faire face à la nature non fiable du transport UDP.

+----------------------+
|      Application     |
+----------------------+
+----------------------+
|  Requests/Responses  |
|----------------------|  CoAP
|       Messages       |
+----------------------+
+----------------------+
|         DTLS         |
+----------------------+
+----------------------+
|          UDP         |
+----------------------+

Figure 13 : Couches abstraites de CoAP sécurisé par DTLS

Dans certains nœuds contraints (mémoire flash et/ou RAM limitées) et certains réseaux (bande passante limitée ou exigences d'évolutivité élevées), et selon les suites de chiffrement spécifiques utilisées, tous les modes de DTLS peuvent ne pas être applicables. Certaines suites de chiffrement DTLS peuvent ajouter une complexité d'implémentation importante ainsi qu'un certain surcoût de poignée de main initial nécessaire à l'établissement de l'association de sécurité. Une fois la poignée de main initiale terminée, DTLS ajoute un surcoût limité par datagramme d'environ 13 octets, sans compter les éventuels vecteurs d'initialisation/nonces (par exemple 8 octets avec TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), les valeurs de contrôle d'intégrité (par exemple 8 octets avec TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]) et le remplissage requis par la suite de chiffrement. L'opportunité d'utiliser un mode donné de DTLS pour une application fondée sur CoAP doit être soigneusement évaluée en tenant compte des suites de chiffrement spécifiques qui peuvent être applicables, de la compatibilité de la maintenance de session avec les flux applicatifs et de la disponibilité de ressources suffisantes sur les nœuds contraints et pour le surcoût réseau ajouté. (Pour certains modes d'utilisation de DTLS, cette spécification identifie une suite de chiffrement obligatoire à implémenter. Il s'agit d'une exigence d'implémentation visant à maximiser l'interopérabilité dans les cas où ces suites de chiffrement sont effectivement appropriées. Les politiques de sécurité spécifiques d'une application peuvent déterminer l'ensemble réel des suites de chiffrement utilisables.) DTLS n'est pas applicable à la gestion de clés de groupe (communication multicast) ; il peut toutefois être un composant d'un futur protocole de gestion de clés de groupe.

9.1.1. Couche de messagerie

Le point de terminaison agissant comme client CoAP devrait également agir comme client DTLS. Il devrait initier une session vers le serveur sur le port approprié. Une fois la poignée de main DTLS terminée, le client peut initier la première requête CoAP. Tous les messages CoAP DOIVENT être envoyés en tant que "données d'application" DTLS.

Les règles suivantes sont ajoutées pour faire correspondre un message Acknowledgement ou un message Reset à un message Confirmable, ou un message Reset à un message Non-confirmable : la session DTLS DOIT être la même, et l'époque DOIT être la même.

Un message est identique lorsqu'il est envoyé au sein de la même session DTLS et de la même époque et qu'il possède la même Message ID.

Note : Lorsqu'un message Confirmable est retransmis, un nouveau numéro de séquence DTLS (sequence_number) est utilisé à chaque tentative, même si la Message ID CoAP reste identique. Un destinataire doit donc toujours effectuer la déduplication telle que décrite à la Section 4.5. Les retransmissions NE DOIVENT PAS être effectuées d'une époque à l'autre.

Les connexions DTLS en mode RawPublicKey et Certificate sont établies à l'aide d'une authentification mutuelle, de sorte qu'elles peuvent rester actives et être réutilisées pour de futurs échanges de messages dans l'un ou l'autre sens. Les dispositifs peuvent fermer une connexion DTLS lorsqu'ils ont besoin de récupérer des ressources, mais en général ils devraient maintenir la connexion active aussi longtemps que possible. Fermer la connexion DTLS après chaque échange de messages CoAP est très inefficace.

9.1.2. Couche requête/réponse

Les règles suivantes sont ajoutées pour faire correspondre une réponse à une requête : la session DTLS DOIT être la même, et l'époque DOIT être la même.

Cela signifie que la réponse à une requête sécurisée par DTLS DOIT toujours être sécurisée par DTLS en utilisant la même session de sécurité et la même époque. Toute tentative de fournir une réponse NoSec à une requête DTLS ne correspond tout simplement pas à la requête et DOIT donc être rejetée (à moins qu'elle ne corresponde à une requête NoSec sans rapport).

9.1.3. Identité du point de terminaison

Les dispositifs DEVRAIENT prendre en charge l'indication de nom de serveur (Server Name Indication, SNI) afin d'indiquer leur autorité dans le champ SNI HostName, tel que défini à la Section 3 de [RFC6066]. Cela est nécessaire pour que, lorsqu'un hôte agissant comme serveur virtuel pour plusieurs autorités reçoit une nouvelle connexion DTLS, il sache quelles clés utiliser pour la session DTLS.

9.1.3.1. Clés pré-partagées

Lors de l'établissement d'une connexion vers un nouveau nœud, le système sélectionne une clé appropriée en fonction des nœuds qu'il cherche à atteindre, puis établit une session DTLS en utilisant un mode PSK (Pre-Shared Key) de DTLS. Les implémentations dans ces modes DOIVENT prendre en charge la suite de chiffrement obligatoire à implémenter TLS_PSK_WITH_AES_128_CCM_8, telle que spécifiée dans [RFC6655].

Selon le modèle de mise en service, les applications peuvent avoir besoin de définir un profil d'application pour les indications d'identité (comme requis et détaillé à la Section 5.2 de [RFC4279]) afin de permettre l'utilisation d'indications d'identité PSK.

Les considérations de sécurité de la Section 7 de [RFC4279] s'appliquent. En particulier, les applications devraient soigneusement évaluer si elles ont besoin ou non de la confidentialité persistante (Perfect Forward Secrecy, PFS) et sélectionner une suite de chiffrement appropriée (Section 7.1 de [RFC4279]). L'entropie de la PSK doit être suffisante pour atténuer les attaques par force brute et (lorsque la PSK n'est pas choisie de manière aléatoire mais par un humain) les attaques par dictionnaire (Section 7.2 de [RFC4279]). La communication en clair des identités des clients peut divulguer des données ou compromettre la vie privée (Section 7.3 de [RFC4279]).

9.1.3.2. Certificats de clé publique brute

Dans ce mode, le dispositif possède une paire de clés asymétriques mais sans certificat X.509 (appelée clé publique brute) ; par exemple, la paire de clés asymétriques est générée par le fabricant et installée sur le dispositif (voir également la Section 11.6). Un dispositif PEUT être configuré avec plusieurs clés publiques brutes. Le type et la longueur de la clé publique brute dépendent de la suite de chiffrement utilisée. Les implémentations en mode RawPublicKey DOIVENT prendre en charge la suite de chiffrement obligatoire à implémenter TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, telle que spécifiée dans [RFC7251], [RFC5246] et [RFC4492]. La clé utilisée DOIT être compatible ECDSA. La courbe secp256r1 DOIT être prise en charge [RFC4492] ; cette courbe est équivalente à la courbe NIST P-256. L'algorithme de hachage est SHA-256. Les implémentations DOIVENT utiliser les extensions Supported Elliptic Curves et Supported Point Formats [RFC4492] ; le format de point non compressé DOIT être pris en charge ; [RFC6090] peut être utilisé comme méthode d'implémentation. Certaines indications relatives à la mise en œuvre de cette suite de chiffrement figurent dans [W3CXMLSEC]. Le mécanisme d'utilisation des clés publiques brutes avec TLS est spécifié dans [RFC7250].

Note d'implémentation : Concrètement, cela signifie que les extensions listées à la Figure 14, avec au moins les valeurs indiquées, seront présentes dans la poignée de main DTLS.

   Extension: elliptic_curves
    Type: elliptic_curves (0x000a)
    Length: 4
    Elliptic Curves Length: 2
    Elliptic curves (1 curve)
      Elliptic curve: secp256r1 (0x0017)

   Extension: ec_point_formats
    Type: ec_point_formats (0x000b)
    Length: 2
    EC point formats Length: 1
    Elliptic curves point formats (1)
      EC point format: uncompressed (0)

   Extension: signature_algorithms
    Type: signature_algorithms (0x000d)
    Length: 4
    Data (4 bytes): 00 02 04 03
      HashAlgorithm: sha256 (4)
      SignatureAlgorithm: ecdsa (3)

Figure 14 : Extensions DTLS présentes pour TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8

9.1.3.2.1. Provisionnement

Le mode RawPublicKey a été conçu pour être facilement provisionné dans les déploiements M2M. On suppose que chaque dispositif dispose d'une paire de clés publiques asymétriques appropriée installée. Un identifiant est calculé par le point de terminaison à partir de la clé publique, comme décrit à la Section 2 de [RFC6920]. Toutes les implémentations qui prennent en charge la vérification des identités RawPublicKey DOIVENT prendre en charge au moins le mode sha-256-120 (SHA-256 tronqué à 120 bits). Les implémentations DEVRAIENT également prendre en charge des identifiants de longueur supérieure et PEUVENT prendre en charge des longueurs plus courtes. Notez que les longueurs plus courtes offrent une sécurité moindre contre les attaques, et que leur utilisation est NON RECOMMANDÉE.

Selon la manière dont les identifiants sont fournis au système qui les vérifie, la prise en charge des formats URI, binaire et/ou lisible par un humain [RFC6920] doit être implémentée. Toutes les implémentations DEVRAIENT prendre en charge le mode binaire, et les implémentations disposant d'une interface utilisateur DEVRAIENT également prendre en charge le format lisible par un humain.

Pendant le provisionnement, l'identifiant de chaque nœud est collecté, par exemple en lisant un code-barres à l'extérieur du dispositif ou en obtenant une liste précompilée des identifiants. Ces identifiants sont ensuite installés dans le point de terminaison correspondant, par exemple un serveur de collecte de données M2M. L'identifiant est utilisé à deux fins : associer le point de terminaison à d'autres informations sur le dispositif et effectuer le contrôle d'accès. Pendant le provisionnement (initial et continu), une liste de contrôle d'accès des identifiants avec lesquels le dispositif peut démarrer des sessions DTLS DEVRAIT également être installée et maintenue.

9.1.3.3. Certificats X.509

Les implémentations en mode Certificate DOIVENT prendre en charge la suite de chiffrement obligatoire à implémenter TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, telle que spécifiée dans [RFC7251], [RFC5246] et [RFC4492]. À savoir, le certificat inclut un SubjectPublicKeyInfo qui indique un algorithme id-ecPublicKey avec namedCurves secp256r1 [RFC5480] ; le format de la clé publique est non compressé [RFC5480] ; l'algorithme de hachage est SHA-256 ; s'il est présent, l'extension key usage indique digitalSignature. Les certificats DOIVENT être signés avec ECDSA en utilisant secp256r1, et la signature DOIT utiliser SHA-256. La clé utilisée DOIT être compatible ECDSA. La courbe secp256r1 DOIT être prise en charge [RFC4492] ; cette courbe est équivalente à la courbe NIST P-256. L'algorithme de hachage est SHA-256. Les implémentations DOIVENT utiliser les extensions Supported Elliptic Curves et Supported Point Formats [RFC4492] ; le format de point non compressé DOIT être pris en charge ; [RFC6090] peut être utilisé comme méthode d'implémentation.

Le sujet du certificat serait construit à partir d'un identifiant unique à long terme du dispositif tel que l'EUI-64 [EUI64]. Le sujet pourrait également être fondé sur le nom de domaine pleinement qualifié (FQDN) utilisé comme partie Host de l'URI CoAP. Toutefois, l'adresse IP du dispositif ne devrait généralement pas être utilisée comme sujet, car elle changerait avec le temps. Le processus de découverte utilisé dans le système établirait la correspondance entre les adresses IP des dispositifs considérés et le sujet de chaque dispositif. Certains dispositifs pourraient avoir plus d'un sujet et auraient besoin de plus d'un certificat.

Lorsqu'une nouvelle connexion est établie, le certificat du dispositif distant doit être vérifié. Si le nœud CoAP dispose d'une source de temps absolu, le nœud DEVRAIT vérifier que les dates de validité du certificat sont dans la plage attendue. Le certificat DOIT être validé conformément aux exigences de sécurité, à l'aide d'une fonctionnalité équivalente à l'algorithme spécifié à la Section 6 de [RFC5280]. Si le certificat contient un SubjectAltName, alors l'autorité de l'URI de la requête DOIT correspondre à au moins l'une des autorités de toute URI CoAP trouvée dans un champ de type URI de l'ensemble SubjectAltName. S'il n'y a pas de SubjectAltName dans le certificat, alors l'autorité de l'URI de la requête DOIT correspondre au Common Name (CN) trouvé dans le certificat en utilisant les règles de correspondance définies dans [RFC3280], à l'exception près que les certificats comportant des caractères génériques ne sont pas autorisés.

La prise en charge par CoRE de la vérification de l'état des certificats nécessite une étude plus approfondie. Comme une correspondance du Online Certificate Status Protocol (OCSP) [RFC6960] sur CoAP n'est pas actuellement définie et qu'OCSP peut également ne pas être facilement applicable dans tous les environnements, une approche alternative peut consister à utiliser l'extension TLS Certificate Status Request (Section 8 de [RFC6066] ; également appelée "OCSP stapling") ou, de préférence, l'extension Multiple Certificate Status ([RFC6961]), si elle est disponible.

Si le système dispose d'une clé partagée en plus du certificat, alors une suite de chiffrement incluant la clé partagée, telle que TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489], DEVRAIT être utilisée.