Algorithmes cryptographiques pour l'information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B - ITSP.40.111

Avant-propos

La présente publication intitulée Algorithmes cryptographiques pour l’information Non classifié, Protégé A et Protégé B est un document NON CLASSIFIÉ publié par le Centre canadien pour la cybersécurité (Centre pour la cybersécurité). Elle constitue une mise à jour et remplace la version publiée précédemment.

Date d’entrée en vigueur

Le présent document entre en vigueur le 17 août 2022.

Historique des révisions

1. Première version : 2 août 2016
2. Version mise à jour (version 2) : 17 août 2022

Vue d’ensemble

La présente publication définit les algorithmes cryptographiques recommandés et les méthodes d’utilisation appropriées que les organisations peuvent mettre en œuvre pour protéger l’information sensible. Pour les organismes et ministères du gouvernement du Canada (GC), les directives contenues dans ce document s’appliquent à l’information NON CLASSIFIÉ, PROTÉGÉ A, et PROTÉGÉ B.

Une organisation se doit d’être en mesure de protéger l’information et les données sensibles pour assurer la prestation de programmes et de services. La cryptographie fournit des mécanismes de sécurité servant à protéger la confidentialité, l’intégrité et l’authenticité de l’information.

Une cryptographique configurée adéquatement présente de nombreux avantages. Elle permet notamment d’assurer la confidentialité, l’intégrité et l’authenticité des données, l’authentification et la responsabilisation des intervenants, de même que la non-répudiation. Plusieurs algorithmes peuvent s’avérer nécessaires pour satisfaire aux exigences de sécurité, et le respect de toutes ces exigences exige parfois la mise en œuvre de chacun de ces algorithmes.

Pour de plus amples renseignements, prière de communiquer avec le :
Centre d’appel du Centre canadien pour la cybersécurité
contact@cyber.gc.ca
613-949-7048 ou 1-833-CYBER-88

1 Introduction

Les organisations recourent à des systèmes de technologies de l’information (TI) pour atteindre leurs objectifs opérationnels. Ces systèmes interconnectés peuvent faire l’objet de sérieuses menaces et cyberattaques pouvant mettre en péril la disponibilité, l’authenticité, la confidentialité et l’intégrité des biens d’information. Des réseaux, des systèmes ou des renseignements compromis peuvent influer négativement les activités et entraîner une atteinte à la protection des données ainsi que des pertes financières.

Le présent document aide les praticiens des technologies à choisir et à utiliser adéquatement des algorithmes cryptographiques. Lorsqu’ils sont utilisés avec des paramètres de domaine valides et des longueurs de clé spécifiques, les algorithmes cryptographiques figurant dans ce document sont des mécanismes cryptographiques recommandés pour protéger la confidentialité et l’intégrité de l’information sensible de niveau NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B associée à un niveau de préjudice moyen, tel qu’il est défini dans l’ITSG-33, La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie ^{Note de bas de page 1}. Pour connaître les exigences relatives à l’utilisation de la cryptographie approuvée par le Centre pour la cybersécurité aux fins de protection de l’information PROTÉGÉ C et classifiée, prière de consulter l’ITSD-01A, Directive en matière de sécurité des TI sur l’application de la sécurité des communications à l’aide de solutions approuvées par le CST ^{Note de bas de page 2}.

Le présent document complète la Ligne directrice sur la définition des exigences en matière d’authentification ^{Note de bas de page 3} du Secrétariat du Conseil du Trésor du Canada (SCT). Les organisations doivent déterminer leurs objectifs et exigences en matière de sécurité dans leur cadre de gestion des risques.

1.1 Notes à l’intention du praticien

Dans le présent document, nous faisons des recommandations relatives aux algorithmes et aux paramètres cryptographiques. Nous dressons également une liste des algorithmes qui devraient être mis hors service. Ainsi, les nouvelles applications ne devraient pas utiliser ces algorithmes. Lorsque les algorithmes sont utilisés dans des applications existantes, ils devraient être remplacés par les algorithmes que nous recommandons dans cette publication. Dans le cas de certains algorithmes, nous précisons une date à laquelle ils auraient dû être remplacés; dans d’autres cas, ces algorithmes doivent être remplacés le plus rapidement possible.

Sauf indication contraire, lorsqu’un algorithme nécessite une primitive, il doit être choisi parmi ceux qui sont recommandés dans le présent document. Par exemple, une fonction de hachage énoncée à la section 6.2 ou 6.3 doit être utilisée avec le code d’authentification de message avec hachage de clé (HMAC pour Keyed-Hash Message Authentication Code) énoncé à la section 7.1. Sauf indication contraire, lorsqu’un algorithme nécessite un paramètre, il doit être choisi parmi ceux qui sont recommandés dans la référence donnée pour l’algorithme.

1.2 Politiques déterminantes

Afin de sécuriser les réseaux, les données et les biens, les organisations doivent analyser et contrer les cybermenaces et les vulnérabilités auxquelles elles font face. Les ministères du GC doivent veiller à ce que les politiques et procédures en matière de sécurité des TI soient mises en œuvre conformément à la Politique sur la sécurité du gouvernement du SCT ^{Note de bas de page 4}.

1.3 Lien avec le processus de gestion des risques liés aux TI

Les lignes directrices du Centre pour la cybersécurité énoncées dans l’ITSG-33, Gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie ^{Note de bas de page 1} proposent un ensemble d’activités pour chacun des deux niveaux organisationnels suivants : le niveau ministériel et le niveau des systèmes d’information.

Description detaillée - Activités de gestion des risques liés à la sécurité des TI

La figure 1 illustre le processus de gestion des risques liés à la sécurité des TI proposé aux annexes 1 et 2 de l’ITSG-33. La figure démontre que les activités de gestion des risques liés à la sécurité des TI sont menées à deux niveaux distincts : au niveau organisationnel et au niveau des systèmes d’information.

Au niveau organisationnel, voici quelques activités de gestion des risques liés à la sécurité des TI menées par les autorités organisationnelles responsables de la sécurité (par exemple, l’ASM, le CSTI) :

• Définir les besoins et les contrôles liés à la sécurité des TI.
• Déployer les contrôles de sécurité.
• Surveiller et évaluer le rendement des contrôles de sécurité, puis maintenir l’autorisation.
• Déterminer les mises à jour des contrôles de sécurité.

Les principaux produits livrables associés au déploiement des contrôles de sécurité sont les profils de contrôle de sécurité organisationnels et les rapports organisationnels d’évaluation des menaces liées aux TI. Ces livrables constituent des éléments clés des activités de gestion des risques liés à la sécurité au niveau des systèmes d’information.

Au niveau des systèmes d’information, voici quelques activités de gestion des risques liés à la sécurité des TI menées par les gestionnaires de projets de TI, les praticiens de la sécurité et les développeurs :

• Définir les besoins et les contrôles liés à la sécurité des TI.
• Concevoir et développer ou acquérir le système d’information dans le respect de la sécurité.
• Intégrer, tester et installer le système d’information dans le respect de la sécurité.
• Exploiter, surveiller et tenir à jour les systèmes d’information dans le respect de la sécurité.
• Éliminer les biens de TI de façon sécuritaire après leur retrait.

L’information découlant des activités opérationnelles et des activités liées à la maintenance contribue à la réalisation des activités de surveillance et d’évaluation au niveau organisationnel. La rétroaction sur le rendement de la sécurité des TI soutient l’activité liée au maintien de l’autorisation dans le cadre de la surveillance et de l’évaluation.

Les activités du niveau ministériel sont intégrées au programme de sécurité de l’organisation pour planifier, gérer, évaluer et améliorer la gestion des risques liés à la sécurité des TI. Les algorithmes cryptographiques doivent être pris en compte dans le cadre des activités de définition, de déploiement, de surveillance et d’évaluation. Ces activités sont décrites en détail à l’annexe 1 de l’ITSG-33 ^{Note de bas de page 1}.

Les activités du niveau des systèmes d’information sont intégrées au cycle de vie d’un système d’information pour s’assurer de ce qui suit :

• les besoins de sécurité des activités opérationnelles prises en charge sont satisfaits;
• des contrôles de sécurité appropriés sont mis en œuvre et fonctionnent comme prévu;
• le rendement des contrôles de sécurité existants est évalué en permanence, fait l’objet de rapports et des mesures appropriées sont prises pour corriger toute lacune relevée.

Les algorithmes cryptographiques doivent être pris en compte dans le cadre de toutes les activités du niveau des systèmes d’information. Ces activités sont décrites en détail à l’annexe 2 de l’ITSG-33 ^{Note de bas de page 1}.

La section suivante décrit les algorithmes de chiffrement que nous recommandons pour protéger la confidentialité de l’information NON CLASSIFIÉ, PROTÉGÉ A, et PROTÉGÉ B. Nous précisons également les algorithmes de chiffrement qui ont été recommandés dans une version antérieure de cette publication, mais qui devraient être abandonnés d’ici 2023.

2 Algorithmes de chiffrement

La section suivante décrit les algorithmes de chiffrement que nous recommandons pour protéger la confidentialité de l’information NON CLASSIFIÉ, PROTÉGÉ A, et PROTÉGÉ B. Nous précisons également les algorithmes de chiffrement qui ont été recommandés dans une version antérieure de cette publication, mais qui devraient être abandonnés d’ici 2023.

2.1 Algorithme de chiffrement avancé

Nous recommandons l’algorithme AES (pour Advanced Encryption Standard), conformément au document intitulé Federal Information Processing Standards (FIPS) Publication 197: Advanced Encryption Standard (en anglais seulement) (National Institute of Standards and Technology, 26 novembre 2001) au moyen d’une longueur de clé de 128, 192 ou 256 bits.

2.2 Algorithme de chiffrement de données triple

L’utilisation de l’algorithme TDEA à trois clés devrait être abandonnée d’ici la fin de 2023.

Nous ne recommandons plus l’option à trois clés de l’algorithme de chiffrement de données triple (TDEA pour Triple Data Encryption Algorithm), conformément au document Special Publication (SP) 800-67 Revision 2: Recommendation for the Triple Data Encryption Algorithm Block Cipher (en anglais seulement) ^{Note de bas de page 6} (National Institute of Standards and Technology, novembre 2017). Une restriction importante est à noter : un trousseau de clés ne devrait pas être utilisé pour chiffrer plus de 2²⁰ blocs de données de 64 bits (National Institute of Standards and Technology, novembre 2017). ^{Note de bas de page 6}

2.3 CAST5

L’utilisation de l’algorithme CAST5 devrait être abandonnée d’ici la fin de 2023.

Nous ne recommandons plus l’utilisation de l’algorithme CAST5, conformément au document Request for Comments (RFC) 2144 The CAST-128 Encryption Algorithm (Adams, mai 1997).^{Note de bas de page 7}

3 Modes de fonctionnement des algorithmes de chiffrement

La section suivante décrit les modes de fonctionnement des algorithmes de chiffrement que nous recommandons d’utiliser avec l’algorithme AES, conformément à la section 2.1.

3.1 Protection de la confidentialité de l’information

Nous recommandons les modes de fonctionnement de chiffrement par blocs suivants pour protéger la confidentialité de l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B, conformément au document NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation – Methods and Techniques (en anglais seulement) (National Institute of Standards and Technology, décembre 2001) : ^{Note de bas de page 8}

• mode de chiffrement par carnet de codage électronique (ECB pour Electronic Codebook) – le mode ECB ne s’applique que dans des situations au cours desquelles un seul bloc de données est chiffré ou conformément à ce qui est précisé pour des algorithmes dérivés, dont l’encapsulation de clé (voir la section 9). Il ne devrait pas être utilisé pour le chiffrement de donnée en masse;
• mode de chiffrement à rétroaction (CFB pour Cipher Feedback);
• mode de chiffrement à rétroaction de sortie (OFB pour Output Feedback);
• mode de chiffrement basé sur un compteur (CTR pour Counter);
• mode de chiffrement par chaînage de blocs (CBC pour Cipher Block Chaining) – lors de l’utilisation du mode CBC avec une entrée de texte clair d’une longueur de bits supérieure ou égale à la taille du bloc, une méthode de remplissage doit être utilisée tel qu’il est décrit dans l’annexe A du document SP800-38A. Les protocoles précisent habituellement les méthodes particulières de remplissage pouvant être utilisées. Si aucune méthode de remplissage n’est précisée, nous recommandons les méthodes suivantes tirées de l’addenda du document NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode (en anglais seulement) (National Institute of Standards and Technology, octobre 2010) : ^{Note de bas de page 9}
  • CBC-CS1;
  • CBC-CS2;
  • CBC-CS3.

Plusieurs exigences importantes sont tirées du document NIST SP 800 38A: Recommendation for Block Cipher Modes of Operation – Methods and Techniques (en anglais seulement) (National Institute of Standards and Technology, décembre 2001) : ^{Note de bas de page 8}

• Les modes CBC et CFB nécessitent des motifs d’initialisation (IV pour Initialization Vector) imprévisibles.
• Pour le mode OFB, l’IV doit être un nonce unique à chaque exécution de l’opération de chiffrement. Il n’a pas à être imprévisible.
• Le mode CTR exige un bloc compteur unique pour chacun des blocs de texte clair chiffré conformément à une clé donnée, et ce, pour tous les messages.

Pour assurer la protection des données sur des dispositifs de stockage, nous recommandons l’utilisation du mode XTS-AES, conformément au document NIST SP 800-38E: Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices (en anglais seulement) (National Institute of Standards and Technology, janvier 2010). ^{Footnote 10}.

3.2 Protection de la confidentialité et de l’authenticité de l’information

Nous recommandons les modes de fonctionnement suivants pour protéger la confidentialité et l’authenticité de l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B :

• mode de chiffrement basé sur un compteur avec code d’authentification de message avec chiffrement par chaînage de blocs (CCM pour Counter with Cipher Block Chaining Message Authentication Code), conformément au document NIST SP 800–38C: Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality (en anglais seulement) (National Institute of Standards and Technology, mai 2004); ^{Note de bas de page 11}
• mode Galois/compteur (GCM pour Galois/Counter Mode), conformément au document SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (en anglais seulement) (National Institute of Standards and Technology, novembre 2007). ^{Note de bas de page 12}

4 Schémas d’établissement de clés

La section suivante décrit les schémas d’établissement de clés que nous recommandons d’utiliser avec les algorithmes cryptographiques pour protéger l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B.

4.1 Rivest-Shamir-Adleman (RSA)

Nous recommandons les schémas de négociation et de transport de clés basés sur l’algorithme RSA, conformément au document NIST SP 800-56B Revision 2: Recommendation for Pair-Wise Key-Establishment Schemes Using Integer Factorization Cryptography (en anglais seulement) (National Institute of Standards and Technology, mars 2019) ^{Note de bas de page 13}avec une longueur de module RSA d’au moins 2048 bits.

La longueur du module RSA devrait être augmentée à au moins 3072 bits d’ici la fin de 2030.

4.2 Cryptographie à corps fini (FFC) de Diffie-Hellman (DH) et de Menezes-Qu-Vanstone (MQV)

Nous recommandons les schémas de négociation de clés basés sur la cryptographie à corps fini (FFC pour Finite Field Cryptography) de Diffie-Hellman (DH) et de Menezes-Qu-Vanstone (MQV), utilisés conjointement avec des paramètres de domaine valides pour les ensembles tailles-paramètres FB ou FC FFC, conformément au document NIST SP 800-56A Revision 3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography (en anglais seulement) (National Institute of Standards and Technology, avril 2018). La taille de corps (paramètre du module composé) devrait être d’au moins 2048 bits.^{Note de bas de page 14}

4.3 Cryptographie à courbe elliptique de Diffie-Hellman avec cofacteur (CCE CDH) et de Menezes-Qu-Vanstone (CCE MQV)

Nous recommandons les schémas de négociation de clés basés sur la cryptographie à courbe elliptique de Diffie-Hellman avec cofacteur (CCE CDH) et de Menezes-Qu-Vanstone (CCE MQV), conformément au document NIST SP 800-56A Revision 3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography (en anglais seulement) (National Institute of Standards and Technology, avril 2018) ^{Note de bas de page 14}avec une courbe elliptique tirée du tableau 24 et une taille de corps d’au moins 224 bits.

5 Schémas de signature numérique

La section suivante décrit les algorithmes que nous recommandons pour les applications de signature numérique offrant une intégrité des données et une authentification de l’origine des données pour l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B.

5.1 RSA

Nous recommandons le schéma de signature numérique RSA, conformément aux documents NIST FIPS 186-4: Digital Signature Standard (en anglais seulement) ^{Note de bas de page 15} (National Institute of Standards and Technology, juillet 2013) et RSA PKCS #1 v2.2: RSA Cryptography Standard ^{Note de bas de page 16} (RSA Laboratories, novembre 2016) avec une longueur de module RSA d’au moins 2048 bits.

5.2 Algorithme de signature numérique (DSA)

Nous recommandons l’utilisation de l’algorithme de signature numérique (DSA pour Digital Signature Algorithm), conformément au document NIST FIPS 186-4: Digital Signature Standard (en anglais seulement) (National Institute of Standards and Technology, juillet 2013) ^{Note de bas de page 15} avec des paramètres de domaine valides pour une taille de corps d’une longueur minimale de 2048 bits.

5.3 Algorithme de signature numérique à courbe elliptique (ECDSA)

Nous recommandons l’utilisation de l’algorithme de signature numérique à courbe elliptique (ECDSA pour Elliptic Curve Digital Signature Algorithm), conformément au document NIST FIPS 186-4: Digital Signature Standard ^{Note de bas de page 15} (National Institute of Standards and Technology, juillet 2013) avec une courbe elliptique tirée de l’annexe D du document NIST FIPS 186-4: Digital Signature Standard ^{Note de bas de page 1d} (National Institute of Standards and Technology, juillet 2013) et une taille de corps d’une longueur minimale de 224 bits.

5.4 Schémas de signature numérique à hachage dynamique

Nous recommandons d’utiliser les signatures numériques à hachage dynamique uniquement dans des situations où tous les éléments suivants s’appliquent :

1. lorsqu’un schéma de signature numérique à résistance quantique doit être mis en œuvre dans un avenir proche, avant que d’autres schémas de signature numérique à résistance quantique d’usage général soient normalisés (voir la section 12);
2. lorsque la mise en œuvre aura une longue durée de vie et qu’elle n’est pas pratique pour passer à un nouveau schéma de signature numérique une fois la mise en œuvre déployée;
3. lorsque la lente génération de clés et les calculs de signature sont acceptables sur le plan opérationnel;
4. lorsque la gestion des états peut être mise en œuvre.

Dans de telles situations, nous recommandons l’utilisation des schémas de signature numérique à hachage suivants, conformément au document NIST SP 800-208: Recommendation for Stateful Hash-based Signatures Scheme (en anglais seulement) ^{Note de bas de page 17}(National Institute of Standards and Technology, octobre 2020) :

• Leighton-Micali Signature (LMS);
• Hierarchical Signature System (HSS);
• eXtended Merkle Signature Scheme (XMSS);
• Multi-tree eXtended Merkle Signature Scheme (XMSSMT).

6 Algorithmes de hachage sécurisé (SHA)

La section suivante décrit les algorithmes de hachage sécurisé (SHA pour Secure Hash Algorithm) que nous recommandons d’utiliser avec les algorithmes cryptographiques précisés dans la présente publication pour protéger l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B.

6.1 SHA-1

Nous ne recommandons plus l’utilisation de l’algorithme SHA-1 conformément au document NIST FIPS 180-4: Secure Hash Standard (en anglais seulement) (National Institute of Standards and Technology, août 2015). ^{Note de bas de page 18}Son utilisation était auparavant approuvée avec les codes d’authentification de message avec hachage de clé, les fonctions de dérivation de clés et les générateurs de bits aléatoires.

6.2 SHA-2

Nous recommandons l’utilisation des algorithmes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 et SHA-512/256, conformément au document NIST FIPS 180-4: Secure Hash Standard (en anglais seulement) (National Institute of Standards and Technology, août 2015) ^{Note de bas de page 18}pour les schémas de signature numérique, les codes d’authentification de message avec hachage de clé, les fonctions de dérivation de clés et les générateurs de bits aléatoires.

6.3 SHA-3

Nous recommandons l’utilisation des algorithmes SHA3-224, SHA3-256, SHA3-384 et SHA3-512, conformément au document NIST FIPS 202: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions (en anglais seulement) (National Institute of Standards and Technology, août 2015) ^{Note de bas de page 19}pour les schémas de signature numérique, les codes d’authentification de message avec hachage de clé, les fonctions de dérivation de clés et les générateurs de bits aléatoires.

7 Codes d’authentification de message (MAC)

Les sections suivantes décrivent les algorithmes MAC (Message Authentication Code) que nous recommandons pour l’intégrité des données et l’authentification de l’origine des données pour l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B.

7.1 Code d’authentification de message avec hachage de clé (HMAC)

Nous recommandons l’utilisation du code d’authentification de message avec hachage de clé (HMAC pour Keyed-Hash Message Authentification Code), conformément au document NIST FIPS 198-1: The Keyed-Hash Message Authentication Code (en anglais seulement) (National Institute of Standards and Technology, juillet 2008) ^{Note de bas de page 20} avec une clé d’au moins 112 bits de longueur.

7.2 Code d’authentification de message basé sur le chiffrement (CMAC)

Nous recommandons l’utilisation du code d’authentification de message basé sur le chiffrement (CMAC pour Cipher-based Message Authentication Code), conformément au document NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication (en anglais seulement) (National Institute of Standards and Technology, mai 2005, avec mises à jour depuis le 10-06-2016) avec une clé d’au moins 112 bits de longueur. ^{Footnote 21} with a key length of at least 112 bits.

7.3 Code d’authentification de message avec mode Galois/compteur (GMAC)

Nous recommandons l’utilisation du code d’authentification de message avec le mode Galois/compteur (GMAC pour Galois/Counter Mode Message Authentication Code), conformément au document NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (en anglais seulement) (National Institute of Standards and Technology, novembre 2007). ^{Note de bas de page 12} L’utilisation du code GMAC n’est recommandée qu’avec l’algorithme AES, conformément à la section 2.1.

8 Fonctions de dérivation de clés (KDF)

Les sections suivantes décrivent les fonctions de dérivation de clés (KDF pour Key Derivation Function) que nous recommandons pour la dérivation des clés cryptographiques à partir de secrets prépartagés ou d’établissement de clés. Ces fonctions sont utilisées pour la protection d’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B.

8.1 KDF à une étape

Nous recommandons l’utilisation de la fonction de dérivation de clés (KDF) à une étape, conformément au document NIST SP 800-56C Revision 2: Recommendation for Key Derivation Methods in Key-Establishment Schemes (National Institute of Standards and Technology, août 2020). ^{Footnote 22}.

8.2 KDF à deux étapes

Nous recommandons l’utilisation de la procédure de dérivation de clés par extraction puis expansion à deux étapes, conformément au document NIST SP 800-56C Revision 2: Recommendation for Key Derivation Methods in Key-Establishment Schemes (National Institute of Standards and Technology, août 2020). ^{Note de bas de page 22} Il est à noter que la version 1.3 du protocole de sécurité de la couche de transport (Transport Layer Security) (TLS 1.3) utilise cette KDF.

8.3 Dérivation de clés au moyen de fonctions pseudo-aléatoires

Nous recommandons l’utilisation des KDF se servant de fonctions pseudo-aléatoires (PRF pour Pseudorandom Function), conformément au document NIST SP 800-108: Recommendation for Key Derivation Using Pseudorandom Functions (en anglais seulement) (National Institute of Standards and Technology, octobre 2009). ^{Note de bas de page 23}

8.4 KDF avec la version 2 du protocole d’échange de clés Internet (IKEv2)

Lorsqu’elle est utilisée dans le contexte de la version 2 du protocole d’échange de clés Internet (IKEv2 pour Internet Key Exchange version 2), nous recommandons le recours à la KDF IKEv2, conformément au document NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions (en anglais seulement) (National Institute of Standards and Technology, décembre 2011) ^{Note de bas de page 24}.

8.5 KDF avec la version 1.2 du protocole de sécurité de la couche transport (TLS 1.2)

Lorsqu’elle est utilisée dans le contexte de la version 1.2 du protocole de sécurité de la couche de transport (TLS 1.2), nous recommandons le recours à la KDF TLS 1.2, conformément au document NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions (en anglais seulement) (National Institute of Standards and Technology, décembre 2011)^{Note de bas de page 24}.

8.6 KDF avec protocole Secure Shell (SSH)

Lorsqu’elle est utilisée dans le contexte du protocole SSH, nous recommandons le recours à la KDF SSH, conformément au document NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions (en anglais seulement) (National Institute of Standards and Technology, décembre 2011) ^{Note de bas de page 24}.

8.7 KDF avec protocole de transport en temps réel sécurisé (SRTP)

Lorsqu’elle est utilisée dans le contexte du protocole de transport en temps réel sécurisé (SRTP pour Secure Real-time Transport Protocol), nous recommandons le recours à la KDF SRTP, conformément au document NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions (en anglais seulement) (National Institute of Standards and Technology, décembre 2011).

8.8 KDF avec module de plateforme fiable (TPM)

Lorsqu’elle est utilisée dans le contexte d’une session de module de plateforme fiable (TPM pour Trusted Platform Module), nous recommandons le recours à la KDF TPM, conformément au document NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions (en anglais seulement) (National Institute of Standards and Technology, décembre 2011) ^{Note de bas de page 24}.

8.9 Fonction de dérivation de clés basée sur des mots de passe (PBKDF)

Nous recommandons l’utilisation de la fonction de dérivation de clés basée sur des mots de passe (PBKDF pour Password-Based Key Derivation Function) conformément au document NIST SP 800-132: Recommendation for Password Based Key Derivation: Part 1: Storage Applications (en anglais seulement) (National Institute of Standards and Technology, décembre 2010) pour la protection des données sur des dispositifs de stockage ^{Note de bas de page 25}.

9 Modes de fonctionnement des enveloppements de clé

Les sections suivantes décrivent les modes de fonctionnement des enveloppements de clé que nous recommandons pour protéger la confidentialité et l’intégrité des clés cryptographiques servant à la protection d’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B.

9.1 Enveloppement de clé AES (KW)

Nous recommandons l’utilisation du mode d’enveloppement de clé (KW) avec norme de chiffrement avancé (AES), conformément au document NIST SP 800-38F: Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping (en anglais seulement) (National Institute of Standards and Technology, décembre 2012) ^{Note de bas de page 26}.

9.2 Enveloppement de clé AES avec remplissage (KWP)

Lorsque l’entrée n’est pas un multiple de 64 bits, nous recommandons l’utilisation du mode d’enveloppement de clé AES avec remplissage (KWP pour Key Wrap with Padding), conformément au document NIST SP 800-38F: Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping (en anglais seulement) (National Institute of Standards and Technology, décembre 2012) ^{Note de bas de page 26}.

9.3 Enveloppement de clé avec chiffrement de données triple (TKW)

Nous ne recommandons plus l’utilisation du mode d’enveloppement de clé avec chiffrement de données triple (TKW pour Triple Data Encryption Algorithm Key Wrap), conformément au document NIST SP 800-38F: Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping (en anglais seulement) (National Institute of Standards and Technology, décembre 2012). Ce mode était auparavant approuvé avec une clé d’une longueur de 168 bits ^{Note de bas de page 26}.

10 Générateurs de bits aléatoires déterministes (DRBG)

Nous recommandons l’utilisation des générateurs de bits aléatoires déterministes (DRBG pour Deterministic Random Bit Generator) suivants, conformément au document NIST SP 800-90A Revision 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators (en anglais seulement) (National Institute of Standards and Technology, juin 2015) ^{Note de bas de page 27} pour produire des bits aléatoires aux fins d’applications cryptographiques, en vue de protéger l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B :

• Hash_DRBG;
• HMAC_DRBG;
• CTR_DRBG.

11 Programmes d’assurance des technologies commerciales

Outre l’utilisation recommandée dans ce document des algorithmes cryptographiques, des paramètres et des longueurs de clé pour assurer un niveau adéquat de sécurité cryptographique, nous recommandons également ce qui suit en ce qui concerne la mise en œuvre de programmes d’assurance :

1. les mises en œuvre d’algorithmes cryptographiques devraient être testées et validées en vertu du Programme de validation des algorithmes cryptographiques (CAVP pour Cryptographic Algorithm Validation Program) (National Institute of Standards and Technology, 2016); ^{Note de bas de page 28}
2. les essais et la validation des modules cryptographiques devraient être réalisés en vertu du Programme de validation des modules cryptographiques (PVMC) pour évaluer la conformité à la norme FIPS 140-3: Security Requirements for Cryptographic Modules (en anglais seulement) ^{Note de bas de page 29};
3. 3. les produits de sécurité des technologies de l’information devraient être évalués et certifiés comme étant conformes aux Critères communs ^{Note de bas de page 30} par un Schéma d’autorisation de certification qui est membre de l’Arrangement relatif à la reconnaissance des certificats liés aux Critères communs (ARCC).

Les produits comportant des modules cryptographiques validés en vertu du PVMC sont mentionnés dans les listes de validation des modules du PVMC (en anglais seulement) et sont accompagnés d’un document de politique de sécurité non exclusif provenant du fournisseur (voir Sélection d’un produit validé en vertu du PVMC (en anglais seulement)). Ce document précise la sécurité cryptographique fournie par un module et décrit ses capacités, sa protection et ses contrôles d’accès. Nous recommandons l’utilisation du document de politique de sécurité pour sélectionner des produits de sécurité cryptographique adéquats et pour configurer les produits dans les modes de fonctionnement approuvés par les FIPS, conformément au document Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program (en anglais seulement) ^{Note de bas de page 31} pour s’assurer que seuls des algorithmes approuvés par le Centre pour la cybersécurité sont utilisés.

12 Préparation à la cryptographie à résistance quantique

Les ordinateurs quantiques menacent de percer les cryptosystèmes à clé publique et d’affaiblir les cryptosystèmes symétriques que nous utilisons actuellement. Bien que les technologies quantiques ne soient pas encore suffisamment puissantes pour percer la cryptographie recommandée dans cette publication, d’importants travaux de recherche sont réalisés dans ce domaine. En 2016, le NIST a entamé un processus visant à solliciter, à évaluer et à normaliser des algorithmes cryptographiques à clé publique et à résistance quantique. Le processus est toujours en cours, mais tous les algorithmes projetés diffèrent sensiblement des cryptosystèmes actuels à clé publique, et la transition nécessitera d’apporter d’importants changements logiciels et matériels aux systèmes de TI actuels.

Le NIST prévoit compléter les normes d’ici 2024. Nous mettrons à jour les directives contenues dans le présent document pour aborder la question de la menace quantique dès que les normes seront disponibles. D’ici là, nous recommandons les étapes de haut niveau suivantes :

• évaluer la sensibilité des renseignements de l’organisation et en déterminer la longévité afin d’identifier les renseignements pouvant être à risque (p. ex. dans le cadre de processus continus d’évaluation des risques);
• passer en revue le budget et le plan de gestion du cycle de vie des TI de l’organisation pour déterminer les mises à jour logicielles et matérielles pouvant s’avérer importantes;
• sensibiliser le personnel à la menace quantique;
• envisager l’utilisation de schémas de signature numérique à hachage dynamique si l’organisation remplit les conditions énumérées à la section 5.4.

Pour obtenir de plus amples renseignements sur la préparation à cet égard, consultez le document Préparez votre organisation à la menace que pose l’informatique quantique pour la cryptographie (ITSAP.00.017) ^{Note de bas de page 32} (Centre canadien pour la cybersécurité, février 2021).

Les organisations devraient attendre que les normes relatives aux schémas de signature numérique et au chiffrement à clé publique et à résistance quantique soient diffusées avant d’utiliser un algorithme projeté pour protéger les renseignements ou les systèmes.

13 Sommaire

La cryptographie fournit des mécanismes de sécurité servant à protéger l’authenticité, la confidentialité et l’intégrité de l’information sensible. Plusieurs algorithmes peuvent s’avérer nécessaires pour satisfaire aux exigences de sécurité, et le respect de toutes ces exigences exige parfois la mise en œuvre de chacun de ces algorithmes. La présente publication offre des directives sur l’utilisation des algorithmes cryptographiques recommandés par le Centre pour la cybersécurité pour protéger l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B.

13.1 Aide et renseignements

Pour obtenir de plus amples renseignements sur les algorithmes cryptographiques pour l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B, prière de communiquer avec le :

Centre canadien pour la cybersécurité
Téléphone : 613-949-7048 or 1‑833‑CYBER‑88
Courriel : contact@cyber.gc.ca |

14 Contenu complémentaire

14.3 Références