10. Mécanismes de Sécurité

Cette section décrit la génération et le traitement des messages RPL sécurisés. Le bit de poids fort du code de message RPL identifie si un message RPL est sécurisé ou non. En plus des versions sécurisées des messages de contrôle de base (DIS, DIO, DAO, DAO-ACK), RPL possède plusieurs messages qui ne sont pertinents que dans les réseaux où la sécurité est activée.

La complexité et la taille de l'implémentation sont une préoccupation majeure pour les LLN, de sorte qu'il peut être économiquement ou physiquement impossible d'inclure des dispositions de sécurité sophistiquées dans une implémentation RPL. De plus, de nombreux déploiements peuvent utiliser la sécurité de la couche liaison ou d'autres mécanismes de sécurité pour répondre à leurs exigences de sécurité sans nécessiter l'utilisation de la sécurité dans RPL.

Par conséquent, les fonctionnalités de sécurité décrites dans ce document sont OPTIONNELLES à implémenter. Une implémentation donnée PEUT supporter un sous-ensemble (y compris l'ensemble vide) des fonctionnalités de sécurité décrites, par exemple, elle pourrait supporter l'intégrité et la confidentialité, mais pas les signatures. Une implémentation DEVRAIT spécifier clairement quels mécanismes de sécurité sont supportés, et il est RECOMMANDÉ que les implémenteurs examinent attentivement les exigences de sécurité et la disponibilité des mécanismes de sécurité dans leur réseau.

10.1. Aperçu de la Sécurité

RPL supporte trois modes de sécurité :

• Non sécurisé (Unsecured) : Dans ce mode de sécurité, RPL utilise des messages DIS, DIO, DAO et DAO-ACK de base, qui n'ont pas de sections de sécurité. Comme un réseau pourrait utiliser d'autres mécanismes de sécurité, tels que la sécurité de la couche liaison, le mode non sécurisé n'implique pas que tous les messages sont envoyés sans aucune protection.

• Préinstallé (Preinstalled) : Dans ce mode de sécurité, RPL utilise des messages sécurisés. Pour rejoindre une instance RPL, un nœud doit avoir une clé préinstallée. Les nœuds l'utilisent pour assurer la confidentialité, l'intégrité et l'authenticité des messages. Un nœud peut, en utilisant cette clé préinstallée, rejoindre le réseau RPL soit en tant qu'hôte, soit en tant que routeur.

• Authentifié (Authenticated) : Dans ce mode de sécurité, RPL utilise des messages sécurisés. Pour rejoindre une instance RPL, un nœud doit avoir une clé préinstallée. Les nœuds utilisent cette clé pour assurer la confidentialité, l'intégrité et l'authenticité des messages. En utilisant cette clé préinstallée, un nœud ne peut rejoindre le réseau qu'en tant qu'hôte. Pour rejoindre le réseau en tant que routeur, un nœud doit obtenir une seconde clé auprès d'une autorité de clé. Cette autorité de clé peut authentifier que le demandeur est autorisé à être un routeur avant de lui fournir la seconde clé. Le mode authentifié ne peut pas être supporté par des algorithmes symétriques. Au moment de la rédaction de cette spécification, RPL ne supporte que les algorithmes symétriques : le mode authentifié est inclus au bénéfice de futures primitives cryptographiques potentielles. Voir la Section 10.3.

Le fait que l'instance RPL utilise ou non le mode non sécurisé est signalé par le fait qu'elle utilise ou non des messages RPL sécurisés. Le fait qu'un réseau sécurisé utilise le mode préinstallé ou authentifié est signalé par le bit 'A' de l'option de configuration DAG.

Cette spécification spécifie CCM -- Counter with CBC-MAC (Cipher Block Chaining - Message Authentication Code) -- comme base cryptographique pour la sécurité RPL [RFC3610]. Dans cette spécification, CCM utilise AES-128 comme algorithme cryptographique sous-jacent. Il y a des bits réservés dans la section Sécurité pour spécifier d'autres algorithmes à l'avenir.

Tous les messages RPL sécurisés ont soit un MAC, soit une signature. Optionnellement, les messages RPL sécurisés ont également une protection par chiffrement pour la confidentialité. Les formats de messages RPL sécurisés supportent à la fois les schémas de chiffrement/authentification intégrés (par exemple, CCM) ainsi que les schémas qui chiffrent et authentifient les paquets séparément.

10.2. Rejoindre un Réseau Sécurisé

La sécurité RPL suppose qu'un nœud souhaitant rejoindre un réseau sécurisé a été pré-configuré avec une clé partagée pour communiquer avec les voisins et la racine RPL. Pour rejoindre un réseau RPL sécurisé, un nœud écoute les DIO sécurisés ou déclenche des DIO sécurisés en envoyant un DIS sécurisé. En plus des règles DIO/DIS de la Section 8, les messages DIO et DIS sécurisés ont ces règles :

1. S'il est envoyé, ce DIS sécurisé initial DOIT définir le champ Mode d'Identifiant de Clé (Key Identifier Mode) à 0 (00) et DOIT définir le champ Niveau de Sécurité (Security Level) à 1 (001). La clé utilisée DOIT être la clé de groupe pré-configurée (Index de Clé 0x00).

2. Lorsqu'un nœud réinitialise son temporisateur Trickle en réponse à un DIS sécurisé (Section 8.3), le prochain DIO qu'il transmet DOIT être un DIO sécurisé avec la même configuration de sécurité que le DIS sécurisé. Si un nœud reçoit plusieurs messages DIS sécurisés avant de transmettre un DIO, le DIO sécurisé DOIT avoir la même configuration de sécurité que le dernier DIS auquel il répond.

3. Lorsqu'un nœud envoie un DIO en réponse à un DIS sécurisé unicast (Section 8.3), le DIO DOIT être un DIO sécurisé.

Les règles ci-dessus permettent à un nœud de rejoindre une instance RPL sécurisée en utilisant la clé partagée pré-configurée. Une fois qu'un nœud a rejoint le DODAG en utilisant la clé partagée pré-configurée, le bit 'A' de l'option de Configuration détermine ses capacités. Si le bit 'A' de l'option de Configuration est effacé, alors les nœuds peuvent utiliser cette clé partagée préinstallée pour échanger des messages normalement : ils peuvent émettre des DIO, des DAO, etc.

Si le bit 'A' de l'option de Configuration est défini et que l'instance RPL fonctionne en mode authentifié :

1. Un nœud NE DOIT PAS annoncer un Rang autre que INFINITE_RANK dans les DIO sécurisés avec l'Index de Clé 0x00. Lors du traitement des messages DIO sécurisés avec l'Index de Clé 0x00, un nœud de traitement DOIT considérer le Rang annoncé comme étant INFINITE_RANK. Toute autre valeur entraîne le rejet du message.

2. Les DAO sécurisés utilisant un Index de Clé 0x00 NE DOIVENT PAS avoir une option Cible RPL avec un préfixe autre que l'adresse du nœud. Si un nœud reçoit un message DAO sécurisé utilisant la clé partagée préinstallée où l'option Cible RPL ne correspond pas à l'adresse source IPv6, il DOIT rejeter le message DAO sécurisé sans traitement supplémentaire.

Les règles ci-dessus signifient que dans les instances RPL où le bit 'A' est défini, en utilisant l'Index de Clé 0x00, un nœud peut rejoindre l'instance RPL en tant qu'hôte mais pas en tant que routeur. Un nœud doit communiquer avec une autorité de clé pour obtenir une clé qui lui permettra d'agir en tant que routeur.

10.3. Installation des Clés

Le mode authentifié nécessite qu'un futur routeur installe dynamiquement de nouvelles clés une fois qu'il a rejoint un réseau en tant qu'hôte. Ayant rejoint en tant qu'hôte, le nœud utilise la messagerie IP standard pour communiquer avec un serveur d'autorisation, qui peut fournir de nouvelles clés.

Le protocole pour obtenir de telles clés est hors de portée de cette spécification et sera élaboré dans de futures spécifications. Cette élaboration est nécessaire pour que RPL fonctionne de manière sécurisée en mode authentifié.

10.4. Vérifications de Cohérence

Les nœuds RPL envoient des messages de Vérification de Cohérence (Consistency Check - CC) pour se protéger contre les attaques par rejeu et synchroniser les compteurs.

1. Si un nœud reçoit un message CC unicast avec le bit 'R' effacé, et qu'il est membre de ou est en train de rejoindre le DODAG associé, il DEVRAIT répondre avec un message CC unicast à l'expéditeur. Cette réponse DOIT avoir le bit 'R' défini, et elle DOIT avoir les mêmes champs nonce CC, RPLInstanceID et DODAGID que le message qu'il a reçu.

2. Si un nœud reçoit un message CC multicast, il DOIT rejeter le message sans traitement supplémentaire.

Les messages de Vérification de Cohérence permettent aux nœuds d'émettre un défi-réponse pour valider la valeur actuelle du compteur d'un nœud. Parce que le nonce CC est généré par le challengeur, un adversaire rejouant des messages a peu de chances de pouvoir générer une réponse correcte. Le compteur dans la réponse de Vérification de Cohérence permet au challengeur de valider les valeurs de compteur qu'il entend.

10.5. Compteurs

Dans le cas le plus simple, la valeur du compteur est un entier non signé qu'un nœud incrémente de un ou plus à chaque transmission RPL sécurisée. Le compteur PEUT représenter un horodatage qui a les propriétés suivantes :

1. L'horodatage DOIT avoir une longueur d'au moins six octets.

2. L'horodatage DOIT être en granularité de 1024 Hz (milliseconde binaire).

3. L'heure de début de l'horodatage DOIT être le 1er janvier 1970, 00:00:00 UTC.

4. Si le compteur représente un horodatage, la valeur du compteur DOIT être une valeur calculée comme suit. Soit T l'horodatage, S l'heure de début de la clé utilisée, et E l'heure de fin de la clé utilisée. S et E sont tous deux représentés en utilisant les trois mêmes règles que l'horodatage décrit ci-dessus. Si E > T < S, alors le compteur est invalide et un nœud NE DOIT PAS générer de paquet. Sinon, la valeur du compteur est égale à T-S.

5. Si le compteur représente un tel horodatage, un nœud PEUT définir le drapeau 'T' de la section Sécurité des paquets RPL sécurisés.

6. Si le champ Compteur ne présente pas un tel horodatage, alors un nœud NE DOIT PAS définir le drapeau 'T'.

7. Si un nœud n'a pas d'horodatage local qui satisfait aux exigences ci-dessus, il DOIT ignorer le drapeau 'T'.

Si un nœud supporte de tels horodatages et qu'il reçoit un message avec le drapeau 'T' défini, il PEUT appliquer la vérification temporelle sur le message reçu décrite dans la Section 10.7.1. Si un nœud reçoit un message sans le drapeau 'T' défini, il NE DOIT PAS appliquer cette vérification temporelle. La politique de sécurité d'un nœud PEUT, pour des raisons d'application, inclure le rejet de tous les messages sans le drapeau 'T' défini.

Le drapeau 'T' est présent parce que de nombreux LLN aujourd'hui maintiennent déjà une synchronisation temporelle globale à une granularité inférieure à la milliseconde pour la sécurité, l'application et d'autres raisons. Permettre à RPL de tirer parti de cette fonctionnalité existante lorsqu'elle est présente simplifie grandement les solutions à certains problèmes de sécurité, tels que la protection contre les délais.

10.6. Transmission de Paquets Sortants

Étant donné un paquet de contrôle RPL sortant et la protection de sécurité requise, cette section décrit comment RPL génère le paquet sécurisé à transmettre. Elle décrit également l'ordre des opérations cryptographiques pour fournir la protection requise.

L'exigence de protection de sécurité et le niveau de sécurité à appliquer à un paquet RPL sortant seront déterminés par la base de données de politique de sécurité du nœud. La configuration de cette base de données de politique de sécurité pour le traitement des paquets sortants est spécifique à l'implémentation.

Lorsque des messages RPL sécurisés doivent être transmis, un nœud RPL DOIT définir la section Sécurité (T, Sec, KIM et LVL) dans le paquet RPL sortant pour décrire le niveau de protection et les paramètres de sécurité qui sont appliqués (voir Section 6.1). Le bit de sous-champ Sécurité du champ Code de Message RPL DOIT être défini pour indiquer le message RPL sécurisé.

La valeur du compteur utilisée dans la construction du nonce CCM AES-128 (Figure 31) pour sécuriser le paquet sortant DOIT être un incrément du dernier compteur transmis à l'adresse de destination particulière.

Lorsque la politique de sécurité spécifie l'application de la protection contre les délais, le compteur d'Horodatage utilisé dans la construction du nonce CCM pour sécuriser le paquet sortant DOIT être incrémenté selon les règles de la Section 10.5. Lorsqu'un compteur d'Horodatage est appliqué (indiqué avec le drapeau 'T' défini), le compteur d'Horodatage maintenu localement DOIT être inclus comme partie du message RPL sécurisé transmis.

L'algorithme cryptographique utilisé pour sécuriser le paquet sortant sera spécifié par la base de données de politique de sécurité du nœud et DOIT être indiqué dans la valeur du champ Sec défini dans le message sortant.

La politique de sécurité pour le paquet sortant déterminera le KIM applicable et l'Identifiant de Clé spécifiant la clé de sécurité à utiliser pour le traitement cryptographique du paquet, y compris l'utilisation optionnelle de clés de signature (voir Section 6.1). La politique de sécurité spécifiera également l'algorithme (Algorithm) et le niveau de protection (Level) sous la forme d'authentification ou d'authentification et chiffrement, et l'utilisation potentielle de signatures qui s'appliqueront au paquet sortant.

Lorsque le chiffrement est appliqué, un nœud DOIT remplacer la charge utile du paquet d'origine par cette charge utile chiffrée en utilisant la protection de sécurité, la clé et le nonce CCM spécifiés dans la section Sécurité du paquet.

Tous les messages RPL sécurisés incluent une protection de l'intégrité. Conjointement avec le traitement de l'algorithme de sécurité, un nœud dérive soit un MAC, soit une signature qui DOIT être incluse comme partie du paquet RPL sécurisé sortant.

10.7. Réception de Paquets Entrants

Cette section décrit la réception et le traitement d'un paquet RPL sécurisé. Étant donné un paquet RPL sécurisé entrant, où le bit de sous-champ Sécurité du champ Code de Message RPL est défini, cette section décrit comment RPL génère une variante non chiffrée du paquet et valide son intégrité.

Le récepteur utilise les champs de contrôle de sécurité RPL pour déterminer le traitement de sécurité de paquet nécessaire. Si le niveau de sécurité décrit pour le type de message et l'expéditeur est inconnu ou ne répond pas aux politiques de sécurité maintenues localement, un nœud DOIT rejeter le paquet sans traitement supplémentaire, PEUT lever une alerte de gestion, et NE DOIT PAS envoyer de messages en réponse. Ces politiques peuvent inclure des niveaux de sécurité, des clés utilisées, des identifiants de source, ou l'absence de compteurs basés sur l'horodatage (comme indiqué par le drapeau 'T'). La configuration de la base de données de politique de sécurité pour le traitement des paquets entrants est hors de portée de cette spécification (elle peut, par exemple, être définie via la Configuration DIO ou via une configuration de routeur administratif hors bande).

Lorsque le Niveau de Sécurité du message (LVL) indique un message RPL chiffré, le nœud utilise les informations de clé identifiées par le champ KIM ainsi que le nonce CCM comme entrée pour le traitement de déchiffrement de la charge utile du message. Le nonce CCM sera dérivé du champ Compteur du message et d'autres informations reçues et maintenues localement (voir Section 10.9.1). Le contenu du message en clair sera obtenu en invoquant le mode d'opération cryptographique inverse spécifié par le champ Sec du paquet reçu.

Le récepteur utilisera le nonce CCM et les informations de clé identifiées pour vérifier l'intégrité du paquet entrant. Si la vérification de l'intégrité échoue par rapport au MAC reçu, un nœud DOIT rejeter le paquet.

Si le message reçu a une valeur de compteur initialisée (valeur zéro) et que le récepteur a un compteur entrant actuellement maintenu pour l'expéditeur du message, le récepteur DOIT initier une resynchronisation de compteur en envoyant un message de réponse de Vérification de Cohérence (voir Section 6.6) à la source du message. Le message de réponse de Vérification de Cohérence sera protégé avec le compteur sortant complet actuel maintenu pour l'adresse de nœud particulière. Ce compteur sortant sera inclus dans la section de sécurité du message tandis que le compteur entrant sera inclus dans la charge utile du message de Vérification de Cohérence.

Sur la base de la politique de sécurité spécifiée, un nœud PEUT appliquer une protection contre le rejeu pour un message RPL reçu. La vérification de rejeu DEVRAIT être effectuée avant l'authentification du paquet reçu. Le compteur, tel qu'obtenu à partir du paquet entrant, sera comparé au filigrane du compteur entrant maintenu pour l'adresse de nœud d'origine donnée. Si la valeur du compteur du message reçu est non nulle et inférieure au filigrane du compteur entrant maintenu, un rejeu de paquet potentiel est indiqué et le nœud DOIT rejeter le paquet entrant.

Si la protection contre les délais est spécifiée comme partie des vérifications de politique de sécurité des paquets entrants, le compteur d'Horodatage est utilisé pour valider la rapidité du message RPL reçu. Si la valeur du compteur d'Horodatage du message entrant indique une heure de transmission de message antérieure au compteur de temps de transmission maintenu localement pour l'adresse de l'expéditeur, une violation de rejeu est indiquée et le nœud DOIT rejeter le paquet entrant. Si la valeur du compteur d'Horodatage reçu indique une heure de transmission de message qui est antérieure à l'heure Actuelle moins le délai de paquet acceptable, une violation de délai est indiquée et le nœud DOIT rejeter le paquet entrant.

Une fois qu'un message a été déchiffré, le cas échéant, et a passé avec succès sa vérification d'intégrité, sa vérification de rejeu, et optionnellement ses vérifications de protection contre les délais, le nœud peut mettre à jour ses informations de sécurité locales, telles que la valeur de compteur attendue de la source pour la comparaison de rejeu.

Un nœud NE DOIT PAS mettre à jour ses informations de sécurité à la réception d'un message qui échoue aux vérifications de politique de sécurité ou à d'autres vérifications d'intégrité, de rejeu ou de délai appliquées.

10.7.1. Vérifications de Clé d'Horodatage

Si le drapeau 'T' d'un message est défini et qu'un nœud a un horodatage local qui suit les exigences de la Section 10.5, alors un nœud PEUT vérifier la cohérence temporelle du message. Le nœud calcule l'heure de transmission du message en ajoutant la valeur du compteur à l'heure de début de la clé associée. Si cette heure de transmission est postérieure à l'heure de fin de la clé, le nœud PEUT rejeter le message sans traitement supplémentaire. Si l'heure de transmission est trop loin dans le passé ou le futur par rapport à l'heure locale sur le récepteur, il PEUT rejeter le message sans traitement supplémentaire.

10.8. Couverture de l'Intégrité et de la Confidentialité

Pour un message RPL ICMPv6, le paquet entier est dans la portée de la sécurité RPL.

Les MAC et les signatures sont calculés sur le paquet IPv6 non sécurisé entier. Lors du calcul des MAC et des signatures, les champs IPv6 mutables sont considérés comme remplis de zéros, suivant les règles de la Section 3.3.3.1 de [RFC4302] (IPsec Authenticated Header). Les calculs de MAC et de signature sont effectués avant toute compression que les couches inférieures peuvent appliquer.

Lorsqu'un message RPL ICMPv6 est chiffré, le chiffrement commence au premier octet après la section Sécurité et continue jusqu'au dernier octet du paquet. L'en-tête IPv6, l'en-tête ICMPv6 et le message RPL jusqu'à la fin de la section Sécurité ne sont pas chiffrés, car ils sont nécessaires pour déchiffrer correctement le paquet.

Par exemple, un nœud envoyant un message avec LVL=1, KIM=0, et Algorithm=0 utilise l'algorithme CCM [RFC3610] pour créer un paquet avec les attributs ENC-MAC-32 : il chiffre le paquet et ajoute un MAC de 32 bits. La clé de chiffrement par bloc est déterminée par l'Index de Clé. Le nonce CCM est calculé comme décrit dans la Section 10.9.1 ; le message à authentifier et chiffrer est le message RPL commençant au premier octet après la section Sécurité et se termine par le dernier octet du paquet. Les données d'authentification supplémentaires commencent par le début de l'en-tête IPv6 et se terminent par le dernier octet de la section Sécurité RPL.

10.9. Mode d'Opération Cryptographique

Le mode d'opération cryptographique décrit dans cette spécification (Algorithm = 0) est basé sur CCM et le chiffrement par bloc AES-128 [RFC3610]. Ce mode d'opération est largement supporté par les implémentations existantes. Le mode CCM nécessite un nonce (nonce CCM).

10.9.1. Nonce CCM

Un nœud RPL construit un nonce CCM comme suit :

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                       Identifiant Source                      +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Compteur                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |KIM|Resvd| LVL |
    +-+-+-+-+-+-+-+-+

                        Figure 31 : Nonce CCM

• Identifiant Source (Source Identifier) : 8 octets. L'Identifiant Source est défini à l'identifiant logique de l'expéditeur du paquet protégé.

• Compteur (Counter) : 4 octets. Le Compteur est défini à la valeur (non compressée) du champ correspondant dans l'option Sécurité du message de contrôle RPL.

• Mode d'Identifiant de Clé (Key Identifier Mode - KIM) : 2 bits. KIM est défini à la valeur du champ correspondant dans l'option Sécurité du message de contrôle RPL.

• Niveau de Sécurité (Security Level - LVL) : 3 bits. Le Niveau de Sécurité est défini à la valeur du champ correspondant dans l'option Sécurité du message de contrôle RPL.

Les bits non assignés du nonce CCM sont réservés. Ils DOIVENT être mis à zéro lors de la construction du nonce CCM.

Tous les champs du nonce CCM sont représentés dans l'ordre de l'octet le plus significatif et du bit le plus significatif en premier.

10.9.2. Signatures

Si le KIM indique l'utilisation de signatures (une valeur de 3), alors un nœud ajoute une signature à la charge utile de données du paquet. Le champ Niveau de Sécurité (LVL) décrit la longueur de cette signature. Le schéma de signature dans RPL pour le Mode de Sécurité 3 est une instanciation de l'algorithme RSA (RSASSA-PSS) tel que défini dans la Section 8.1 de [RFC3447]. Comme clé publique, il utilise la paire (n,e), où n est un module RSA de 2048 bits ou 3072 bits et où e=2^{16}+1. Il utilise le mode CCM [RFC3610] comme schéma de chiffrement avec M=0 (comme un chiffrement de flux). Notez que bien que [RFC3610] interdise le mode CCM avec M=0, RPL autorise explicitement le mode CCM avec M=0 lorsqu'il est utilisé conjointement avec une signature, car la signature fournit une authentification de données suffisante. Ici, le mode CCM avec M=0 est spécifié comme dans [RFC3610], mais où le champ M' dans la Section 2.2 DOIT être mis à 0. Il utilise la fonction de hachage SHA-256 spécifiée dans la Section 6.2 de [FIPS180]. Il utilise les règles d'encodage de message de la Section 8.1 de [RFC3447].

Soit 'a' une concaténation d'une représentation de 6 octets du compteur et de l'en-tête du message. La charge utile du paquet est la concaténation droite des données du paquet 'm' et de la signature 's'. Ce schéma de signature est invoqué avec la concaténation droite des parties de message a et m, tandis que la vérification de signature est invoquée avec la concaténation droite des parties de message a et m et avec la signature s.

Les signatures RSA de cette forme fournissent une protection suffisante pour les réseaux RPL. Si nécessaire, des schémas de signature alternatifs qui produisent des signatures plus concises sont hors de portée de cette spécification et peuvent faire l'objet d'une future spécification.

Une implémentation qui supporte la signature RSA avec des signatures de 2048 bits ou 3072 bits DEVRAIT supporter la vérification des signatures RSA de 2048 bits et 3072 bits. Ceci est en considération de fournir un chemin de mise à niveau pour un déploiement RPL.