807-Criptologia de Empleo ENS

Machine Translated by Google
Guide de sécurité des TIC
CCNSTIC 807
La cryptologie de l'emploi dans le
Régime de sécurité nationale
Mai 2022
CCNSTIC807 Cryptologie de l'emploi dans le régime de sécurité nationale
se.bog.rpm.egapc
Catalogue des publications de l'administration générale de l'État
https://cpage.mpr.gob.es
Éditeur:
P.º de la Castellana 109, 28046 Madrid
© Centre national de cryptologie, 2022
ET : 08322225X
Date d'édition : Mai 2022
L'ISDEFE a participé à la préparation et à la modification de ce document et de ses annexes.
LIMITATION DE RESPONSABILITÉ
Ce document est fourni conformément aux termes qui y sont contenus, rejetant expressément tout type de garantie implicite
qui pourrait s'y rapporter. En aucun cas, le Centre national de cryptologie ne peut être tenu responsable des dommages
directs, indirects, accessoires ou extraordinaires découlant de l'utilisation des informations et logiciels indiqués, même
lorsqu'une telle possibilité est signalée.
AVIS JURIDIQUE
La reproduction partielle ou totale de ce document par quelque procédé ou procédé que ce soit, y compris la reprographie et
le traitement informatique, ainsi que la diffusion de copies de celuici sont strictement interdites sans l'autorisation écrite du
Centre National de Cryptologie, sous peine des sanctions prévues par la loi sur la location ou la publicité. prêt.
Centre national de cryptologie 2
AVANTPROPOS
Dans un monde de plus en plus complexe et globalisé, dans lequel les technologies de l'information et de la
communication (TIC) jouent un rôle très important, nous devons être conscients que la bonne gestion de la
cybersécurité est un défi collectif qui nous oblige nécessairement à faire face Il est nécessaire de garantir la protection
de la capacité économique, technologique et politique de notre pays, d'autant plus que la prolifération des attaques
ciblées et le vol d'informations sensibles représentent une réalité incontestable.
Par conséquent, il est essentiel d'être à jour avec les menaces et les vulnérabilités associées à l'utilisation des
nouvelles technologies. La connaissance des risques qui pèsent sur le cyberespace doit être utilisée pour mettre en
œuvre avec des garanties les mesures, tant procédurales que techniques et organisationnelles, qui permettent un
environnement sûr et fiable.
La loi 11/2002, du 6 mai, réglementant le Centre national de renseignement (CNI), confie au Centre national de
renseignement l'exercice de fonctions liées à la sécurité des technologies de l'information et à la protection des
informations classifiées, En même temps, elle confère à son Secrétaire d'Etat Directeur la charge de diriger le Centre
National de Cryptologie (CCN).
Sur la base des connaissances et de l'expérience du CNI sur les menaces et les vulnérabilités en termes de risques
émergents, le Centre exerce, par l'intermédiaire du Centre national de cryptologie, réglementé par le décret royal
421/2004 du 12 mars, diverses activités directement liées à la sécurité TIC, visant la formation de personnel expert,
l'utilisation de technologies de sécurité appropriées et l'application de politiques et de procédures de sécurité.
Précisément, cette série de documents CCNSTIC est un reflet clair du travail que cet organisme effectue en termes
de mise en œuvre de la sécurité, permettant l'application de politiques et de procédures, puisque les guides ont été
préparés avec un objectif clair : améliorer le degré de la cybersécurité des organisations, conscients de l'importance
d'établir un cadre de référence en la matière qui serve de support au personnel de l'Administration pour mener à bien
la difficile tâche d'assurer la sécurité des systèmes TIC sous votre responsabilité.
Avec cette série de documents, le Centre national de cryptologie, conformément à ses tâches et à ce qui est reflété
dans le décret royal 3/2010, qui réglemente le régime de sécurité nationale dans le domaine de l'administration
électronique, contribue à améliorer la cybersécurité espagnole et à maintenir les infrastructures et systèmes
d'information de toutes les administrations publiques avec des niveaux de sécurité optimaux. Tout cela, afin de
générer de la confiance et des garanties dans l'utilisation de ces technologies, en protégeant la confidentialité des
données et en garantissant leur authenticité, leur intégrité et leur disponibilité.
Mai 2022
Paix Stephen Lopez
secrétaire d'État
Directeur du Centre National de Cryptologie
INDICE
INTRODUCTION................................................. .................................................. 6 1.
1.1 ORGANISMES DE NORMALISATION ....................................................... ....................................7
2. OBJECTIF ..................................................................... .................................................. .... .....8
3. MÉCANISMES CRYPTOGRAPHIQUES AUTORISÉS .................................................. ....... 9 3.1
CHIFFREMENT SYMÉTRIQUE ......................................... ........... ....................................... ...........9 3.2
PRIMITIVES ASYMETRIQUES........................................ ............................................................... ....10 3.2.1.
PROBLÈME DE FACTORISATION DES NOMBRES ENTIERS (RSA)............................11 3.2.2. PROBLÈME
DE LOGARITHME MULTIPLICATIF DISCRET (FFDLOG) ......11 3.2.3. PROBLÈME DE LOGARITHME
DISCRET ADDITIF (ECDLOG)...................................11 3.3 FONCTIONS
RÉSUMÉ.. ....... ................................................ ..................................................................... .....12 3.4
CHIFFREMENT DE LA CLE PUBLIQUE................. ...................... .......................................... ........ ............13
3.5 ACCORD CLÉ ................................................................. ..................................................14 3.6
ÉLECTRONIQUE DE SIGNATURE......................................................... .. ................................................ ...15
3.7 CODE D'AUTHENTIFICATION DES MESSAGES (MAC) ...................................... .......... .16 3.8 CRYPTAGE
AVEC AUTHENTIFICATION (AE / AEAD) .................................. ...... ..................17 3.9 FONCTIONS DE
DERIVATION DE CLE (KDF).................... ........... ................................18 3.10 PROTECTION DE LA CLE
(ENVELOPPEMENT ).............................................................. .................................... .19 4. PROTOCOLES
CRYPTOGRAPHIQUES ....... ......................................... ......... ............. vingtetun
4.1 TLS .................................................. .................................................. ..................................21 4.2
SSH.............................. .................................................. ..................................................23
4.2.1. ÉCHANGE DE CLÉ .................................................. .... .....24
4.2.2. CHIFFREMENT – ALGORITHME DE CHIFFREMENT .................................................. .......................25
4.2.3. AUTENTICACIÓN – AUTHENTIFICATION PAR CLÉ PUBLIQUE.................................................. .. 26
4.2.4. INTÉGRITÉ ET AUTHENTICITÉ DE L'ORIGINE – ALGORITHME MAC .......................26
4.3 IPSEC......................................................... .................................................. .......................................27 4.3.1.
ACCORD CLÉ (LE GROUPE DIFFIEHELLMAN SE TRANSFORME) .................29 4.3.2. CHIFFREMENT
(TRANSFORMATION DES ALGORITHMES DE CHIFFREMENT) .................30 4.3.3. INTÉGRITÉ ET
AUTHENTIFICATION DE L'ORIGINE (TRANSFORMATIONS D'ALGORITHMES
D'INTÉGRITÉ) .................................. .. ................................................ ..................................31 4.3.4.
FONCTIONS PRF (TRANSFORMATIONS DE FONCTIONS PSEUDORANDOM)...............32 4.3.5.
MÉCANISME D'AUTHENTIFICATION ....................................................... .. ......................33
5. MESURES DE SÉCURITÉ .................................................. .. .................................. 35
5.1 DIMENSIONS DE SÉCURITÉ CONSIDÉRÉES ................................................ .. .......35
5.2 NIVEAUX DE MENACE ....................................................... .................................................. ..35
5.3 IDENTIFICATION. [OP.ACC.1] .................................. ......... .............................36 5.4 MÉCANISMES
D'AUTHENTIFICATION (UTILISATEURS EXTERNES) [OP.ACC.5]...... .......37 5.4.1. EXIGENCES GÉNÉRALES
POUR L'ÉTABLISSEMENT DE MOTS DE PASSE (CONCERTÉS OU
ALÉATOIRES)............................................ .................................................................... ....................40 5.4.2.
PROTOCOLES D'AUTHENTIFICATION ....................................................... ..... .....................42 5.5
MÉCANISMES D'AUTHENTIFICATION (UTILISATEURS INTERNES) [OP.ACC.6]......... ...... .42 5.5.1.
PROTOCOLES D'AUTHENTIFICATION ....................................................... .....................................45 5.6
PROTECTION DES CLÉS CRYPTOGRAPHIQUES [OP.EXP.10]............ ......................................46
5.7 PROTECTION DE LA CONFIDENTIALITÉ. [MP.COM.2].................................46
5.8 PROTECTION DE L'AUTHENTICITÉ ET DE L'INTÉGRITÉ [MP.COM.3]..........................48
5.9 CRYPTOGRAPHIE [MP.SI.2] ET PROTECTION DES EQUIPEMENTS PORTATIFS [MP.EQ.3]....49
5.10 SIGNATURE ÉLECTRONIQUE [MP.INFO.3].................................... .... .............................cinquante
5.11 Horodatages [MP.INFO.4]................................... ..... .......................................52
5.12EXEMPLE D'APPLICATION : TLS …………………………………………………………. ......................... ..........5
6. LES RÉFÉRENCES................................................. ....................................... 55
1. INTRODUCTION
1. Le Schéma National de Sécurité (ciaprès, ENS) a pour objet de déterminer la politique de
sécurité dans l'utilisation des moyens électroniques des entités relevant de son champ
d'application. Il détermine les principes de base et les exigences minimales requises pour
garantir de manière adéquate la sécurité des informations traitées et des services fournis par
lesdites entités.
2. L'annexe II dudit texte détaille les mesures de sécurité, structurées en trois groupes : le cadre
organisationnel [org], composé de l'ensemble des mesures liées à l'organisation globale de
la sécurité ; le cadre opérationnel [op], formé par les mesures à prendre pour protéger le
fonctionnement du système en tant qu'ensemble intégral de composants pour un objectif ; et
les mesures de protection [mp], qui se concentrent sur la protection d'actifs spécifiques, en
fonction de leur nature et de la qualité requise par le niveau de sécurité des dimensions
concernées.
3. Parmi ces mesures, certaines reposent sur l'utilisation d'algorithmes et de mécanismes
cryptographiques pour offrir le niveau de sécurité requis. Cependant, la simple utilisation de
la cryptographie ne suffit pas si (1) les algorithmes ou mécanismes cryptographiques ne sont
pas suffisamment robustes ou (2) la mise en œuvre concrète dudit algorithme/mécanisme
n'est pas correcte.
4. Concernant ce deuxième point, l'évaluation et la certification d'un produit ou service de
sécurité TIC est le seul moyen objectif permettant d'évaluer et d'accréditer sa capacité à
traiter l'information en toute sécurité. En Espagne, cette responsabilité est attribuée au Centre
national de cryptologie (CCN) par le biais du RD 421/2004 du 12 mars à l'article 1 et à l'article
2.1, qui établit que le secrétaire d'État directeur du Centre national de renseignement, en tant
que directeur du Centre national de cryptologie Centre (CCN, ciaprès) est l'autorité de
certification de la sécurité des technologies de l'information et de la communication et l'autorité
de certification cryptologique.
5. De même, l'arrêté royal qui réglemente l'ENS, indique que l'organisme de certification du
schéma national d'évaluation et de certification de la sécurité des technologies de l'information
du CCN, en tenant compte des critères et méthodologies d'évaluation nationaux et
internationaux reconnus,
Il déterminera les exigences de certification requises, ainsi que les critères à suivre dans les
cas où il n'y a pas de produits ou de services certifiés.
6. Sur la base de ces compétences, le CCN publie le guide CCNSTIC 105 Catalogue des
produits et services de sécurité des technologies de l'information et de la communication
(CPSTIC). Ce catalogue a pour objet de proposer aux administrations un ensemble de
produits ou services STIC de référence dont les fonctionnalités de sécurité liées à l'objet de
leur acquisition ont été certifiées et respectent les exigences minimales de sécurité établies
par le CCN.
1.1 ORGANISMES DE NORMALISATION
7. Il existe différentes organisations internationales chargées d'établir certains systèmes,
produits et équipements en tant que "normes" , parmi lesquels figurent également des
algorithmes et des protocoles cryptographiques. Ces organismes sont ceux qui déterminent
la qualité et la fiabilité des différents systèmes et produits à usage commercial. La plupart des
agences sont des entités indépendantes (bien que d'autres appartiennent à des agences
gouvernementales).
8. Les organisations internationales de normalisation les plus importantes sont les suivantes :
a) ANSI (American National Standards Institute) : L'American National Standards Institute
(http://www.ansi.org/) est une organisation nordaméricaine qui supervise l'élaboration
de normes pour les produits, les services, les processus et les systèmes. Il est
membre de l'ISO et de la CEI. Il est en charge de la coordination entre les normes
nordaméricaines et internationales.
b) CEI (Commission électrotechnique internationale) : la Commission électrotechnique
internationale (http://www.iec.ch/) est un organisme de normalisation dans les
domaines de l'électricité, de l'électronique et des autres technologies qui leur sont
liées. De nombreuses normes sont élaborées conjointement avec l'ISO, c'est pourquoi
nombre d'entre elles sont connues sous le nom de normes ISO/CEI.
c) IEEE (Institute of Electrical and Electronics Engineers) : l'Institute of Electrical and
Electronic Engineers (http://www.ieee.org/index.html) est une association mondiale à
caractère technicoprofessionnel dédiée à la normalisation des technologies dérivées
de l'électricité : génie informatique, technologie biomédicale et aérospatiale, énergie
électrique, télécommunications, etc.
d) ISO (Organisation internationale de normalisation) : l'Organisation internationale de
normalisation (http://www.iso.org/iso/home.html) est l'organisme chargé d'élaborer
des normes internationales pour la fabrication, le commerce et la communication dans
toutes les branches de l'industrie (à l'exception de celles relatives à l'industrie
électrique et électronique), en particulier dans les domaines liés aux normes et à la
sécurité des produits.
e) NIST (National Institute of Standards and Technology) : est une agence du United
Département de States Trade de Les
(http://www.nist.gov/index.html). Il promeut l'innovation et la concurrence industrielle
aux ÉtatsUnis grâce aux progrès des normes appliquées et de la technologie elle
même. Ses principaux domaines d'activité sont les biotechnologies, les
nanotechnologies et les technologies de l'information.
f) SECG (Standards for Efficient Cryptography Group) : le Groupe de normalisation pour
une cryptographie efficace (http://www.secg.org/) est un consortium international dont
l'objectif principal est de promouvoir l'utilisation de la cryptographie basée sur les
courbes elliptiques. Ses membres comprennent Certicom, Entrust, Fujitsu et Visa.
2. OBJECTIF
9. Ce guide a pour objet la présentation des mécanismes cryptographiques dont
l'utilisation a été autorisée dans l'ENS, ainsi que la robustesse requise et les garanties
d'évaluation et de certification qui doivent être présentées, selon le niveau de sécurité
requis, pour chacun d'entre eux. . des mesures qui l'exigent.
10. A cet effet, les sections 3 et 4 du présent document contiennent une liste des
mécanismes cryptographiques autorisés et leurs normes correspondantes.
ainsi que certains protocoles couramment utilisés, tandis que dans la section
5 présente une liste des mécanismes qui doivent être utilisés pour chacune des
mesures incluses dans l'annexe II de l'ENS ainsi que la résistance requise, selon le
niveau de sécurité requis pour chacune des dimensions considérées ou la catégorie
du système.
3. MÉCANISMES CRYPTOGRAPHIQUES AUTORISÉS
11. Cette section liste les mécanismes cryptographiques considérés comme autorisés
par le CCN pour une utilisation au sein de l'ENS, à condition qu'ils soient
correctement mis en œuvre, en suivant les indications précisées pour chaque cas.
12. Les mécanismes cryptographiques autorisés indiqués dans les sections suivantes
ont été classés en deux (2) catégories (CAT) selon leur puissance estimée à court
et à long terme :
a) Recommandé (R) : mécanismes offrant un niveau de sécurité adéquat sur le
long terme. Ils sont considérés comme représentant l'état actuel de l'art en
matière de sécurité cryptographique et, à ce jour, ne présentent aucun risque
de sécurité significatif. Ils peuvent être utilisés en toute sécurité à long terme,
même en tenant compte de l'augmentation de la puissance de calcul attendue
dans un avenir proche. Tout risque résiduel ne peut provenir que du
développement d'attaques très innovantes.
b) Inherited or Legacy (L) : mécanismes dont l'implémentation est aujourd'hui
largement répandue, mais qui n'offrent un niveau de sécurité acceptable qu'à
court terme. Ils ne doivent être utilisés que dans des scénarios où la menace
est faible/moyenne et le niveau de sécurité requis par le système est faible/
moyen (comme nous le verrons dans la section 5) et ils doivent être remplacés
dès que possible, car ils sont considérés comme obsolètes. par rapport à
l'état actuel de l'art en matière de sécurité cryptographique, et sa garantie de
sécurité est limitée par rapport à celle offerte par les mécanismes préconisés.
En conséquence, pour ces mécanismes, la période de validité est définie
jusqu'en 2025 (31 décembre), sauf indication expresse contraire.
3.1 CHIFFREMENT SYMÉTRIQUE
13. Cette section comprend les schémas de chiffrement symétriques, qui permettent
d'assurer la confidentialité du message et des données. Pour ce faire, la procédure
de chiffrement transforme un texte en clair en un texte chiffré à l'aide d'une clé
secrète, tandis que la procédure de déchiffrement permet d'obtenir le texte en clair
à partir du texte chiffré et de la clé.
14. Les schémas de chiffrement symétrique autorisés inclus dans cette section sont
constitués d'un chiffrement par bloc, également appelé primitive, qui agit selon un
mode de fonctionnement. Presque tous sont basés sur le chiffreur AES
(Standard d'encryptage avancé).
15. Le tableau 31 répertorie les schémas de chiffrement symétrique autorisés. Comme
on peut le voir, tous sont des mécanismes recommandés mais ils doivent
nécessairement être utilisés avec l'un des mécanismes d'authentification qui sont
inclus dans la section 3.7. Exceptionnellement dans le chiffrement de disque dur,
l'utilisation d'AESXTS est acceptée.
Chiffrer / Longueur
Mode de fonctionnement Force
Caractéristiques de clé CHAT
/ Caractéristiques (morceaux)
(morceaux)
NIST SP800
ISO/CEI 128 128
38A
AES 180333 RadioCanada 192 192 R1
ISO/CEI
FIPS 197 256 256
10116
NIST SP800
ISO/CEI 128 128
38A
AES 180333 CTR 192 192 R1
ISO/CEI
FIPS 197 256 256
10116
NIST SP800
ISO/CEI 128 128
38A
AES 180333 BFC 192 192 R1
ISO/CEI
FIPS 197 256 256
10116
NIST SP800
ISO/CEI 128 128
38A
AES 180333 OFB 192 192 R1
ISO/CEI
FIPS 197 256 256
10116
ISO/CEI NIST SP800 128 128

AES 180333 XTS 38E 192 192 R2
FIPS 197 IEEE 1619 256 256
Tableau 31. Schémas de chiffrement symétrique autorisés
3.2 PRIMITIVES ASYMETRIQUES
16. La cryptographie asymétrique (parfois aussi appelée clé publique) a la propriété
distinctive que chaque utilisateur utilise deux clés, une pour le processus de cryptage
et une différente pour le processus de décryptage. La première des clés est la clé
publique que chaque utilisateur divulgue afin qu'elle puisse être utilisée comme clé
pour chiffrer les messages qui lui sont envoyés ; tandis que l'autre est la clé privée
(ou secrète), que seul ledit utilisateur connaît et lui permet de déchiffrer les messages
chiffrés qu'il reçoit. Les deux clés sont liées au moyen d'un problème mathématique
puisqu'elles effectuent des processus inverses (l'un chiffre et l'autre décrypte).
17. Les primitives asymétriques acceptées et les problèmes mathématiques
les correspondants sont présentés cidessous.
1
Toujours avec un mécanisme d'authentification de la section 3.7
2
Accepté sans mécanisme d'authentification pour le chiffrement de disque
Centre national de cryptologie dix
3.2.1. PROBLÈME DE FACTORISATION EN ENTIER (RSA)
18. Le tableau suivant montre les tailles de clé convenues pour la primitive sur la base du problème de
factorisation d'entiers (RSA) et d'autres caractéristiques.
primitif Taille du paramètre (bits) CHAT
n ≥ 3000, log2(e) > 16 n R
RSA
≥ 2048, log2(e) > 16 L
Tableau 32. Taille des primitives RSA convenues
3.2.2. PROBLÈME DE JOURNAL DE MULTIPLICATION DISCRET (FFDLOG)
19. Le tableau suivant montre les tailles de clé convenues pour la primitive sur la base du problème de
logarithme discret multiplicatif sur un corps fini.
primitif Groupe CHAT
3072 bits R
4096 bits R
MODP [RFC 3526] 6144 bits R
8192 bits R
2048 bits L
Tableau 33. Taille des primitives convenues du logarithme discret multiplicatif sur un corps fini
3.2.3. PROBLÈME DE JOURNAL DISCRET ADDITIF (ECDLOG)
20. Le tableau suivant montre les familles de courbes elliptiques convenues.
Famille Courbe CHAT
BrainpoolP256r1 R
Brainpool [RFC5639] BrainpoolP384r1 R
BrainpoolP5121r1 R
NIST P256 ou secp256r11 R
NIST [FIPS1864, 1
NIST P384 ou secp384r1 R
Annexe D.1.2]
1 R
NIST P521 ou secp521r1
Courbe25519 R
Bernstein
Courbe448 R
1
En TLS (RFC 4492) ou IPsec avec IKE v2 (RFC 5903)
Tableau 34. courbes elliptiques convenues
21. Il faut vérifier que les points considérés sont sur la courbe, c'estàdire qu'ils vérifient leur
équation.
22. Il est également nécessaire de vérifier que les points considérés sont dans le sousgroupe
considéré de la courbe. Notez que l'utilisation de sousgroupes de la courbe se produit
lorsque l'ordre de la courbe n'est pas un nombre premier. Cependant, si l'ordre du sous
groupe est un nombre premier, c'estàdire q = r, et qu'il est tel que r2 ne divise pas le
cardinal de la courbe, les vérifications se réduisent à vérifier que les points considérés ont
précisément l'ordre r.
3.3 FONCTIONS SOMMAIRES
23. Cette section comprend les fonctions de résumé ou fonctions de hachage, qui sont des
fonctions qui, sans utiliser de clé cryptographique, traitent une entrée consistant en un
message de longueur arbitraire et produisent une sortie de longueur prédéterminée (selon
la fonction). Cette sortie est appelée valeur de hachage. Les fonctions de résumé sont
utilisées dans de nombreux services, tels que la génération et la vérification de signature,
la dérivation de clé, la génération de valeur aléatoire ou le calcul de code MAC. Ils peuvent
également être utilisés seuls pour fournir des services d'intégrité des messages.
24. Les fonctions de résumé ou fonctions de hachage autorisées sont les fonctions SHA2 et
SHA3, l'utilisation recommandée étant celles qui fournissent une force de sécurité de 128
bits ou plus, et Legacy utilise celles qui fournissent une force entre 112 et 128 bits. Le
tableau 35 répertorie ces fonctions et leurs spécifications correspondantes.
25. L'utilisation de la fonction SHA1 n'est pas autorisée, sauf dans les constructions HMAC (voir
rubrique 3.7).
MBL HVL
Niveau de
Message Hacher
Spécifications récapitulatives des fonctions sécurité (bit) CHAT
Bloc Valeur
Longueur Longueur
ISO 101183
SHA2224 512 224 112 L
FIPS 1804
ISO 101183
SHA2512/224 1024 224 112 L
FIPS 1804
ISO 101183
SHA2256 512 256 128 R
FIPS 1804
ISO 101183
SHA2512/256 1024 256 128 R
FIPS 1804
ISO 101183
SHA2384 1024 384 192 R
FIPS 1804
MBL HVL
Niveau de
Message Hacher
Spécifications récapitulatives des fonctions sécurité (bit) CHAT
Bloc Valeur
Longueur Longueur
ISO 101183
SHA2512 1024 512 256 R
FIPS 1804
SHA3256 FIPS 202 1088 256 128 R
SHA3384 FIPS 202 832 384 192 R
SHA3512 FIPS 202 576 512 256 R
BLAKE2s/BLAKE2b RFC7693 512/1024 >=256 >128 R1
Tableau 35. Fonctions récapitulatives autorisées
3.4 CRYPTAGE À CLÉ PUBLIQUE
26. Cette section comprend les schémas de chiffrement à clé publique ou le chiffrement asymétrique.
Ces schémas ne sont pas recommandés pour le chiffrement de données en bloc, pour lequel
le chiffrement symétrique est plus efficace.
27. L'utilisation la plus répandue, et pour laquelle le chiffrement asymétrique est recommandé, est
de protéger l'envoi de clés symétriques, qui seront utilisées pour le chiffrement des données.
Cette utilisation est ce qui fait que les schémas de chiffrement asymétriques indiqués dans
cette section sont considérés dans de nombreuses normes comme des schémas de transport
de clés .
28. Les schémas de chiffrement asymétrique classiques utilisent des mécanismes de bourrage pour
augmenter la longueur du message à chiffrer (c'estàdire des clés symétriques, qui ont une
longueur limitée).
29. Dans les schémas de chiffrement asymétriques classiques, les deux (2) schémas autorisés sont
basés sur la primitive RSA et sont spécifiés dans la RFC 8017 (une réédition de la norme
RSA Laboratories PKCS #1) . Le schéma RSAESOAEP
est celui autorisé pour une utilisation recommandée, et le schéma RSAESPKCS1v1_5 est
autorisé pour une utilisation Legacy uniquement.
30. Le tableau 36 répertorie les schémas de chiffrement asymétrique autorisés et la longueur de clé
requise pour fournir un niveau de sécurité de 112 bits et 128 bits.
1
Son utilisation n'est autorisée que dans le cadre de certains protocoles modernes tels que
Wireguard ou bruit
Genre de Force Longueur de

Schéma de chiffrement / Spécifications CHAT
Cryptographie (morceaux) clé (bits)
PKCS#1v2.2 (RFC 8017), 112 2048 L

RSA RSAESOAEP
PKCS#1v2.1 (RFC 3447) ≥128 ≥3072 R
RSAES PKCS#1v2.2 (RFC 8017), 112 2048
RSA L
PKCS1v1_5 PKCS#1v2.1 (RFC 3447) ≥128 ≥3072
Tableau 36. Schémas de chiffrement à clé publique autorisés.
3.5 ACCORD CLÉ
31. Cette section contient les programmes d'accord clé ,
moyennant quoi le matériel de clé secrète devant être obtenu par les participants à
la communication est dérivé des informations fournies par chacun d'eux.
32. Les schémas d'accord de clé les plus répandus sont basés sur les primitives Diffie
Hellman (DH) , basées sur le problème du logarithme discret (DLOG). Le schéma
DH correspondant à la cryptographie à champ fini (FFC) et le schéma ECDH
correspondant à la cryptographie à courbe elliptique (ECC) sont considérés comme
autorisés pour une utilisation recommandée .
33. Un autre mécanisme remplissant la fonction d'un protocole d'échange de clé est
l'encapsulation de clé ou KEM (Key Encapsulation Mechanism).
34. Les mécanismes KEM autorisés pour une utilisation recommandée sont : DLIESKEM
(basé sur la cryptographie à champs finis, FFC) et ECIESKEM (basé sur la
cryptographie à courbes elliptiques, ECC).
35. Le tableau 37 répertorie les schémas d'accord de clé autorisés et la longueur de clé
requise pour fournir un niveau de sécurité de 112 bits et 128 bits.
Longueur
Genre de Schéma d'accord clé / Force
de clé CHAT
Cryptographie Caractéristiques (morceaux)
(morceaux)
NIST SP 80056A
ISO/CEI 117703 112 2048 L
DH
ANSI X9.42 ≥128 ≥3072 R
FFDLOG
IEEE 1363
DIES 112 2048 L
ISO/CEI 180332
CRÈME ≥128 ≥3072 R
NIST SP 80056A
ISO/CEI 117703
112 224 L
ECDLOG CEDH ANSI X9.63
≥128 ≥ 256 R
IEEE 1363
SEC1
longueur
Genre de Schéma d'accord clé / Force
de clé CHAT
Cryptographie Caractéristiques (morceaux)
(morceaux)
ECIES 112 224 L

ISO/CEI 180332
CRÈME ≥128 ≥ 256 R
Tableau 37. Schémas d'accords de clés autorisés
3.6 SIGNATURE ÉLECTRONIQUE
36. Cette section comprend les schémas de signature électronique utilisés pour fournir au message
des services d'intégrité, d'authentification de l'origine et de nonrépudiation. Pour ce faire, ils
fournissent une fonction de génération de signature et une fonction de vérification de
signature.
37. Les schémas de signature électronique autorisés pour une utilisation recommandée basée sur
la primitive RSA sont : RSAPSS (RFC3447 et ISO 97962)
38. En ce qui concerne les schémas de signature basés sur le logarithme discret (DLOG), DSA,
KCDSA et Schnorr sont acceptés pour une utilisation recommandée ainsi que leurs variantes
de courbe elliptique ECDSA, ECKCDSA et EC Schnorr avec ECGDSA défini dans l'ISO/CEI
148883.
39. De plus, le schéma de signature basé sur les fonctions de hachage est considéré comme
autorisé pour une utilisation recommandée : XMSS (eXtended Merkle Signature Scheme),
mis en œuvre tel que défini dans la RFC 8391.
40. Le tableau 38 répertorie les schémas de signature autorisés et la longueur de clé requise pour
fournir un niveau de sécurité de 112 bits et 128 bits.
longueur
Genre de Force
Schéma de signature / Spécifications de clé CHAT
Cryptographie (morceaux)
(morceaux)
PKCS#1v2.2 (RFC
8017)
112 2048 L
RSA RSASSAPSS PKCS#1v2.1 (RFC
≥128 ≥3072 R
3347)
FIPS 1864 (Annexe 5.5)
PKCS#1v2.2 (RFC
8017)
112 2048
RSA RSASSAPKCS1v1_5 PKCS#1v2.1 (RFC L
≥128 ≥3072
3347)
FIPS 1864 (Annexe 5.5)
FIPS 1864 (Annexe 4)
112 2048 L
FFDLOG AVD ISO 148883
≥128 ≥3072 R
ANSI X9.30
112 2048 L
FFDLOG KCDSA (DSA coréen) ISO 148883
≥128 ≥3072 R
longueur
Genre de Force
Schéma de signature / Spécifications de clé CHAT
Cryptographie (morceaux)
(morceaux)
112 2048 L
FFDLOG emprunter ISO 148883 (Ad1)
≥128 ≥3072 R
FIPS 1864 (Annexe 6)
ISO 148883 112 224 L
ECDLOG ECDSA
ANSI X9.62 ≥128 ≥ 256 R
SEC.1
112 224 L
ECDLOG ECKCDSA ISO 148883
≥128 ≥ 256 R
112 224 L
ECDLOG ECGDSA ISO 148883
≥128 ≥ 256 R
112 224 L
ECDLOG EC Schnorr ISO 148883 (Ad1)
≥128 ≥ 256 R
XMSS
les fonctions RFC 8391
Merkle étendu R
Hachage SHA2 NISTSP 800208
Schéma de signature
Tableau 38. Schémas de signature électronique autorisés.
3.7 CODE D'AUTHENTIFICATION DES MESSAGES (MAC)
41. Cette section inclut les constructions MAC (Message Authentication Code) , qui sont utilisées
pour fournir des services d'intégrité et d'authenticité de l'origine, basés sur des mécanismes
à clé symétrique.
42. Les schémas MAC sont classés en trois types : basés sur le chiffrement par bloc, basés sur la
fonction de hachage et basés sur le chiffrement plus la fonction de hachage. La force de
sécurité offerte par un schéma MAC dépend de la primitive cryptographique utilisée
(chiffrement par bloc ou fonction de hachage) et de la longueur de la clé cryptographique.
43. Dans la catégorie des schémas MAC basés sur des chiffrements par blocs, CBCMAC1 est
autorisé pour une utilisation recommandée . Il doit être basé sur le chiffrement symétrique
AES autorisé.
44. Dans la catégorie des schémas MAC basés sur des fonctions de hachage (également appelées
fonctions de hachage à clé), les schémas HMAC basés sur des fonctions de hachage SHA2
et SHA3 sont autorisés pour une utilisation recommandée. HMACSHA1 est concédé sous
licence pour une utilisation héritée uniquement.
45. Dans la catégorie des schémas MAC basés sur le chiffrement par bloc et la fonction de hachage
(également appelés fonctions de hachage universelles), le schéma GMAC spécifié dans le
NIST SP 80038D est autorisé pour une utilisation recommandée.
1
Elle n'est autorisée que dans les contextes où les tailles de toutes les entrées pour lesquelles
CBCMAC est calculé avec la même clé.
46. Le tableau 39 répertorie les schémas MAC autorisés et la longueur de clé requise pour
fournir un niveau de sécurité de 112 bits et 128 bits.
Genre de Chiffrer /
Schéma MAC / Force Longueur de
schème Fonction CHAT
Caractéristiques (morceaux) clé (bits)
MAC résumé
128 128
ISO 97971
R1
RadioCanada
AES 192 192

Basé sur MAC (algorithme MAC 1)
256 256
chiffrement
ISO 97971 128 128
par blocs
CCMC (algorithme MAC 5) AES 192 192 R
SP80038B 256 256
112
SHA1 ≥100 L
≥128
Basé sur ISO/CEI 97972
112 ≥100 L
fonction HMAC RFC2104 SHA2
≥128 ≥125 R
résumé FIPS 1981
112 ≥100 L
SHA3
≥128 ≥125 R
Basé sur
128 128
chiffrer et AES
GMAC NIST SP80038D 192 192 R1
Fonction GASH
256 256
Hacher
Tableau 39. Schémas MAC autorisés
3.8 CHIFFREMENT AVEC AUTHENTIFICATION (AE / AEAD)
47. Cette section comprend les schémas de chiffrement avec authentification, également connus
sous leur acronyme AE (Authenticated Encryption), qui fournissent
Services de confidentialité, d'intégrité et d'authentification de l'origine des messages.
Pour ce faire, ils utilisent un chiffrement symétrique (bloc ou flux) et un mécanisme MAC
(Message Authentication Code). L'utilisation d'une composition générique (Encryptthen
mac) est autorisée tant que les mécanismes de chiffrement et les schémas MAC sont
recommandés dans ce guide (Tableau 31 et Tableau 39). Lors de l'utilisation de ce
schéma, des précautions particulières doivent être prises pour vérifier que l'IV est
également authentifié.
48. Les schémas présentés dans cette section offrent une fonctionnalité supplémentaire,
consistant en la possibilité d'appliquer le cryptage à une partie seulement du message, en
laissant le reste des données (par exemple, un entête) non crypté, et en ne lui appliquant
qu'une authentification. Les schémas AE avec cette fonctionnalité sont appelés AEAD
(Authentication Encryption with Associated Data).
49. Les schémas AE/AEAD dont l'utilisation recommandée est autorisée sont EAX, GCM et CCM
basé sur le chiffrement par blocs AES.
1
La répétition de IV avec la même clé doit être évitée, la longueur du IV doit être de 96 bits et pour sa
la construction doit utiliser la méthode déterministe définie à la section 8.2.1 du SP800038D. La longueur MAC
doit être de 128.
50. Le schéma ChaCha20+Poly1305, qui est basé sur le chiffrement de flux ChaCha20 et la fonction
de hachage universelle Poly1305, est également autorisé pour une utilisation recommandée.
51. Le tableau 310 répertorie les régimes AE/AEAD autorisés et la durée
mot de passe.
longueur
Chiffre / Fonction Force
Schéma AE / Spécifications de clé CHAT
Hacher (morceaux)
(morceaux)
RFC 8439 ChaCha20
ChaCha20+Poly1305 2561 256 R
RFC 7905 Poly1305
128 128
EAX ISO/CEI 19772 AES 192 192 R
256 256
128 128
ISO/CEI 19772
MCG AES 192 192 R
NISTSP80038D
256 256
128 128
ISO/CEI 19772
CCM AES 192 192 R
NISTSP80038C
256 256
Tableau 310. Régimes AE/AEAD autorisés
3.9 FONCTIONS DE DÉRIVATION DE CLÉ (KDF)
52. Cette section comprend les fonctions de dérivation de clé (KDF, fonctions de dérivation de clé).
Ces fonctions permettent d'obtenir les clés cryptographiques à partir d'un secret partagé, qui
aura été généré par les mécanismes d'accord/transport de clés, ou à partir d'une source
d'entropie.
53. Le tableau 311 répertorie une série de KDF largement utilisés et autorisés pour une utilisation
recommandée. Il existe également d'autres modèles autorisés pour implémenter des fonctions
de dérivation de clés tels que ceux qui incluent les protocoles IKEv2, TLS 1.2 et TLS 1.3 qui
ont leur propre implémentation de KDF, comme spécifié dans les RFC correspondantes (RFC
7296 et 5246 respectivement).
54. Ce qui sera considéré comme une exigence pour qu'un KDF soit autorisé pour une utilisation
recommandée est que les mécanismes cryptographiques qu'il utilise (généralement des
schémas MAC ou des fonctions de résumé) soient parmi ceux autorisés dans ce guide.
1
ChaCha20 spécifié dans la RFC 8439 est une variante de ChaCha qui utilise 20 tours et une clé de
256 bits. Il existe des variantes avec des clés de 128 bits et de 8 à 12 tours, mais elles ne sont pas autorisées.
mécanisme dans lequel
KDF / Spécifications CHAT
base
NIST 80056AKDF NIST SP 80056A Fonction récapitulative (hachage)1 R
1
NIST 80056BKDF NIST SP 80056B Fonction de résumé (hachage) R
NIST 80056CKDF NIST SP 80056C Schéma MAC2 R
NIST 800108 NISTSP 800108 HMAC / CMAC R
1
X9.63KDF ANSI X9.63 Fonction de résumé (hachage) R
RFC 8018 (PKCS#5 v2.1)
PBKDF2 HMAC2 R
NISTSP 800132
SCRYPTE RFC7914 HMAC2 R
Tableau 311. Fonctions de dérivation de clé autorisées (KDF)
3.10 PROTECTION DES CLES (KEY WRAPPING)
55. Cette section comprend des mécanismes de protection des clés (Key Wrapping), qui
permettent de stocker et de transmettre les clés cryptographiques de manière
sécurisée, en garantissant leur confidentialité, leur intégrité et l'authentification de leur origine.
56. Ces mécanismes utilisent des chiffrements par blocs pour « envelopper » la clé qu'ils
protègent. Une considération très importante à prendre en compte est que le niveau
de sécurité de la clé à protéger est déterminé par le niveau de sécurité du mécanisme
de protection utilisé. Par exemple, si un mécanisme de protection basé sur AES128
est utilisé pour protéger une clé AES256, le niveau de sécurité de la clé sera réduit à
128 bits.
57. Le Tableau 312 répertorie les mécanismes de protection de clé ou Key Wrapping
autorisé. Cependant, tous les mécanismes cryptographiques autorisés dans les
sections précédentes peuvent également être utilisés pour protéger les clés, tels que
les schémas de chiffrement avec authentification (AE) (voir
section 3.8) ou une combinaison de schémas de chiffrement (voir section 3.1) avec
des mécanismes MAC (voir section 3.7).
1 Les KDF basés sur des fonctions récapitulatives doivent utiliser des fonctions autorisées comme indiqué dans le Tableau 35.
2 Les KDF basés sur MAC doivent utiliser des schémas MAC autorisés, comme indiqué dans le Tableau 39.
Mécanisme de protection des clés / Force Longueur de

chiffrer CHAT
Caractéristiques (morceaux) clé (bits)
128 128
VIS RFC 5297 AES 192 192 R
256 256
NIST SP 80038F 128 128
AESKeyWrap (KW) RFC 3394 AES 192 192 R
ISO/CEI 19772 256 256
128 128
AESKeyWrap avec NIST SP 80038F
AES 192 192 R
Rembourrage (KWP) RFC 5649
256 256
Tableau 312. Mécanismes d'enveloppement de clé autorisés
4. PROTOCOLES CRYPTOGRAPHIQUES
4.1 TLS
58. TLS (Transport Layer Security Protocol) est un protocole de sécurité cryptographique
qui permet de protéger les communications.
59. TLS est largement utilisé. Le plus connu est la protection du trafic HTTP entre un client web non
authentifié (navigateur web) et un site web authentifié , bien que le protocole soit déjà utilisé
dans de nombreuses autres applications aujourd'hui.
dû, en partie, à la disponibilité et à la facilité d'utilisation d'une variété de bibliothèques qui
l'implémentent.
60. Le protocole TLS est divisé en deux (2) phases : la phase de négociation ou Handshake, dans
laquelle les paramètres de connexion sont négociés, l'authentification est effectuée et les clés
cryptographiques sont générées, et la phase de chiffrement ou Record Protocol, dans laquelle
et la réception de messages est effectuée, en utilisant les clés et les algorithmes négociés.
61. Il existe plusieurs versions de TLS, dont certaines se sont déjà avérées non sécurisées. Les
versions TLS 1.2 et 1.3 doivent être utilisées et l'utilisation de versions TLS inférieures n'est
pas autorisée.
62. En ce qui concerne les mécanismes cryptographiques utilisés par TLS, ceuxci sont établis dans
la phase de négociation ou Handshake, et sont identifiés à travers ce que l'on appelle la suite
cryptographique ou suite de chiffrement. En général, une suite de chiffrement TLS 1.2 est
représentée comme suit :
• TLS_KeyExchange_Auth_WITH_Cipher_KeyLength_Mode_HashFunction
Une liste complète de toutes les suites de chiffrement TLS est disponible sur le site Web IANA1
pour TLS.
63. Suites de chiffrement qui :
a) N'utilisez pas de mécanismes cryptographiques pour : l'accord de clé ou le transport de clé,
l'authentification, le cryptage, l'intégrité et l'authenticité de l'origine. Autrement dit, les suites
de chiffrement qui indiquent "NULL" ou "anon" dans l'un de leurs
des champs.
Par exemple : TLS_RSA_WITH_NULL_SHA ou TLS_DH_anon_WITH_AES_128_CBC_SHA
b) Qui utilisent des mécanismes cryptographiques qui ne font pas partie des
autorisé dans ce guide (voir section 3).
Par exemple : TLS_RSA_WITH_RC4_128_MD5 ou TLS_RSA_WITH_IDEA_CBC_SHA
1
http://www.iana.org/assignments/tlsparameters/tlsparameters.xml
64. Suites de chiffrement qui :
a) Utilisez des clés prépartagées (PSK) comme méthode d'authentification, car l'authentification
avec des certificats X.509v3 est recommandée. c'estàdire suites de chiffrement
du genre :
TLS_ _PSK_AVEC_
TLS_PSK_WITH_
b) La raison pour ne pas les recommander est double :
• Toute partie connaissant le PSK peut s'authentifier et se connecter au VPN.
• Ils sont souvent vulnérables aux attaques par dictionnaire.
c) Ils ne doivent être utilisés que lorsqu'il est possible de s'assurer que :
• Ils ont été générés avec un générateur aléatoire, c'estàdire qu'ils n'ont pas été
dérivés de mots de passe à faible entropie.
• Elles sont renouvelées à chaque session établie.
65. Les suites de chiffrement TLS 1.2 suivantes sont autorisées :
Suites de chiffrement TLS 1.2 CHAT
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
R
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CCM
TLS_ECDHE_ECDSA_WITH_AES_128_CCM
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
1
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
1
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
L
1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
1
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_AND_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_AND_RSA_WITH_AES_256_CCM
L
TLS_AND_RSA_WITH_AES_128_CCM
1
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
1
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
1
L'utilisation de suites de chiffrement dont le mécanisme de chiffrement est basé sur CBC est recommandée pour utiliser l'extension
encrypt_then_mac
1
TLS_RSA_WITH_AES_256_GCM_SHA384
2
TLS_RSA_WITH_AES_128_GCM_SHA256
2
TLS_RSA_WITH_AES_256_CCM
2
TLS_RSA_WITH_AES_128_CCM L
1 2
TLS_RSA_WITH_AES_256_CBC_SHA256 ¡Erreur ! Marcador non
défini. 1
TLS_RSA_WITH_AES_128_CBC_SHA256
2
Tableau 41. Suites de chiffrement TLS 1.2 autorisées
66. Concernant TLS 1.3, plusieurs changements liés à la cryptographie sont introduits.
Les suites de chiffrement utilisent désormais uniquement les mécanismes AEAD et
l'utilisation de la fonction SHA1 est supprimée. Concernant la méthode Key Agreement ,
elle n'apparaît plus dans la suite de chiffrement et est négociée dans le Handshake à
l'aide de nouvelles extensions (Supported Groups). Les méthodes d'accord de clé
disponibles sont : clé prépartagée (PSK), DHE ou ECDHE, et PSK avec DHE.
67. Les cinq (5) suites de chiffrement actuelles pour TLS 1.3 sont sous licence pour une
utilisation recommandée. L'utilisation de clés prépartagées comme mécanisme d'accord
de clés n'est pas autorisée, mais les mécanismes autorisés pour une utilisation
recommandée seront DHE ou ECDHE (voir 3.2 et 3.5 ).
TLS_AES_128_GCM_SHA256 R
TLS_AES_256_GCM_SHA384 R
TLS_CHACHA20_POLY1305_SHA256 R
TLS_AES_128_CCM_SHA256 R
TLS_AES_128_CCM_8_SHA256 R
Tableau 42. Suites de chiffrement TLS 1.3 autorisées
4.2 SSH
68. SSH (Secure Shell) est un protocole de sécurité cryptographique conçu à l'origine pour
remplacer les protocoles de connexion à distance shell non sécurisés tels que Telnet.
69. Aujourd'hui, SSH est inclus de manière native et est utilisé comme principal mécanisme
d'administration à distance pour de nombreux systèmes d'exploitation et périphériques,
notamment Linux, Unix, routeurs, parefeu, périphériques réseau, etc.
Il peut également être utilisé par d'autres applications (par exemple FTP).
1
Ne fournit pas le secret de transmission
23
Centre national de cryptologie
70. SSH suit une architecture client/serveur typique. Une application cliente SSH sur l'hôte A initie une
connexion SSH avec une application serveur SSH sur l'hôte B. Les deux hôtes négocient les
mécanismes cryptographiques, établissent une clé cryptographique pour la session, effectuent
l'authentification pour l'hôte serveur (B) et enfin le client ( A) envoie les identifiants d'authentification
(par exemple, nom d'utilisateur et mot de passe) au serveur (B). Si l'authentification est valide, la
session SSH est lancée entre les deux (2) hôtes.
71. La seule version autorisée de SSH est SSHv2. Il a été démontré que les versions précédentes
présentaient de graves vulnérabilités connues et ne sont donc pas autorisées.
Version SSH Standard CHAT
RFC 4251
RFC 4252
SSHv2 R
RFC 4253
RFC 4254
Tableau 43. Versions SSH autorisées
72. Tous les mécanismes cryptographiques existants pour SSH sont répertoriés sur le site Web
de l'IANA1 pour SSH : mécanismes d'accord de clés (Key Exchange Method), authentification
(Public Key Algorithm), chiffrement (Encryption Algorithm) et authenticité et intégrité des messages
(MAC Algorithm). Les mécanismes autorisés sont indiqués cidessous.
4.2.1. ÉCHANGE DE CLÉ – ÉCHANGE DE CLÉ
Le mécanisme d'accord de clé (Key Exchange) dans SSH est basé sur DiffieHellman.
RFC 4253 indique que le diffiehellmangroup1
sha1 (Oackley Group 2, 1024 bits) et diffiehellmangroup14sha1 (Oackley Group 14, 2048 bits).
Cependant, le serveur SSH peut proposer de nouveaux groupes que le client doit accepter, comme
indiqué dans la RFC 4419.
Seules les méthodes d'échange de clé qui utilisent des mécanismes d'accord de clé parmi ceux
autorisés à la section 3.5, et qui fournissent une force de sécurité d'au moins 112 bits, sont autorisées.
Force
SSH Méthode d'échange de clés Groupes DH / Courbes elliptiques standard CHAT
(morceaux)
Groupe MODP 2048 bits14
diffiehellmangroup14sha1 RFC 4253 112 L
(RFC3526)
diffiehellmangroup14sha256 RFC 8268 112 L
(RFC3526)
diffiehellmangroup15sha512 RFC 8268 128 R
(RFC3526)
1
https://www.iana.org/assignments/sshparameters/sshparameters.xml
Force
SSH Méthode d'échange de clés Groupes DH / Courbes elliptiques standard CHAT
(morceaux)
diffiehellmangroupe16sha512 RFC 8268 >128 R
(RFC3526)
(RFC3526)
(RFC3526)
nistp256 (NIST) ou secp256r1
ecdhsha2nistp256 RFC 5656 128 R
(SEC2)
ecdhsha2nistp384 RFC 5656 >128 R
(SEC2)
ecdhsha2nistp521 RFC 5656 >128 R
(SEC2)
Tableau 44. Méthodes d'échange de clés SSH autorisées
4.2.2. CHIFFRÉ – ALGORITHME DE CHIFFREMENT
Une fois les clés obtenues via la méthode Key Exchange, tous les messages sont
envoyés chiffrés à l'aide du protocole BPP (BinaryPacket Protocol, RFC 4253). Cela
spécifie l'utilisation d'un schéma de chiffrement basé sur une construction Encode
thenEncryptandMAC utilisant un chiffrement par blocs en mode CBC ou le
chiffrement de flux RC4. La RFC 4344 définit de nouveaux mécanismes de
chiffrement qui utilisent un chiffrement par bloc en mode CTR, et la RFC 5647 définit
l'utilisation des schémas AEAD dans SSH.
Seuls les mécanismes de chiffrement qui utilisent un schéma de chiffrement parmi
ceux autorisés à la section 3.1, ou un schéma AEAD parmi ceux autorisés à la
section 3.8 sont autorisés.
SSH – Chiffrement Force
Composition Standard CHAT
Algorithme (morceaux)
aes128cbc AES en mode CBC Clé 128 bits RFC4253 128 L1
aes128ctr AES en mode CTR clé 128 bits RFC4344 128 R1
aes192ctr AES en mode CTR Clé 192 bits RFC4344 192 R1
aes256ctr AES en mode CTR clé 256 bits RFC4344 256 R1
AEAD_AES_128_GCM Clé AES GCM 128 bits RFC5647 128 R
AEAD_AES_256_GCM Clé AES GCM 256 bits RFC5647 256 R
1
Si un mode de cryptage non authentifié est choisi (c'estàdire aesctr, aescbc), il sera obligatoire d'utiliser l'une des options
recommandées pour protéger l'intégrité et l'authenticité des messages (c'estàdire HMACSHA2)
Tableau 45. Mécanismes de chiffrement SSH autorisés .
4.2.3. AUTHENTIFICATION – AUTHENTIFICATION PAR CLÉ PUBLIQUE
L'authentification du serveur SSH est réalisée par cryptographie à clé publique, à l'aide
de clés publiques ou de certificats (authentification à clé publique). L'authentification du
client peut être réalisée par diverses méthodes, mais la cryptographie à clé publique est
toujours recommandée, au moins comme l'un des facteurs.
La RFC 4253 définit les algorithmes de clé publique initialement pris en charge par SSH.
D'autres RFC ont ajouté plus d'algorithmes et de constructions.
Seuls les mécanismes d'authentification à clé publique qui utilisent des schémas de
signature de ceux autorisés à la section 3.6 sont autorisés.
SSH Algorithme de clé publique Composition Standard Force CHAT
RSASSAPKCS1v1_5 (RFC
112 (clé RSA 2048)
rsasha2256 8017) & SHA256 (FIPS RFC8332 L
128 (clé RSA 3072)
1804)
RSASSAPKCS1v1_5 (RFC
112 (clé RSA 2048)
rsasha2512 8017) & SHA512 (FIPS RFC8332 L
128 (clé RSA 3072)
1804)
ECDSA (SEC1) nistp256 &
ecdsasha2nistp256 RFC5656 128 R
SHA256 (FIPS 1803)
ecdsasha2nistp384 RFC5656 >128 R
SHA384 (FIPS 1803)
ecdsasha2nistp521 RFC5656 >128 R
SHA512 (FIPS 1803)
RSASSAPKCS1v1_5
x509v3rsa2048sha256 (RFC3347) et SHA256 RFC6187 112 (clé RSA 2048) L
(FIPS 1803)
ECDSA (FIPS 1843)
x509v3ecdsasha2nistp256 nistp256 et SHA256 (FIPS RFC6187 128 R
1803)
ECDSA (FIPS 1843)
509v3ecdsasha2nistp384 nistp384 et SHA384 (FIPS RFC6187 >128 R
1803)
ECDSA (FIPS 1843)
x509v3ecdsasha2nistp521 nistp521 & SHA512 (FIPS RFC6187 >128 R
1803)
Tableau 46. Mécanismes d'authentification SSHPublic Key autorisés
4.2.4. INTÉGRITÉ ET AUTHENTICITÉ DE L'ORIGINE – ALGORITHME MAC
La RFC 4253 spécifie les schémas HMAC avec les fonctions SHA1 ou MD5 pour les
constructions MAC. Comme indiqué dans la section 3.7, la construction HMACSHA1
il est concédé sous licence pour une utilisation héritée uniquement et les versions MD5 ne sont pas concédées
sous licence. La RFC 6668 détaille l'utilisation des constructions HMACSHA2.
Seuls les mécanismes MAC qui utilisent des schémas MAC de ceux autorisés à la
section 3.7 ou un schéma AEAD de ceux autorisés à la section 3.8 sont autorisés .
Force
Algorithme MAC Composition Standard CHAT
(morceaux)
hmacsha1 HMAC avec SHA1 clé 160 bits RFC4253 >128 L
hmacsha196 HMAC avec SHA1 clé 160 bits RFC4253 >128 L
hmacsha2256 HMAC avec SHA256 Clé 256 bits RFC6668 > 128 R
hmacsha2512 HMAC avec SHA512 Clé 512 bits RFC6668 > 128 R
AEAD_AES_128_GCM Clé AES GCM 128 bits RFC5647 >128 R
AEAD_AES_256_GCM Clé AES GCM 256 bits RFC5647 >128 R
Tableau 47. Mécanismes SSHMAC autorisés
4.3 IPSEC
73. IPsec est une norme ouverte qui assure la sécurité au niveau de la couche réseau IP
dans la pile de protocoles TCP/IP. Cela diffère des protocoles TLS et SSH mentionnés
dans d'autres sections, car ils assurent la sécurité au niveau des couches supérieures,
telles que les couches d'application.
74. L'utilisation principale d'IPsec est de créer des VPN (réseaux privés virtuels) qui
établissent des canaux de communication sécurisés via des réseaux IP non sécurisés,
tels qu'Internet.
75. IPsec peut être déployé selon deux modes : tunnel et transport.
a) En mode tunnel, l'ensemble du paquet IP est protégé cryptographiquement (plus
les champs de sécurité insérés), c'estàdire que le paquet est traité comme la
charge utile d' un nouveau paquet IP externe, avec son propre entête. On peut
dire que le paquet IP d'origine est encapsulé à l'intérieur du paquet IP externe.
b) En mode transport, l'entête du paquet IP d'origine est conservé et certains
champs de sécurité sont ajoutés. C'est la charge utile avec un champ d'entête
qui subit un traitement cryptographique. Le mode transport fournit une protection
pour l'essentiel à la charge utile.
Le mode tunnel offre donc une plus grande sécurité que le mode transport.
Par conséquent, dans la mesure du possible, nous travaillerons dans cette configuration.
Le choix du mode de transport ne doit être justifié que dans le cas où la taille des paquets
pose problème en raison des restrictions imposées par le réseau.
76. IPsec a deux composants principaux :
a) L'accord de clé réalisé avec le protocole IKE (Internet Key Exchange). C'est le
protocole utilisé par IPsec pour établir une association de sécurité (SA) de manière
automatique. Cela comprend la négociation des paramètres de connexion,
l'établissement du secret partagé et la dérivation du matériel de clé cryptographique.
Il est également chargé de réaliser l'authentification mutuelle des extrémités de
communication (peers).
La version actuelle autorisée pour une utilisation recommandée est IKEv2, spécifiée
dans la RFC 72961 . La version précédente IKEv1, n'est autorisée que pour une
utilisation Legacy et uniquement dans les modes : Main et Quick mode. Pas en mode
agressif2 .
b) Protection des données pouvant être réalisée avec les protocoles AH (Authentication
Header) ou ESP (Encapsulating Security Payload). Sont les
protocoles qui assurent la protection de l'authenticité, de l'intégrité et/ou
confidentialité des données. Le protocole AH garantit l'intégrité et l'authenticité, mais
pas la confidentialité. ESP garantit la confidentialité et éventuellement l'intégrité et
l'authenticité.
Il existe des attaques connues lorsque IPsec est implémenté dans n'importe quelle
configuration MACthenEncrypt (comme l'utilisation d'AH en mode transport avant
un ESP en chiffrement uniquement en mode tunnel). D'un autre côté, il n'y a pas
d'attaques connues sur IPsec si vous utilisez uniquement le cryptage ESP suivi de
AH ou ESP avec authenticité et intégrité sans qu'un autre AH ne le suive. Par
conséquent, il est recommandé d'utiliser ESP toujours avec les options de protection
d'intégrité et d'authenticité, en plus de la confidentialité.
Protocole Standard modes recommandés CHAT
RFC 4301 à 4309
IPsec mode tunnel R
RFC 8221
Confidentialité &
ESP RFC 4303 R
Intégrité et authenticité
1
La RFC 7296 est la révision des précédentes RFC 5996 et RFC 4306. La RFC 7296 définit la base du protocole IKEv2, mais
il existe de nombreuses autres RFC qui spécifient les extensions IKE.
2
IKEv1 utilise principalement deux méthodes d'échange de clés lors de la phase 1 de négociation : le mode principal et le
mode agressif. Les deux diffèrent par le nombre de cycles de négociation et par les informations échangées dans chacun
d'eux. Le mode principal utilise plus de tours et est donc plus lent et plus complexe à mettre en œuvre. Le mode agressif est
plus rapide, mais une partie des informations échangées dans les rondes n'est pas cryptée, donc plus précaire. Le mode
rapide est similaire au mode agressif , sauf que toutes les données sont protégées dans une association de sécurité IKE SA.
Protocole Standard modes recommandés CHAT
RFC 2407, 2408, 2409
IKEv1 Mode principal et mode rapide L
RFC 4109
RFC 7296
IKEv2 Tous R
RFC 8247
Tableau 48. Versions IPsec autorisées.
77. Lors du premier échange qui se produit dans le protocole IKE (IKE_SA_INIT), les paramètres
cryptographiques de la connexion sont négociés (schémas de chiffrement, accord de clé,
intégrité, etc.). Ces paramètres sont appelés "Transformés".
La liste de tous les paramètres ou Transforms se trouve sur le site web IANA1 .
.
Les types de paramètres cryptographiques ou Transforms sont :
DiffieHellman Group Transforms : groupes (EC)DH qui seront utilisés pour l'accord de clé
(échange de clé).
Transformées de fonctions pseudoaléatoires : fonctions pseudoaléatoires (PRF) qui
seront utilisées pour la génération des valeurs aléatoires et pour la dérivation du matériel
de clé.
Encryption Algorithm Transforms : schémas de chiffrement classiques ou schémas AEAD
qui seront utilisés pour la protection de la confidentialité.
Integrity Algorithm Transforms : schémas MAC à utiliser pour la protection
d'intégrité.
4.3.1. ACCORD CLE (LE GROUPE DIFFIEHELLMAN SE TRANSFORME)
Le mécanisme d'accord de clé (Key Exchange) utilisé dans le protocole IKEv2 est basé sur
DiffieHellman. Lors du premier échange IKE_SA_INIT, les paramètres DiffieHellman
nécessaires sont également envoyés pour qu'une fois l'échange terminé, les deux extrémités
(peers) aient finalisé l'accord de clé et aient généré le secret partagé.
Plusieurs groupes DiffieHellman, à la fois MODP (Modular Exponential) et Elliptic Curve
(ECC), ont été définis pour être utilisés dans IKEv2. Ces groupes sont définis à la fois dans
le document de base de la spécification IKEv2 (RFC 7296) et dans d'autres RFC qui
définissent des extensions pour IKEv2.
Parmi tous les groupes (EC)DH ou DiffieHellman Group Transforms définis , ceux indiqués
dans le tableau suivant sont autorisés.
1
https://www.iana.org/assignments/ikev2parameters/ikev2parameters.xhtml
Standard Force
Groupe (EC)DH CHAT
IKEv2 (morceaux)
14 Groupe MODP 2048 bits RFC 3526 112 L
15 Groupe MODP 3072 bits RFC 3526 128 R
16 Groupe MODP 4096 bits RFC 3526 >128 R
19 Groupe ECP aléatoire de 256 bits RFC 5903 128 R
20 groupe ECP aléatoire de 384 bits RFC 5903 >128 R
21 Groupe ECP aléatoire de 521 bits RFC 5903 >128 R
28 brainpoolP256r1 RFC 6954 128 R
29 brainpoolP384r1 RFC 6954 >128 R
30 brainpoolP512r1 RFC 6954 >128 R
31 x 25519 RFC 8031 128 R
32x448 RFC 8031 >128 R
Tableau 49. Groupes (EC)DH autorisés pour IKEv2.
4.3.2. CIFRADO (TRANSFORMATION DES ALGORITHMES DE CHIFFREMENT)
Les propositions de schémas de chiffrement IKEv2 et ESP peuvent inclure à la fois des
schémas de chiffrement classiques et des schémas AEAD.
Suivant les recommandations faites dans les sections 3.1 et 3.8, des schémas de
chiffrement ou schémas de chiffrement avec authentification définis, ceux indiqués dans le
tableau suivant sont autorisés.
Standard Standard Force Longueur de

Schéma de chiffrement /AEAD CHAT
IKEv2 ESP (morceaux) clé (bits)
128 128
ENCR_AES_CBC RFC 7296 RFC 3602 192 192 R1
256 256
128 128
ENCR_AES_CTR RFC 5930 RFC 3686 192 192 R
256 256
128 128
RFC 5282
ENCR_AES_CCM_12 (1) RFC 4309 192 192 R
RFC 8247
256 256
128 128
RFC 5282
ENCR_AES_CCM_16 (1) RFC 4309 192 192 R
RFC 8247
256 256
128 128
RFC 5282 RFC 4106
ENCR_AES_GCM_12 (1)(2) 192 192 R
RFC 8247 RFC 8750
256 256
128 128
RFC 5282 RFC 4106
ENCR_AES_GCM_16 (1)(2) 192 192 R
RFC 8247 RFC 8750
256 256
RFC 7634
ENCR_CHACHA20_POLY1305 (2) RFC 7634 256 256 R
RFC 8750
Tableau 410. Schémas AEAD/cryptage autorisés pour IKEv2 et ESP.
(1) 12/16 désigne la valeur en octets de l'ICV2 (Integrity Check Value). Sur les trois (3)
valeurs possibles (8, 12 et 16 octets) définies dans les RFC, la valeur recommandée est
de 16 octets bien que 12 octets soient également acceptables.
(2) Inclut les variantes de vecteur d'initialisation implicite (IIV)3 définies dans la RFC 8750
pour ESP uniquement (AES_GCM_16_IIV et CHACHA20_POLY1305_IIV).
4.3.3. INTÉGRITÉ ET AUTHENTIFICATION DE L'ORIGINE (TRANSFORMATION DES
ALGORITHMES D'INTÉGRITÉ)
Les protocoles ESP et IKEv2 utilisent des mécanismes MAC pour la vérification de
l'intégrité et l'authentification de l'origine, c'estàdire pour garantir que les paquets sont
authentiques et n'ont pas été modifiés en transit.
Dans les cas où, dans la proposition d' algorithme de chiffrement
Transforme un schéma AEAD est inclus, aucun mécanisme ne sera utilisé pour
1
Toujours avec un mécanisme d'authentification de la section 3.7
2
L'ICV (Integrity Check Value) est la balise d'authentification, ou valeur générée par le schéma AEAD pour la vérification
de l'intégrité et de l'authenticité de l'origine.
3
Les schémas AEAD définis pour ESP (AES_CCM, AES_GCM, CHACHA20_POLY1305) nécessitent un vecteur
d'initialisation (IV) ou une valeur nonce. Pour le générer, un autre vecteur d'initialisation que chaque paquet ESP apporte
est utilisé. Cette génération du nonce , ou IV, est appelée IV explicite. Dans certaines implémentations, au lieu de transporter
les octets supplémentaires de données IV dans chaque paquet, il peut être préférable de générer l'IV localement sur chaque
périphérique (homologue). Cette génération locale du VI est appelée IV implicite (VII).
protection de l'intégrité et authentification de l'origine. Cela ne sera utilisé que lorsqu'un
schéma de chiffrement classique est inclus dans la proposition.
Les mécanismes MAC autorisés pour une utilisation recommandée sont ceux basés sur les
schémas AESCMAC, AESGMAC et HMACSHA2.
En ce qui concerne les schémas HMACSHA2, lorsqu'ils sont utilisés dans IPsec comme
mécanismes d'intégrité et d'authenticité, la longueur de la clé sera fixée en fonction de la
taille de la valeur de hachage de sortie, et output1 est tronqué :
HMACSHA256128 : utilise une clé de 256 bits et tronque la sortie pour
128 bits.
HMACSHA384192 : utilisez une clé de 384 bits et tronquez la sortie pour
192 bits.
HMACSHA512256 : utilise une clé de 512 bits et tronque la sortie pour
256 bits.
Par rapport au schéma HMACSHA1_962 , il utilise une longueur de clé fixe de 160 bits et
une troncature de sortie à 96 bits. Comme indiqué dans la section 3.7, les mécanismes
basés sur HMACSHA1 ne sont autorisés que pour une utilisation Legacy.
Standard Longueur de Force
Schéma MAC CHAT
IKEv2/ESP clé (bits) (morceaux)
RFC2404
AUTH_HMAC_SHA1_96 160 ≥128 L
RFC 7296
AUTH_HMAC_SHA2_256_128 RFC 4868 256 ≥128 R
AUTH_AES_CMAC_963 RFC 4494 128 128 R
128 128
AUTH_AES_GMAC RFC 4543 192 192 R
256 256
Tableau 411. Schémas MAC autorisés pour IKEv2 et ESP.
4.3.4. FUNCIONES PRF (TRANSFORMATIONS DE FONCTIONS PSEUDORANDOM)
Les clés de chiffrement et d'authentification des messages (MAC) seront dérivées du secret
partagé obtenu avec l' échange DiffieHellman, en utilisant la fonction PRF négociée.
1
Spécifié dans RFC 4868, qui définit comment les schémas HMACSHA2 sont utilisés dans IPsec.
2
Spécifié dans RFC 2402, qui définit HMACSHA1 pour ESP.
3
Le mécanisme AESCMAC96 est une variante de AES128CMAC avec la sortie tronquée aux 96 bits les plus significatifs.
(MSB), défini pour être utilisé comme mécanisme d'intégrité pour ESP uniquement (RFC 4494).
Les fonctions PRF utilisées dans IKEv2 sont similaires aux mécanismes MAC indiqués cidessus, sauf
que la restriction de taille de clé fixe est supprimée et que la troncature est supprimée, en raison de la
criticité de la taille de la sortie de la fonction.
Les fonctions PRF autorisées pour une utilisation recommandée seront donc celles basées sur les
schémas AESCMAC et HMACSHA2.

Fonction PRF CHAT
IKEv2 clé (bits) (morceaux)
PRF_HMAC_SHA1 RFC2104 ≥100 112 L
≥100 112 L
PRF_HMAC_SHA2_256 RFC 4868
≥125 ≥128 R
≥100 112 L
≥125 ≥128 R
≥100 112 L
≥125 ≥128 R
PRF_AES128_CMAC RFC 4615 128 128 R
Tableau 412. Fonctions PRF autorisées pour IKEv2.
4.3.5. MÉCANISME D'AUTHENTIFICATION
L'authentification des extrémités de connexion (peers) s'effectue au travers des échanges IKE_AUTH,
après avoir terminé la négociation des paramètres et l'établissement et la dérivation du matériel
cryptographique.
Le principal mécanisme d'authentification utilisé dans IKEv2 est la signature électronique avec des clés
publiques/privées (authentification basée sur la signature par clé publique). L'utilisation de certificats
X.509 est recommandée pour lier les clés aux identités des pairs. Les certificats, aussi bien des pairs
que des CA intermédiaires (Autorités de Certification) , seront échangés dans les messages IKE_AUTH.
Les schémas de signature autorisés pour une utilisation avec IKEv2 sont basés sur ECDSA et RSA et
sont répertoriés dans le tableau suivant.

Schéma de signature CHAT
2048 112
Signature numérique RSA (RSASSAPKCS1v1_5) RFC 7296 L
≥3072 ≥128
2048 112 L
Signature numérique RSA (RSASSAPSS) RFC 4055
≥3072 ≥128 R
ECDSA avec SHA256 sur la courbe P256 RFC 4754 256 128 R
ECDSA256 avec BrainpoolP256r1 RFC 7427 256 128 R

Schéma de signature CHAT
ECGDSA256 avec BrainpoolP256r1 RFC 7427 256 128 R
Tableau 413. Schémas de signature autorisés pour IKEv2.
Une autre option d'authentification est les clés prépartagées (PSK), dont l'utilisation
est déconseillée, comme indiqué dans les sections précédentes1 . Il existe
également l'option de nonauthentification, qui ne doit en aucun cas être utilisée.
Enfin, indiquez que IKEv2 supporte également l'authentification avec les méthodes
EAP (Extensible Authentication Protocol) définies dans la RFC 3748. Ce type
d'authentification est déconseillé, car la plupart de ces méthodes sont asymétriques
et n'impliquent pas d'authentification mutuelle, mais servent à authentifier le client
contre le serveur. Si ce type d'authentification est utilisé, il doit être combiné avec
une authentification par signature électronique à clés publiques/privées, du serveur
vers le client, et les recommandations de sécurité pour sa mise en œuvre indiquées
dans les spécifications IKEv2 (RFC 7296) doivent être prises en compte . )2 .
1
En cas d'utilisation de PSK, un aspect critique est de s'assurer qu'elles ont une entropie suffisante. Le PSK doit contenir autant
de caractère aléatoire que la clé la plus forte en cours de négociation. La dérivation du PSK à partir du mot de passe d'un
utilisateur ou de toute autre pratique à faible entropie n'est pas sécurisée. Ces polices sont vulnérables aux attaques par
dictionnaire, à l'ingénierie sociale, etc.
2
La RFC 7296 recommande, entre autres, de n'utiliser que des méthodes EAP qui génèrent une clé partagée qui sert à protéger
la charge utile des échanges IKE_AUTH, offrant une protection contre les attaques d'usurpation de serveur et les attaques de
maintenance au milieu.
5. MESURES DE SÉCURITÉ
78. Chacune des mesures de sécurité spécifiées dans l'ENS qui utilisent des mécanismes
cryptographiques sont énumérées cidessous. Ces mécanismes doivent figurer parmi ceux
autorisés dans ce guide (voir section 3) et, en fonction du niveau de sécurité requis pour les
dimensions de sécurité concernées par la mesure et du niveau de menace considéré pour
chaque scénario d'utilisation, il sera déterminé le minimum force cryptologique nécessaire.
79. La section 5.12 contient un exemple d'application de ces mesures au
protocole TLS.
5.1 DIMENSIONS DE SÉCURITÉ CONSIDÉRÉES
80. Selon la mesure de sécurité, les dimensions de sécurité suivantes seront prises en compte, qui
seront identifiées par leurs initiales correspondantes en majuscules :
a) Disponibilité [D]
b) Authenticité [A]
c) Intégrité [I]
d) Confidentialité [C]
e) Traçabilité [T]
Sauf indication contraire, le niveau de sécurité requis pour chaque mesure sera déterminé par le
niveau de sécurité le plus élevé requis pour chacune des dimensions auxquelles la mesure est
applicable.
5.2 NIVEAUX DE MENACE
81. Les menaces auxquelles une mesure de sécurité doit faire face, tant
À la fois accidentels et volontaires, ils sont liés à l'environnement d'exploitation du système
d'information dans lequel ils sont déployés, puisque ce fait limite le profil des individus pouvant
accéder pour exploiter les vulnérabilités dudit système.
82. Plus précisément, les menaces peuvent provenir des types d'individus suivants :
a) Personnes non authentifiées ou autorisées à accéder aux actifs sensibles
qui protège le système (personnes extérieures au système).
b) Personnes authentifiées non autorisées à accéder aux actifs sensibles
qui protège le système (utilisateurs du système sans privilèges suffisants).
c) Les personnes authentifiées et autorisées à accéder aux actifs sensibles qui
protège le système (utilisateurs autorisés et authentifiés).
83. Les niveaux de menace peuvent être classés comme suit, selon l'origine
des menaces :
a) Niveau de menace ÉLEVÉ : lorsqu'un actif est exposé à des attaques provenant d'individus non
autorisés et non authentifiés.
b) Niveau de menace MOYEN : lorsqu'un bien est exposé à des attaques provenant d'individus non
autorisés, mais authentifiés.
c) Niveau de menace FAIBLE : lorsqu'un actif est exposé à des attaques
émanant de personnes authentifiées et autorisées.
84. En général, la force requise pour une certaine mesure de sécurité sera déterminée par le niveau de menace
qui doit être atténué.
5.3 IDENTIFICATION. [OP.ACC.1]
85. Comme indiqué à l'[op.acc.1.5] de l'annexe II de l'ENS, dans les cas de communications électroniques, les
parties concernées s'identifieront conformément aux mécanismes prévus par la législation européenne
et nationale en la matière, notamment par les systèmes d'identification électronique prévus par le
règlement (UE) n° 910/2014 du Parlement européen et du Conseil du 23 juillet 2014 concernant
l'identification électronique et les services de confiance pour les transactions électroniques dans le
marché intérieur, ciaprès le règlement eIDAS et, le cas échéant, par les dispositions de la loi 39/2015
sur la procédure administrative commune des administrations publiques et la loi 40/2015 sur le régime
juridique du secteur public, toutes deux du 1er octobre, et par le décret royal 203/2021, du 30 mars, qui
approuve la régulation de l'action et du fonctionnement du secteur public par voie électronique.
86. Différents niveaux de sécurité seront établis pour cette mesure, en fonction du niveau de sécurité maximal
requis par le système pour chacune des dimensions Traçabilité [T] et Authenticité [A]. Le tableau suivant
présente une correspondance entre les niveaux de sécurité établis par le Règlement eIDAS dans son
article 8 et les niveaux requis par l'ENS :
Niveau de sécurité eIDAS
BAS FAIBLE, SUBSTANTIEL OU ÉLEVÉ
Niveau maximum
ENS obligatoire MOITIÉ SUBSTANTIEL OU ÉLEVÉ
à [T] ou [A]
HAUT HAUT
Tableau 51. [op.acc.1] Correspondance niveaux ENS – niveaux requis eIDAS
5.4 MÉCANISMES D'AUTHENTIFICATION (UTILISATEURS EXTERNES)
[OP.ACC.5]
87. Pour garantir la sécurité des systèmes, l'identité numérique de ceux qui demandent à y accéder est utilisée.
Chaque personne doit avoir une identité et cela permet aux systèmes de les identifier, en les distinguant
des autres.
Dans ce scénario, nous différencierons : l'identification, qui est le processus par lequel l'utilisateur du
système fournit les informations d'identification ou la preuve qui l'identifie ; l'authentification, qui consiste en
la vérification par le système des informations d'identification fournies par l'utilisateur, vérifiant qu'il est bien
celui qu'il prétend être ; autorisation, constituée des privilèges accordés à l'utilisateur, ou des actions
autorisées à être effectuées, sur la base d'une authentification avec les informations d'identification qui
l'identifient.
88. De manière générale, les mécanismes d'authentification reposent sur l'utilisation de trois (3) propriétés ou
caractéristiques possibles de la partie à authentifier (facteurs d'authentification) :
a) « quelque chose que vous savez » : mots de passe ou clés concertés.
b) « quelque chose que vous possédez » : composants logiques (tels que des certificats de logiciel) ou
certificats de périphérique physique.
c) « quelque chose qui est » : éléments biométriques (un trait ou une propriété biométrique, des traits du
visage, une empreinte digitale, un motif d'iris, etc.).
89. Pour l'authentification des utilisateurs extérieurs au système dans le cadre de l'ENS,
considérera les méthodes d'authentification suivantes :
a) Mot de passe (1 facteur : « quelque chose de connu ») : Orienté vers les systèmes de catégories
BASIC, il consiste en une chaîne de caractères alphanumériques utilisée comme mécanisme
d'authentification. Pour ces mots de passe, une robustesse, une périodicité minimale et un nombre
de tentatives d'authentification infructueuses sont définis, après quoi le système doit :
1. Bloquer et demander une intervention spécifique pour réactiver le
compte. Cette option est recommandée.
2. Incluez un délai entre les tentatives d'authentification, afin d'éviter les attaques d'authentification
par force brute. Il est recommandé que ce délai soit incrémentiel.
b) Mots de passe + OTP (2 facteurs : "quelque chose que vous savez" + "quelque chose que vous avez") :
Outre l'utilisation d'un mot de passe, ce mécanisme nécessitera un mot de passe à usage unique
(OTP) supplémentaire, généré ou transmis à un appareil sur lequel l'utilisateur a, avec un niveau de
confiance élevé, un contrôle exclusif.
c) Les certificats qualifiés (conformément aux dispositions du Règlement eIDAS), dont l'utilisation est
protégée par un second facteur, de type PIN (« quelque chose
que l'on a » + « quelque chose que l'on sait ») ou biométrique (« quelque chose que l'on a » + «
quelque chose que l'on est »). De plus, les informations d'identification utilisées doivent avoir
été obtenues après une précédente inscription en personne ou par voie électronique, à l'aide
d'un certificat électronique qualifié.
d) Certificats qualifiés dans un dispositif physique permettant la création d'une signature qualifiée.
L'utilisation du certificat sera également protégée par un deuxième facteur de type PIN ("quelque
chose que vous avez" + quelque chose que vous savez") ou biométrique ("quelque chose que
vous avez" + "quelque chose que vous êtes"). Les informations d'identification utilisées doivent
avoir été obtenues après une précédente inscription en personne ou par voie électronique, à
l'aide d'un certificat électronique qualifié.
90. En règle générale, l'ENS établit qu'avant de fournir des identifiants d'authentification à des entités,
utilisateurs ou processus externes, ceuxci doivent avoir été identifiés et enregistrés de manière fiable
auprès du système ou auprès d'un Prestataire de Services de Confiance Qualifié ou d'un fournisseur
d'identité électronique reconnu par administrations publiques, conformément aux dispositions de la loi
39/2015, du 1er octobre.
91. Différents niveaux de sécurité seront pris en compte pour les mécanismes d'authentification des utilisateurs
externes, en fonction du niveau de sécurité maximal requis par le système pour l'une des dimensions
de Confidentialité [C], Intégrité [I], Traçabilité [T] ou Authenticité [ TO]. Le tableau suivant présente les
méthodes d'authentification recommandées pour chacun des niveaux, ainsi que les exigences de
robustesse pour chacun d'eux :
Méthodes
d'authentification Exigences
autorisé
Longueur minimale : 8 caractères avec un
minimum de trois types différents, parmi ceux
décrits dans la section 5.4.1.
Fréquence de renouvellement : 2 ans,
mots de passe maximum.
Nombre maximum de tentatives d'authentification
infructueuses : 5
Niveau
FAIBLE (1 Interdiction de réutiliser 5 mots de passe
ou 2 facteurs) précédent.
Longueur minimum : 8 caractères avec un
minimum de trois types différents.
Mots de passe + OTP
maximum.
Nombre maximal de tentatives infructueuses
authentification : 5
Interdiction de réutiliser 5 mots de passe
précédents.
Utilisation de certificats X509v3.
Résistance minimale des mécanismes
cryptographique : 112.
Certificats
L'utilisation d' algorithmes hérités est autorisée.
Nombre maximal de tentatives d'authentification
infructueuses : 10
Utilisation de certificats X509v3
Résistance minimale des mécanismes :
Certificats sur
appareil physique
infructueuses : 10
Longueur minimale du mot de passe 12
caractères avec un minimum de trois types
différents.
Mots de passe + OTP maximum.
infructueuses : 5
précédent.
Niveau
MOYEN (2 Résistance minimale des mécanismes :
facteurs) Certificats + pin ou cryptographique : 128.
biométrique.
L'utilisation d'algorithmes recommandés est
autorisée.
Option
recommandée pour le Longueur minimale du code PIN : 6 caractères
niveau MOYEN. alphanumériques.
authentification : entre 10 et 5
Certificats en Utilisation de certificats X509v3.
dispositif physique + Résistance minimale des mécanismes :
code PIN ou biométrique. cryptographique : 128.
Option L'utilisation d'algorithmes recommandés est
recommandée pour le autorisée.
niveau MOYEN.
Longueur minimale du code PIN : 6 caractères
alphanumériques.
authentification : entre 10 et 5
Longueur minimale du mot de passe 12
caractères avec un minimum de trois types différents.
Fréquence de renouvellement : 2 ans, maximum.
Mots de passe + OTP
Interdiction de réutiliser 10 mots de passe précédents.
Résistance minimale des mécanismes : 128.
Niveau L'utilisation d'algorithmes recommandés est
autorisée.
ÉLEVÉ (2 Certificats
facteurs) Longueur minimale du code PIN : 6 caractères
alphanumériques.
Certificats sur Résistance minimale des mécanismes : 128.
appareil physique + pin L'utilisation d'algorithmes recommandés est
ou biométrique. autorisée.
Option Longueur minimale du code PIN : 6 caractères
recommandée pour le alphanumériques.
niveau HIGH.
infructueuses : 5
Tableau 52. [op.acc.5] Exigences d'authentification pour les utilisateurs externes.
5.4.1. EXIGENCES GÉNÉRALES POUR L'ÉTABLISSEMENT DE MOTS DE PASSE
(CONCERTÉ OU ALÉATOIRE)
92. Lors de la sélection des mots de passe, les directives suivantes doivent être suivies et
options de configuration :
a) S'il est nécessaire de sauvegarder une copie du mot de passe, cela se fera dans un
conteneur sécurisé.
b) Les mots de passe à usage unique doivent être générés lorsqu'ils sont établis par le
gestionnaire de mots de passe pour un tiers, de manière à ce que leur modification soit
nécessaire lors des accès ultérieurs.
c) Selon le niveau de sécurité requis et en respectant les valeurs limites préalablement établies,
la politique de gestion des mots de passe déterminera :
La fenêtre de réutilisation des mots de passe (nombre de mots de passe
cidessus qui ne doit pas être répété).
La périodicité avec laquelle ils doivent être changés. Établir une période minimale et
une période maximale. Le fait d'établir une période minimale est de les empêcher
de faire tous les changements de mot de passe autorisés consécutivement afin
de conserver le même mot de passe.
Le nombre minimum de types de caractères alphanumériques qui doivent contenir
parmi les suivants : Chiffres, majuscules, minuscules, signes de ponctuation et
caractères spéciaux (du type : « ! », « @ », « # », « $ », « % ", "^", "&", "*", "(", ")").
93. Dans le cas où les mots de passe sont définis manuellement, une liste noire de mots de passe sera
établie qui ne doit pas être utilisée car, avec l'aide de l'ingénierie sociale, combinée à des
attaques par force brute, ils pourraient être devinés. Cidessous une liste (non exhaustive) des
mots de passe interdits1 :
a) Mots de passe obtenus lors de failles de sécurité précédentes.
b) Le nom d'hôte du système ou le nom de l'entreprise de l'organisation ellemême.
c) Tout mot qui apparaît dans un dictionnaire, y compris les dictionnaires de langues autres
que l'espagnol (anglais, français...).
d) Plaques d'immatriculation de ses propres véhicules, date de naissance, date de mariage,
nom de l'animal, etc.
e) Noms propres, titres de films, séries télévisées, etc.
f) Séquences de caractères, caractères répétitifs, modèles de clavier (c'estàdire :
"aaaa", "12345", "abcde", "zaq12wsx".
g) Permutations de tout ce qui précède. Par exemple, un mot du dictionnaire dont les voyelles
ont été remplacées par des chiffres (par exemple : f00t) ou auquel des chiffres sont ajoutés
à la fin.
1
Pour plus d'informations sur la création et l'utilisation des mots de passe, voir Annexe V – Règles de
Création et utilisation des mots de passe, du Guide CCNSTIC 821.
94. Si, au contraire, les mots de passe sont générés de manière aléatoire ou pseudoaléatoire, ils
doivent avoir une sécurité suffisante pour éviter les répétitions ou les hypothèses sur leur
éventuelle valeur.
5.4.2. PROTOCOLES D'AUTHENTIFICATION
95. En ce qui concerne les protocoles d'authentification, les suivants seront acceptables :
a) Kerberos.
b) RADIUS (Remote Authentication DialIn User Server) avec EAPTLS.
c) WPA3 (accès WiFi protégé).
5.5 MÉCANISMES D'AUTHENTIFICATION (UTILISATEURS INTERNES)
[OP.ACC.6]
96. Pour l'authentification des utilisateurs internes, c'estàdire le personnel de l'organisation elle
même ou sous contrat pouvant avoir accès aux informations contenues dans le système dans
le cadre de l'ENS, les méthodes d'authentification suivantes seront envisagées :
e) Mot de passe (1 facteur "quelque chose qui est connu") : Orienté vers les systèmes de
catégories BASIC, il consiste en une chaîne de caractères alphanumériques utilisée
comme mécanisme d'authentification. Pour ces mots de passe, une robustesse, une
périodicité minimale et un nombre de tentatives d'authentification infructueuses sont
définis, après quoi le système doit :
1. Bloquer et demander une intervention spécifique pour réactiver le
compte
2. Inclure un délai croissant entre les tentatives d'authentification, de sorte que
afin d'éviter les attaques d'authentification par force brute.
f) Mots de passe + OTP (2 facteurs : "quelque chose que vous savez" + "quelque chose que
vous avez") : en plus d'utiliser un mot de passe, ce mécanisme nécessitera un mot de
passe à usage unique (OTP) en complément.
g) Les certificats qualifiés (selon les dispositions du Règlement eIDAS), dont l'utilisation est
protégée par un second facteur, de type PIN ("quelque chose que vous avez" + quelque
chose que vous savez") ou biométrique ("quelque chose que vous avez" + " quelque
chose qui est »). De plus, les informations d'identification utilisées doivent avoir été
obtenues après une précédente inscription en personne ou par voie électronique, à l'aide
d'un certificat électronique qualifié.
h) Certificats qualifiés dans un dispositif physique permettant la création d'une signature
qualifiée. L'utilisation du certificat sera également protégée par un deuxième facteur de
type PIN ("quelque chose que vous avez" + quelque chose que vous savez") ou
biométrique ("quelque chose que vous avez" + "quelque chose que vous êtes"). Les
informations d'identification utilisées doivent avoir été obtenues après une précédente
inscription en personne ou par voie électronique, à l'aide d'un certificat électronique qualifié.
97. Contrairement aux utilisateurs externes [OP.ACC.5], les identifiants d'authentification des entités,
utilisateurs ou processus internes n'ont pas besoin d'être
ont été identifiés et enregistrés de manière fiable dans le système ou auprès d'un fournisseur de
services de confiance qualifié ou d'un fournisseur d'identité électronique reconnu par les administrations
publiques, bien que devant l'organisme qui, à ces fins, a été déterminé par l'organisation utilisatrice.
98. Différents niveaux de sécurité seront envisagés pour les mécanismes de
l'authentification des utilisateurs internes, en fonction du niveau de sécurité maximal requis par le
système pour l'une des dimensions de Confidentialité [C], Intégrité [I], Traçabilité [T] ou Authenticité
[A]. Le tableau suivant présente les méthodes d'authentification recommandées pour chacun des
niveaux, ainsi que les exigences de robustesse pour chacun d'eux :
Méthodes
d'authentification Exigences
autorisé
Niveau BAS (1 ou L'accès doit provenir d'une "zone contrôlée",
2 facteurs) c'estàdire non accessible au public, et que
l'utilisateur, avant d'y accéder
à l'équipement, a été préalablement authentifié
d'une manière (facility access control), différente
du mécanisme d'authentification.
authentification logique par rapport au système
mots de passe
maximum.
précédents.
maximum.
Mots de passe + OTP
Nombre maximum de tentatives
d'authentification infructueuses : 5
précédent.
Résistance minimale des mécanismes
Certificats
Nombre maximal de tentatives
Certificats en
appareil physique L'utilisation d' algorithmes hérités est autorisée.
Nombre maximal de tentatives
Niveau MOYEN (2 Longueur minimale du mot de passe 12
facteurs) caractères avec un minimum de trois
différents types.
Interdiction de réutiliser 10
mots de passe précédents.
Certificats + pin
autorisée.
biométrique
alphanumériques.
d'authentification infructueuses : entre 10 et 5
Certificats sur Résistance minimale des mécanismes :
appareil physique + pin cryptographique : 128.
ou biométrique
autorisée.
alphanumériques.
d'authentification infructueuses : entre 10 et 5
Niveau ÉLEVÉ (2 Longueur minimale du mot de passe 12
facteurs) caractères avec un minimum de trois
différents types.
infructueuses : 3
Interdiction de réutiliser 10
mots de passe précédents.
128.
Certificats autorisée.
alphanumériques.
128.
Certificats en L'utilisation d'algorithmes est autorisée
dispositif physique + Recommandé.
code PIN ou biométrique
alphanumériques.
Tableau 53. [op.acc.6] Exigences d'authentification pour les utilisateurs internes.
5.5.1. PROTOCOLES D'AUTHENTIFICATION
99. En ce qui concerne les protocoles d'authentification, les systèmes suivants seront acceptables :
a) Kerberos
b) RADIUS (en francés, Remote Authentication DialIn User Server) avec EAPTLS.
c) WPA3 (accès WiFi protégé).
5.6 PROTECTION DES CLÉS CRYPTOGRAPHIQUES [OP.EXP.10]
100. Les clés cryptographiques, quelle que soit la sécurité qu'elles offrent, seront protégées tout au
long de leur cycle de vie. Cela signifie que les mesures de sécurité nécessaires doivent être
arbitrées à la fois dans le processus de génération des clés, ainsi que dans leur transport
jusqu'au point d'exploitation, dans leur garde pendant le temps de leur utilisation et dans leur
stockage ultérieur après leur vie active. .. jusqu'à sa destruction définitive.
101. Dans la mesure du possible, on s'assurera que les appareils portables ne stockent pas les clés
d'accès à distance, c'estàdire celles qui permettent d'accéder aux propres équipements de
l'Organisation ou à ceux d'autres organisations apparentées.
102. Il est recommandé que, dans le cas où il est nécessaire de stocker des clés sur des ordinateurs
portables ou d'autres appareils amovibles, cellesci soient à leur tour cryptées par d'autres clés
que seul le propriétaire de la solution qui les a stockées est capable de générer et d'utiliser.
103. En général, les processus de génération de clés doivent être isolés des
moyen d'exploitation. De même, les clés archivées pour avoir été retirées et en attente d'être
détruites, doivent également être stockées dans des dispositifs isolés de ceux d'exploitation.
104. Le tableau suivant montre la force minimale des mécanismes cryptographiques requis pour l'accès
aux processus de génération, de transport, de conservation et de stockage des clés selon la
catégorie ENS des informations que le système gérera.
BASIQUE 112
112 ou 128, selon le cas
Catégorie ENS MÉDIAS en fonction du niveau de
menace
HAUT 128
Tableau 54. [op.exp.10] Solidité des mécanismes et sécurité équivalente des clés
105. En outre, pour les systèmes de catégorie MOYENNE et ÉLEVÉE, les outils ou dispositifs
cryptographiques figurant dans le catalogue des produits et services de sécurité TIC (ciaprès,
CPSTIC) disponible dans le guide CCNSTIC 105 seront utilisés, conformément aux dispositions
de l'ENS. ([op.pl.5] Composants certifiés)
5.7 PROTECTION DE LA CONFIDENTIALITÉ. [MP.COM.2]
106. La confidentialité des informations consiste à conserver lesdites informations
secret pour tous sauf ceux autorisés à le savoir.
107. Pour maintenir la confidentialité des informations, des réseaux privés virtuels ou des canaux d'accès
sécurisés seront utilisés lorsque la communication passe par des réseaux extérieurs au domaine de
sécurité luimême. Seront notamment utilisés les protocoles IPsec (en anglais, Internet Protocol Security)
et TLS (en anglais, Transport Layer Security) .
108. IPsec est un protocole qui permet de protéger les communications sur un réseau IP, de sorte que chacun
des paquets de données transmis soit crypté et authentifié. Comme IPsec inclut des protocoles
d'établissement de clés de chiffrement, ceuxci doivent garantir, au minimum, une sécurité équivalente à
la puissance des mécanismes requis.
109. Pour sa part, TLS (successeur de SSL, c'est pourquoi les VPN avec ce protocole sont encore appelés VPN
SSL), est un protocole cryptographique qui assure l'authenticité et la confidentialité dans un réseau, c'est
àdire des communications sécurisées, en utilisant des méthodes cryptographiques. Par défaut, dans ces
protocoles, seul le serveur est authentifié, laissant le client non authentifié. Comme pour IPsec, les clés
utilisées dans ces protocoles doivent avoir un niveau de sécurité équivalent à la force du mécanisme
requis.
110. Pour les catégories MOYENNE et ÉLEVÉE de l'ENS, seront utilisés les produits présents dans le CPSTIC,
conformément aux dispositions de l'ENS (composants certifiés [op.pl.5]). De plus, pour la catégorie HIGH,
des dispositifs matériels seront de préférence utilisés pour établir lesdits VPN.
111. Le tableau suivant présente la robustesse minimale requise pour les mécanismes cryptographiques
autorisés (Legacy/Recommended) qui sont utilisés, en tenant compte du niveau de menace considéré et
du niveau de confidentialité [C] requis par le système pour les informations transmises.
niveau de menace
BAS MOITIÉ HAUT
BAS N / A N / A N / A

Niveau de
112 (L) 112 (L)
MOITIÉ 128 (R)
ENS de sécurité 128 (R) 128 (R)
[C] 112 (L)
HAUT 128 (R) 128 (R)
128 (R)
Tableau 55. [mp.com.2] Bastion des mécanismes autorisés
112. Comme nous l'avons vu dans la section 3, un niveau de sécurité équivalent à 112 bits est
se traduit par :
a) Clés de 112 bits (ou plus) pour les systèmes de chiffrement symétriques.
b) des clés de longueur 2048 bits (ou plus) pour le cryptosystème RSA.
c) des clés de longueurs comprises entre 224 et 255 bits pour
cryptosystèmes basés sur des courbes elliptiques.
113. Un niveau de sécurité équivalent à 128 bits suppose l'utilisation de :
a) Clés de 128 bits (ou plus) pour le système de chiffrement symétrique AES.
b) des clés entre 256 et 283 bits pour les systèmes basés sur des courbes elliptiques.
c) des clés d'au moins 3072 bits pour le cryptosystème RSA.
5.8 PROTECTION DE L'AUTHENTICITÉ ET DE L'INTÉGRITÉ [MP.COM.3]
114. L'authenticité de l'information s'entend comme la corroboration de la source de l'information, c'està
dire la vérification que la personne qui l'a préparée ou l'expéditeur de l'information est bien celle
qu'elle prétend être. Pour sa part, l'intégrité des informations fait référence à la vérification que les
informations reçues n'ont pas été altérées par des entités non autorisées ou par des moyens
inconnus.
115. Pour tout niveau de sécurité requis, au moins l'authenticité sera assurée afin que d'éventuelles attaques
actives soient empêchées, qui seront, au minimum, détectées.
116. Les attaques actives (par opposition aux attaques passives dans lesquelles la communication n'est
surveillée que pour obtenir des informations d'elle ou de ce qui y est échangé) sont considérées
comme des attaques dans lesquelles les informations en transit sont altérées, les informations
trompeuses sont inséré, ou détournement de session par un tiers.
117. Pour les catégories MOYENNE et ÉLEVÉE de l'ENS, seront utilisés les produits présents dans le
CPSTIC, conformément aux dispositions de l'ENS (composants certifiés [op.pl.5]). De plus, pour la
catégorie ÉLEVÉE, les dispositifs matériels seront de préférence utilisés pour établir des Réseaux
Privés Virtuels.
118. Le tableau suivant présente la robustesse minimale requise pour les mécanismes cryptographiques
autorisés (Legacy/Recommended) qui sont utilisés, en tenant compte du niveau de menace considéré
et du niveau de sécurité maximal requis par le système pour les dimensions d'intégrité et d'authenticité
des les informations transmises.
niveau de menace
BAS MOITIÉ HAUT
112 (L) 112 (L) 112 (L)

BASIQUE
128 (R) 128 (R) 128 (R)
Niveau maximum
112 (L) 112 (L)
Intégrité [I] et MOITIÉ 128 (R)
128 (R) 128 (R)
authenticité [A]
112 (L)
HAUT 128 (R) 128 (R)
128 (R)
Tableau 56. [mp.com.3] Mécanisme Forteresse
5.9 CRYPTOGRAPHIE [MP.SI.2] ET PROTECTION DES EQUIPEMENTS PORTATIFS
[MP.EQ.3]
119. Chiffrer une information consiste à la transformer de telle sorte qu'elle devienne inintelligible à tous sauf aux
entités autorisées à y accéder. En général, l'accès à l'information d'origine à partir de sa version cryptée
s'effectue grâce à l'utilisation de clés et d'algorithmes.
120. La mesure [mp.si.2] s'applique notamment à tous les appareils amovibles. Par supports amovibles, on
entend les CD, DVD, disques amovibles, clés USB, mémoires USB ou autres de nature similaire. La
mesure [mp.eq.3] s'applique aux équipements (ordinateurs portables, tablettes, etc.) susceptibles de
quitter les installations de l'organisation et ne pouvant bénéficier de la protection physique correspondante,
avec un risque manifeste de perte ou de vol.
121. Pour les catégories MOYEN et ÉLEVÉ de l' ENS , les produits de chiffrement hors ligne ou au repos trouvés
dans le CPSTIC seront utilisés, conformément aux dispositions de l'ENS (composants certifiés [op.pl.5 ]).
122. Le tableau cidessous indique la robustesse minimale des mécanismes cryptographiques requise, compte
tenu du niveau de menace considéré et du niveau maximal de sécurité requis par le système à l'égard
des informations stockées sur des supports ou des dispositifs portables dans les dimensions d'intégrité
[I ] et confidentialité [C].
niveau de menace
BAS MOITIÉ HAUT
BASIQUE N / A N / A N / A

Niveau maximum
112 (L) 112 (L)
MOITIÉ 128 (R)
Intégrité [I] et 128 (R) 128 (R)
Confidentialité [C] 112 (L)
HAUT 128 (R) 128 (R)
128 (R)
Tableau 57. [mp.si.2] Force des mécanismes
123. Il est important de noter que le niveau de menace faible ne sera pris en compte que dans le cas où les
supports et appareils portables ne sont accessibles que
par du personnel interne et autorisé, pour lequel des mesures de surveillance complémentaires
spécifiques doivent être établies pour lesdits appareils, étant donné que, de par leur nature, les supports
et les appareils portables sont exposés à un niveau de menace élevé, notamment en dehors du périmètre
physique de l'Organisation .
124. Ces mêmes considérations, bien que les mesures de contrôle mises en œuvre soient moins contraignantes,
seraient applicables pour le niveau de menace moyen, dans lequel on considère que les supports et
appareils portables ne sont accessibles que par les utilisateurs internes et autorisés dans le périmètre de
l'Organisation .
5.10 SIGNATURE ÉLECTRONIQUE [MP.INFO.3]
125. Une signature électronique, telle que définie dans le règlement eIDAS, est une donnée au format
électronique jointe à d'autres données électroniques ou
logiquement avec eux que le signataire utilise pour signer et dont le but est de lier solidement
des informations électroniques à une entité, c'estàdire le signataire, lorsque la volonté et le
consentement de l'intéressé doivent être accrédités
concernant le contenu. De cette façon, la signature électronique empêche le fait qu'un signataire
puisse répudier être l'auteur de l'information signée, en plus du fait que cela, lorsqu'il est fait
d'une certaine manière, permet de garantir l'intégrité du contenu signé.
126. Différents niveaux de sécurité seront envisagés pour les types de signature électronique, en
fonction du niveau de sécurité maximal requis par le système pour l'une quelconque des
dimensions Intégrité [I] ou Authenticité [A]. Le tableau suivant présente les types de signatures
autorisées pour chacun des niveaux, ainsi que les exigences de robustesse pour chacun d'eux :
Types de signature autorisés Exigences
Tout type de signature
électronique prévu
par la législation en vigueur,
La force minimale des mécanismes
y compris les systèmes de
utilisés doit être de 112 bits et ils
code de vérification sécurisés
peuvent être hérités [L] ou
liés à l'Administration
recommandés [R].
En ce sens, les protocoles de signature
Public, organisme,
électronique utiliseront
Niveau organisme public ou
certificats numériques avec :
BAS personne morale
a) Clés RSA (du signataire) d'au
public, dans les termes et
moins 2048 bits.
conditions établis dans la loi
b) Clés de 224 à 255 bits si des
39/2015, du 1er octobre, sur
courbes elliptiques sont utilisées.
la procédure
c) Fonctions de hachage SHA256 ou
Administratif Commun des
supérieures .
Administrations
Public et dans la loi
40/2015, du 1er octobre
Types de signature autorisés Exigences
Les certificats utilisés doivent
être qualifié.
Les mécanismes utilisés doivent être
autorisés et avoir une force minimale
de 112 bits.
En ce sens, les protocoles de signature
électronique utiliseront
certificats numériques avec :
a) Clés RSA (du signataire) d'au
Une signature
moins 2048 bits.
électronique qualifiée sera utilisée
b) Clés de 224 à 255 bits si des
incorporant des certificats
Niveau courbes elliptiques
qualifiés, conformément aux
MOITIÉ sont utilisées.
dispositions de la
([I] ou [A]) c) Fonctions de hachage SHA256
Règlement eIDAS et les
ou supérieures .
dispositions des lois
Le cas échéant, la vérification et la
39/2015 et 40/2015.
validation de la signature électronique
seront garanties pendant le temps
requis par l'activité administrative
qu'elle supporte.
A cet effet, toutes les informations pertinentes
pour sa vérification et sa validation seront
jointes à la signature, ou référencées, y
compris les certificats ou les données de
vérification et de validation.
Les mécanismes utilisés doivent être
recommandés et avoir une force minimale
de 128 bits.
Comme établi dans [op.pl.5], les
Une signature produits inclus dans le CPSTIC seront
électronique qualifiée sera utilisée utilisés.
intégrant des certificats qualifiés Le cas échéant, la vérification et la
Niveau
et des dispositifs de création validation de la signature électronique
HAUT
qualifiés seront garanties pendant le temps
([I] ou [A])
de signature conformément requis par l'activité administrative
aux dispositions de la qu'elle supporte. A cet effet, toutes les
Règlement eIDAS informations pertinentes pour sa
vérification et sa validation seront jointes
à la signature, ou référencées, y compris
les certificats ou les données de vérification
et de validation.
5.11 Horodateurs [MP.INFO.4]
127. Selon la définition donnée par le règlement eIDAS, un horodatage électronique est une donnée au
format électronique qui relie d'autres données au format électronique à un instant précis, apportant la
preuve que ces dernières existaient à cet instant. Ainsi, à des fins pratiques, les horodatages sont
l'attribution par voie électronique d'une date et d'une heure à un document électronique, avec
l'intervention d'un prestataire de service de certification, qui assure l'exactitude et l'intégrité de
l'horodatage du document auquel il est attaché, de sorte que ledit document ne peut être répudié
après le moment où le scellement est effectué.
128. Différents niveaux de sécurité seront envisagés en fonction du niveau requis pour la dimension
Traçabilité [T]. Le tableau suivant présente les exigences minimales établies pour chacun de ces
niveaux :
Exigences d'horodatage
Niveau BAS [T] Ne s'applique pas
Niveau MOYEN [T] Ne s'applique pas
Les produits certifiés seront utilisés conformément aux
dispositions de l'ENS ([op.pl.5] Composants certifiés).
Des « horodatages électroniques qualifiés » seront utilisés
conformément aux dispositions du
Règlement eIDAS.
Des mécanismes de signature électronique seront utilisés
recommandée et force minimale de 128 bits, c'estàdire :
• RSA d'au moins 3072 bits (bien que 4096 bits soient
Niveau HAUT [T] recommandés).
• Courbes elliptiques avec des clés d'au moins 256 bits.
• Fonctions récapitulatives de celles incluses dans la série
SHA2 ou SHA3 avec une sécurité supérieure ou égale à
SHA256.
Pour les schémas liés, la sécurité repose sur la fonction de
résumé utilisée, par conséquent, l'une des fonctions de la
série SHA2 ou SHA3 avec une sécurité supérieure ou égale
à SHA256 sera utilisée.
5.12 EXEMPLE D'APPLICATION : TLS
129. Un guichet électronique est censé proposer un portail HTTPS permettant aux citoyens d'effectuer des
démarches auprès de l'Administration. Les informations échangées entre le portail web et le citoyen
sont des informations sensibles, et ont des exigences de haut niveau pour les dimensions de
Confidentialité [C], Intégrité [I] et Authenticité [A].
130. L'échange d'informations doit être effectué via un canal de communication, en appliquant les mesures
relatives aux communications : [mp.com.2] et [mp.com.3] à leur niveau HIGH.
131. Cela aura les implications suivantes :
a) Un VPN (IPsec ou TLS) doit être utilisé, mis en œuvre au moyen d'un dispositif matériel certifié
conformément aux dispositions du média [op.pl.5]. Dans ce cas, le protocole TLS sera utilisé, et
pour mettre en œuvre le VPN TLS, par exemple, un équipement qualifié pour un niveau HIGH
ENS dans le catalogue CPSTIC, au sein de la famille "TLS Virtual Networks", pourra être utilisé .
b) Bien que l'ENS n'établisse aucune version de TLS comme obligatoire, il convient d'utiliser les
versions TLS autorisées TLS 1.2 ou TLS 1.3, car les versions antérieures sont considérées
comme non sécurisées.
c) Les mécanismes cryptographiques que le protocole TLS utilisera doivent être parmi ceux autorisés
dans ce guide, et doivent fournir un niveau de sécurité équivalent à 128 bits. Pour cela:
• Sélectionnez une suite de chiffrement TLS appropriée (voir Tableau 41 et Tableau
42)
• Vérifiez que l'implémentation TLS utilise des schémas cryptographiques autorisés et des
longueurs de clé qui fournissent les 128 bits de sécurité.
132. Il existe de nombreuses suites de chiffrement TLS 1.2 qui répondent à ces exigences. Par exemple,
une suite de chiffrement appropriée serait :
où ECDHE est utilisé pour l'accord de clé, AES256 en mode GMC est utilisé pour le chiffrement,
l'intégrité et l'authentification d'origine et SHA384 comme fonction de hachage pour PRF (fonction
pseudoaléatoire).
133. D'autres mesures ENS qui pourraient s'appliquer à cet exemple sont :
a) [op.acc.1] et [op.acc.5] qui s'appliqueraient à l'identification et à l'authentification des citoyens
sur le portail web. Dans le cas où l'un des facteurs d'authentification utilise des mécanismes
cryptographiques, il doit figurer parmi ceux autorisés.
b) [op.exp.11] qui s'appliquerait à la protection de la clé privée du serveur HTTPS et également du
client dans le cas où il est authentifié via certificat,
ou par d'autres mécanismes cryptographiques. Pour la protection de ces
clés, des mécanismes cryptographiques autorisés doivent être utilisés, tels
que Key Wrapping dans la section 3.10 ou toute autre combinaison de
mécanismes autorisés (par exemple, des mécanismes AEAD).
6. RÉFÉRENCES
[1] American National Standards Institute, ANSI X9.30 Public Key Cryptography for the Financial Services
Industry: Part 1: the Digital Signature Algorithm (DSA),
1997.
[2] American National Standards Institute, ANSI X9.42 Accord des clés symétriques
Utilisation de la cryptographie logarithmique discrète, 2005.
Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA), 2005.
Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography, 2011.
[5] Organisation internationale de normalisation, ISO/CEI 10116 Technologies de l'information —
Techniques de sécurité — Modes de fonctionnement pour un chiffrement par blocs de n bits, 2017.
[6] Organisation internationale de normalisation, ISO/IEC 101183 Techniques de sécurité informatique
— Fonctions de hachage — Partie 3 : Fonctions de hachage dédiées, 2018.
[7] Organisation internationale de normalisation, ISO/CEI 117703 Sécurité de l'information — Gestion
des clés — Partie 3 : Mécanismes utilisant des techniques asymétriques, 2021.
[8] Organisation internationale de normalisation, ISO/IEC 148883 Techniques de sécurité informatique
— Signatures numériques avec appendice — Partie 3 : Mécanismes basés sur un logarithme
discret, 2018.
Techniques de sécurité — Algorithmes de chiffrement — Partie 2 : chiffrements
asymétriques, 2006.
Techniques de sécurité — Algorithmes de chiffrement — Partie 3 : Chiffrements par blocs, 2010.
[11] Organisation internationale de normalisation, ISO/CEI 180333:2010
Technologies de l'informationTechniques de sécuritéAlgorithmes de chiffrementPartie 3 : Chiffrements
par blocs, 2010.
[12] Organisation internationale de normalisation, Informations ISO/CEI 19772
sécurité — Chiffrement authentifié, 2020.
technologie — Techniques de sécurité — Schémas de signature numérique permettant la récupération
de message — Partie 2 : Mécanismes basés sur la factorisation d'entiers, 2010.
technologie — Techniques de sécurité — Codes d'authentification de message (MAC) —
Partie 1 : Mécanismes utilisant un chiffrement par bloc, 2011.
sécurité — Codes d'authentification de message (MAC) — Partie 2: Mécanismes utilisant une fonction de
hachage dédiée, 2021.
[16] Institut des ingénieurs électriciens et électroniciens, norme IEEE 13632000
Spécifications pour la cryptographie à clé publique, 2000.
[17] Institute of Electrical and Electronics Engineers, IEEE 16192018 Cryptographic Protection of Data on Block
Oriented Storage Devices, 2018.
[18] National Institute of Standards and Technology, Federal Information Processing Standards Publication 180.
Secure Hash Standard (SHS), 2015.
[19] National Institute of Standards and Technology, Special Publication 80038C Recommendation for Block
Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality, 2007.
[20] National Institute of Standards and Technology, Special Publication 80038F Recommendation for Block
Cipher Modes of Operation: Methods for Key Wrapping, 2012.
[21] National Institute of Standards and Technology, Publication spéciale 80056A Recommendation for Pair
Wise KeyEstablishment Schemes Using Discrete Logarithm Cryptography, 2018.
[22] Institut national des normes et de la technologie, Publication spéciale 80056B Recommandation pour
l'établissement de clés par paires à l'aide de la cryptographie à factorisation d'entiers, 2020.
[23] Institut national des normes et de la technologie, publication spéciale 80038A
Recommandation pour les modes de fonctionnement du chiffrement par blocs, 2001.
[24] Institut national des normes et de la technologie, publication spéciale 80038E
Recommandation pour les modes de fonctionnement du chiffrement par blocs : le mode XTSAES pour la
confidentialité sur les périphériques de stockage, 2010.
[25] Institut national des normes et de la technologie, publication spéciale 80038D
Recommandation pour les modes de fonctionnement du chiffrement par blocs : Galois/Counter Mode
(GCM) et GMAC, 2007.
[26] Institut national des normes et de la technologie, publication spéciale 800208
Recommandation pour les schémas de signature basés sur le hachage avec état, 2020.
[27] National Institute of Standards and Technology, Special Publication 800132 Recommendation for
PasswordBased Key Derivation Part 1: Storage Applications, 2010.
[28] National Institute of Standards and Technology, Special Publication 800108 Recommendation for Key
Derivation Using Pseudorandom Functions, 2009.
[29] Institut national des normes et de la technologie, publication spéciale 80056B
Recommandation pour l'établissement de clés par paires à l'aide de la cryptographie par factorisation
d'entiers, 2019.
[30] Institut national des normes et de la technologie, Federal Information Processing Standards198. Le code
d'authentification de message de hachage à clé (HMAC), 2008.
[31] Institut national des normes et de la technologie, traitement de l'information fédéral
Normes 186. Norme de signature numérique (DSS), 2013.
[32] Institut national des normes et de la technologie, Federal Information Processing Standards 197.
Advanced Encryption Standard (AES), 2001.
[33] Institut national des normes et de la technologie, traitement de l'information fédéral
Publication de normes 202. Norme SHA3 : Fonctions de hachage et de sortie extensibles
basées sur la permutation, 2015.
[34] Groupe des normes pour une cryptographie efficace, SEC 1 : Cryptographie à courbe elliptique,
2009.
[35] H. Krawczyk, M. Bellare et R. Canetti, RFC 2104 HMAC : KeyedHashing for Message
Authentication, Internet Engineering Task Force (IETF), 1997.
[36] J. Schaad et R. Housley, RFC 3394 Advanced Encryption Standard (AES) Key Wrap
Algorithme, Internet Engineering Task Force (IETF), 2002.
[37] J. Jonsson et B. Kaliski, RFC 3447 PublicKey Cryptography Standards (PKCS) #1 : RSA
Cryptography Specifications Version 2.1, Internet Engineering Task Force (IETF), 2003.
[38] K. Igoe et J. Solinas, RFC 5647 AES Galois Counter Mode for the Secure Shell Transport
Layer Protocol, Internet Engineering Task Force (IETF) , 2009.
[39] T. Ylonen et C. Lonvick, RFC 4253 Le protocole de couche de transport Secure Shell (SSH),
Groupe de travail sur l'ingénierie Internet (IETF), 2006.
[40] M. Lochter et J. Merkle, RFC 5639 Cryptographie à courbe elliptique (ECC) Brainpool
Courbes standard et génération de courbes, Internet Engineering Task Force (IETF), 2010.
[41] T. Dierks et E. Rescorla, RFC 5246 La version 1.2 du protocole TLS (Transport Layer
Security), Internet Engineering Task Force (IETF), 2008.
[42] M. Friedl, N. Provos et W. Simpson, RFC 4419 DiffieHellman Group Exchange for the Secure
Shell (SSH) Transport Layer Protocol, Internet Engineering Task Force (IETF), 2006.
[43] D. Harkins, RFC 5297 Vecteur d'initialisation synthétique (SIV) authentifié
Chiffrement à l'aide de la norme de chiffrement avancée (AES), Internet Engineering Task Force
(IETF), 2008.
[44] T. Kivinen et M. Kojo, RFC 3526 More Modular Exponential (MODP) Groupes DiffieHellman pour
Internet Key Exchange (IKE), Internet Engineering Task Force (IETF), 2003.
[45] T. Kohno et C. Namprempre, RFC 4344 Les modes de cryptage de la couche de transport
Secure Shell (SSH), Internet Engineering Task Force (IETF), 2006.
[46] R. Housley et M. Dworkin, RFC 5649 Advanced Encryption Standard (AES) Key Wrap with
Padding Algorithm, Internet Engineering Task Force (IETF), 2009.
[47] D. Stebila et J. Green, RFC 5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport
Layer, Internet Engineering Task Force (IETF), 2009.
[48] K. Igoe et D. Stebila, RFC 6187 X.509v3 Certificates for Secure Shell Authentication, Internet
Engineering Task Force (IETF) , 2011.
[49] D. Bider et M. Baushke, RFC 6668 SHA2 Data Integrity Verification for the Secure Shell (SSH)
Transport Layer Protocol, Internet Engineering Task Force (IETF), 2012.
[50] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen et T. Kivinen, RFC 7296 Internet Key Exchange
Protocol Version 2 (IKEv2), Internet Engineering Task Force (IETF), 2014.
[51] M.J. Saarinen et J.P. Aumasson, RFC 7693 The BLAKE2 Cryptographic Hash and Message
Authentication Code (MAC), Internet Engineering Task Force (IETF) , 2015.
[52] A. Langley, W. Chang, N. Mavrogiannopoulos, J. Strombergson et S. Josefsson, RFC
7905 ChaCha20Poly1305 Cipher Suites for Transport Layer Security (TLS), Internet
Engineering Task Force (IETF), 2016.
[53] C. Percival et S. Josefsson, RFC 7914 The scrypt PasswordBased Key Derivation Function,
Internet Engineering Task Force (IETF), 2016.
[54] K. Moriarty, B. Kaliski, J. Jonsson et A. Rusch, RFC 8017 PKCS #1 : RSA Cryptography Specifications
Version 2.2, Internet Engineering Task Force (IETF), 2016.
[55] K. Moriarty, B. Kaliski et A. Rusch, RFC 8018 PKCS #5 :
Spécification de cryptographie version 2.1, Groupe de travail d'ingénierie Internet (IETF) ,
2017.
[56] M. Baushke, RFC 8268 Plus d'exponentiation modulaire (MODP) DiffieHellman
(DH) Groupes d'échange de clés (KEX) pour Secure Shell (SSH), Internet Engineering Task Force
(IETF), 2017.
[57] D. Bider, RFC 8332 Utilisation des clés RSA avec SHA256 et SHA512 dans le protocole Secure
Shell (SSH), Internet Engineering Task Force (IETF), 2018.
[58] A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld et A. Mohaisen, RFC 8391 XMSS : eXtended
Merkle Signature Scheme, Internet Engineering Task Force (IETF), 2018.
[59] Y. Nir et A. Langley, RFC 8439 ChaCha20 et Poly1305 pour les protocoles IETF, Internet
Groupe de travail d'ingénierie (IETF), 2018.
[60] National Institute of Standards and Technology, Publication spéciale 800131A Transitioning
the Use of Cryptographic Algorithms and Key Lengths, 2019.
[61] Ministère de la Présidence, Décret Royal 3/2010, du 8 janvier, réglementant le Régime, "BOE"
no. 25, du 29 janvier 2010 Référence : BOEA 20101330, 2010.

807-Criptologia de Empleo ENS

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

807-Criptologia de Empleo ENS

Transféré par

Droits d'auteur :

Formats disponibles

Machine Translated by Google

ISO/CEI NIST SP800­ 128 128

primitif Taille du paramètre (bits) CHAT

primitif Groupe CHAT

Famille Courbe CHAT

SHA3­256 FIPS 202 1088 256 128 R

SHA3­384 FIPS 202 832 384 192 R

SHA3­512 FIPS 202 576 512 256 R

BLAKE2s/BLAKE2b RFC7693 512/1024 >=256 >128 R1

Genre de Force Longueur de

PKCS#1v2.2 (RFC 8017), 112 2048 L

ECIES 112 224 L

AES 192 192

NIST 800­56A­KDF NIST SP 800­56A Fonction récapitulative (hachage)1 R

NIST 800­56C­KDF NIST SP 800­56C Schéma MAC2 R

NIST 800­108 NISTSP 800­108 HMAC / CMAC R

SCRYPTE RFC7914 HMAC2 R

Mécanisme de protection des clés / Force Longueur de

Version SSH Standard CHAT

aes128­cbc AES en mode CBC ­ Clé 128 bits RFC4253 128 L1

aes192­cbc AES en mode CBC ­ Clé 192 bits RFC4253 192 L1

aes256­cbc AES en mode CBC ­ Clé 256 bits RFC4253 256 L1

aes128­ctr AES en mode CTR ­ clé 128 bits RFC4344 128 R1

aes192­ctr AES en mode CTR ­ Clé 192 bits RFC4344 192 R1

aes256­ctr AES en mode CTR ­ clé 256 bits RFC4344 256 R1

AEAD_AES_128_GCM Clé AES GCM ­128 bits RFC5647 128 R

AEAD_AES_256_GCM Clé AES GCM ­ 256 bits RFC5647 256 R

SSH ­ Algorithme de clé publique Composition Standard Force CHAT

hmac­sha1 HMAC avec SHA­1 ­ clé 160 bits RFC4253 >128 L

hmac­sha1­96 HMAC avec SHA­1 ­ clé 160 bits RFC4253 >128 L

Protocole Standard modes recommandés CHAT

Protocole Standard modes recommandés CHAT

14 Groupe MODP 2048 bits RFC 3526 112 L

15 Groupe MODP 3072 bits RFC 3526 128 R

16 Groupe MODP 4096 bits RFC 3526 >128 R

17 Groupe MODP 6144 bits RFC 3526 >128 R

18 Groupe MODP 8192 bits RFC 3526 >128 R

19 Groupe ECP aléatoire de 256 bits RFC 5903 128 R

20 groupe ECP aléatoire de 384 bits RFC 5903 >128 R

21 Groupe ECP aléatoire de 521 bits RFC 5903 >128 R

28 brainpoolP256r1 RFC 6954 128 R

29 brainpoolP384r1 RFC 6954 >128 R

30 brainpoolP512r1 RFC 6954 >128 R

31 x 25519 RFC 8031 128 R

32x448 RFC 8031 >128 R

Standard Standard Force Longueur de

AUTH_HMAC_SHA2_256_128 RFC 4868 256 ≥128 R

AUTH_HMAC_SHA2_384_192 RFC 4868 384 ≥128 R

AUTH_HMAC_SHA2_512_256 RFC 4868 512 ≥128 R

AUTH_AES_CMAC_963 RFC 4494 128 128 R

Standard Longueur de Force

PRF_HMAC_SHA1 RFC2104 ≥100 112 L

PRF_AES128_CMAC RFC 4615 128 128 R

Standard Longueur de Force

ECDSA avec SHA­256 sur la courbe P­256 RFC 4754 256 128 R

ECDSA avec SHA­384 sur la courbe P­384 RFC 4754 384 192 R

ECDSA avec SHA­512 sur la courbe P­521 RFC 4754 512 256 R

ECDSA­256 avec BrainpoolP256r1 RFC 7427 256 128 R

ECDSA­384 avec BrainpoolP384r1 RFC 7427 384 192 R

Standard Longueur de Force

ECDSA­512 avec BrainpoolP512r1 RFC 7427 512 256 R

ECGDSA­256 avec BrainpoolP256r1 RFC 7427 256 128 R

ECGDSA­384 avec BrainpoolP384r1 RFC 7427 384 192 R

ECGDSA­512 avec BrainpoolP512r1 RFC 7427 512 256 R

ISO/CEI NIST SP800 128 128

SHA3256 FIPS 202 1088 256 128 R

SHA3384 FIPS 202 832 384 192 R

SHA3512 FIPS 202 576 512 256 R

NIST 80056AKDF NIST SP 80056A Fonction récapitulative (hachage)1 R

NIST 80056CKDF NIST SP 80056C Schéma MAC2 R

NIST 800108 NISTSP 800108 HMAC / CMAC R

aes128cbc AES en mode CBC Clé 128 bits RFC4253 128 L1

aes192cbc AES en mode CBC Clé 192 bits RFC4253 192 L1

aes256cbc AES en mode CBC Clé 256 bits RFC4253 256 L1

aes128ctr AES en mode CTR clé 128 bits RFC4344 128 R1

aes192ctr AES en mode CTR Clé 192 bits RFC4344 192 R1

aes256ctr AES en mode CTR clé 256 bits RFC4344 256 R1

AEAD_AES_128_GCM Clé AES GCM 128 bits RFC5647 128 R

AEAD_AES_256_GCM Clé AES GCM 256 bits RFC5647 256 R

SSH Algorithme de clé publique Composition Standard Force CHAT

hmacsha1 HMAC avec SHA1 clé 160 bits RFC4253 >128 L

hmacsha196 HMAC avec SHA1 clé 160 bits RFC4253 >128 L

ECDSA avec SHA256 sur la courbe P256 RFC 4754 256 128 R

ECDSA avec SHA384 sur la courbe P384 RFC 4754 384 192 R

ECDSA avec SHA512 sur la courbe P521 RFC 4754 512 256 R

ECDSA256 avec BrainpoolP256r1 RFC 7427 256 128 R

ECDSA384 avec BrainpoolP384r1 RFC 7427 384 192 R

ECDSA512 avec BrainpoolP512r1 RFC 7427 512 256 R

ECGDSA256 avec BrainpoolP256r1 RFC 7427 256 128 R

ECGDSA384 avec BrainpoolP384r1 RFC 7427 384 192 R

ECGDSA512 avec BrainpoolP512r1 RFC 7427 512 256 R