gestion des clés cryptographiques€¦ · L’objectif de la présente annexe est de présenter le...

RÈGLES ET RECOMMANDATIONS CONCERNANT LA GESTION DES CLÉS CRYPTOGRAPHIQUES UTILISÉES

DANS L’ENSEMBLE DES MÉCANISMES CRYPTOGRAPHIQUES

Annexe à l’Arrêté Ministériel n° 2018-637 du 2 juillet 2018

ANNEXE AU « JOURNAL DE MONACO » N° 8.390

DU 13 JUILLET 2018

JOURNAL DE MONACO Vendredi 13 juillet 20182

TABLE DES MATIÈRES

1 Introduction ..............................................................2

1.1. Contexte ............................................................2

1.1.1. Objectif de l’annexe ...............................2

1.1.2. Positionnement de l’annexe ...................2

1.1.3. Définitiondesrèglesetrecommandations ...2

1.1.4 Mise à jour de l’annexe ...........................3

1.2 Lagestiondecléscryptographiques ................3

1.2.1 Définitionsetconcepts ...........................3

1.2.2 Objectifs de sécurité minimaux .............4

1.3 Typologiedesarchitecturesdegestiondeclés ....5

1.3.1 Cycledeviedescléscryptographiques ....5

1.3.2 Architecturesfonctionnellesdessystèmesutilisateurs ..............................................6

2Règlesetrecommandations ......................................7

2.1 Règlesetrecommandationsgénérales .............7

2.2 Demande de clé ................................................8

2.3 Génération de clé ..............................................8

2.3.1 Génération locale de clé ........................8

2.3.2 Génération centralisée de clé .................8

2.3.3 Générationdeclédesignature ..............8

2.4 Affectation d’une clé ........................................9

2.4.1 Usaged’uneclécryptographique ..........9

2.4.2 Objectifs de sécurité de l’affectation ...10

2.4.3 Objectifssurlepremierenrôlement ....10

2.5 Introduction d’une clé ....................................11

2.5.1 Acheminementdeclé ..........................11

2.5.2 Injection de clé .....................................12

2.5.3 Injectiondeclégénéréepardérivation ...12

2.6 Utilisation d’une clé .......................................13

2.6.1 Diffusion d’une clé ..............................13

2.6.2 Utilisationapplicatived’uneclé ..........13

2.7 Findevied’uneclé ........................................13

2.8 Renouvellementd’uneclé ..............................13

2.9 Recouvrementd’uneclé .................................13

1 Introduction

1.1. Contexte

1.1.1. Objectif de l’annexe

Lasécuritédelaplupartdessystèmesd’informationrepose pour partie sur l’utilisation de fonctionscryptographiques. Ces fonctions ont une sécurité denatureessentiellementmathématiquequireposesurlescaractéristiquesdescléscryptographiquesutilisées.Ceshypothèses peuvent être formalisées par des objectifsde sécurité qui doivent impérativement être respectéspour que les fonctions cryptographiques puissentremplirleurrôle.

Pourquelesfonctionscryptographiquesremplissenteffectivement leur rôle, il est indispensable que leurgestion soit sûre auniveaudu systèmed’information.L’objectif de la présente annexe est de présenter lecycle de vie d’une clé cryptographique et différentesarchitecturesdegestiondecléspossibles.Ilviseaussiàaideràl’élaborationd’unsystèmedegestiondeclés.

1.1.2. Positionnement de l’annexe

Laprésenteannexevientencomplémentdel’annexeà l’arrêté ministériel n° 2018-635 du 2 juillet 2018portant application de l’article 54 de l’OrdonnanceSouverainen°3.413du29août2011portantdiversesmesuresrelativesàlarelationentrel’Administrationetl’administré, modifiée définissant le choix et ledimensionnementdesmécanismescryptographiquesetconcerne.

Elledéfinitlesrèglesetrecommandationsconcernantla gestion des clés utilisées dans les mécanismescryptographiques.

1.1.3. Définitiondesrèglesetrecommandations

Les règlesdéfinissentdesprincipesquidoiventêtresuivispartoutmécanisme.L’observationdecesrèglesest une condition nécessaire à la sécurité du mécanisme. Cependant,lefaitdesuivrel’ensembledesrègles,quisontparnaturetrèsgénériques,n’estpassuffisantpourgarantirlarobustessedumécanismecryptographique;seuleuneanalysespécifiquepermetdes’enassurer.

JOURNAL DE MONACOJOURNAL DE MONACOVendredi 13 juillet 2018 3

À côté des règles, la présente annexe définitégalement des recommandations. Elles ont pour butdeguiderlechoixdecertainesarchitecturesdegestionde clés permettant un gain considérable en termes desécurité, pour un coût souvent modique. Il va de soiqu’entantquerecommandations,leurapplicationpeutêtre plus librement modulée en fonction d’autresimpératifs tels que des contraintes de performance oudecoût.

Il est égalementnécessairede se référer à l’annexede l’arrêté ministériel n° 2018-635 du 2 juillet 2018,précité,définissantles«Mécanismescryptographiques–Règles et recommandations concernant le choix et ledimensionnementdesmécanismescryptographiques»,pourlesdifférenteslimitationsdécritesquis’appliquentaussiàlaprésenteannexe.Ainsi,ilconvientderappelerque les notions, règles et recommandations contenuesdanslaprésenteannexes’adressentàunlecteurfamilierdesconceptsdegestiondeclés.

Lesrèglesetrecommandationssontrepéréesselonlacodification suivante : les premières lettres (Règle ouRecom) indiquent si l’ona affaire àune règleouunerecommandation, le domaine d’application est ensuiteprécisé et, finalement, un chiffre permet de distinguerlesrèglesd’unmêmedomained’application.

1.1.4 Mise à jour de l’annexe

Lamiseàjourdelaprésenteannexeestréaliséeparl’Agence Monégasque de Sécurité Numérique enfonction des évolutions techniques, législatives etrèglementaires en matière de sécurité des systèmesd’information.Laditemiseàjourestpubliéepararrêtéministériel,lequelpréciselesmodalitésdetransitionetdate d’effet.

1.2 Lagestiondecléscryptographiques

1.2.1 Définitionsetconcepts

L’objetdecepointestderappeler lesdéfinitionsetconcepts essentiels en matière de gestion de cléscryptographiquesafindebiencomprendrelesrèglesetrecommandationsémisesdanslaprésenteannexe.

1.2.1.1 Clés secrètes symétriques

Lagestiondes clés peut être plusoumoins simpleselonlesapplications.Danslecontextedemécanismessymétriques, la principale difficulté réside dans ladistribution, ou mise en accord, des clés afin depermettre aux correspondants de partager les mêmessecretsinitiauxsansquedesattaquantspotentielsnelesaient interceptés. Ceci peut être réalisé au moyen detechniquesasymétriquesmodernesmaispeutégalementl’êtreviadesméthodesnoncryptographiquesdenatureorganisationnelle.

Uneduréedeviemaximale,appeléecrypto-période,estdeplusassociéeàchaqueclé.Unetelleduréedeviepeut être représentée par une date limite d’emploi oupar un compteur du nombre d’utilisations qui ne doitpasdépasserunecertainelimite.Unetellelimitationdeladuréedeviedesclésviseengénéralàréduirel’effetd’une éventuelle compromission des clés. Il estimportant de bien comprendre que dans un systèmecryptographiquementbienconçuilnedoitpasyavoirdephénomène«d’usure»descléslimitantleurduréed’utilisation.

Afindeprotégerlescléslorsdeleurstockage,ellespeuvent être elles-mêmes chiffrées avec une autre cléquin’agénéralementpasàêtrepartagée.Ondésigneengénéralsousletermedeclé noireunecléainsichiffrée,paroppositionauxclésrougesquisontenclair.Dansl’acception courante, une clé noire est toutefoisprotégéeavecunniveaudesécuritéaumoinsidentiqueà celui des données qu’elle protège. Or dans certainscas, la protection réalisée sur la clé n’atteint pas ceniveau cryptographique. Par exemple, si la clé estchiffréeà l’aided’unmotdepassedont l’entropieestfaible.Onpourraitdanscecasparlerdeclécamoufléepourdistinguercetypedecasdefigure.

Enfin, il est à noter que dans un cas particulierd’architecture,encoreassezcourant,utilisantunsecretlargementpartagéentreungrandnombred’utilisateurs,la divulgation de telles clés a en général desconséquencesdramatiquesentermesdesécurité.Danscertaines applications, l’usage exclusif de primitivessymétriques rend nécessaire l’emploi de tellesarchitectures ; ceci milite fortement en faveur d’uneutilisation d’architectures asymétriques permettant des’enpasser.

Unemanière simple de résoudre ce problème avecunetechniqueasymétriqueestdefairechoisiràchaquemembre du groupe une bi-clé dont la partie publiqueestcertifiéeparuneautorité.Chaquemembredoitalorsuniquementmémoriser sa bi-clé et la clé publique del’autorité.

1.2.1.2 Bi-clés asymétriques

Lagestiondesclésencryptographieasymétriqueestàlafoisplussimpleetpluscomplexequedanslecassymétrique.Plussimple,maiségalementplussûre,cariln’yaplusbesoindepartagerdessecretsàplusieurs.Ainsi,lacléprivéen’abesoind’êtreconnuequedesonseuldétenteuretenaucuncasdivulguéeàd’autres.Parconséquent, il n’y a en théorie nul besoin de fairegénérerdetellesclésparuntiers.Onpeutparexempletoutàfaitconcevoirqu’unecléprivéesoitgénéréeparune carte à puce et qu’à aucunmoment de la vie dusystème cette clé n’ait à quitter l’enceinte supposéesécurisée de la carte.


Le problème majeur qui se pose réside cependantdanslanécessitéd’associeruneclépubliqueàl’identitédesondétenteurlégitime.Unetellecertificationdeclépubliquepeut êtreeffectuéeaumoyende la signatured’uncertificatparuneautoritéquicertifiedecefaitquetelle clé publique appartient bien à tel individu ouentité.

Seposealorsleproblèmedelavérificationdecettesignature qui va à son tour nécessiter la connaissancede la clé publique de l’autorité.Afinde certifier cetteclé,onpeutconcevoirqu’uneautoritésupérieuregénèreun nouveau certificat, et ainsi de suite. On construitainsiunchemindeconfiancemenantàuneclé racineen laquelle il faut bien finir par avoir confiance. Detelles constructions sont désignées sous le termed’infrastructure de gestion de clés (IGC ou PKI enanglais).

De fait,dansdenombreusesapplicationspratiques,il est nécessaire de disposer d’une sorte de voie desecours permettant par exemple d’accéder à desdonnéeschiffréessansêtrepourautantdestinatairedeces informations.Lesmotivationsde telsmécanismesde recouvrement peuvent être multiples. Mais ellespeuvent être parfaitement légales et légitimes. Laméthodelaplussimpleestleséquestredecléconsistantàmettresousscellélesclésprivéesousecrètestoutencontrôlant les conditions d’accès à ces informations.Des travaux cryptographiques modernes proposentcependant de nombreuses autres solutions bien plussouples,sûresetefficaces.

1.2.2 Objectifs de sécurité minimaux

1.2.2.1 Définitions

«Authenticité»:

Une clé cryptographique n’est qu’une valeurnumérique. Le remplacement d’une clé par une autrepeut permettre, s’il est possible, de contourner unmécanismecryptographique.Lesattaquesdites«par le milieu»utilisentceprincipeenusurpant l’identitédupossesseur de la clé. Mais il peut aussi être trèsdangereux de pouvoir faire employer une clé par unalgorithme cryptographique ou pour un usage pourlequelellen’apasétéprévue.Ilestdoncimportantqueles clés utilisées soient non seulement intègres,c’est-à-dire non modifiées, mais encore correctementassociées à une entité du système, un algorithmecryptographique et un usage. L’objectif de sécuritécorrespondantestappeléauthenticitédelaclé.

«Clésecrèteversus.Privée»:

- une«clé secrète»désigneuneclécryptographiqueutiliséedansunsystèmesymétrique;

- une«clé privée»désignelapartiequidoitrestersecrèted’unebi-cléasymétrique;

- une « clé publique » désigne la partie qui estdiffuséedansunsystèmeasymétrique.

«Environnementdeconfiance»:

- désignel’environnementdanslequelestexploitéeunecléd’unsystèmecryptographique.

- La notion d’environnement de confiance définieici est volontairement très générale. Uneapplicationcryptographiquevaforcémentdisposerau moins d’un environnement de confiance, demêmequelesdifférentesentitésd’unsystèmedegestion de clés. La forme physique de cesenvironnementspeutêtrequelconque.

- Il est naturel d’imaginer que l’environnement deconfiance est sécurisé. Toutefois, il peut existerdes systèmes où l’environnement de confiancen’estpassécurisétechniquement.Inversement,unéquipement peut être sécurisé sans être deconfiance. Le fait d’utiliser des cléscryptographiques implique obligatoirement quepour le niveau de sécurité visé, l’environnementd’utilisation est « suffisamment » de confiance,car cet environnement ayant accès aux cléscryptographiquespeutlesexploiter.

- Mêmesinesontexploitéesquedescléspubliques,l’environnement qui les utilise doit être deconfiance. En effet, si on prend l’exemple d’unoutildevérificationdecertificatsdecléspubliques,ilnevautiliserquedescléspubliquespermettantla vérification de la chaîne de certificats. Pourautant, il est indispensable pour la sécurité dusystème que cet outil de vérification soit deconfiance et que le stockage des clés publiquesqu’il utilise protège ces dernières en authenticitéetenintégrité.

« Tiers de confiance » désigne toute entité quieffectue pour le compte d’utilisateurs finaux desopérations critiques pour la sécurité des clés. Dans laprésente annexe, un tiers de confiance est typiquementune autorité de certification d’une IGC. La confiancedanscetteautoritéesteneffetindispensableàlasécurité.

1.2.2.2 Cryptographiesymétrique

La sécurité des systèmes de cryptographiesymétriquesreposesurlaconfidentialité,l’authenticitéetl’intégritéd’uneouplusieurscléssecrètespartagéesentre deux ou plusieurs entités. Toute atteinte à cesobjectifs de sécurité est une atteinte directe à une ou plusieursdesfonctionsdesécuritéutilisant lesystèmecryptographique.


1.2.2.3 Cryptographieasymétrique

La sécurité des systèmes de cryptographieasymétriquesrepose:

- sur la confidentialité, l’authenticité et l’intégritéd’uneouplusieursclésprivées;

- sur l’authenticité et l’intégrité des clés publiquesutilisées.

Toute atteinte à ces objectifs de sécurité est une atteinte directe à une ou plusieurs des fonctions desécuritéutilisantlesystèmecryptographique.

Les objectifs d’authenticité et d’intégrité des cléspubliques sont tout aussi importants et difficiles àréaliserquel’objectifdeconfidentialitéd’unecléprivéeousecrète.

1.2.2.4 Disponibilité

Outre cesobjectifs liés à lanature cryptographiquedes mécanismes utilisés, le bon fonctionnement dusystèmenécessiteavanttoutechoseladisponibilitédesclés.Cepointpeuts’avérerdéterminantdansbeaucoupd’aspectsdelaconceptiond’unearchitecturedegestionde clés.

1.3Typologiedesarchitecturesdegestiondeclés

1.3.1 Cycledeviedescléscryptographiques

1.3.1.1 Demandedeclé

Une clé cryptographique n’est générée que suite àune demande, implicite ou explicite, qui permetd’identifier le début du cycle de vie d’une clé. Cettedemande peut, dans certains cas, donner lieu à uneformalisationutileausuividelaclédanssoncycledevie.

1.3.1.2 Génération

L’opération de génération de clés dépend desalgorithmes cryptographiques utilisés. Dans tous lescas,uneexpertisecryptographiqueest indispensableàlavalidationde ceprocessus, crucial pour remplir lesobjectifs de sécurité énoncés ci-dessus. Les règles del’étatdel’artenmatièredegénérationdecléspourunalgorithme donné et de génération d’aléa ne sonttoutefoispasl’objetdelaprésenteannexe.

Génération centralisée:Lagénérationdecléspeutêtre effectuée de façon centralisée. Dans ce cas,l’utilisateur final fait confiance à un tiers pour lagénération de ses éléments secrets et privés. Danscertains contextes, la génération de clés fait aussiapparaître la fabrication ou la personnalisationd’éléments matériels.

Danslasuitedeuxcasserontdistingués:

- lagénérationcentraliséedecléaléatoireconsisteàutiliserungénérateurd’aléapour fabriquerselonun procédé cryptographique les clés secrètes ouprivées;

- la dérivation de clé à partir d’une clé Maîtreconsiste à utiliser un procédé cryptographiquepour obtenir à partir d’une clé dite maître etd’élémentspublicsd’identificationdel’utilisateurfinaluneclésecrèteouprivée.

Génération locale:Lagénérationdeclépeutaussiêtreeffectuéede façonprivative lorsque lagénérationintervientlocalementauniveaudel’utilisateurfinal.Lagénération peut être effectuée directement au sein del’environnement de confiance. Il peut aussi y avoirinjection de clé sous le contrôle de l’utilisateur local.Danscederniercas, lagénérationdecléestsupposéecontrôléepar l’utilisateur localetsortdupérimètredelaprésenteannexe.

Danslasuitetroiscasserontdistingués:

- la génération locale de clé aléatoire consiste àutiliser localement un générateur d’aléa pourfabriquer selon un procédé cryptographique lescléssecrètesouprivées;

- la différentiation locale de clé consiste à utiliserunprocédécryptographiquepourobtenir àpartird’unecléprivéeousecrètelocaleetd’élémentsdedifférenciation une autre clé secrète ou privée,généralementdestinéeàunusagedifférent;

- l’échange de clé consiste, lors de l’ouvertured’unesessionentredeuxouplusieursintervenants,àutiliserunprotocolecryptographiquedédiépourélaborer une clé secrète commune auxintervenants.

1.3.1.3 Affectation

Une fois une clé cryptographique générée, sonadmission dans le système d’information est uneopération cruciale en termes de sécurité. C’est cetteopérationquiassocieàunevaleurnumériquel’identitéde l’utilisateur, de l’entité, du flux d’information, etc.auquel elle est affectée ainsi que l’usage qui lui estdévolu (signature, chiffrement, échange de clé, etc),quelacryptographieutiliséesoitasymétriqueounon;elle prend toutefois selon les systèmes des formesdifférentes.Onpeutdéfinircetteopérationcommecellequi fait passer une valeur numérique du statut dedonnéebruteaustatutdeclécryptographiquedansunsystème.


Ilnefautpasconfondrel’affectationavecl’injectiond’uneclédansunéquipement.Cettedernièreopérationest associée dans la présente annexe à l’étaped’introduction de la clé affectée dans le systèmeapplicatif(cf.point1.3.1.4).

L’opération d’affectation prend en outre un aspectencore plus crucial lorsqu’il s’agit de la premièreadmission dans le système. Pour distinguer ce cas defigure, on parlera dans la présente annexe du premierenrôlement d’un utilisateur ou d’un équipement dansun système. En effet, dans ce cas, la sécurité del’opération ne peut résulter que de procédés noncryptographiques, de nature physique etorganisationnels. C’est lors de ce premier enrôlementqueserontaffectésàl’utilisateurouàl’équipementlespremiers éléments cryptographiques permettantultérieurementdelereconnaîtredefaçonsûreetdeluiaffecterdenouvellesclés.

1.3.1.4 Introduction

Un autre aspect de la gestion d’une clé consiste àl’introduire physiquement ou logiquement dansl’ensembledusystèmeapplicatifunefoisquesonrôlea été correctement défini. Cet aspect recouvre ladistributionetletransportdelacléjusqu’àl’utilisateurou à l’équipement, puis son injection éventuelle dansl’environnement de confiance de l’utilisateur ou del’équipement.

L’introduction est l’opération qui fait passer la cléaffectéedu systèmedegestiondeclésproprementditausystèmeapplicatifquival’utiliser.

1.3.1.5 Utilisation

De par leur nature même, les éléments privés ousecrets ne peuvent être employés que dans unenvironnementdeconfiance.Cetenvironnementesteneffetresponsabledustockagedesclésetdeleurbonnegestionpendantladuréeoùellessontutilisées.Ilpeuten découler notamment des exigences quant à laprotectiondel’environnementdeconfianceapplicatif.

1.3.1.6 Findevie

Lafindevied’uneclécryptographiquedonnelieuàunerévocation,unretrait,voireunedestruction,quelacryptographieutiliséesoitasymétriqueounon.

Révoqueruneclén’estpassynonymederetraitencesens qu’une clé peut avoir été révoquée et continuerd’êtreutiliséepourdesopérationsdevérificationoudecompatibilitéascendante.Demêmeleretraitnesignifiepas forcémentque lacléneseraplus jamaisutilisée :ellepeutêtrearchivéepourpermettre,parexemple,demener une enquête ou de déchiffrer un documentpostérieurementàsonretrait.

1.3.1.7 Renouvellement

Lerenouvellementd’uneclécryptographiqueestunprocessus à prévoir dès la conception d’un systèmed’information, que la cryptographie utilisée soitasymétriqueounon.Cerenouvellementpeutintervenirde façon normale ou provoquée par des événementsfortuitscommeunecompromission.

1.3.1.8 Recouvrement

Le recouvrement de clé est une opération qui peutavoir pour objectif d’assurer la disponibilité d’unserviceouderépondreàdesexigenceslégales.Cetypedefonctionnalitéestd’autantplusdifficileàmettreenœuvrequesesobjectifs sontparnaturecontrairesauxobjectifs de sécurité visés par ailleurs. La définitionprécise de la fonctionnalité visée est indispensable demêmequ’uneexpertisecryptographiqueglobale.

L’expertise cryptographique est indispensable cardans certains cas, un simple archivage des clés nerépond pas à l’objectif de recouvrement opérationneldufaitdespropriétésdesprotocolescryptographiques.Par exemple, dans un protocole d’échange de clé detypeDiffie-Hellmanaléatoire, l’ensembledesdonnéeséchangéesdansleprotocolesontpubliquesetlesecretutilisélorsdelasessionestàusageuniqueetn’estpasconservé au-delà de son temps d’utilisation. Laconnaissance de l’ensemble des échanges et des clésprivées n’est d’aucune utilité pour retrouver le secretaléatoirechoisi.

1.3.2 Architectures fonctionnelles dessystèmesutilisateurs

1.3.2.1 Architecturerépartie

Dansunearchitecturerépartie(voirfigure1),chaqueutilisateur final est susceptible d’entrer en relation defaçon cryptographiquement sécurisée avec tous lesautresutilisateursfinauxdusystèmed’information.

Potentiellement, si le système comprend N utilisateurs,alorsilexisteN (N − 1)/2fluxd’informationàprotéger.


Figure1-Architecturefonctionnellerépartie

1.3.2.2 Architecturecentralisée

Dansunearchitecturecentralisée(voirfigure2),lesutilisateurs finaux sont susceptibles de n’entrer enrelation qu’avec un ou plusieurs utilisateurs centrauxidentifiés. Si le système d’information comprend n utilisateurs centraux et Nutilisateurs,alorsilexistenN flux d’information potentiels à protéger. En règlegénérale,nesttrèsinférieuràN.

Figure2-Architecturefonctionnellecentralisée

2 Règlesetrecommandations

Dans toute la suite, des règles et recommandationsminimales sont définies pour des systèmes de gestionde clés. Par raccourci, le terme de clé conforme auréférentiel sera employé lorsque ceci ne prêtera pas àconfusion.

2.1 Règlesetrecommandationsgénérales

L’utilisation d’une clé cryptographique doitobligatoirement se faire dans un environnement deconfiance.Que la clé soit publique, privée ou secrète,lesobjectifsdesécuritésurl’utilisationdecelle-cisonttelsque touteatteinteàcesobjectifsdesécuritéremetencauselesfonctionsdesécuritérempliespar l’usagede la cryptographie. Ces objectifs ont été rappelés aupoint1.2.2.

L’impact d’une clé doit dans tous les cas êtreétudié. Il s’agit, pour un système donné, de mesurerl’impactdel’atteinteàl’undesobjectifsdesécuritéci-dessus.Cecinedoitpasseconfondreavecl’analysedurisquedecompromission.Ils’agitbiend’estimer,sousl’hypothèse que la compromission ou l’atteinte àl’intégritédelacléaeuelieu,lesconséquencespourlesystèmecryptographique.C’estsurcetteétuded’impactque l’analyse de risque peut ensuite s’appuyer pourestimerlarobustessedusystème.

Dans beaucoup de systèmes cryptographiques,notammentceuxfaisantintervenirdestiersdeconfiance,ilexisteuneouplusieursclésdontlacompromissionoul’atteinte à l’intégrité peut entraîner des atteintes auxobjectifsdesécuritédetoutoud’unegrandepartiedesacteurs du système. Il s’agit par exemple des clésMaîtresd’unsystèmededérivationdeclé,d’unecléderéseauoudelacléprivéed’uneautoritédecertification.Unetellecléseraqualifiéedecléprésentantunrisqued’impactsystémiqueoudefaçonplusconcisedecléà risque systémique.

RègleImpact-1.Dansunearchitecturedegestiondeclés l’impact de chaque clé du système doit êtreévalué.

RègleDurée-1. Dans une architecture de gestion declésl’étuded’impactd’uneclédoitprendreencomptelesdifférentesduréesassociéesàcelle-ci.

RègleImpactSystémique-1.Dansunearchitecturedegestion de clés les procédures de récupération dusystème en cas d’atteinte à la confidentialité àl’intégritéouà l’authenticitéd’unecléprésentantunrisque d’impact systémique doivent être étudiées etdocumentées.

RecomImpactSystémique-1. Dans une architecturedegestiondeclésilestrecommandéd’éviterd’avoirrecoursàdesclésprésentantunrisquesystémique.


2.2 Demande de clé

Lademandedeclénefaitpasl’objetderègleouderecommandation particulière. En effet, cette étape ducycle de vie est fortement tributaire du contexteopérationnel.On s’attachera toutefois àbien identifiercetteétapeetlesprocéduresafférentescarc’estparleurcorrectedéfinitionquepourrontêtresatisfaitescertainesdesrèglesetdesrecommandationsliéesàl’affectationultérieure des clés et relatives au contrôle del’authenticitéetdel’intégritédesclés.

2.3 Génération de clé

2.3.1 Génération locale de clé

2.3.1.1 Génération locale de cléaléatoire

RègleAléaLocal-1. La génération locale d’une clécryptographique aléatoire doit faire appel à ungénérateurd’aléaconformeauréférentiel.

2.3.1.2 Différentiationlocaledeclé

RègleDifférentiation-1. La différentiation locale d’une clé cryptographique doit faire appel à unmécanismecryptographiqueconformeauréférentiel.

2.3.1.3 Échangedeclés

RègleÉchangeClés-1. L’échange d’une clécryptographiqueavecuneentitéhomologuedistantedoit faire appel à un mécanisme cryptographiqueconforme au référentiel.

2.3.2 Génération centralisée de clé

2.3.2.1 Génération centralisée de cléaléatoire

RègleAléaCentral-1.Lagénérationcentraliséed’uneclé cryptographique aléatoire doit faire appel à ungénérateurd’aléaconformeauréférentiel.

RecomAléaCentral-1. Il est recommandé que lagénération centralisée d’une clé cryptographiquealéatoirefasseappelàungénérateurd’aléaconformeau référentiel et respectant de plus l’ensemble desrecommandations associées.

RègleGénérationCentralisée-1. La générationcentralisée d’une clé cryptographique aléatoire doitintervenir dans un environnement de confianceconforme au référentiel.

RecomGénérationCentralisée-1. Il est recommandé quelagénérationcentraliséed’uneclécryptographiquealéatoire intervienne dans un environnement deconfiance conforme au référentiel et respectant deplusl’ensembledesrecommandationsassociées.

2.3.2.2 Dérivationdeclés

Unmécanismededérivationdecléviseàremplacerunmécanismedegénérationdeclépurementaléatoireparunprocédédéterministedépendantdel’identitédel’utilisateurfinal.

Ce type de procédé peut présenter des avantages,notamment dans une architecture applicative centraliséeutilisantdesmécanismescryptographiquessymétriques.Ilpermet dans ce cas de réduire le besoin de stockagesécurisé des nutilisateurscentrauxqui,pours’adresseràleurs N utilisateurs rattachés, n’ont à mémoriser qu’unsecretmaîtreaulieudeNsecretsindividuelsd’utilisateurs.

Ilpermetaussidefaciliterl’organisationd’unservicede recouvrement de clés, ce qui peut constituer unbesoinopérationneletfonctionnel.

Par contre, la compromissiond’unecléMaître, quipermetàunattaquantpotentielderetrouverl’ensembledes clés dérivées à partir de cette clé, constitue unrisquemajeurpourcetypedeprocédé.

RègleDérivation-1. La clé Maître d’un mécanismede dérivation de clé doit être exploitée dans unenvironnementdeconfianceconformeauréférentiel.

RecomDérivation-1. Il est recommandé que la clémaître d’un mécanisme de dérivation de clé soitexploitée dans un environnement de confianceconforme au référentiel et respectant de plusl’ensemble des recommandations associées.

RecomDérivation-2.Lesmécanismes de dérivationde clé ne devraient être utilisés que dans desarchitecturesapplicativescentralisées.

2.3.3 Générationdeclédesignature

L’usage de signature implique le souhait d’assurerun objectif de non-répudiation directement au niveaucryptographique.Cetobjectifestdélicatàatteindrepardesmoyenspurementtechniques.Onpourradoncavoirintérêtàviserunsimpleobjectifd’authenticitéetà lecompléter par des mesures opérationnelles oucontractuelles.

Lesrèglesetrecommandationsci-dessousconcernentlagénérationd’uneclédestinéeàunusagedesignature.Elles complètent les règles et recommandationsgénériquesproposéesci-dessus.


RègleDérivationSignature-1. La génération d’uneclé de signature ne doit pas faire intervenir demécanismededérivationdeclé.

RecomGénérationAléatoireSignature-1. Il est recommandéquelagénérationd’uneclédesignaturealéatoire soit effectuée directement par l’utilisateurfinaldanssonenvironnementdeconfiance.

RecomGénérationAléatoireSignature-2. Il est recommandéquelagénérationd’uneclédesignaturealéatoire fasse intervenir de l’aléa provenant d’unesourcemaîtriséeparl’utilisateurfinal.

2.4 Affectation d’une clé

L’affectation d’une clé cryptographique dans unsystèmeapplicatifestuneopérationquiestsouventmalcomprisedanssesimpactsenmatièredesécurité.C’estcette opération qui occasionne le plus de problèmesnotamment en termes d’initialisation. En effet, laproblématiquedepremier enrôlement conduit souventà un problème de « poule et d’œuf » : commentm’enrôlerdansunsystèmedefaçonsûre,alorsquecesystèmenemeconnaîtpas.

L’affectation vise à garantir, pour les autresutilisateurs du système applicatif, que la clé généréeest:

- d’unepartbiendéfiniedanssonrôleàl’égarddusystème;

- d’autre part bien associée à l’identité de sonutilisateur final, qu’il soit personne ou entitéautomatiquedusystème.

L’opération varie notablement en fonction del’existenceounond’untiersdeconfiance.

2.4.1 Usaged’uneclécryptographique

La cryptographie peut être employée pour réaliserbeaucoupdefonctionsdesécuritédenaturesdifférentes.Dans la présente annexe les usages de clés suivantsserontdistingués:

- chiffrement : c’est l’usage le plus connu desalgorithmescryptographiques,visantàrépondreàunobjectifdeconfidentialité(parexempleAESenmodeCBC);

- intégrité : c’est un usage spécifique de lacryptographie symétrique visant à garantir qu’unmessage n’a pas étémodifié (par exemple CBC-MACsurchiffré);

- authentification : c’est un usage visant à garantirl’identité d’une personne ou d’un équipement parunmécanismecryptographiqueinsensibleaurejeu;

- signature : c’est un usage spécifique de lacryptographieasymétriquevisantà répondreàuntriple objectif d’intégrité d’un message,d’authentification de son émetteur et garantissantla non-répudiation (par exemple ECDSA etECKCDSA);

- transfertdeclé:c’estunusagevisantàtransmettrede façon confidentielle une clé cryptographiqueutilisée dans un autre contexte, mais sans quel’authenticité soit nécessaire (par exemplechiffrementCBCparuneclésecrètedechiffrementdeclé);

- échangedeclé:c’estunusagevisantàs’accorderdefaçonconfidentiellesuruneclécryptographiqueutilisée dans un autre contexte, sans quel’authenticité soit nécessaire (par exempleDiffie-Hellman);

- dérivationdeclé :c’estunusagevisantàobtenirpourunensembled’utilisateurs,àpartird’uneclémaître et d’unélémentd’identitéd’unutilisateur,unecléprivéeousecrètespécifiquedecedernier;

- différentiationlocaledeclé:c’estunusagevisantà obtenir, à partir d’une clé privée ou secrète etd’élémentscomplémentaires,uneouplusieursclésprivées ou secrètes destinées à des usagesdifférents;

- sourced’aléa:c’estl’usageconsistantàintroduiredansungénérateurpseudo-aléatoire,unequantitéd’information secrète aléatoire permettant dedifférenciercegénérateurpourchaqueéquipementet de l’utiliser, bien qu’il reste purementdéterministe,commeungénérateurd’aléa.

- L’usage d’une clé peut parfois être difficile àcaractériser. Il semble toutefois, que l’on peuttoujoursseramenerauxcasci-dessus.Ilconvienttoutefois de ne pas confondre l’usage des clés etlesservicesdesécuritéqu’ellesrendent.

Parexemple,dansundéfiDiffie-Hellmansignéparune clé RSA le service rendu est un échange de cléauthentifié. On peut toutefois distinguer l’élémentd’aléa dont découle le challenge (qui est rarementdésigné comme clémais qui reste un élément secret)dont l’usageestde type transfert de clé et la clé RSA dontl’usageestdetypesignature.

RègleUsage-1. L’usage d’une clé doit être unique(saufexceptiondumentjustifiée).


2.4.2 Objectifs de sécurité de l’affectation

L’objectif intrinsèque à l’affectation d’une clécryptographiqueàunutilisateurouàunéquipementestceluid’authenticitéquisedéclineendeuxaspects:

- garantir à l’utilisateur ou à l’équipementl’authenticitédelacléquiluiestproposée;

- garantirpourlesystème,lapossessioneffectivedelacléparl’utilisateuroul’équipementauquelelleest affectée.

RègleAffectation-1. Les mécanismes cryptographiquesutilisés lorsde l’affectation d’uneclé cryptographique à un utilisateur ou à unéquipement donné doivent être conformes auréférentiel. Ces mécanismes doivent garantir laconfidentialité,l’intégritéetl’authenticitédelaclé.

RecomAffectation-1. Il est recommandé que lesmécanismes cryptographiques utilisés lors del’affectation d’une clé cryptographique à unutilisateurouàunéquipementdonnégarantissent lapossessiondelacléparl’utilisateuroul’équipementauquelelleestaffectée.

2.4.3 Objectifssurlepremierenrôlement

Seul lepremierenrôlementd’unutilisateuroud’unéquipementdans le systèmeestmaintenant considéré.Unefoiscetenrôlementréalisé,ilestconsidéréquelesutilisateurs ou équipements finaux disposent desmoyens cryptographiques permettant d’effectuer desaffectations de clés ultérieures.

Les objectifs du premier enrôlement restentidentiquesetvisentàgarantir:

- l’authenticitédelacléproposée;

- lapossessiondelacléparl’utilisateur.

Ces objectifs ne peuvent toutefois être remplis quepar desmesures largement organisationnelles puisqueleséquipementsenprésencenesontpas«à la clé».

Techniquement,cepremierenrôlementvaconsisterenl’introductiond’uneclédebasedansunéquipement.Cette clé d’initialisation cryptographique serviraensuite à protéger les échanges liés à l’affectationd’autres clés dans le système. C’est la raison pourlaquelle le premier enrôlement revêt une importancecruciale,carc’estleseulquinepeutpasreposersurdesmoyenscryptographiquesdeprotectionetc’estpourtantcelui sur lequel reposera dans beaucoup de cas lasécurité des affectations ultérieures.

Remarque:

Lesrèglesetrecommandationsrelativesàcepremierenrôlementdépendentdumodedegénérationdelacléaffectée. Ilseraquestiondepremierenrôlementd’uneclé générée localement pour désigner l’affectationd’une clé générée localement lors du premierenrôlement de l’utilisateur ou de l’équipement auquelelle est affectée.

2.4.3.1 Premier enrôlement d’une clégénéréelocalement

Premierenrôlementd’uneclégénéréelocalementsanstiersdeconfiance

RègleEnrôlementPrivatif-1. Lors de son premierenrôlement, l’utilisateur final d’un système doitproposerà ses interlocuteursunmoyendecontrôlerson identité, l’authenticité de la clé qu’il cherche às’affecteretlefaitqu’ilpossèdebiencetteclé.

Remarques:

Pour un premier enrôlement de clés demessagerievial’internet,onpeututiliserlehache(souventappeléempreinte) d’une clé publique et utiliser l’un desmoyenssuivants:

- lepubliersursonsitepersonnel;

- l’envoyer par SMS (l’authentification découlantalors de la connaissance ou non du numéro de téléphonedel’appelant);

- l’envoyer par courrier signé (l’authentificationrésultantdelasignaturemanuscrite);

- La signaturede laclépubliquepar lacléprivée(auto-signature) ne constitue un élément depreuvedelapossessiondelacléquesiladonnéesignéedépendbiendel’interlocuteur.Danslecascontraire,lerejeuesttoujourspossible.

RecomContrôleIndépendant-1.Dansunsystème,ilest recommandé que le moyen de contrôle proposéparl’utilisateurfinallorsdesonpremierenrôlementsoitvéhiculédefaçonindépendantedesaclé.

Premierenrôlementd’uneclégénéréelocalementauprèsd’untiersdeconfiance

Ilconvienttoutd’aborddenoterquecettesituationn’a de sens que dans le cas d’une infrastructure degestion de clés (IGC), c’est-à-dire d’un systèmecryptographique asymétrique. En effet, dans un telsystème la clé privée de l’utilisateur n’a pas besoind’être communiquée au tiers de confiance et ne sortdonc pas de l’environnement de confiance de


l’utilisateur.Aucontraire,pourunsystèmesymétrique,généreruneclédefaçonlocaleetl’affecteràunusageet une identité auprès d’un tiers de confiance vaconsisteràl’acheminerverscedernier.Onobtiendraaufinalunesituationsimilaireàcelled’unegénérationdeclé symétrique centralisée après acheminement de laclé vers son utilisateur final puisque les deux partiesaurontunsecretpartagé.Cettesituationfinalesimilaireauraittoutefoisétéobtenuedefaçonaberranteparunegénérationdelaclésymétriqueauniveaulocal.

L’utilisateurfinalquiagénérésaclélocalementdanssonenvironnementdeconfiancedoit, préalablement àl’affectationdesacléparletiersdeconfiance,prouveràcedernier:

- l’authenticitédelaclépubliquequ’ilpropose;

- qu’il est bien en possession de la clé privéecorrespondante.

Pour cela, il est nécessaire que l’identité del’utilisateursoitdéjàconnuedutiersdeconfiance.

RègleEnrôlementIGC-1.Dansunsystèmeavectiersde confiance, pour assurer le premier enrôlementd’une clé générée localement, le tiers de confiancedoit disposer d’unmoyen de contrôler l’identité del’utilisateur final, l’authenticité de sa clé et le faitqu’il possède bien cette clé. L’utilisateur final doitdisposer de même d’un moyen de contrôlerl’authenticitédesélémentspublicsdel’IGC.

RecomContrôleIndépendant-1. Il est recommandé que le premier enrôlement auprès d’un tiers deconfiance d’un utilisateur final générant localementsacléutiliseunmoyend’acheminementindépendantduprocessusd’enregistrementpourtouslesélémentsde contrôle de l’identité de l’utilisateur, del’authenticitédelacléetdecelledesélémentspublicsde l’IGC.

2.4.3.2 Premier enrôlement d’une clégénéréedefaçoncentralisée

Premier enrôlement d’une clé générée de façoncentraliséesanstiersdeconfiance

Cette situation n’a pas de sens car le centre degénérationdeclésestdefactountiersdeconfiance.

Premier enrôlement d’une clé générée de façoncentraliséeavectiersdeconfiance

RègleEnrôlementCentralSécuritéPhysique-1.Dansunsystèmeavec tiersdeconfiance, lepremierenrôlement d’une clé générée de façon centraliséedoitêtreréalisédansunenvironnementdeconfianceetparunlienphysiquedeconfiance.

RègleEnrôlementCentral-1.Dans un système avectiersdeconfiance,lorsd’unpremierenrôle-ment,letiers de confiance doit disposer d’un moyen decontrôlerl’identitédel’utilisateurfinaletl’utilisateurfinaldoitavoirunmoyendevérifierl’authenticitédesa clé générée de façon centralisée par le tiers deconfiance.

Premierenrôlementd’uneclédérivée

RègleEnrôlementDérivationSécuritéPhysique-1.Le premier enrôlement d’une clé générée par unprocessusdedérivationàpartird’uneclémaîtredoitêtre réalisé dans un environnement de confiance etparunlienphysiquedeconfiance.

RègleEnrôlementDérivation-1. Lors d’un premierenrôlement, le tiers de confiance doit disposer d’unmoyendecontrôler l’identitéde l’utilisateurfinaletl’utilisateur final doit avoir un moyen de vérifierl’authenticitéde saclégénéréepardérivationd’uneclémaîtrecontrôléeparletiersdeconfiance.

2.5 Introduction d’une clé

2.5.1 Acheminementdeclé

Le problème d’acheminement d’une clé intervientparexemplelorsd’unegénérationcentraliséeoud’unegénérationparunprocédédedérivationàpartird’uneclémaître.

L’acheminement des éléments de premierenrôlement, pour lesquels la protection ne peuts’appuyer sur des mécanismes cryptographiques,n’est pas envisageable. Cette opération de premierenrôlementaététraitéeaupoint2.4.3.

L’acheminementdeclépeutaussiintervenirdansunprocessus de génération locale d’une clé secrète, parexemple au coursd’unprocessusd’échangede clé. Ilestconsidérédanscecasqueleprocessusd’échangedeclé est du niveau applicatif et ne fait pas partie de lagestion des clés. Il n’en demeure pas moins que lesobjectifs de sécurité sur ce mécanisme sont tout à fait similairesàceuxdel’acheminementd’unecléaléatoiregénéréedefaçoncentralisée.


2.5.1.1 Acheminementdecléaléatoiregénéréedefaçoncentralisée

RègleAcheminemementCléCentral-1.L’acheminement jusqu’à l’utilisateur final d’une clécrypto- graphique générée aléatoirement de façoncentralisée doit bénéficier de moyens de protectionconformesauréférentiel.Cesmoyensdoiventgarantirl’authenticité,l’intégritéetlaconfidentialitédelacléacheminée.

RecomAcheminementNoirCentralBout-en-bout-1.Il est recommandé que l’acheminement jusqu’àl’utilisateur final d’une clé cryptographique généréealéatoirement de façon centralisée soit protégécryptographiquementdeboutenboutenauthenticité,intégrité et confidentialité par des mécanismes deprotectionconformesauréférentiel.

2.5.1.2 Acheminement de clé généréepardérivation

RègleAcheminemementCléDérivée-1.L’acheminement jusqu’à l’utilisateur final d’une clécryptographiquegénéréeparunprocédédedérivationàpartird’uneclémaîtredoitbénéficierdemoyensdeprotection conformes au référentiels. Ces moyensdoivent garantir l’authenticité, l’intégrité et laconfidentialitédelacléacheminée.

RecomAcheminementNoirDérivéeBout-en-bout-1.Il est recommandé que l’acheminement jusqu’àl’utilisateur final d’une clé cryptographique généréeparunprocédédedérivationàpartird’uneclémaîtresoitprotégécryptographiquementdeboutenboutenauthenticité, intégrité et confidentialité par desmécanismesdeprotectionconformesauréférentiel.

2.5.2 Injection de clé

2.5.2.1 Injection de clé généréelocalement

Ilestpossibled’injecteruneclégénéréelocalement.Toutefois, dans certains cas, la génération d’une clépeut être effectuée par l’utilisateur dans unenvironnementdeconfiancedistinctdel’environnementdeconfianceapplicatif.

Parexemple,unutilisateuravertipourraitemployerun logiciel autonome pour générer sa clé privée designature et vouloir ensuite l’injecter dans un logicielde messagerie. Dans ce cas, la génération est localemais l’environnement de confiance de l’utilisateur estscindé en deux parties relatives à la génération et àl’utilisation des clés.

RecomInjectionCléLocale-1. Ilestrecommandéquela génération locale d’une clé cryptographique nedonnepaslieuàunprocessusd’injection.

RègleInjectionCléLocale-1. L’injection d’une clé cryptographique générée localement doit bénéficierde moyensdeprotectionconformesau référentiel.Cesmoyensdoiventgarantirl’authenticité,l’intégritéetlaconfidentialitédelacléinjectée.

2.5.2.2 Injection de clé aléatoiregénéréedefaçoncentralisée

RègleInjectionCléCentral-1. L’injection dans l’environnement de confiance de l’utilisateur finald’une clé cryptographique générée aléatoirement defaçon centralisée doit bénéficier de moyens deprotection conformes au référentiel. Ces moyensdoivent garantir l’authenticité, l’intégrité et laconfidentialitédelacléinjectée.

RecomInjectionCléCentral-1. Il est recommandé quel’injectiondansl’environnementdeconfiancedel’utilisateur final d’une clé cryptographique généréealéatoirement de façon centralisée soit effectuée àpartir d’une donnée protégée dès la génération enconfidentialité, authenticité et intégrité par desmécanismes cryptographiques conformes auréférentiel.

Remarque:

Cette recommandation ne s’applique pas auxéléments de premier enrôlement pour lesquels laprotection ne peut s’appuyer sur un mécanismecryptographique.

2.5.3 Injectiondeclégénéréepardérivation

RègleInjectionCléDérivée-1. L’injection dans l’environnement de confiance de l’utilisateur finald’uneclé cryptographiquegénéréeparunprocessusdedérivationàpartird’uneclémaîtredoitbénéficierde moyens de protection conformes au référentiel.Cesmoyensdoiventgarantirl’authenticité,l’intégritéetlaconfidentialitédelacléinjectée.

RecomInjectionCléDérivée-1. Il est recommandé quel’injectiondansl’environnementdeconfiancedel’utilisateur final d’une clé cryptographique généréepar un processus de dérivation à partir d’une clémaître soit effectuée àpartir d’unedonnéeprotégéedès la génération en confidentialité, authenticité etintégrité par des mécanismes cryptographiquesconformes au référentiel.


2.6 Utilisation d’une clé

2.6.1 Diffusion d’une clé

Ladiffusiond’uneclédansunsystèmeestlenombred’environnements de confiance qui sont susceptiblesd’yaccéderenclair.Ladiffusionaugmentelerisquedecompromissiond’uneclé.

Ladiffusionminimaled’unecléest:

- pour une clé privée, limitée à un seulenvironnementdeconfiance;

- pour une clé secrète, limitée à deuxenvironnementsdeconfiance.

Ilexisted’unpointdevuethéoriquedesmoyensdepartagerunsecretentreplusieursentitésdetellefaçonque des calculs puissent être effectués à partir de cesecret sans le révéler. Ces méthodes mathématiquespeuvent êtreutiliséesmaisne sontpasenvisagées ici.Ellesvontplusloinquelesimplepartagedesecret,quipermet, à partir de parts de secret distinctes, dereconstituer un secret dans un environnement deconfianceetdel’utiliser.

RecomDiffusion-1. Il est recommandé que ladiffusiond’unecléprivéeousecrètesoitlimitéeauxseuls environnements de confiance qui l’utilisentvraiment.

2.6.2 Utilisationapplicatived’uneclé

RègleEnvironnementConfiance-1. L’utilisation d’uneclécryptographiquedansunsystèmeapplicatifdoitobligatoirementsefairedansunenvironnementdeconfianceayantunniveaudesécuritéconformeauréférentiel.

RègleVérificationAuthenticité-1. Avant touteutilisationd’uneclédansun systèmeapplicatif, sonauthenticitéetsonintégritédoiventêtrevérifiéesparun mécanisme de sécurité conforme au référentiel.

RègleVérificationUtilisabilité-1. Avant touteutilisation d’une clé dans un système applicatif, ildoit être vérifié par un mécanisme de sécuritéconforme au référentiel que la clé est toujoursutilisable.

2.7Findevied’uneclé

RègleFinUtilisation-1. Une architecture de gestionde clés doit prévoir la fin de vie de l’ensemble desclésqu’ellegèreouutilise.

RecomCauseFinUtilisation-1. Il est recommandé qu’une architecture de gestion de clés traite lesdifférentes causes de fin de vie d’une clé de façondistincte.

RègleEffacement-1. Une clé dont la durée d’utilisation est dépassée doit être effacée desenvironnementsdeconfianceoùelleétaitutiliséeparunmoyentechniqueconformeauréférentiel.

2.8Renouvellementd’uneclé

RègleRenouvellement-1.Unearchitecturedegestiondeclésdoitprévoirlerenouvellementdel’ensembledesclésqu’ellegèreouutilise.

RègleRenouvellementEnrôlement-1. Une architecture de gestion de clés doit assurer que lerenouvellementd’uneclénepuissesefairequ’aprèsvérificationde l’authenticitéde lanouvellecléetdela possession de celle-ci par l’utilisateur. Lesmécanismes utilisés pour cette vérification doiventêtreconformesauréférentiel.

2.9Recouvrementd’uneclé

RègleRecouvrement-1.Une architecture de gestiondeclésquiprévoitdesfonctionsderecouvrementdeclésdoitmettreenplacedescontrôlesd’accèsàcettefonctionnalité conformes au référentiel et respectantdeplusl’ensembledesrecommandationsassociées.

gestion des clés cryptographiques€¦ · L’objectif de la présente annexe est de présenter le...

Documents

Transcript of gestion des clés cryptographiques€¦ · L’objectif de la présente annexe est de présenter le...