La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 Infrastructures à Clefs publiques Public Key Infrastructure (PKI) Stéphane Natkin 2006.

Présentations similaires


Présentation au sujet: "1 Infrastructures à Clefs publiques Public Key Infrastructure (PKI) Stéphane Natkin 2006."— Transcription de la présentation:

1 1 Infrastructures à Clefs publiques Public Key Infrastructure (PKI) Stéphane Natkin 2006

2 2 Les ICP Au cœur des mécanismes de sécurité basés sur la cryptographie à clefs publiques: Echange des clefs de session Signature et authentification

3 3 Différentes utilisation dune ICP Il peut sagir dun moyen interne dauthentification des ressources et des personnes, ainsi que le support de la gestion de clefs de chiffrement. Il peut sagir, dans le cadre dun accord contractuel entre entités, dun moyen support dauthentification et de chiffrement, mais également dune signature électronique faisant foi dans les rapports entre les signataires des contrats. Enfin il peut sagir dune infrastructure support de la signature électronique de droit public. Une signature générée à partir dun bi clefs de linfrastructure doit donc être valide devant les tribunaux au même titre que la signature manuelle

4 4 ANNUAIRE DES CERTIFICATS AC: autorité de certification Norme de représentation des certificats X509 Norme de protocole daccès: LDAP Alice a Bob b Charles c Validc Validb ValidaPara NOM Clef ValiditéExtensions Signature Parb Parc

5 5 Une structure signée SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier } SignedAttributes ::= SET SIZE (1..MAX) OF Attribute UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY SignatureValue ::= OCTET STRING

6 6 Une chaîne de certification -Serial Number :224 -Issuer : CA1 -Subject : Alice -Clef publique dAlice -Signature du certificat par CA1 -Serial Number :125 -Issuer : CA0 -Subject : CA1 -Clef publique de CA1 -Signature du certificat par CA0 -Serial Number :005 -Issuer : CA0 -Subject : CA0 -Clef publique dAlice -Signature du certificat par CA0

7 7 Un certificat X509 serialNumber CertificateSerialNumber : Numéro de certificat unique pour une autorité donnée. signature AlgorithmIdentifier : Il existe différents algorithmes de signature numérique utilisant des clés publiques des clés privées et des fonctions de hachage variées. Ce champ décrit l'algorithme retenu par lautorité de certification pour signer le certificat. issuer Name : C'est le nom de lautorité de certification qui a émise et signé le certificat. Ce nom est codé selon une syntaxe le la norme dannuaire X500 (DN Distinguished Name). validity Validity : Définit la période de validité du certificat comme l'indique clairement le type validity décrit en ASN1 Validity ::=SEQUENCE{ notBefore UTCTime, notAfter UTCTime } subject Name, C'est le nom au format DN de lentité possesseur du certificat, qui à lusage de la clef privée correspondant à la clef publique définie dans le champ suivant. subjectPublicKeyInfo Contient le nom du crypto système asymétrique auquel se rapporte le certificat et la clef publique correspondante Les champs extension

8 8 Un certificat X509 (2) Certificate ::= SIGNED { SEQUENCE{ version [0] IMPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version must be v2 or v3 subjectUniqueIdentifier[2] IMPLICIT UniqueIdentifier OPTIONAL -- If present, version must be v2 or v3 extensions[3] Extensions OPTIONAL -- If present, version must be v3 -- } } Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER AlgorithmIdentifier ::= SEQUENCE { algorithmALGORITHM.&id({SupportedAlgorithms}), parametersALGORITHM.&Type ({SupportedAlgorithms} OPTIONAL } SupportedAlgorithms ALGORITHM ::= {... } Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } Time ::= CHOICE { utcTime UTCTime, generalizedTime GeneralizedTime } SIGNED { ToBeSigned } ::= SEQUENCE { toBeSigned ToBeSigned, encrypted ENCRYPTED { HASHED {ToBeSigned }} }

9 9 Extensions SubjectType : Précise si le possesseur (subject) est un utilisateur du certificat ou sil sagit dun certificat de signature dune autorité de certification. Keyattributes précise diverses données sur la clef publique. –KeyUsage est lextension la plus importante. Elle décrit le ou les utilisations autorisées du certificat. –privateKeyUsagePeriod permet de limiter lusage des clefs privées avant lexpiration du certificat –subjectKeyIdetifier et authorityKeyIdentifier permettent de donner un numéro unique à ces deux clefs.

10 10 Renouvellement des clefs T+t/2T+t Période de validité de Caut Période de validité de la clef privée associée à Caut Période de validité du dernier certificat signé avec Caut

11 11 Infrastructure à clefs publiques (PKI) Fonctionnalités Modules RA/LRA : Autorité d enregistrement locale des clients Elle enregistre la demande de certificat et les renseignements associés Module CA : Autorité de Certification Elle contrôle l identité du demandeur et génère le certificat, écrit dans l annuaire et la carte à puce, écrit dans la carte la clef privée Module DIR : Annuaire LDAPv3 de Netscape Sert à publier les certificats Module TTS : Horodateur sécurisé par carte Module PERS : personnalisation des dispositifs de sécurité utilisateurs : cartes à puce, disquettes

12 12 Garde Barrière Internet/ Intranet Annuaire de référence des certificats et de CRL Horodateur Certifié Autorité de Certification Personnalisation Utilisateurs Clients ou serveurs Station Carte Disquette Serveur de certificats et de CRL Base locale de certificats Garde Barrière Autorité d enregistrement déportée Autorité denregistrement locale

13 13 FONCTIONNEMENT DES INFRASTRUCTURES À CLEFS PUBLIQUES(PKI) Internet/ Intranet Annuaire de certificats et de CRL Horodateur Certifié Autorité de Certification Carte Autorité Autorité d enregistrement (RA) Personnalisation X.509 Station Client Station Client Carte Disquette Serveur

14 14 lAutorité de Certification (AC ou CA Certification Authority) Cest le cœur du système. Elle a la responsabilité de la qualité du service de certification, définie par un document qui doit être connu de tous les utilisateurs des certificats : La Politique de Certification (PC) (Certification Policy PC). Celle ci peut être précisée par des DPC (Déclaration de Procédures de Certifications) (Certification Practice Statement CPS). Une PC est une déclaration dengagement qui doit permettre à un tiers de juger sil peut utiliser un certificat pour une application donnée.

15 15 Lautorité denregistrement (AE) LAC peut déléguer tout ou partie de la réalisation des fonctions dont elle est responsable. La fonction qui est le plus souvent déléguée est celle de lAutorité dEnregistrement (AE ou RA Registration Authority). Lautorité denregistrement collecte les demandes de certificats avec le informations nécessaires aux vérification didentité. Elle transmet cette demande à lAC et sert dintermédiaire pour la distribution de supports physiques de certificats (cartes à puces par exemple) et de mot de passes utilisés dans les échanges avec les utilisateurs. Elle peut servir également dintermédiaire pour les révocations (en cas de perte de cartes par exemple).

16 16 Autres composants Tiers de séquestre : Opérateur qui fournit les moyens de déchiffrer un message quand le détenteur des clefs de déchiffrement ne peut ou ne veut pas le déchiffrer et que les nécessités ou la loi ly oblige. Un tiers de séquestre, séquestre donc des clefs de déchiffrement. Horodatage de confiance: Il sagit doffrir un accès à un serveur de temps permettant de dater de documents faisant lobjet de signatures électroniques. Les propriétés de ce serveur doivent couvrir les attaques danti et post datage du document.

17 17 CONTRÔLE DES CERTIFICATS Toutes entités impliquées dans un schéma à clef publique doit détenir la clef publique de l autorité de certification. Tout accès à un certificat doit être contrôlé: Vérifier que la signature est valide Vérifier que la date courante est dans la période de validité Pour éviter les rejeux de certificats invalidés le serveur d annuaire doit : Soit sauthentifier Soit dater et signer sa réponse Soit transmettre périodiquement des listes de révocation datée et signées

18 18 CONTRÔLE DES CERTIFICATS Procédure Contrôler_Certificat(in :certificat, out : statut) Début % Soit C=(Autor,125,Alice,a,01/01/ /12/2002,Sig) le certificat % Etape 1 % Contrôle de la signature de lautorité % Si Sig incorrecte alors statut := la signature est incorrecte, le certificat nest pas valide ; retour ; Sinon % comme les données contenues dans le certificat ont été générée par Autor et nont pas été altérée, % passer à létape 2 ; fsi Etape 2 % Contrôle de la date de validité du certificat % Si (date_courante 31/12/2002) statut := certificat périmé ; retour ; Sinon passer à létape 3 ; fsi

19 19 CONTRÔLE DES CERTIFICATS Etape 3 % Récupération de la liste de révocation % Exécuter CRL_Req(Bob) ; Attendre CRL_Rep(Bob,CRL, statut) ; Si (statut OK) passer létape 3 % jusquà ce quune liste ait été récupérée% Sinon passer à létape 4 ; fsi Etape 4 %Vérification de la validité de la liste% % Soit CRL= (Autor, liste,date_de_mise à jour,Sig) la liste récupérée % Etape 4.1 % Vérifier la signature de la liste :% Si signature fausse Aller à létape 3 % Pour récupérer une liste correcte % Sinon Etape 4.2 % Vérifier la fraîcheur de la liste % Si (date_courante>date_de_mise_à_jour+ Période) Alors % Période est la période de rafraîchissement des listes déclarées par Autor (24h par exemple), la liste est trop ancienne% Aller à létape 3 % Pour récupérer une liste fraîche % fsi

20 20 CONTRÔLE DES CERTIFICATS Etape 5 % Vérification de la non-répudiation du certificat dAlice% Si (125 liste) statut := certificat dAlice est révoqué ; retour ; Sinon % certificat valide % statut :=OK ; retour ; fsi fin

21 21 STOCKAGE DES CLEFS ASYMÉTRIQUES Clef publique de lautorité, ne doit pas pouvoir être modifiée: Dans le code en dur, sur un support fiable (carte à puce) Clef privée de l utilisateur, ne doit pas pouvoir être lue: sur un support confidentiel (carte à puce) ou un fichier chiffré avec un mot de passe (local au poste ou sur disquette) Certificat de l utilisateur: Annuaire+support local ou carte ou disquette Annuaire: Annuaire central+version locales (cache, annuaire privé

22 22 SYSTÈME ASYMÉTRIQUE: HIÉRARCHIE DES AUTORITÉS DE CERTIFICATION (CHAÎNE DE CERTIFICATION ) Autorité Internationale Certificat auto- signé Autorité nationale Certificat signé par lautorité internationale Autorité professionnelle ou commerciale Certificat signé par lautorité nationale Agent de létat Certificat signé par lautorité nationale Individus Certificat didentité signé par un agent de létat Personne morale Certificat signé par lautorité professionnelle ou commerciale Personnel/ Clients/ Fournisseurs Certificat signé par la personne morale Services Web Certificat signé par la personne morale Objets informatiques Certificat signé par lutilisateur Objets informatiques Certificat signé par lutilisateur ou un objet prestataire de service Clefs de session Autorité nationale Certificat signé par lautorité internationale

23 23 Certification croisée ACA AliceACA.PC BSE BSE.PEBSE.OSBob CharlesDominiqueEponineFrançoiseGérardHenri

24 24 Récupération des certificats (1) AliceCA Requête signée Réponse signée CAAlice Requête signée Réponse chiffrée Mot de passe (Par la poste) AliceRA Requête Réponse CA Requête signée Réponse signée Se présente physiquement au RA

25 25 Récupération des certificats (2) AliceRA Requête Mot de passe CA Requête signée + mot de passe chiffré Réponse Se présente physiquement au RA Requête authentifiée avec le mot de passe CMP (Certificate Management Protocol) RFC 2510 et 2511 CMC (Certificate Management Protocol using CMS) la RFC 2797.

26 26 Politiques De Certification Du R.E.AL

27 27 La politique de certification Lobjectif général du service offert, Les types de certificats délivrés et leurs usages Lorganisation des composants de lICP La hiérarchie de certification les principes de gestion du cycle de vie dun certificat et en particulier les contrôles didentité réalisés lors de la délivrance et les conditions et moyens dune révocation Les principes de publication des certificats et des listes de révocation Les engagements en matière de performance, disponibilité, intégrité et confidentialité des données gérées La RFC 2527 propose un plan type et décrit ce que doit obligatoirement contenir ce document

28 28 Classes De Certification Classe 0 : applicable aux systèmes et objets informatiques Classe 1 : applicable aux employés des études notariales et composantes de lICP Classe 2 : applicable aux notaires en exercices Classe 3 : applicable aux autorités de certification

29 29 Politiques De Certification

30 30 Titulaire membre Niveau 2 Titulaire abonné Niveau 2 Titulaire machine Niveau 2 LCR Autorité OSC Niveau 1 ADSN Autorité de Certification Racine (Niveau 0) CSN Certificat Auto Signé LAR Titulaire AC Niveau 1 CSN Gestion OSC Niveau 1 ADSN Serveur Temps T T S Niveau 1 ADSN Signature des LAR Signature des LCR Certificats Signé par l AC Certificats Signé par lOSC Chaîne De Certification Du R.E.AL

31 31 Certificat Type de certificats. Authentification : certificats destinés à lauthentification forte des entités (personnes, ordinateurs, objets informatiques) par les applications électroniques sécurisées. Signature des documents: certificats utilisés pour la signature (des documents) numériques et sa vérification. Chiffrement des données : certificats utilisés pour lencodage (cryptage) des données et des clés de session. Signature des certificats : certificats utilisés pour la signature des certificats

32 32 Carte R.E.AL Type de cartes R.E.AL Une carte autorité AC contenant un certificat auto-signé de classe 3, qui sert à signer les certificats de niveau 1 3 cartes autorité OSC, ( une carte de lentité dhorodatage, une carte de lentité de fabrication contient un certificat de signature des certificats de niveau 2 et des LCR, et une carte de lentité de gestion pour le contrôle des signatures des demandes de fabrication et de révocations) Une carte titulaire AC contient un certificat de signature de classe 2, qui sert à signer les ordres de fabrication et de révocation Des cartes titulaires machine contenant tous les certificats de classe 0 Des cartes titulaires physique contenant tous les certificats de classe 1 Des cartes de notaire en exercice contenant des certificats de signature de classe 2 et des certificats dauthentification et de chiffrement de classe 1

33 33 Transmissiondes cartesR.E.AL Consultation des LCR Demande de carte R.E.AL. Demande de révocation Demande de récupération Remise des cartes R.E.AL Publication des LCR LCR Titulaire Opérateur de Service de Certification Édition des LCR Édition des certificats valide Génération des cartes et codes PIN Certificats Autorité OSC Niveau 1 Horodatage Signature des certificat de niveau 2 Signature des LCR ADSN Transmission des demandes de cartes R.E.AL Transmission des demandes de révocations Accusés de réception Ordres de fabrications Ordres de révocations Autorité dEnregistrement Vérification et Enregistrement des Demandes de cartes R.E.AL. Remise des cartes R.E.AL aux Titulaires Abonnées CDN Autorité dEnregistrement CRN ICP Autorité dEnregistrement CSN LA R Signature des LAR Consultation des LAR Transmissio n des demandes de récupération des cartes et code PIN Autorité de Certification.Mise en œuvre de la PC et DPC Validation des demandes de cartes R.E.AL Certificat Titulaire AC Niveau 1 Signature des ordres de fabrication Signature des ordres de révocation Certificat Racine AC niveau 0 Signature des certificats de niveau 1 Signature de la LAR CSN Transmission des codes PIN aux Titulaires ICP dans son Environnement

34 34 Autorité De Certification Rôles Mettre en œuvre la PC et la DPC Générer sa clé privée, les clés de lOSC (clé de génération des cartes et la clé de lhorodatage) et ceux des titulaires AC, Vérifier les données denregistrement, de génération, de renouvellement, et de révocation des cartes R.E.AL Respecter les contrôles de conformité et de remédier aux non-conformités quil révèle, Signer et transmettre les ordres de fabrication des cartes R.E.AL. À lOSC Signer la liste des autorités de certification révoquées Archiver les demandes de création et de révocation des cartes R.E.AL., Révoquer une composante de lICP dans le cas dun échec de contrôle de conformité Fournir les renseignements sur les certificats pour toute demande de notaire Réception des demandes de révocation durgence

35 35 Autorité De D Enregistrement Rôles Vérifier l'identité, la véracité des pièces justificatives, et lexactitude des mentions qui établissent lidentité des personnes voulant obtenir une carte R.E.AL Vérifier la validité des pièces justificatives pour les titulaires machines Vérifier l'identité et habilitation des demandeurs de cartes R.E.AL Recevoir les cartes R.E.AL. des abonnés Délivrer les cartes R.E.AL à leurs titulaires après la signature du registre Réceptionner, vérifier lexactitude, et enregistrer les demandes de révocations Transmettre les demandes de création et de révocation des cartes R.E.AL avec copies des pièces justificatives, à l AC (autorité de certification) dans les délais Transmettre périodiquement à lAC lensemble des pièces relatives à la vie des certificats Transmettre les demandes de récupérations des cartes R.E.AL bloquées et des codes dans les délais

36 36 Opérateur De Service De Certification Rôles La réception des ordres de fabrication des cartes R.E.AL La génération des cartes R.E.AL. et code PIN en respectant les règles établies dans la PC et la présente DPC La transmission des cartes aux AE La transmission des codes PIN aux titulaires La livraison et la maintenance des kits de sécurité utilisés par les abonnés du R.E.AL La réception des ordres de révocation de lAC La publication des certificats valides La publication des LCR Lassistance en ligne pour la mise en œuvre des moyens mis à la disposition des abonné(e)s

37 37 Opérateur De Service De Certification Rôles La gestion de lensemble du cycle de vie des certificats émis pour les abonnés Larchivage des certificats et des LCR La gestion des journaux et des archives informatiques La fourniture à l AC des moyens d'accès aux journaux et aux archives Lhorodatage La récupération des cartes R.E.AL en cas de blocage et des codes PIN en cas doublie La garantie à travers le R.E.AL. dun accès continu à lensemble des certificats

38 38 Opérateur De Service De Certification Obligation en matière de sécurité de linformation Conserver et protéger en confidentialité les données confidentielles relatives aux titulaires, en particulier les causes de révocations Garantir la validité et lintégrité des données publiées (annuaire des certificats valides et LCR) Garantir lintégrité des certificats stockés dans les cartes à puces R.E.AL Garantir lintégrité des transferts des cartes R.E.AL aux AE Garantir lintégrité des transferts des codes PIN aux titulaires Garantir lintégrité des clés privées Contrôler les accès aux données publiées

39 39 Opérateur De Service De Certification Obligation en matière de disponibilité de linformation Respect de la fréquence de publication des certificats valides et des listes de révocations, Respect des délais transmission des codes PIN aux titulaires, et des cartes R.E.AL aux AE Respect du délai de récupération des archives

40 40 Déclaration Des Pratiques De Certification

41 41 Déclaration Des Pratiques De Certification De Losc Organisation interne de lOSC Contrôle du personnel de lOSC Contrôle de sécurité physique Contrôle de sécurité du système de traitement des informations Contrôle de conformité (audit) de lOSC

42 42 Président de lOSC Administrateur Responsable de lhorodatage Responsable de gestion Responsable de publication Ingénieur système Responsable de sécurité Opérateur de fabrication Opérateur de gestion Opérateur de publication Agent de sécurité Responsable de fabrication Organisation Interne De Losc Héritage Fonctionnel

43 43 Contrôle Du Personnel De L'osc Clauses de confidentialité Procédures interne de fonctionnement Enquête sur le passé professionnel/personnel Compétenence qualification et fréquence de formation Les sanctions Documentations fournies au personnel

44 44 Les Procédures Procédure IV: génération et transmission des ordres de fabrication à losc Procédure V: génération des cartes R.E.AL et codes PIN Procédure VI: transmission des cartes R.E.AL aux AE Procédure VII: transmission des codes PIN aux titulaires Procédure XIII: génération et transmission des ordres de révocations à lOSC Procédure xiv:traitement des révocations

45 45 Les Procédures Procédure xvi:publication des LCR Procédure xviii:enregistrement et transmission des demandes de récupération à losc Procédure xix:traitement de la demande de récupération Procédure xxi:renouvellement des cartes R.E.AL Procédure xxii:demande dinformations Procédure XXVII: journalisation des évènements Procédure XXVIII: archivages

46 46 Les Procédures Procédure XXXI: changement des clés de lOSC Procédure XXXII: plans durgences Procédure XXXIII: révocation du certificat racine Procédure XXXV: révocation des certificats de lOSC Procédure XXXVI: cessation dactivité ou fin de vie de la composante Procédure xxxvii:indemnisation par lICP

47 47 Profil de protection

48 48 COMPOSANTS (1) Les autorités d'enregistrement (notées AE) collectent les informations nécessaires à lidentification des utilisateurs et vérifient leurs droits pour les communiquer aux AC. Les autorités de certification (notées AC) ont pour principale fonction de signer les certificats et de communiquer au centre de publication les certificats de clés publiques. Les AC assurent la révocation des certificats qui ne sont plus de confiance, ainsi que la mise en publication de la liste des certificats révoqués (CRL). Le Centre de Publication (noté CP) assure, sur demande des AC, la publication des certificats et des listes de révocation au sein de lIGC et pour les applications utilisatrices.

49 49 COMPOSANTS (2) Le Centre de Génération de Clés (noté CGC) assure, sur demande de l'AC, la génération de bi-clés. Il transmet alors la clé publique à l'AC pour certification Une Base de Données (noté BD) qui contient tout les biens sensibles de la TOE : les clés privées, les évènements daudit, les codes PIN et les codes de déblocage des exploitants, les attributs de sécurité des exploitants et des rôles. Tous ces biens sont chiffrés à laide de clés symétriques, de plus, certains dentre eux sont protégés en intégrité.

50 50 REFERENCE A DES PROFILS DE PROTECTION PP_AC : Profil de protection pour une autorité de certification dans le cadre dune infrastructure de gestion de clés. PP_AE : Profil de protection pour une autorité d'enregistrement pour une infrastructure de gestion de clés. PP_IGC : Profil de protection pour une infrastructure de gestion de clés. PP_RCIGC Profil de protection pour les ressources cryptographiques d'une infrastructure de gestion de clés.

51 51 HYPOTHÈSES Dans cette cible dévaluation, il est considéré : - quaucune hypothèse nest définie sur la nature des relations entre AC (graphe et hiérarchie); - quaucune hypothèse nest définie sur le caractère générique des AC (AC dédiée à une ou plusieurs applications); - quaucune hypothèse nest définie sur les supports de communication entre lAC et les composantes de lIGC (réseaux ouverts ou fermés). Par définition, un grand nombre de mesures de protection mises en œuvre au sein dune IGC sappuie sur des mécanismes cryptographiques. Le fonctionnement de lIGC est régi par une politique de sécurité.

52 52 SERVICES VITAUX S_DATAREVOC : recevoir et authentifier les demandes de révocation transmises par l'AE, S_REVOC : générer les listes de certificats révoqués (notés CRL), S_TRANSREVOC : transmettre les demandes de publication de CRL au Centre de Publication, S_AUDIT : enregistrer des traces sur toutes les opérations effectuées en sassurant de leur imputabilité.

53 53 SERVICES ÉLÉMENTAIRES S_ADMIN : gérer les profils et les droits des exploitants, configurer le poste AC et superviser les actions réalisées (S_AUDIT), S_AUTHEN : identifier et authentifier des exploitants, S_DATACERT : recevoir et authentifier les demandes de certificats et de renouvellement transmises par l'AE ; ces demandes peuvent être accompagnées d'une demande de génération de bi-clé, à transmettre au CGC, S_CERTIF : générer les certificats et renouveler des certificats demandés par l'AE, S_TRANSCERT : transmettre les demandes de publication de certificats au Centre de Publication,

54 54 ENVIRONNEMENT Service de Publication demande de publication de certificats et CRL CGC AE demande de génération de bi-clé retour clé publique demandes : certificats, cartes, révocations ou renouvellement Poste informatique de l' AC BD Service de personnalisation TOE demande de personnalisation de cartes Lecteur(s) de carte à puce informations didentification et dauthentification

55 55 ENVIRONNEMENT SUITE Les systèmes d'exploitation sont Windows NT 4.0 et Windows Le logiciel TrustyKey nécessite la présence d'une base de données. Les bases de données supportées sont Oracle et SQL-Serveur. TrustyKey fonctionne avec un contrôle direct par carte à puce. La TOE est hébergée sur une plate-forme informatique (matériel, logiciel, réseaux) s'appuyant sur les ressources cryptographiques du CGC. La TOE couvre le développement, linitialisation et lexploitation de lAC ainsi que les états transitoires (livraison, installation). Les ordinateurs sont reliés entre eux par un réseau Ethernet 100 Base T, sous TCP/ IP. Les réseaux locaux dans une même pièce, sans connexion vers lextérieur sont considérés comme sécurisés. Le personnel autorisé à utiliser le système est habilité par lorganisme utilisant TrustyKey. Tous les locaux entreposant le système ou une partie du système sont sous haute surveillance (contrôle daccès, gardiennage …).

56 56 RÔLES Utilisateurs Rôles d administration Ingénieur système Master-administrateur Rôles de service Officier de certification Opérateur de certification. Officier de gestion Superviseur

57 57 TYPOLOGIE DES ATTAQUANTS un exploitant autorisé mais pouvant commettre une erreur ou un acte de malveillance, les personnes ou machines qui disposent de moyens d'investigation et d'action sur les réseaux supports de la TOE, les personnes ou machines qui disposent de moyens d'investigation et d'action sur la TOE (personnel de passage sur le site de la TOE, personnel de nettoyage, gardien, etc.).

58 58 BIENS A PROTEGER Les demandes émises par l AC B.DEM_CERTIF, B.DEM_REVOC, B.DEM_BICLE,… Les demandes reçues par l AC B.DEM_PUB_CERTIF, B.DEM_PUB_REVOC, B.DEM_GEN_BICLE les données internes à l'AC B.TRACES_AUDIT, B.CONFIG les services assurés par l'AC B.SERVICES

59 59 MENACES Issues des EBIOS M.CONFIDENTIALITE M.INTERGRITE M.SINISTRE M.MASCARADE M.VOL …. M.REPUDIATION : un utilisateur ou un exploitant nie être l'auteur d'une action. Reniement dactions (EBIOS 41) Cette menace concerne les actions déclenchées par l'AC, donc les biens suivants : B.DEM_PUB_CERTIF, B.DEM_PUB_REVOC, B.DEM_GEN_BICLE.

60 60 AUTRES HYPOTHESES Politiques d organisation (références) Hypothèses d utilisation

61 61 OBJECTIFS DE LA TOE (EXEMPLES) OT.IDENT : la TOE doit être capable d'identifier de façon unique et dauthentifier les utilisateurs avant dautoriser tout accès aux biens protégés par la TOE. OT.NOBUG : la TOE ne doit pas présenter de défauts majeurs de développement qui remettraient en cause sa capacité à remplir sa mission : cela concerne en particulier la qualité de développement des composants logiciels ou matériels de la TOE. OT.TRACE : toute opération réalisée par un exploitant de la TOE doit être tracée, et imputable à son auteur. L'intégrité des traces doit être garantie par la TOE. OT.PROTECT_DATA : la TOE doit limiter l'accès aux biens confidentiels qu'elle manipule aux personnes ayant le besoin d'en connaître, conformément aux rôles identifiés. En particulier, la TOE doit contrôler l'accès aux biens suivants : B.TRACES_AUDIT, B.CONFIG.

62 62 EXIGENCES FONCTIONNELLES (EXEMPLE) FAU_GEN.1 Génération de données daudit FAU_GEN.2 Lien avec lidentité de lutilisateur FAU_SAR.1 Revue daudit FAU_SAR.2 Revue daudit restreinte FAU_SAR.3 Revue daudit sélective FAU_STG.2 Garanties de disponibilité des données daudit FAU_STG.4 Prévention des pertes de données daudit

63 63 EXEMPLE DE SPECIFICATION FCO_NRO.2.1 La TSF doit mettre en œuvre la génération de la preuve de lorigine à tout moment pour [ les demandes émises par l'AC ] transmises. Raffinement : "les demandes émises par l'AC" pour lesquelles une preuve d'origine sera générée sont les demandes de publications B.DEM_PUB_CERTIF, B.DEM_PUB_REVOC et les demandes de génération de bi-clés B.DEM_GEN_BICLE. Raffinement : Dans POLITIQUE_SECU, ces demandes correspondent aux demandes de mise en publication de certificats, de CRL, ou dARL envoyées au Centre de Publication (DEM_PUB_CERT, DEM_PUB_AUT, DEM_PUB_CRL, DEM_PUB_ARL),et les demandes de génération de bi-clé à transmettre au Centre de Génération de Clés (DEM_GEN )

64 64 NIVEAU D ASSURANCE EAL 3 avec modèle informel de la politique de sécurité

65 65 EXEMPLE: GESTION DE CONFIGURATION

66 66 CONCEPTION FORMELLE

67 67 CONCEPTION DESCRIPTIVE

68 68 TRACABILITE

69 69 "PREUVE INFORMELLE »: COUVERVURE DES MENACES PAR LES OBJECTIFS


Télécharger ppt "1 Infrastructures à Clefs publiques Public Key Infrastructure (PKI) Stéphane Natkin 2006."

Présentations similaires


Annonces Google