MISE EN PLACE D’UNE INFRASTRUCTURE À CLÉS PUBLIQUES (ICP) ENJEUX ET CONFORMITÉUNE VISION PRATIQUE

HECTOR SZABO – THOMAS PORNIN

CONFÉRENCIER HECTOR SZABO

DATE 31 MARS 2015

http://www.isaca‐quebec.ca

2

OBJECTIF ET AGENDAObjectif Décrire les enjeux principaux lors de la mise en place, opération et amélioration d’une ICP

Agenda Concepts entourant une ICP Certificats numériques et infonuagique Gouvernance et ICP: impacts sur l’audit et la conformité WebTrust 2.0: un encadrement robuste Montage et audit d’une Autorité de Certification: défis pratiques  Utiliser des certificats: quelques orientations Conclusions

3

Concepts entourant une ICPInfrastructures à clés publiques

4

INFRASTRUCTURE À CLÉS PUBLIQUES (OQLF)

Système permettant la gestion de clés de chiffrement constituées de séquences de symboles et la délivrance de certificats numériques, tout en assurant la sécurité et la confidentialité des échanges d'information et des transactions électroniques par des réseaux informatiques comme Internet.

4

5

AUTORITÉS DE CERTIFICATION: POURQUOI?Objectifs Identifier les partenaires d’affaires sans ambigüités Simplifier et uniformiser les procédures d’autorisation Permettre la signature numérique Assurer la non‐répudiation des transactions Assurer la non‐répudiation de la date et heure des transactions Assurer la pérennité des signatures numériques  Assurer la confidentialité des communications Assurer la confidentialité des contenus Permettre la récupération de contenus confidentiels

6

SERVICES ET COMPOSANTES POSSIBLES D’UNE SOLUTION D’ICP

Identité et clés

Identification / émission de certificats

Révocation et publicationde certificats 

annulés 

Publication des certificats (annuaire)

Conservation des certificats et historique 

des clés

Sauvegarde des clés 

(chiffrement)

Recouvrement des clés 

(chiffrement)

6

Autres services

Certification croisée

Solutions d’itinérance

Provision de jetons logiques

Chiffrement

Horodatage

Signature (non 

répudiation)

7

IDENTITÉ

Identification •Annoncer dans un format normalisé les données nominatives de l’utilisateur•Établir les données requises•Supporter différents moyens de discrétion et anonymat

Authentification •Assurer l’intégrité des données d’identification présentées•Utiliser des moyens normalisés pour la vérification de l’intégrité

Autorisation•Fournir des moyens normalisés pour décider les accès aux ressources fournies•Admettre la délégation dans la gestion des accès•Admettre la fédération des identités et droits sur la base d’indicateurs de qualité 

8

CRYPTOGRAPHIE: BASES ET UTILISATION

9

CHIFFREMENTASSURE LA CONFIDENTIALITÉ

• Chiffrement : transformation des données pour les rendre inintelligibles.

• Le chiffrement utilise un algorithme (public) et une clé (secrète).

• L’opération est réversible (déchiffrement) à condition de connaître la clé.

Le chiffrement réduit le problème de la confidentialité des données à celui de la confidentialité de la clé.

9

10

MACMESSAGE AUTHENTICATION CODE : ASSURE L’INTÉGRITÉ

• Calcul d’une somme de contrôle sur des données binaires arbitraires, paramétré par une clé secrète.

• Le MAC est recalculé par le destinataire, en utilisant la même clé.

• Sans la clé, impossible de reproduire un MAC valide.

10

b7 22 a1 84 97 a5 24 75 c8 45 c2 f6 f8 34 c3 a6 ed ba 27 7a

EF1C3A

Hash

Lorem ipsum dolor sit amet, consecteturadipiscing elit. Praesent vitae sem dolor. 

Suspendisse interdum purus non nisl ultricies, actempus odio efficitur. 

Le contrôle d’intégrité est important pour assurer la confidentialité (attaques actives qui observent le comportement du destinataire sur des données modifiées).

11

CHIFFREMENT ASYMÉTRIQUE• Chiffrement asymétrique : la clé de chiffrement

et la clé de déchiffrement sont mathématiquement liées, mais distinctes.

• On peut rendre publique la clé de chiffrement, sans révéler la clé de déchiffrement (clé privée).

• RSA, ElGamal, ECIES…

Le chiffrement asymétrique transforme le problème de distribution de clés secrètes en un problème de distribution de clés publiques.

11

12

POURQUOI ASYMÉTRIQUE• Le chiffrement symétrique requiert des prévisions 

pour la distribution, conservation et destruction de la clé symétrique utilisée.

• La gestion de la clé unique requiert le même niveau de sécurité et de moyens de prévention du risque sur tous les utilisateurs de la même clé

• La robustesse de la distribution de clés symétriques revient au maillon le plus faible des lignes et moyens de distribution 

13

SIGNATURE

13

• La signature utilise le chiffrement assymétrique

• La clé de génération de signature, et la clé de vérification de signature, sont distinctes.

• Algorithmes : RSA, DSA, ECDSA…

• Les signatures sont un outil utile pour la non‐répudiation.

• Il n’est pas conseillé d’utiliser la même clé pour le chiffrement asymétrique et pour les signatures.

• Une clé publique n’est pas une identité.

Signature

• Contenant protégé

• Longue durée

Chiffrement

• Tiers de confiance

• Cycle court

14

CERTIFICATS NUMÉRIQUES ET INFONUAGIQUE

Cryptographie et son utilisation dans les interactions dans l’infonuagique

15

CERTIFICATS

15

• Certificat : établit le lien entre une identité et une clé publique.

• Le certificat est émis (signé) par une Autorité de Certification.

• Standard : X.509.

Un certificat contient :

• Un numéro de série

• L’identité du propriétaire du certificat

• L’identité de l’AC qui a émis le certificat

• La clé publique du propriétaire du certificat

• Des dates de validité

• Des extensions…

16

CERTIFICATS : ÉMISSION

16

• L’Autorité d’Enregistrement (Registration Authority) :fait le lien entre l’identité physique et la clé publique, via une procédure (par exemple rencontre en personne avec le détenteur de la clé).

• L’AE communique à l’AC la clé publique et l’identité ; l’AC émet le certificat.

• La clé publique voyage sous la forme d’une requête de certificat (PKCS#10, CMC…).

• La clé privée ne sort pas du contrôle du détenteur.

• Variante : la paire de clé est générée par l’AC, et communiquée au détenteur avec le certificat.

17

CERTIFICATS : CHAÎNES

17

Nom: Jeanne TremblayDate d’émission: 2012/04/20Date d’échéance: 2015/04/20Numéro de série: 122aced2Émetteur: AC FooBarEmetUtilisation du certificat…Autres données

0EVwRUMEZDM9K777i3Ge jDqyCzEN2iv7SyDqCwXE

Nom: AC FooBarEmetDate d’émission: 2012/01/10Date d’échéance: 2018/01/10Numéro de série: a234efa1Émetteur:AC Racine FooBarUtilisation du certificat…Autres données

KedJuTob5gtvYx9qM3k3gm7kbLBwVbEQRl26S2tmXjqNND7MRGtoew==

Signé avec la clé privéeDe l’autorité racine

Nom: AC Racine FooBarDate d’émission: 2011/01/10Date d’échéance: 2037/01/10Numéro de série: aa234113Émetteur:AC Racine FooBarUtilisation du certificat…Autres données

Signale où retrouver le Certificat et la liste de certificats révoqués de

l’autorité de certificationémettrice

Signale où retrouver le Certificat et la liste de certificats révoqués de

l’autorité de certificationracine

Utilisateur

Signé avec la clé privéeDe l’autorité de certification

Auto‐signéPar l’autorité racine

18

CERTIFICATS : CHAÎNES

18

• Pour vérifier la signature sur un certificat, il faut connaître la clé publique de l’AC → le problème a été déplacé.

• Chaque participant connaît quelques clés d’AC « racines » a priori (installées avec le système d’exploitation ou par l’administrateur).

• Une AC non‐racine est dite « intermédiaire ».

• Chaque certificat peut contenir un lien (URL) vers le certificat de son AC émettrice.

• La validation est un processus compliqué dont l’élément principal est la vérification des signatures cryptographiques.

19

CERTIFICATS : RÉVOCATION

19

20

CERTIFICATS : RÉVOCATION

20

• Révocation : permet de déclarer des certificats comme invalides.

• Publication régulière de Certificate Revocation Lists qui contiennent les numéros de série des certificats révoqués. Chaque CRL est signée (normalement par l’AC elle‐même) et a une durée de vie brève.

• Un certificat contient des liens (URL) vers la CRL qui le concerne.

• La validation du certificat comporte la vérification de CRL .

Le mécanisme de révocation est fonctionnellement équivalent à une réémission automatique de certificats à courte durée de vie.

21

CARTE À PUCE• Une carte à puce est un dispositif blindé qui fabrique, stocke et utilise une 

clé privée.

• La carte authentifie son détenteur via un code PIN.

21

22

CARTE À PUCE : INITIALISATION

22

• Le code PIN est normalementchoisi par l’utilisateur.

• Le code PIN est un mot de passe.

• La carte à puce se bloque après plusieurs tentativesinfructueuses.

• L’initialisation est souvent faitesous contrôle de l’AE : l’utilisateurreçoit sa carte et son certificat enmême temps.

23

CARTE À PUCE : GÉNÉRATION DES CLÉS

23

• La carte contient un accélérateur cryptographique qui lui permet de fabriquer efficacement une nouvelle paire de clés (quelques secondes).

• Le certificat est obtenu auprès de l’AC et stocké sur la carte.

• Sans code PIN, on peut obtenir une copie du certificat, mais on ne peut pas utiliser la clé privée.

• La clé privée ne sort jamais.

• Après un certain nombre d’accès ratés la carte se bloque ou se détruit

24

CARTE À PUCE : UTILISATION

24

• La carte à puce produit une signature sur le haché du document présenté (la carte ne voit pas le document lui‐même).

• La carte accepte de produire une signature sur présentation du code PIN.

• Déchiffrement : fonctionnement similaire.

• Authentification par carte à puce (Kerberos, SSL…) : en interne, une signature est calculée par la carte, sur un défi (Challenge) envoyé par le serveur.

25

HORODATAGE• Un horodatage est une signature effectuée par une Autorité d’Horodatage (Time Stamp Authority). Cette 

signature porte sur le haché d’un document et la date d’horodatage.

• L’horodatage établit une preuve d’antériorité.

• On peut « sceller » une signature en appliquant un horodatage : cela permet une validation a posteriori en se plaçant à la date de l’horodatage, même si le certificat de signature a expiré ou a été révoqué entretemps.

• … mais uniquement si on peut valider le certificat de la TSA à la date courante.

• Applications : DLL ActiveX, documents PDF signés (PAdES).

25

26

TYPES D’AUTORITÉS DE CERTIFICATION• Autorité racine:

• Par définition, une autorité racine est irrévocable. Elle doit donc être particulièrement protégée.

• Une autorité racine robuste est hors‐ligne. Elle émet des listes de certificats révoqués avec une procédure régulière mais manuelle (transfert par clé USB).

• Autorité émettrice:• Elle est en ligne et émet les certificats pour les utilisateurs et les « choses » 

(pour l’Internet of things)

• Autorité intermédiaire:• Une autorité intermédiaire pourrait être utilisée si on décide avoir des autorités 

émettrices distinctes pour des rôles très différents (certificats pour des ballots et certificats de signature, par exemple)

26

27

SERVICES ET COMPOSANTES POSSIBLES D’UNE SOLUTION D’ICP – CAS TYPIQUE

Identité et clés

Identification / émission de certificats

Révocation et publicationde certificats 

annulés 

Publication des certificats (annuaire)

Conservation des certificats et historique 

des clés

Sauvegarde des clés 

(chiffrement)

Recouvrement des clés 

(chiffrement)

27

Autres services

Certification croisée

Solutions d’itinérance

Provision de jetons logiques

Chiffrement

Horodatage

Signature (non 

répudiation)

28

GOUVERNANCE ET ICP: IMPACTS SUR L’AUDIT ET LA CONFORMITÉ

Quelques mots sur l’arrimage des objectifs de l’entreprise et les besoins en ICP

Impacts sur les fonctions d’audit, conformité et vérification

29

L’ICP COMMENCE PAR LES ENTENTES

• Sans un cadre concret, signé et accepté par tous les utilisateurs des produits de l’ICP, ceux‐ci n’auront pas la valeur prévue.

• Les scénarios de compromission sont flous ou risquent d’être déconnectés avec la réalité.

• Les exigences et la gestion des RRHH manquent d’un cadre directeur pour établir des barèmes et contrôles.

• La valeur des produits de l’ICP reste ressort de la bonne volonté et peut être discutable si une situation de conflit d’intérêts se produit.

30

ENCADREMENT:LES ENTENTES PRÉALABLES QUI RENDENT UNE ICP UTILE

Cadre d’identification

Cadre d’octroi de certificats

Utilisations acceptées

Niveaux de confiance requis

Moyens de conservation acceptés

Gestion des supports cryptographiques

Gestion de la compromission

Contextes admissibles pour la récupération

30

31

TYPES DE PARTENARIATQuelques exemples d’ententes et ses impacts

32

TYPES DE PARTENARIATQUELQUES EXEMPLES D’ENTENTES ET SES IMPACTS

Loteries (terminaux)

Moyen : Certificats signés par le concessionnaire aux exploitants de la concessionCadre : Règles non négociablesBut : Connexion SSL et identificationBesoin : Postes portatifs faciles à volerSolution : Identification / non répudiation / SSL / révocation simple.

Santé Moyen : Certificats à valeur gouvernementaleCadre : Lois de la santé, ententes entre fournisseurs de services et produitsBut : Connexion SSL, identification et signatureBesoin : non répudiation des actes médicaux, protection des donnéesSolution : Identification / non répudiation (utilisateur et B2B) / contrôle des accès

Home Banking Moyen : Certificats à valeur universelleCadre : Ententes très fortes non négociablesBut : Signature des transferts entre comptes et transactions internationales / Lien SSLBesoin : Assurer la non‐répudiation à valeur juridique sur des moyens robustesSolution : Cartes cryptographiques pour authentification de transactions bancaires 

32

33

LES BESOINSLE CLIENT POURRA IDENTIFIER SES BESOINS ET ÉTABLIR LE CADRE D’ENTENTES

33

Niveaux de confiance requis• Standard adhéré par la solution•Moyens acceptés pour le support de multiples niveaux de confiance• Cadre inter‐partenaire et légal en application

Services requis• Standards adhérés pour chaque service• Identification, Chiffrement, Signature, Horodatage

Contenants cryptographiques

• Standard adhéré • Quantité de facteurs requis selon le niveau de confiance• Types de plateformes à supporter• Exigences acceptées par les partenaires, provision, mise à jour et remplacement des contenants 

Niveau de service

• Comment assurer la CIA /CID• Résilience requise et plans de relève•Moyens de support requis, coûts et moyens de financement, RRHH (rôles, exclusions, disponibilités)

34

ICP: DE LA SOLUTION DE GARAGE AUX SOLUTIONS HOMOLOGABLES

Autorité unique auto‐signée• Démos• Preuves de concept initiales

Autorité à deux niveaux virtuels sur infrastructure partagée• Preuves de concept

• Solutions internes

Autorité à deux niveaux virtuels sur infrastructure privée• Solutions internes

• Développement de solutions complexes

• Preuves de concept avancées

Autorité à deux niveaux physiques avec racine isolée, sans HSM• Solutions d’affaires à faible encadrement légal

Autorité à deux niveaux avec racine isolée et conteneurs de clés cryptographiques (HSM)• Solution homologable

• Solutions d’affaires complexes

Autorité à deux niveaux, racine isolée, HSM et HSM pour keyescrow• Solution homologable pour chiffrement

Autorité à trois ou plus niveaux, racine isolée et HSM • Support de solutions à niveaux de confiance différents

34

35

PLAN DE TRAVAIL POUR LE MONTAGE D’UNE ICP

Établir le niveau de reconnaissance requis

Établissement de la documentation pour le niveau de reconnaissance requis

Préparation des procédures pour le niveau de reconnaissance requis

Moyens d’assurance des niveaux de résilience requis

Moyens de préservation de l’autorité de certification émettrice et la racine (CIA/CID)

Moyens de préservation et diffusion du PDS (IA/ID)

Établissement des ressources humaines requises pour le montage (profil/ségrégation)

35

CIA: Confidentiality, Integrity, Availability, Confidentialité, Intégrité, Disponibilité (CID)

36

INTÉRACTION DES COMPOSANTES TYPIQUES D’UNE ICP

36

Identités

AC Racine

AEIdentitéRBAC

AD

AD

Identités

AD

CRLOCSP

TITULAIRE

AC

AC Émettrice

37

WEBTRUST 2.0: UN ENCADREMENT ROBUSTE

38

WEB TRUST 2.0: TRUST SERVICE PRINCIPLES AND CRITERIA FOR CERTIFICATION 

Introduction

1. Divulgation des pratiques d’affaires de l’AC

2. Gestion des pratiques d’affaires de l’AC

3.  Contrôles environnementaux de l’AC

4. Contrôles de gestion du cycle de vie des clés de l’AC

5. Contrôles de gestion du cycle de vie des clés des souscripteurs

6. Contrôles de gestion du cycle de vie des certificats

38

39

WEBTRUST 2.0PATRONS DE CONTRÔLE

Traçabilité du matériel

Pré‐documenté

Traçabilité du logiciel Horodatage

Contrôles croisés

Valider avec l’auditeur

Enregistrement 

Zonage

40

IMPACTS DES EXIGENCES WEBTRUST

Les activités de configuration doivent prévoir la traçabilité

Les composantes ont différents niveaux d’exigence

Quelques activités requièrent la présence d’un notaire ou enregistrement vidéo

Les normes des CTI exigent qu’on n’utilise pas des caméras dans les locaux

Quelques activités requièrent deux participants indépendants ou témoins

La virtualisation de composantes peut complexifier la gestion des ressources

La plupart des exigences sont incluses dans les normes et pratiques de l’industrie

40

41

ZONAGE WEBTRUST ‐ ACCÈS

41

AD

AC Émettrice

AC Racine

LRAIdentitéRBAC

AD

AD

CRLOCSP

TITULAIRE

SCSMS

LCA

42

ZONAGE WEBTRUST: DÉPLOIEMENT DU CODE

42

AD

AC Émettrice

AC Racine

LRAIdentitéRBAC

AD

AD

CRLOCSP

TITULAIRE

SCSMS

LCA

43

Utiliser des certificats: quelques orientations

Quelques idées et bonnes pratiques

44

UTILISER DES CERTIFICATS

Réaliser la demande sur le serveur qui les utilisera

Déclarer les clés non exportables

Prévoir des procédures de mitigation en cas de destruction

Limiter le personnel qui peut demander et déployer des certificats

Établir le cadre d’utilisation et responsabilité

Documenter au préalable et tester les procédures

Choisir soigneusement l’autorité de certification

44

45

UTILISER DES CERTIFICATS

Certificats de signature de code

Chiffrement de contenus (documents, disques)

Certificats pour des serveurs en grappe

Caractères spéciaux 

HSM ‐ TPM

Certificat comme moyen d’accès (mauvaise pratique)

45

46

Conclusions

47

LEÇONS APPRISES : QUELQUES EXEMPLES  

Clé de diversification

Gestion des sources et du déploiement

Vidéo

Gestion des clés

Râteliers et murs

Virtualisation et SAN

Redondance

47

48

LEÇONS APPRISES : ÉLÉMENTS CRITIQUES

CRL

Annuaires

Échéances, renouvellements et propagation

Vieillissement des moyens cryptographiques

Facteur humain

48

49

COORDONNÉES

Hector.Szabo@gmail.comThomas.Pornin@cgi.com

49