27
1 Vers une infrastructure de gestion de clés pour Rennes 1 Signature et chiffrement sont à la mode Qu’est-ce c’est ? Pourquoi ? Comment ?

Vers une infrastructure de gestion de clés pour Rennes 1

  • Upload
    rasul

  • View
    23

  • Download
    0

Embed Size (px)

DESCRIPTION

Vers une infrastructure de gestion de clés pour Rennes 1. Signature et chiffrement sont à la mode Qu’est-ce c’est ? Pourquoi ? Comment ?. Chiffrement symétrique 1/2. crypt( key ,crypt( key ,msg))=msg. message. cryptogramme. message. cryptogramme. Chiffrement asymétrique. - PowerPoint PPT Presentation

Citation preview

Page 1: Vers une infrastructure de gestion de clés pour Rennes 1

1

Vers une infrastructure de gestion de clés pour Rennes 1

Signature et chiffrement sont à la mode Qu’est-ce c’est ? Pourquoi ? Comment ?

Page 2: Vers une infrastructure de gestion de clés pour Rennes 1

2

Chiffrement symétrique 1/2

message cryptogramme

message cryptogramme

•crypt(key,crypt(key,msg))=msg

Page 3: Vers une infrastructure de gestion de clés pour Rennes 1

3

Chiffrement asymétrique

Deux clefs fabriquées ensemble et qui respectent :

1. Ce qui est chiffré avec une des clés ne peut être déchiffré que par l’autre clef. crypt(key1,crypt(key2,msg))=msg

2. La connaissance d’une des clés ne permet pas de déduire l’autre.

Page 4: Vers une infrastructure de gestion de clés pour Rennes 1

4

Chiffrement asymétrique

1. On décide arbitrairement de rendre publique une des clefs, l’autre est privée.

2. Confidentialité : on chiffre avec la clef publique du destinataire, seul le titulaire de la clef privée associée à la clef publique peut déchiffrer.

3. Signature : on chiffre une empreinte du message avec la clef privée de l’émetteur. Cette empreinte peut être déchiffré et recalculée par quiconque avec la clef publique de l’émetteur.

Page 5: Vers une infrastructure de gestion de clés pour Rennes 1

5

Chiffrement symétrique

RAND

Clé pub(destinataire)

Chiffrement asymétrique

Clé priv(destinataire)

déchiffrement asymétrique

déchiffrement symétrique

Page 6: Vers une infrastructure de gestion de clés pour Rennes 1

6

Chiffrement asymétrique

Clé priv(émetteur)

empreinte

empreinte

Clé pub(émetteur)

déchiffement asymétrique

Page 7: Vers une infrastructure de gestion de clés pour Rennes 1

7

Chiffrement asymétriquePB : Tout repose sur la confiance dans

la provenance de la clef publique ?

• Si celui qui forge une signature a forgé la clef publique de sa victime ?

• Autrement dit si celui qui souhaite écouter les messages de votre correspondant vous a remis une fausse clef publique pour cette personne ?

• Exemple SSH

Page 8: Vers une infrastructure de gestion de clés pour Rennes 1

8

Certificat X509

Solution : une autorité est chargée de signer les clefs publiques : elle chiffre (avec sa clef privée) une empreinte de : L’identité de son titulaire, personne, serveur ou application

(Distinguished Name of Subject) La clef publique Les informations relatives à l’usage de cette clef, (période

de validité, type des opérations possibles, etc). L’ensemble est appelé certificat X509. Les certificats

X509 font l’objet d’une norme : ITU-T X509 international standard V3 1996, RFC2459

Page 9: Vers une infrastructure de gestion de clés pour Rennes 1

9

Certificat X509

On s’assure de la provenance d’une clef publique en vérifiant la signature qui y a été apposée à l’aide de la clef publique de l’autorité de certification (CA).

Plus besoin de faire directement confiance à toutes les clefs publiques en circulation mais seulement à celles des autorités de certification.

Page 10: Vers une infrastructure de gestion de clés pour Rennes 1

10

Nom de l’AC

SignatureDe l’AC

Certificat X509

Clef publique NomPériode

DeValidité

Attributs

Le certificat établit un lien fort entre le nom (DN) de son titulaire et sa clé publique

Page 11: Vers une infrastructure de gestion de clés pour Rennes 1

11

Les usages

Messagerie S/MIME : signature (certificat de l’émetteur) et/ou chiffrement (certificat du destinataire)

SSL ou TLS : en particulier HTTPS pour chiffrer les sessions du client et authentifier le serveur. Plus rarement authentifier le client.

SSL POPS, IMAPS, LDAPS, SMTP/TLS, … VPN et IPsec

Page 12: Vers une infrastructure de gestion de clés pour Rennes 1

12

Applications

Applications de confiance (applet JAVA, pilote Windows XP, …)

Sécurisation des processus « web services » en particulier les serveurs d’authentification (SSO)

Horodatage Signature E-commerce Dématérialisation de procédure administrative

(Workflow) E-Vote

Page 13: Vers une infrastructure de gestion de clés pour Rennes 1

13

SSL: Secure socket Layer

A ce jour, probablement le domaine d’application le plus utilisé.

Utiliser une couche avec chiffrement et authentification au dessus de TCP/IP

Applicable à toutes les applications sur TCP (sans réécriture de celles-ci)

Page 14: Vers une infrastructure de gestion de clés pour Rennes 1

14

Principes généraux de SSL

LD

AP

PO

P

HT

TP

TCP

IP

IMA

P

SSLX50

9

LD

AP

PO

P

HT

TP

TCP

IP

IMA

P

SSL

X509

Communication sécurisée

Page 15: Vers une infrastructure de gestion de clés pour Rennes 1

15

Protéger les clefs privées

module de chiffrement du navigateur (netscape) ou du système (windows NT + IE). En général 3DES

Supports de clés cryptographique : token USB, Cartes à puce (personnalisables mais impose un lecteur)

Page 16: Vers une infrastructure de gestion de clés pour Rennes 1

16

Cartes à puce et certificats Il existe toute sorte de cartes à puce,

certaines extrêmement sophistiquées. Certaines peuvent générer elle même

un bi-clef. Dans ce cas la clef privée ne quitte jamais la carte à puce.

Une API (PKCS11 ou MS Crypto API) permet d’accéder à des fonctions de signature/chiffrement sans accéder à la clé elle-même.

Page 17: Vers une infrastructure de gestion de clés pour Rennes 1

17

Objectifs de l’IGC

La technologie est relativement simple mais le déploiement est réputé très lourd :

L’enjeu est de formaliser le degré de confiance requis pour mettre en œuvre le niveau de sécurité qui en découle.

Prouver un niveau de sécurité est plus difficile que de mettre en œuvre celui-ci.

Page 18: Vers une infrastructure de gestion de clés pour Rennes 1

18

Les services de l’IGC L’émission de certificat n’est pas le seul

service de l’IGC vérifie l’identité du titulaire lors de l’émission

de certificatpublie le certificat,assure le renouvellement,révoque les certificats invalidés,assure parfois le recouvrement de la clef

privée.

Page 19: Vers une infrastructure de gestion de clés pour Rennes 1

19

Révocation

Accepteriez vous d’utiliser une carte bancaire si vous ne pouviez par y faire opposition, même en cas de vol ?

Les CRL : la liste des certificats révoqués, liste signée par la CA

Mal implémenté dans les navigateurs Pas encore de CRL incrémentale. Alternative : OCSP La révocation est une limite théorique au modèle des

PKIs.

Page 20: Vers une infrastructure de gestion de clés pour Rennes 1

20

Architecture de l’IGC

On distingue différents composants dans une IGC :

Autorité de certification AC (certificat authority)

Autorité d’enregistrement AE (registry authority)

Interface utilisateur (Enrolment Entity)

Page 21: Vers une infrastructure de gestion de clés pour Rennes 1

21

Autorité de certification C’est une organisation qui délivre des

certificats à une population. Il existe des autorités privées (intranet d’une

entreprise), organisationnelles (CRU, CNRS), corporative (notaires), commerciales (Thawte, Verisign, …), très commerciales (microsoft), institutionnelles, etc

Page 22: Vers une infrastructure de gestion de clés pour Rennes 1

22

L’autorité de certification•Protège la clé privée de la AC (bunker informatique)

•Vérifie les demandes de certificats (Certificat Signing Request) provenant des AE

•Génère les certificats et les publie

•Génère les listes de certificats révoqués (Certificat Revocation List)

Page 23: Vers une infrastructure de gestion de clés pour Rennes 1

23

L’autorité d’enregistrement•Vérifie l’identité des demandeurs de certificats et les éléments de la demande. Exemple :

•L’email présent dans le DN est-il l’email canonique ?

• Le demandeur a-t-il le droit de disposer d’un certificat de signature ?

•Transmet les demandes valides par un canal sûr à l’AC (demandes signées par l’opérateur de la AC)

•Recueille et vérifie les demandes de révocation

Page 24: Vers une infrastructure de gestion de clés pour Rennes 1

24

Délégation de l’AE Le CRU propose à partir de Septembre

la délégation d’une AE aux établissements qui le demanderaient.

Relation contractuelle incluant un énoncé de la politique d’enregistrement :Vérification automatique du emailRapport direct de confirmation de l’origine

de la demande (rapport facial / téléphonique)

Utilisation de la carte professionnelle.

Page 25: Vers une infrastructure de gestion de clés pour Rennes 1

25

Aspect légaux de la signature

Validité de l’écrit électronique et reconnaissance juridique de la signature électronique

Le cadre est défini par la loi du 13 mars 2000, décret du 30 mars 2001, décret du 18 avril 2002 et l’arrêté du 31 mai 2002.

Obligation de dématérialisation des procédures

Page 26: Vers une infrastructure de gestion de clés pour Rennes 1

26

Type de signature

Type de signature

Validité Présomption de fiabilité

Signature électronique

Identification du signataire et intégrité du document

non

Signature électronique sécurisée

Idem + Signature personnelle sous contrôle exclusif

non

Signature électronique

sécurisée présumée fiable

Signature sécurisée, utilisant des moyens certifiés et des certificats qualifiés

oui

Page 27: Vers une infrastructure de gestion de clés pour Rennes 1

27Utilisateur

X509Dispositifde signature

Prestataire de certification

CESTI

DCSSI

Premier Ministre

organisme accrédité

Cofrac

Rapport d’évaluation

Rapport de certification

Rapport d’évaluation

Accrédite2ans

informe

Qualifie1ans

informeCertifie

Commande

Agrée

Editeur

Vends Vends

AchèteSigneun

acte/document