Certification Mécanismes de sécurité Plan - Accueildeptinfo.unice.fr/~bmartin/7-CS-4.pdf · Définis dans la norme ISO 7498-2 comme : 1 service d’authentification d’entités

CertificationServices et mécanismes de sécurité

Mécanismes de sécuritéDemain : IBE, CLE

Certification et protocoles

Bruno MARTIN,Université Nice Sophia Antipolis

Bruno MARTIN, Université Nice Sophia Antipolis Certification et protocoles 1



Plan

1 Certification

2 Services et mécanismes de sécurité

3 Mécanismes de sécuritéGestion des clésIdentification et authentificationSécurité des réseaux

4 Demain : IBE, CLE




Contenu d’un certificat (X.509)

Associe une clé publique à l’identité d’un sujet ; comprend :

Subject : Nom Distingué, Clé publiqueIssuer : Nom Distingué, SignaturePeriod of Validity : date de début, date de finAdministrative Information : version, numéro de sérieExtended Information :

où l’information « Nom Distingué » comprend les champs :

Common Name : nom à certifier Bruno MartinOrganization| Company : contexte UCAOrganizational Unit : contexte spécifique I3SCity/Locality : ville Sophia AntipolisState/Province : pour US PACACountry : code pays fr




Politique d’utilisation par AC

L’autorité de certification spécifie les champs obligatoires etoptionnels et impose évent. cond. de validité sur des champs

Exemple

Vérif. requiert que le champ Common Name d’un serveurcorresponde au nom de domaine du serveur (unice.fr).

Le certificat délivré par AC garantit la relation (Identité, pk) envérifiant que l’identité du détenteur de la biclé (pk,sk) correspondbien à celui inscrit dans le certificat.L’AC s’en assure lors de la requête de certificat.Si Alice requiert un certificat personnel, l’AC doit tout d’abordvérifier qu’Alice est bien la personne requérante.




Chaîne de certification

Une AC peut aussi fournir uncertificat à une autre AC.Bob peut ainsi remonter unechaîne de certification jusqu’àtrouver une AC en qui il aconfiance. Il peut aussi déciderde limiter la taille de la chaînede certification pour diminuer lerisque qu’un des certificats de lachaîne soit mauvais.

IdAC,KAC

AC1

IdA,cléA

AC

IdC,cléC

ACr

IdB,cléB

ACr

IdAC1,KAC1

ACr

IdACr,KACr

ACr




Création d’une AC « racine »

Problème : il faut une AC « racine » qui ne peut se faire certifier.Son certificat est auto-délivré. L’entité qui délivre le certificat estidentique au sujet certifié.La confiance repose dans une large distribution de la pk de l’AC.Les clients et les serveurs sont configurés pour faire confiance àcertaines AC par défaut, comme CertiSign ou VeriSign.Ces sociétés proposent des techniques de gestion des certificats, desprocédures de vérification de l’information, délivrent des certificats.Il est possible de se déclarer comme AC « racine », utile au seind’un intranet, où la vérification de l’information est plus aisé.Observons que la librairie OpenSSL délègue la confiance à l’OS.




Rupture dans la chaîne




Services de certification

Commercialisent, délivrent des certificats via procédure spécifique.Gèrent des liste de révocation des certificats :

liste des certificats corrompus ou invalidescertificats casséscertificat d’un sujet obsolète (licenciement, panne serveur)

Réalisation « asymétrique » : au moyen d’un schéma de

signature avec appendice qui consiste en [2] :une opération de signatureune opération de vérification

sur le contenu d’un certificat.Avec un contenu répondant à la norme X509, on fournit unidentificateur numérique ou Digital ID, une “carte d’identité”numérique.




Certification & Vérification

IdA,cléA hachage

h

SignAC SignAC(h(IdA,cléA))

IdA,cléA

SignAC(h(IdA,cléA))

Clé de A

certifiée par ACIdA,cléA

AC

hachage

h

VerACSignAC(h(IdA,cléA))

h(IdA,cléA)

oui/non

Clé de A

certifiée par AC

Algorithme public

de vérification de AC

IdA,cléA

IdA,cléA

AC




Une attaque MIM de plus haut niveau

Porte sur la transmission d’un certificat dont l’AC n’est pasconnue. C’est le cas, par exemple, d’un certificat “auto-délivré”.




Certificat original et celui falsifié




Avec quel outil ?

Des logiciels libres comme dsniff ou ettercap permettent demener à bien de telles attaques sur un LAN.




Attaque de l’homme du milieu en pratique sur un LAN

ServeurIP:192.168.1.12MAC: 00:0b:db:c9:df:44

ClientIP: 192.168.1.1MAC: 00:50:da:16:cb:08

MelchiorIP:192.168.1.113MAC: 00:11:43:cd:0a:c8

192.168.1.1=00:11:43:cd:0a:c8 192.168.1.1=00:50:da:16:cb:08 192.168.1.12=00:11:43:cd:0a:c8192.168.1.12=00:0b:db:c9:df:44

contenu destables arp

192.168.1.1 192.168.1.12vers de

192.168.1.1 192.168.1.12vers de

192.168.1.12 192.168.1.1vers de

192.168.1.12 192.168.1.1vers de

1 1

22




Plan

1 Certification



4 Demain : IBE, CLE




Services et mécanismes de sécurité

services de sécurité implémentent la politique de sécurité.Certains services inutiles pour une politique donnée.Exemple : intégrité ne requiert pas le chi�rementChaque service traite un ensemble particulier de menacesExemple : confidentialité prémunit contre l’accès non-autorisé àl’information.Services de sécurité implémentés par les mécanismes desécuritécertains services utilisent le même mécanismeExemple : hachage utilisé en identification et signature.




Services de sécurité

Définis dans la norme ISO 7498-2 comme :1 service d’authentification d’entités

service d’authentification de l’origine des données2 service de contrôle d’accès3 service de confidentialité avec/sans connexion

service de confidentialité sélectifservice de confidentialité du flux de trafic

4 service d’intégrité de connexion avec/sans récupérationservice d’intégrité sélectifservice d’intégrité sans connexion (sélectif ou non)

5 non répudiation avec preuve d’originenon répudiation avec preuve de dépot




Mécanismes de sécurité

Implémentent les services de sécurité

chi�rementsignatures numériquesmécanismes de contrôle d’accèsmécanismes d’integrité des donnéesmécanismes d’authentificationempaquetage pour le traficcontrôle de routagetiers de confiance (notariat électronique)

gestionnaire de sécurité (gestion des clés)auditdétection d’intrusion




Standards Internet et l’IETF

l’Internet Engineering Task Force (IETF) : groupe techniquechargé de l’ingénierie et de l’évolution d’Internet. Propose desstandards via des groupes de travail, p.e. en sécurité :

Open specification for PGPAuthenticated Firewall TraversalCommon Authentication TechnologyDomain Name SecurityIP Security Protocol (IPSEC)One time password authenticationPublic Key InfrastructureS/MIME Mail SecuritySecure ShellSimple Public Key InfrastructureTransport Layer SecurityWeb Transaction Security




Que produit l’IETF ?

Des RFC (Request for Comments) proposent des standardspour l’évolution d’internet.Des documents de travail, Internet Drafts sans statut formelde durée de vie de 6 mois.

Les RFC recouvrent une grande variété de documents allant desdocuments informels jusqu’à la spécification complète de certainsprotocoles. Une fois publié comme RFC le document reçoit unnuméro. Un document n’est ni revu ni ré-édité sous le mêmenuméro. On les trouve à l’adresse www.ietf.org/rfc.html




Gestion des clésIdentification et authentificationSécurité des réseaux

Plan

1 Certification



4 Demain : IBE, CLE





Techniques de gestion de clés [1]

Reposent sur

chi�rementutilisation des cléspolitique de sécurité

permettent d’éviter :

la modificationla destructionmalintentionnéele rejeula divulgation(disclosure)

Prête Active Usée

génération

destruction destruction

réactivation

activation désactivation

Pendant toute la durée de vie des clés, il faut assurer :la génération sûre suppression révocation la certificationl’enregistrement distribution destruction installation





Modèles pour l’établissement de clés

Procédé qui rend disponible une clé à une ou plusieurs entités.Recouvre :

transport de clés (publiques, secrètes)mise à jour des clésdérivation des clésmise en accord symétrique





Transport de clés

Besoin d’échanger des clés de façon sûre :évident dans le cas de la crypto à clé secrètecontrer « MIM » pour la crypto à clé publique

Comment faire ?

techniques cryptographiques :chi�rement contre la divulgation et l’utilisation frauduleuse.mécanismes d’intégrité contre la modification abusive.mécanismes d’authentification contre la masquarade.





Premières solutions

1 Fixer un rendez-vous pour échanger les clés2 Envoyer la clé par un courrier spécial3 Utiliser une clé partagée pour chi�rer une nouvelle clé

Discussion

2 premiers cas : contact nécessaire pour échanger la clé. Pastoujours possible. P.e. dans un conflit.Dans le dernier cas, on considère un réseau de communicationentre N utilisateurs. Pour que chaque utilisateur puissecommuniquer avec n’importe quel autre de façon sûre, il faut!N

2"

= O(N2) clés partagées distribuées de manière sûre.





Etablissement de clés point à point

Mécanisme de basebasé sur un échange symétrique : les deux entités partagentune clé secrète commune.basé sur un échange asymétrique : chaque entité a un couple(clé publique certifiée/clé privée) et la clé publique certifiée del’autre partie

pour l’intégrité des données ou l’authentification de l’origine, ledestinataire a besoin du certificat de la clé publique del’expéditeurpour la confidentialité, l’expéditeur a besoin du certificat de laclé publique du destinataire.





Etablissement de clés au sein d’un même domaine

Solution possible : centre de

distribution de clé (CDC) en quitout le monde a confiance.Chaque utilisateur partage une clésecrète avec le CDC. Quand A veutcommuniquer avec B, elle choisitune nouvelle clé de session et l’en-voie (chi�rée) au CDC qui la re-transmet à B chi�rée avec la clécommune entre le CDC et B.Moyen convenable pour l’échange

au sein d’un même domaine.

CDC

entité Bentité A

1 tout le monde a confiance en CDC !2 Tous les utilisateurs partagent une

clé avec le CDC3 CDC a accès à tous les messages

échangés





Etablissement de clés entre deux domaines

Hyp : ÷ CDC (ou autorité de sécurité) par domaine.

AS AS

entité A entité B

Domaine A Domaine B

Si A et B ont une confiance mutuelle ou si chaque entité aconfiance en l’AS de l’autre domaine, tout se passe comme s’il n’yen avait qu’un.Deux réalisations : asymétriques ou symétriques.





Etablissement de clés entre deux domaines (asymétrique)

Si les entités n’ont pas de service de certification, chaque entitécontacte sa propre AS pour obtenir le certificat de soncorrespondant. Les AS peuvent échanger les certificats des cléspubliques des entités A et B et les redistribuer à A et B.Autre approche : certification croisée, i.e. une AS certifie les cléspubliques de l’autre.





Etablissement de clés entre deux domaines (symétrique)

1 Une des entités contacte son AS pour obtenir une clé desession.

2 Les deux AS établissent une clé secrète partagée utilisée parles deux entités.

3 clé distribuée par chaque AS qui utilise l’autre comme centre

de traduction de clé1 ou par l’intermédiaire d’une des entités

qui sera responsable de la transmission vers la seconde entité.

Si les AS ne se font pas confiance, il faut ajouter une autorité decertification supplémentaire.

1. un CTC recoit une clé chi�rée d’une entité, la déchi�re et la rechi�re enutilisant une clé partagée avec l’entité de son domaine.





Mécanismes de transport de clés

PubliquesProcédé qui permet la mise à disposition de la clé publique d’une entité àd’autres entités.Principale condition à assurer : authentification de la clé qui estsouvent réalisée au moyen de tiers de confiance. Si on utilise une AC,l’authentification est faite au moyen du certificat de la clé publique.SecrètesProcédé qui permet de transférer une clé secrète créée –ou obtenue s’ils’agit d’un tiers de confiance– par une entité à une autre entité.

Réalisation par de techniques de chi�rement, (a)symétriques.

18 mécanismes dans ISO/IEC 11770-2 et 3, dont 5 sont point à point, lesautres utilisent des tiers de confiance comme CDC. Les di�érencesrésident surtout dans le nombre d’étapes de communication, les partiesqui contrôlent les clés reçues, l’authentification. . .





Transport de clé secrète (symétrique avec tiers de confiance)

Exemple : Needham-Schroeder ;suppose l’existence d’un tiers deconfiance qui sert de serveurd’authentification (AS). AS par-tage une clé secrète avec chaqueacteur principal [3].





Utilité dans Kerberos

Permettre à l’utilisateur U du clientC de prouver son identité à unserveur d’applications sans que cesdonnées transitent par le réseau.Requiert un tiers de confiance quisert de centre de distribution de

clé (KDC) pour le domaine ; il estcomposé de :

serveur d’auth. (AS)

distributeur de tickets (TGS)

qui sont sécurisés

1

2

3

4

5U,T

GS,

T,L

KU(K,N,Tc,tgs )

S,N,T c,tgs ,Ac,tgs

K(Tc,s ,K')

Tc,s ,Ac,s

AS

TGS

serv eur S

K'(T+1)

6

Tc,tgs =KTGS (U,C,TGS,T,L,K) tick et TGTTc,s =KS(U,C,S,T, L ,K') tick et de sessionAc,tgs =K(C,T) authentificateur pour Tc,tgsAc,s =K'(C,T ) authentificateur pour Tc,s

U/C





Systèmes analogues

Systèmes analogues

Kryptoknight, par IBM qui utilise à la fois le modèle pull et lemodèle push.Sesame, projet Européen qui ajoute un serveur de privilèges.





Autres modèles de distribution de clés

A B

KDC1

23

Modèle pull

A B

KDC

1

23

4Modèle push

A B

KDC

1

2

32’

3’

Modèle mixte





Mise à jour des clés

La clé une fois obtenue, on fait évoluer la clé d’une session à l’autre parmise à jour des clés : procédé pour partager des clés construites aupréalable en les faisant évoluer via des paramètres de session.On définit une nouvelle clé de session K à partir :

d’une clé partagée KAB

d’un paramètre F (nombre aléa, estampille, numéro de séquence)d’une fonction de calcul de clé f

Fonctionnement en deux étapes :

1 l’initiateur A choisit le paramètre de dérivation F et le transmet à B2 A et B calculent K en utilisant la fonction de calcul f t.q.

K = f (KAB , F )

Exemple de fonction f : utiliser une fonction de hachagecryptographique H à la concaténation de données : K = H(KAB ; F )





Protocole de mise en accord (Di�e Hellman)

Procédé qui permet d’établir une clé partagée entre plusieursentités de telle sorte qu’aucune d’entre elle ne puisse établir savaleur par avance.On cherche donc une solution qui permette à deux entités :

qui ne se sont jamais rencontrésqui ne possèdent pas d’information partagée

de construire une clé secrète communeconnue d’eux seulsinconnue de quiconque, même d’un indiscret qui écouteraitleurs communications.

L’idée

Imaginer une solution facile à calculer pour les utilisateurs légauxet di�cile pour un indiscret : une fonction à sens unique.Un bon candidat est le logarithme discret.





Mise en accord par Di�e Hellman [4]

Etape préliminaire

On choisit q un grand premierOn choisit a, 1 < a < q

Les clés : Chaque utilisateur U :choisit secrètement une valeur aléatoire XU , 1 < XU < q et laconserve secrète ;publie YU = aXU mod q

A et B construisent une clé commune avec : YA et YB .A calcule K = Y XA

B mod qB calcule K = Y XB

A mod qA et B ont alors une clé (secrète) commune K :

Y XAB © (aXB )XA © aXBXA © Y XB

A mod q





Remède pour éviter l’attaque de l’homme du milieu

Protocole STS Station To Station. Variante de Di�e Hellmanauquel on a jouté une authentification. Une autre variante estutilisée dans le protocole IPsec, intégré dans IPv6.

aXB

aXA|ChK(SignA(aXB|aXA|B))

Ch (SignB(aXB|aXA|A))

En arithmétique mod q

XA

XB

K





Identification & authentification

identification procédé qui permet de vérifier l’identité d’une entité.authentification similaire ; permet à une entité d’accéder à uneressource (comme un compte internet). L’authentification ne metpas nécéssairement en jeu l’identification d’une entité. Elledétermine si l’entité est autorisée à accomplir une certaine tâche.Principales di�érences

L’identification requiert que le vérificateur teste l’information présentéeen fonction de toutes les entités connues tandis que l’authentificationnécessite que l’information soit vérifiée par une seule entitéprécédemment identifiée.De plus, l’identification doit, par définition, identifier de manière uniqueune entité, l’authentification ne requiert pas l’unicité.Exemple : une personne qui se connecte à un compte partagé n’est pasidentifiée de façon unique mais en connaissant le mot de passe partagé,elle est authentifiée comme un utilisateur du compte.





Exemple d’authentification « asymétrique »

msg-alea

DeB(MD(msg-alea)

Si on n’utilise pas de calcul de l’empreinte du msg-aléa, ceprotocole peut subir des attaques (msg-aléa/DeB(msg-aléa)).Requiert qu’Alice connaisse la clé publique de Bob au préalable.





Exemple d’identification certifiée « asymétrique »

salut

je suis Bob

prouve-le

Envoi cle secrete

Dialogue confidentiel

certif

msg-alea

DeB(MD(msg-alea)

ChB(CleSecrete=CS)

ChCS(msg)

ChCS(msg)

Identification avec certificat





Sécurité de la couche de transport (TCP)

Protocoles pour sécuriser TCP :Secure Socket Layer

Private Communication

Technology (Microsoft)Transport Layer Security

standardisé par l’IETF, évolutionde SSL3

SMTP HTTP

TCP (Transmission Control Protocol)

IP (Internet Protocol)

Transport Layer Security

(SSL, TLS)





Protocole vs Implementation

Ne pas confondre le protocole avec son implémentation ! TLS (quiremplace maintenant SSL) est implémenté par de nombreuseslibraires. Voir à ce sujet https://en.wikipedia.org/wiki/

Comparison_of_TLS_implementations. Les plus classiques :OpenSSLLibreSSLBoringSSLGnuTLS

Et voir aussi les recommandations sur Crypto Best Practice





SSL & TLS

SSL fournit authentification, compression, intégrité, chi�rement.plusieurs mécanismes d’authentification et de chi�rement ; protègetout protocole au niveau applicatif (http,smtp)TLS repose sur SSL3.0. Deux couches :

Rencontre ou Handshake ProtocolCommunication ou Record Protocol

qui fournissent les services suivants :confidentialité de la connexion par AES, Camellia, DES,3DESintégrité de la connexion par un MAC utilisant une clé envaleur initiale (SHA-1 ou SHA256 ou SHA384). Voir lesdi�érents SHA





Identification–handshake

C’est le moyen pour Alice de vérifier l’identité de Bob.pkB la clé publique de Bob et skB sa clé privée.

A æ B r = un message aléatoireB æ A c = {r}skB

Signer un message aléatoire r fourni par un tiers et le réexpédierpeut s’avérer dangereux.Une idée serait d’utiliser une fonction de hachage h afin que Bobsigne en chi�rant h(r). Mais le danger persiste.





Identification–handshake

Mieux vaut que Bob signe un message de son cru

A æ B "Bonjour, est-ce Bob ?"B æ A m = "Alice, je suis bien Bob"

c = {h(m)}skB





Authentification–handshake

Alice n’a pas forcément déjà connaissance de la clé publique deBob. Comment informer sûrement quelqu’un de sa clé publique ?

A æ B "Bonjour"B æ A "Bonjour, je suis Bob. Voici ma clé publique" pkBA æ B "Prouve-le."B æ A m = "Alice, c’est bien Bob"

c = {h(m)}skB

N’importe qui peut se faire passer pour Bob aux yeux d’Alice, endonnant sa propre clé publique, correspondant à sa clé secrète.





Transmettre un certificat–handshake

Certificat garantit la relation entre une identité et clé publique.

A æ B "Bonjour"B æ A "Bonjour, je suis Bob. Voici mon certificat" certBA æ B "Prouve-le."B æ A m = "Alice, c’est bien Bob"

c = {h(m)}skB

Eve pourrait se substituer à Bob dans les trois premiers échanges,mais échouera à répondre au delà.





Echanger un secret–handshake

La communication par clés publiques est coûteuse, une fois finie laphase d’identification, on s’échange une clé pour utiliser un chi�reà clé secrète symétrique.

A æ B "Bonjour"B æ A "Bonjour, je suis Bob. Voici mon certificat" certBA æ B "Prouve-le".B æ A m = "Alice, c’est bien Bob"

c = {h(m)}skBA æ B "Ok Bob, voici notre secret :"

s = {secret}pkBB æ A mÕ = {message de Bob}secret





Attaque MIM

L’homme du milieu Melchior peut s’interposer dans les 5 premierséchanges. Arrivé au sixième, il peut brouiller le message de Bob,quitte à ne pas envoyer un message très intelligible à Alice :

B æ M mÕ = {message de Bob}secretM æ A altération de mÕ

Alice n’a aucune certitude quant à l’existence de Melchior, mêmesi elle trouve suspect le dernier message de Bob.





SSL–handshake

Pour éviter cette incertitude, mieux vaut utiliser un MAC :M = h(un message de Bob, secret)

A æ B "Bonjour"B æ A "Bonjour, je suis Bob. Voici mon certificat" certBA æ B "Prouve-le".B æ A m = "Alice, c’est bien Bob"

c = {h(m)}skBA æ B "Ok Bob, voici notre secret :"

s = {secret}pkBB æ A mÕ = {message de Bob}secret

M = h(message de Bob, secret)

Melchior peut pertuber ce qu’il veut, M aura au moins l’avantaged’en avertir le destinataire.





La communication–record

Ce protocole transmet un message de taille arbitraire. Il le découpeen blocs, le comprime éventuellement, ajoute un MAC, chi�re ettransmet le résultat en ajoutant un numéro de séquence pourdétecter s’il manque des messages ou si certains ont été altérés.

Il assure :confidentialité des données transmises par l’applicationintégrité des donnéesauthentification de l’origine

Une fois le record protocol achevé, les données chi�rées sontfournies à TCP.




Plan

1 Certification



4 Demain : IBE, CLE




Identity Based Encryption (IBE)

Génère la clé publique du destinataire via ([email protected]).http://www.hackinsight.org/news,187.html

Le destinataire s’adresse à un générateur de clé privée (KGC) pourobtenir la clé privée de déchi�rement.Inconvénient : KGC peut calculer la clé de déchi�rement de touset le destinataire doit avoir confiance dans son KGC.

émetteur

CA

dest.

cert pk

pk KGC

émetteur dest.

clé déchiffrement

chiffre avec PKI IBEBruno MARTIN, Université Nice Sophia Antipolis Certification et protocoles 54



Schémas de chi�rement sans certificat

Propriétés1 le schéma est sûr sans que pk soit validée par un certificat2 le schema reste sûr contre les attaques

2 biclés nécessaires :dest. génère une biclé traditionnelle :

sk : valeur secrète (éviter confusion avec sk complète)pk : publique mais non certifiée

une biclé d’identité (IB) :pk : id. digital du dest.sk : clé privée IB fournie par un KGC, clé privée partielle

Chi�rer : l’émetteur utilise l’id. digital du dest. et sa clé publique.Déchi�rer : dest. utilise la valeur secrète et la clé privée partielle.Beaucoup de modèles proposés.




W. Fumy.Key management techniques.In State of the art in applied cryptography, number 1528 in LNCS, pages209–223. Springer Verlag, 1997.

RSA Laboratories.PKCS ˘1 v2.0, RSA cryptography standard.Technical report, RSA Data Security, 1998.

R. Oppliger.Internet and intranet security.Artech House, 1998.

D. Stinson.Cryptographie, théorie et pratique.International Thomson Publishing, 1995.


Documents

Certification Mécanismes de sécurité Plan - Accueildeptinfo.unice.fr/~bmartin/7-CS-4.pdf · Définis dans la norme ISO 7498-2 comme : 1 service d’authentification d’entités