Infrastructures à Clefs publiques

Public Key Infrastructure

(PKI)

Stéphane Natkin
2006

1
 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

2
 Différentes utilisation d’une ICP
• Il peut s’agir d’un moyen interne d’authentification des
ressources et des personnes, ainsi que le support de la
gestion de clefs de chiffrement.
• Il peut s’agir, dans le cadre d’un accord contractuel entre
entités, d’un moyen support d’authentification et de
chiffrement, mais également d’une signature
électronique faisant foi dans les rapports entre les
signataires des contrats.
• Enfin il peut s’agir d’une infrastructure support de la
signature électronique de droit public. Une signature
générée à partir d’un bi clefs de l’infrastructure doit
donc être valide devant les tribunaux au même titre que
la signature manuelle
3
 ANNUAIRE
DES
CERTIFICATS
NOM Clef Validité Extensions Signature

Alice a Valida Para  Alice, a, Valida, Para SIG

AC

Bob b Validb Parb  Bob, b, Validb, Parb SIG

AC

Charles c Validc Parc  Charles, c, Validc, Parc SIG

AC

AC: autorité de certification

Norme de représentation des certificats X509
Norme de protocole d’accès: LDAP
4
 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

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

6
 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 l’autorité de certification pour signer le certificat.
• issuer Name : C'est le nom de l’autorité de certification qui a émise et signé le certificat.
Ce nom est codé selon une syntaxe le la norme d’annuaire 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 l’entité possesseur du certificat, qui à
l’usage 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

7
 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 {
algorithm ALGORITHM.&id({SupportedAlgorithms}),
parameters ALGORITHM.&Type ({SupportedAlgorithms}
{@algorithm}) 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 }}
}

8
 Extensions
• SubjectType : Précise si le possesseur (subject) est un
utilisateur du certificat ou s’il s’agit d’un certificat de
signature d’une autorité de certification.
• Keyattributes précise diverses données sur la clef
publique.
– KeyUsage  est l’extension la plus importante. Elle décrit le
ou les utilisations autorisées du certificat.
– privateKeyUsagePeriod  permet de limiter l’usage des clefs
privées avant l’expiration du certificat
– subjectKeyIdetifier et authorityKeyIdentifier permettent de
donner un numéro unique à ces deux clefs.

9
 Renouvellement des clefs

Période de validité du dernier

certificat signé avec Caut

Période de validité de la clef privée

associée à Caut

Période de validité de Caut

T+t/2 T+t

10
 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

11
Carte Annuaire de référence Autorité
Personnalisation Autorité de des d’enregistrement
Certification certificats locale
et de CRL

Horodateur
Certifié Garde Barrière

Disquette Serveur
de certificats et de CRL

Internet/
Intranet

Utilisateurs
Clients ou serveurs

Garde Barrière

Station
Base locale
de
certificats
12
 FONCTIONNEMENT DES INFRASTRUCTURES À
Carte
CLEFS PUBLIQUES(PKI) Autorité
Personnalisation Autorité de d ’enregistrement (RA)
Certification
X.509

Carte Autorité

Horodateur Annuaire de
Certifié certificats
Disquette
et de CRL

Client

Internet/ Serveur
Station Intranet
Client

Station 13
l’Autorité de Certification (AC ou
CA Certification Authority)
C’est 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 d’engagement qui doit
permettre à un tiers de juger s’il peut utiliser un certificat
pour une application donnée.

14
 L’autorité d’enregistrement (AE)
L’AC 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 l’Autorité d’Enregistrement (AE ou RA Registration
Authority).

• L’autorité d’enregistrement collecte les demandes de certificats avec le

informations nécessaires aux vérification d’identité.
• Elle transmet cette demande à l’AC et sert d’intermé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 d’intermédiaire pour les révocations (en cas
de perte de cartes par exemple).

15
 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 l’y oblige. Un tiers de séquestre,
séquestre donc des clefs de déchiffrement.
Horodatage de confiance: Il s’agit d’offrir un accès à un
serveur de temps permettant de dater de documents faisant
l’objet de signatures électroniques. Les propriétés de ce
serveur doivent couvrir les attaques d’anti et post datage
du document.

16
 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 s’authentifier
Soit dater et signer sa réponse
Soit transmettre périodiquement des listes
de révocation datée et signées
17
 CONTRÔLE DES CERTIFICATS

Procédure Contrôler_Certificat(in :certificat, out : statut)

Début
% Soit C=(Autor,125,Alice,a,01/01/2001-31/12/2002,Sig) le certificat %
Etape 1 % Contrôle de la signature de l’autorité %
Si Sig incorrecte alors
statut := “la signature est incorrecte, le certificat n’est pas valide ” ;
retour ;
Sinon
% comme les données contenues dans le certificat ont été générée par Autor et n’ont pas été altérée, %
passer à l’étape 2 ;
fsi
Etape 2 % Contrôle de la date de validité du certificat %
Si (date_courante<01/01/2001 ou date_courante>31/12/2002)
statut := “ certificat périmé ” ;
retour ;
Sinon passer à l’étape 3 ;
fsi

18
 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 qu’une 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
fsi

19
 CONTRÔLE DES CERTIFICATS

Etape 5 % Vérification de la non-répudiation du certificat d’Alice%

Si (125liste)
statut := “ certificat d’Alice est révoqué ” ;
retour ;
Sinon % certificat valide %
statut :=OK ;
retour ;
fsi
fin

20
 STOCKAGE DES CLEFS ASYMÉTRIQUES

Clef publique de l’autorité, 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é

21
 Autorité
Internationale
SYSTÈME
ASYMÉTRIQUE: Certificat auto-
signé
HIÉRARCHIE DES Autorité Autorité
AUTORITÉS DE nationale nationale
CERTIFICATION Certificat signé Certificat signé
(CHAÎNE DE par l’autorité par l’autorité
internationale internationale
Autorité Agent de l’état
CERTIFICATION) professionnelle
ou Certificat signé par
commerciale l’autorité nationale

Certificat signé par

l’autorité nationale
Personne Individus
morale
Certificat d’identité
Certificat signé par signé par un agent
l’autorité de l’état
professionnelle ou
commerciale

Personnel/ Services Web

Clients/
Fournisseurs Certificat signé par
la personne morale
Certificat signé par
la personne morale

Objets Objets
informatiques Clefs de informatiques
session
Certificat signé par Certificat signé par
l’utilisateur l’utilisateur ou un 22
objet prestataire de
service
 Certification croisée

ACA
BSE

Alice ACA.PC BSE.PE BSE.OS Bob

Charles Dominique Eponine Françoise Gérard Henri

23
 Récupération des certificats (1)

Alice CA
Alice CA
Requête signée
Requête signée

Réponse chiffrée

Réponse signée
Mot de passe
(Par la poste)

Alice RA CA
Requête Requête signée
Se présente
physiquement au
RA
Réponse signée
Réponse

24
 Récupération des certificats (2)

Alice RA CA
Requête Requête signée
Se présente + mot de passe
physiquement au chiffré
RA

Mot de passe

Requête authentifiée avec

le mot de passe

Réponse

CMP (Certificate Management Protocol) RFC 2510 et 2511

CMC (Certificate Management Protocol using CMS) la RFC 2797.
25
Politiques De Certification Du
R.E.AL

26
 La politique de certification
• L’objectif général du service offert,
• Les types de certificats délivrés et leurs usages
• L’organisation des composants de l’ICP
• La hiérarchie de certification
• les principes de gestion du cycle de vie d’un certificat et en particulier
les contrôles d’identité réalisés lors de la délivrance et les conditions et
moyens d’une 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

27
 Classes De Certification

Classe 0 : applicable aux systèmes et objets

informatiques

Classe 1 : applicable aux employés des études notariales

et composantes de l’ICP

 Classe 2 : applicable aux notaires en exercices

Classe 3 : applicable aux autorités de certification

28
 Politiques De Certification

Signature des Signature des

Authentification Chiffrement
documents certificats

Classe 0 XXXXXX

Classe 1 XXXXXX

Classe 2 XXXXXXX XXXXXX XXXXXX

Classe 3 XXXXXXX XXXXXXX XXXXXX

29
 Chaîne De Certification Du R.E.AL

Certificat Auto Signé

Autorité de Certification
Signature des LAR
Racine (Niveau 0)

CSN

LAR

Certificats Signé par l ’AC

Autorité OSC Titulaire AC

Signature des LCR Serveur Gestion
Temps OSC
Niveau 1 Niveau
TTS
1
Niveau 1
CSN
Niveau 1
ADSN ADSN
LCR ADSN

Certificats Signé par  l’OSC

Titulaire Titulaire Titulaire

membre abonné machine
Niveau
Niveau 2 Niveau 2 2

30
 Certificat

• Type de certificats
.Authentification : certificats destinés à l’authentification 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 l’encodage

(cryptage) des données et des clés de session

.Signature des certificats : certificats utilisés pour la signature des

certificats

31
 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 l’entité d’horodatage, une carte de
l’entité de fabrication contient un certificat de signature des certificats
de niveau 2 et des LCR, et une carte de l’entité 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 d’authentification et de chiffrement de
classe 1

32
 ICP dans son Environnement

Autorité de Certification
Transmission Opérateur de Service de
Certification
ICP .Mise en œuvre de la PC et DPC
des codes PIN Validation des demandes de cartes R.E.AL
aux Titulaires Édition des LCR
Édition des certificats valide
 Génération des cartes et
Certificat Racine AC niveau 0
codes PIN
Signature des certificats de niveau 1
Ordres de fabrications
Signature de la LAR Signature des
Certificats Autorité Ordres de CSN LAR
OSC révocations
Niveau 1
Horodatage Accusés de Certificat Titulaire AC
Publication des Signature des réception Niveau 1
LCR certificat de niveau
Signature des ordres de
2
fabrication
Signature des LCR
ADSN Signature des ordres de
révocation

Transmissio Transmission des

n des demandes de cartes
demandes R .E.AL LA R
de Transmission des
demandes de révocations
récupération
LCR des cartes et
code PIN Accusés de réception

Autorité d’Enregistrement Autorité Autorité

d’Enregistrement d’Enregistrement
Vérification et Enregistrement
des Demandes de cartes
Transmission R.E.AL.
des cartes Remise des cartes R.E.AL aux
R.E.AL Titulaires Abonnées

CRN CSN
CDN

Consultation
des LAR

Consultation des LCR

Demande de carte R.E.AL.
Demande de révocation
Demande de récupération

Remise des cartes R.E.AL

Titulaire Titulaire Titulaire Titulaire

33
  Autorité De Certification

• Rôles
 Mettre en œuvre la PC et la DPC
 Générer sa clé privée, les clés de l’OSC (clé de génération des cartes et la clé de
l’horodatage) et ceux des titulaires AC,
 Vérifier les données d’enregistrement, 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 qu’il
révèle,
 Signer et transmettre les ordres de fabrication des cartes R.E.AL. À l’OSC
 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 l’ICP dans le cas d’un échec de contrôle de conformité
 Fournir les renseignements sur les certificats pour toute demande de notaire
 Réception des demandes de révocation d’urgence

34
  Autorité De D ’Enregistrement
• Rôles
 Vérifier l'identité, la véracité des pièces justificatives, et l’exactitude des mentions qui
établissent l’identité 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 l’exactitude, 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 à l’AC l’ensemble 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

35
  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 l’AC
 La publication des certificats valides
 La publication des LCR
 L’assistance en ligne pour la mise en œuvre des moyens mis à la
disposition des abonné(e)s

36
 Opérateur De Service De Certification
• Rôles
 La gestion de l’ensemble du cycle de vie des certificats émis pour les
abonnés
 L’archivage 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
 L’horodatage
 La récupération des cartes R.E.AL en cas de blocage et des codes PIN
en cas d’oublie
 La garantie à travers le R.E.AL. d’un accès continu à l’ensemble des
certificats

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

38
 Opérateur De Service De Certification
• Obligation en matière de disponibilité de l’information

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

39
Déclaration Des Pratiques De
Certification

40
 Déclaration Des Pratiques De
Certification De L’osc

 Organisation interne de l’OSC

 Contrôle du personnel de l’OSC
 Contrôle de sécurité physique
 Contrôle de sécurité du système de
traitement des informations
 Contrôle de conformité (audit) de l’OSC

41
 Organisation Interne De L’osc
Héritage Fonctionnel
Président de l’OSC
Président de l’OSC

Administrateur
Administrateur

Responsable de Responsable de Responsable de Responsable de Responsable Ingénieur

Responsable de Responsable Responsable de Responsable de deResponsable Ingénieur
l’horodatage publication de gestion fabrication sécurité système
l’horodatage publication gestion fabrication de sécurité système

Opérateur de Opérateur de Opérateur de Agent de

Opérateur de
publication Opérateur
gestion de Opérateur de
fabrication Agent de
sécurité
publication gestion fabrication sécurité

42
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

43
 Les Procédures

 Procédure IV: génération et transmission des ordres de fabrication

à l’osc
 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 à l’OSC
 Procédure xiv:traitement des révocations

44
 Les Procédures

 Procédure xvi:publication des LCR

 Procédure xviii:enregistrement et transmission des demandes de
récupération à l’osc
 Procédure xix:traitement de la demande de récupération
 Procédure xxi:renouvellement des cartes R.E.AL
 Procédure xxii:demande d’informations
 Procédure XXVII: journalisation des évènements
 Procédure XXVIII: archivages

45
 Les Procédures

 Procédure XXXI: changement des clés de l’OSC

 Procédure XXXII: plans d’urgences
 Procédure XXXIII: révocation du certificat racine
 Procédure XXXV: révocation des certificats de l’OSC
 Procédure XXXVI: cessation d’activité ou fin de vie de la
composante
 Procédure xxxvii:indemnisation par l’ICP

46
Profil de protection

47
 COMPOSANTS (1)
 Les autorités d'enregistrement (notées AE) collectent les informations
nécessaires à l’identification 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 l’IGC et
pour les applications utilisatrices.
48
 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 d’audit, 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 à l’aide de clés
symétriques, de plus, certains d’entre eux sont protégés en intégrité.

49
REFERENCE A DES PROFILS DE
PROTECTION
 PP_AC : Profil de protection pour une autorité de certification dans le
cadre d’une 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.

50
 HYPOTHÈSES
Dans cette cible d’évaluation, il est considéré :
• - qu’aucune hypothèse n’est définie sur la nature des relations
entre AC (graphe et hiérarchie);
• - qu’aucune hypothèse n’est définie sur le caractère générique
des AC (AC dédiée à une ou plusieurs applications);
• - qu’aucune hypothèse n’est définie sur les supports de
communication entre l’AC et les composantes de l’IGC
(réseaux ouverts ou fermés).
• Par définition, un grand nombre de mesures de protection
mises en œuvre au sein d’une IGC s’appuie sur des
mécanismes cryptographiques.

Le fonctionnement de l’IGC est régi par une politique de sécurité.

51
 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 s’assurant de leur
imputabilité.

52
 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,

53
 ENVIRONNEMENT
CGC

demande de génération de bi-clé

retour clé publique

demandes :
demande de certificats, cartes,
publication de révocations ou
certificats et CRL renouvellement
Service de Poste informatique AE
Publication de l' AC

informations d’identification et
Service de d’authentification
personnalisation demande de
personnalisation de
cartes Lecteur(s) de carte à
BD puce

TOE

54
 ENVIRONNEMENT SUITE
• Les systèmes d'exploitation sont Windows NT 4.0 et Windows 2000.
• 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, l’initialisation et l’exploitation de l’AC 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 l’extérieur sont
considérés comme sécurisés.
• Le personnel autorisé à utiliser le système est “ habilité ” par l’organisme utilisant
TrustyKey. Tous les locaux entreposant le système ou une partie du système sont sous
haute surveillance (contrôle d’accès, gardiennage …).

55
 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

56
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.).

57
 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

58
 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 d’actions (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.

59
 AUTRES HYPOTHESES
• Politiques d ’organisation (références)
• Hypothèses d ’utilisation

60
 OBJECTIFS DE LA TOE
(EXEMPLES)
• OT.IDENT : la TOE doit être capable d'identifier de façon unique et
d’authentifier les utilisateurs avant d’autoriser 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.

61
EXIGENCES FONCTIONNELLES
(EXEMPLE)
• FAU_GEN.1 Génération de données d’audit
• FAU_GEN.2 Lien avec l’identité de l’utilisateur
• FAU_SAR.1 Revue d’audit
• FAU_SAR.2 Revue d’audit restreinte
• FAU_SAR.3 Revue d’audit sélective
• FAU_STG.2 Garanties de disponibilité des données d’audit
• FAU_STG.4 Prévention des pertes de données d’audit

62
EXEMPLE DE SPECIFICATION
FCO_NRO.2.1 La TSF doit mettre en œuvre la génération de la preuve de
l’origine à 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 d’ARL
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 )

63
 NIVEAU D ’ASSURANCE

EAL 3 avec modèle informel de la politique de sécurité

64
EXEMPLE: GESTION DE
CONFIGURATION

65
CONCEPTION FORMELLE

66
CONCEPTION DESCRIPTIVE

67
TRACABILITE

68
 "PREUVE INFORMELLE »:
COUVERVURE DES MENACES
PAR LES OBJECTIFS
M.MASCARADE OT.IDENT - L'identification et l'authentification des
OT.TRACE exploitants rendent difficile cet abus, le contrôle
OT.ADMINIS d'accès physique à la TOE venant renforcer ces
OE.SENSIB_EXPL objectifs.
OE.ACCES - La sensibilisation des exploitants, à la
nécessité de protéger leurs moyens
d'authentification notamment, rend moins
probable la possibilité de réussir une telle
attaque.
- La séparation des tâches et la nécessaire
collaboration entre exploitants, ainsi que
l'administration correcte de ces rôles renforce le
contrôle de légitimité des exploitants.
- La traçabilité de toutes les opérations, et
l'exploitation de ces traces aide à détecter une 69
éventuelle mascarade.