Une introduction à SSL - Set sivelles · 2017-02-04 · Introduction et concepts de base...

Introduction et concepts de baseCertificats X.509 et protocole SSL

Infrastructure à clefs publiquesLogiciels et matériel pour SSL

Conclusion

Une introduction à SSL

Felip Manyé i Ballester

6 juin 2009

1



Conclusion

Plan

1 Introduction et concepts de baseButs et enjeux de SSLConcepts de base

2 Certificats X.509 et protocole SSLCertificats X.509Protocole SSL

3 Infrastructure à clefs publiques

4 Logiciels et matériel pour SSLAccélération SSLLogiciels de PKI

5 Conclusion

2



Conclusion

Buts et enjeux de SSLConcepts de base

Plan





5 Conclusion

3



Conclusion


Buts et enjeux de SSL

ButSécuriser les échanges de données sur Internet (sur un réseauTCP/IP) entre un client et un serveur.

FonctionnalitésAuthentification du serveur voire du clientChiffrement des donnéesNon-répudiationIntégrité des données

4



Conclusion


Chiffrement et déchiffrement des messages

PrincipeOn souhaite transformer un message « en clair »M en un messageinintelligible, « chiffré »C . On se donne

une fonction de chiffrement E, telle que C = E (M)

une fonction de déchiffrement D, telle queM = D(C )

l’identité suivante doit donc être vérifiée : D(E (M)) = M

Algorithmes et clefsAlgorithme cryptographique : méthode de chiffrementClef cryptographique : donnée secrète, au moins en partie,dans un espace de cardinalité importante, sur laquelle se baseun algorithme

5



Conclusion


Chiffrement symétrique

PrincipeLa même clef est utilisée par les deux parties, pour le chiffrementet le déchiffrement.

AvantagesRapidité du calculAuthentificationConfidentialité

Inconvénients

Échange de la clef ?

Exemples d’utilisationChiffrement d’une clef privée (« passphrase »)Chiffrement au sein d’une session SSL

6



Conclusion


Quelques algorithmes symétriques ou à clef secrète (parblocs)

DES (Data Encryption Standard) : seulement 256 clefs ;craqué en 1999 en 22h15minAES (Advanced Encryption Standard) : remplaçant d’AES.128 bits, 192 bits, 256 bitsTriple DES : construit sur DES. 112 bits, 168 bitsIDEA (International Data Encryption Algorithm). Clef de 128bitsBlowfish : peut remplacer DES. Pas de brevet ni licence.Éprouvé. 32 bits à 448 bits.RC4, RC5 (Ron’s Code our Rivest’s Cipher)

7



Conclusion


Chiffrement asymétrique

PrincipeLa clef de chiffrement est différente de la clef de déchiffrementClef de chiffrement : clef privée, secrèteClef de déchiffrement : clef publique, divulguée

AvantagesGestion des clefs facilitée

Inconvénients1000 fois plus coûteux

Exemples d’utilisationAuthentification, signatureChiffrement de messages courtsÉchange de clefs

8



Conclusion


Quelques algorithmes asymétriques (à clef publique)

RSA (Rivest-Shamir-Adleman) : signature, chiffrement. Lebrevet a expiré en 2000. Clefs : 1024 bits à 2048 bits(utilisateurs)DSA (Digital Signature Algorithm) : signature uniquementDiffie-Hellman : échange de clefs

9



Conclusion


Fonction de hachage à sens unique

DéfinitionFonction f :

qui convertit une suite de bits de taille quelconque en unesuite de bits de taille fixe (« empreinte numérique »)telle qu’il est très difficile de trouver x1 6= x2 vérifiantf (x1) = f (x2) (« collision »)

En pratiqueSi l’on change un seul bit de l’information en entrée, lerésultat est drastiquement différentUne empreinte numérique de 128 bits est un minimum(cassable)

10



Conclusion


Signature numérique

PrincipeEnvoyer :

un message en clair Mle même message chiffré avec sa clef privée C = Epriv (M) : lasignature

Le destinataire du message calcule M ′ = Dpub(C ) avec la clefpublique. Si M = M ′, la signature est vérifiée.

En PratiqueOn envoie un « code d’identification de message »(MAC),c’est-à-dire l’empreinte numérique chiffrée avec la clef privée.

11



Conclusion


Fiabilité des algorithmes et sécurité

Ne pas utiliser de méthodes « maison », leur préférer desalgorithmes éprouvés par les cryptanalistesConserver jalousement les clefs secrètes ou privéesChoisir un bon compromis en termes de longueur de clef

temps de calculaspects légaux

L’entropie doit être suffisante lors de la génération de la clefProscrire les sources d’entropie « maison » : utiliser/dev/urandom sous *nixOn doit pouvoir faire confiance à OpenSSL dans ce domaine

Évidemment, mettre les systèmes à jour (cf. faille Debian enmai 2008)

12



Conclusion


Aspects légaux de la cryptographie en 2008

Utilisation« En vertu de l’article 30-l de la loi 2004-575 du 21 juin 2004,l’utilisation de moyens de cryptologie est libre »

Autres circonstances« En revanche, la fourniture, l’importation et l’exportation des cesmoyens sont réglementés en France. Ces opérations sont soumisessoit au régime de la déclaration, soit au régime de l’autorisation. »

Source :http ://www.ssi.gouv.fr/fr/reglementation/index.html#crypto

13



Conclusion

Certificats X.509Protocole SSL

Plan





5 Conclusion

14



Conclusion


Certificats X.509

Un certificat :est le support de la clef publique d’une entitécontient des données sur ce dernier

Trois champs sont obligatoires :le TBS (To Be Signed) qui sera signé et contient lesinformations du certificatl’algorithme asymétrique et la fonction de hachage utiliséepour la signaturela signature de l’empreinte numérique du TBS

15



Conclusion


Description ASN.1 simplifiée d’un certificat X.509

Certificate : := SEQUENCE {tbsCertificate TBSCertificate,signatureAlgorithm AlgorithmIdentifier,signatureValue BIT STRING }

TBSCertificate : := SEQUENCE {version [0] EXPLICIT Version DEFAULT v1,serialNumber CertificateSerialNumber,signature AlgorithmIdentifier,issuer Name,validity Validity,subject Name,subjectPublicKeyInfo SubjectPublicKeyInfo,issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,

– If present, version MUST be v2 or v3subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,

– If present, version MUST be v2 or v3extensions [3] EXPLICIT Extensions OPTIONAL

– If present, version MUST be v3}

16



Conclusion


Chaîne de certificats

Un certificat signé par une autorité de certification (AC)« mère » peut à son tour signer un autre certificatOn parle de « chaîne de certificats »Pour contrôler cette chaîne, on utilise les extensionsbasicConstraints (valeurs CA :false ou CA :true) etkeyCertSign (pour en limiter la longueur)On valide un certificat fils de manière récursive avec la clefpublique du parent, jusqu’à la CA racine dont le certificat est« auto-signé »

17



Conclusion


Vérification d’une signature de certificat

Pour vérifier la validité de la signature d’un certificat :on calcule l’empreinte M du TBSon récupère la clef publique de l’autorité de certification dansle certificat racine pré-installéce qui permet de déchiffrer le contenu du champ signature S :M ′ = D(S)

on s’assure que M = M ′, ce qui prouve que le certificat a bienété signé par cette autorité de certification, et qu’il appartientà la bonne personne (authentification), mais aussi qu’il n’apas été contrefait (intégrité)

18



Conclusion


Champ d’utilisation d’un certificat

Les extensions de SSLv3 permettent de destiner le certificat à unusage particulier :

keyUsage : signature (digitalSignature, nonRepudiation),chiffrement (keyEncipherment), délégation ACfille(keyCertSign)nsCertType : serveur (server), utilisateur (clientAuth,emailProtection)

19



Conclusion


Validation d’un certificat

Certificat serveurpériode de validitéAC de confiance ?vérification de la signatureselon applications, vérifier lenom de domaine

Certificat clientpériode de validitéAC de confiance ?vérifier la signature (voirCertificateVerify) oucomparer à copie ducertificat installer localementle DN est-il connue (stockédans un LDAP. . .) ?vérifier les permissions

20



Conclusion


Formats de certificats

DER (« Distinguished Encoding Rules ») : certificat binaireencodé selon règles ASN.1PEM (« Privacy Enhanced Mail ») : certificat DER encodé àson tour en base 64PKCS#12 (« Public-Key Cryptography Standard #12 ») :rassemble en un seul fichier un biclef, le certificatcorrespondant et toute la chaîne de certificats AC. Cf SagemPKCS#10 : demande de certificat (Lyra)

21



Conclusion


Plan





5 Conclusion

22



Conclusion


Historique

Secure Socket Layer : développé par Netscape, qui équipe sesnavigateurs de la version 2.0Actuellement, SSLv3Brevet US racheté par l’IETF en 2001 ⇒ description deTLSv1 (Transport Layer Security) dans la RFC 2246SSLv3 et TLSv1 subtilement incompatibles, mais exactementle même principe

23



Conclusion


Principe

Au-dessus d’unprotocole de transportconnecté (TCP)Une phase denégociation de clef desession :cryptographieasymétriquePendant la session :cryptographiesymétrique

24



Conclusion


Algorithmes

Algorithmes utilisésun algorithme asymétrique pour l’authentification : RSA, DSAun algorithme asymétrique pour l’échange de clefs secrètes :RSA, Diffie-Hellmanun algorithme à clef secrète pour le chiffrement du traficune fonction de hachage à sens unique pour calculer les codesd’authentification de messages (MAC)

« Handshake » SSLAuthentification des partiesNégociation des algorithmes cryptographiquesNégociation de la clef de session pour SSL Record : MasterKey

25



Conclusion


« Handshake » SSL 1/10

Demande de connexion au serveurInitiation du dialogue SSLLe client envoie au serveur :

la version du protocole SSLun identificateur de session(session_identifier)la liste des algorithmescryptographiques supportés(cipher_suite)la liste des méthodes decompressionun nombre aléatoireclient_random sur 32 octets

26



Conclusion



Le serveur envoie au client :la version du protocole SSLl’identificateur de sessionsession_identifierles algorithmes cryptographiquessélectionnésun nombre aléatoireserver_random sur 32 octets

Si les listes d’algorithmes neconcordent pas, renvoi de l’erreurhandshake_failure.

27



Conclusion



Le serveur envoie son certificatX.509Le client le vérifie. Si erreur, laconnexion ne sera pas établie

Éventuellement, le serveur peut aussienvoyer un message ServerKeyExchangepour initier l’échange de clef avecDiffie-Hellman.

28



Conclusion



Cette étape est optionnelle ; elle estutilisée pour la doubleauthentification. Le serveurdemande le certificat du client.

29



Conclusion



Le serveur a envoyé tous sesmessages et se met en attente d’unréponse.

30



Conclusion



Si le serveur l’a demandé, le clientenvoie son certificat.S’il n’en a pas, il envoie le messaged’alerte no_certificate. C’est alorsau serveur de décider s’il poursuitla communication.

31



Conclusion



Le client envoie une pré-clef secrètePreMasterKey chiffrée avec la clefpublique du serveur :

Dans le cas de RSA, suitealéatoire de 48 octetsDans le cas de Diffie-Hellman,elle a déjà été échangée

À partir de PreMasterKey,client_random et server_random,et à l’aide de fonctions de hachage,les deux parties calculent la clef desession MasterKey

32



Conclusion



En double authentification, le clientprouve qu’il est en possession de laclef privée correspondant à soncertificat en envoyant des donnéesdéjà échangées chiffrées avec saclef privée

33



Conclusion



Les algorithmes ont été acceptés

34



Conclusion



Fin de la négociation et du« Handshake »Début de la session SSLDorénavant, les communicationssont chiffrées de manièresymétrique avec la clef de sessionMasterKey négociée précédemment

35



Conclusion

Plan





5 Conclusion

36



Conclusion

Infrastructure à clefs publiques

une PKI (Public Key Infrastructure) ou ICP (infrastructure àclefs publiques) met à disposition les clefs publiques (donc lescertificats) de ses utilisateurs.elle gère l’intégralité du cycle de vie d’un certificat, de sasignature à sa mort naturelle (dates de validité) ou sarévocation s’il est compromis.un logiciel de PKI permet d’accomplir ces tâches et de garderune trace des certificats clientsle groupe PKIX de l’IETF est à l’origine d’un effort denormalisation des spécifications et protocoles de PKI

37



Conclusion

Autorités de certification et d’enregistrement

L’autorité de certification (AC ou CA) est une entitéreprésentant le capital de la confiance de la PKI. C’est elle quisigne les demandes de certificat avec sa clef privée, dont laconfidentialité est primordialeL’autorité d’enregistrement (AE ou RA) est chargée derecevoir les demandes de signature de certificat et de s’assurerde leur validité et de l’identité du demandeur. Elle peut êtreincluse à l’AE

38



Conclusion

Entité d’enrôlement

l’entité d’enrôlement (EE) peut être accessible directementpar l’utilisateur, ou uniquement par un opérateur de l’AE.elle permet d’effectuer une demande de certificat, par exempleau travers d’une interface web.l’utilisateur peut fournir ses données ou un certificatPKCS#10la fonctionnalité SPKAC des navigateurs (Signed Public KeyAnd Challenge) permet d’effectuer une demande de manièredécentralisée

39



Conclusion

Mais que faire des certificats compromis ?

le point faible des PKIle préjudice d’une compromission aggravé par lecomportement des clients courants (navigateurs. . ., quiignorent les protocoles existantsles CRL (Certification Revocation List), « normalisées » par laRFC 3280 :

moyen de mise à disposition ? (cf. Verisign...). LDAP,HTTP,. . .rythme d’actualisation ? (fenêtre de temps)taille et stockage ?consultation par les clients ?

OCSP (Online Certificate Status Protocol), RFC 2560 :déclare valide un certificat qui n’a pas été révoquésujet aux attaques : messages signés en cache, messagesd’erreur non signés

40



Conclusion

Accélération SSLLogiciels de PKI

Plan





5 Conclusion

41



Conclusion


Pourquoi l’accélération SSL ?

les calculs de cryptographie asymétrique peuvent mettre unserveur à genouxpour dissocier totalement la couche SSL de STAP

42



Conclusion


Accélération logicielle : utilisation de stunnel

Stunnel est capable de gérer la couche SSL indépendamment del’application. Suivant les versions, paramétrable en ligne decommandes ou avec un fichier de configuration.

Exemple en ligne de commandestunnel -f -D 7 -d 9501 -r afsollx :9500 -o log -p stunnel.pem -P/̃.stunnel/pidfile -v 3 -a /̃.stunnel/cert_clients

-d et -r : IP/port source et destination. Exécuter stunnel surune autre machine permet de monter une installation typeproxy SSL-p : fichier PEM contenant le certificat et la clef privée duserveur-v : vérification du certificat. 2 : validité, 3 : comparaison avecfichiers installés localement (-a).

43



Conclusion


Dispositifs d’accélération matérielle

Différents typescartes jouant le rôle de co-processeur (CryptoNetX chezBroadcom) : obsolètecartes réseau contenant les biclefs et gérant le flux SSL(nCipher, Sun).boîtiers indépendants (nCipher, Kemp). Mêmesfonctionnalités + répartition de charge.

Intégrationavec la PKI ?avec stunnel et/ou OpenSSL ?avec l’environnement (drivers fermés) ?

44



Conclusion


Accélération matérielle : quart d’heure consumériste

Fig. 1: nCipher netHSM Fig. 2: nCipher nFast et nForce

Fig. 3: Kemp Load Balancer 1500

45



Conclusion


Plan





5 Conclusion

46



Conclusion


Généralités

Un logiciel de PKI permet de gérer les certificats d’uneorganisation.Liste d’applications libres ou « open source » :

tinyCANewPKIEJBCAIDX-PKI, et sa version "commerciale" OpenTrust PKIOpenCA

47



Conclusion


Outils extérieurs à la PKI

LDAP : annuaire. Stockage de données concernant l’émissionde certificats en plus des données usuellesKerberos : serveur d’authentification

48



Conclusion


OpenSSL en ligne de commandeFichier de configuration de l’AC 1/2

[ ca ]default_ca = exampleca[ exampleca ]dir = /opt/examplecacertificate = $dir/cacert.pemdatabase = $dir/index.txtnew_certs_dir = $dir/certsprivate_key = $dir/private/cakey.pemserial = $dir/serialdefault_crl_days = 7default_days = 365default_md = md5policy = exampleca_policyx509_extensions =certificate_extensions

[ exampleca_policy ]commonName = suppliedstateOrProvinceName = suppliedcountryName = suppliedemailAddress = suppliedorganizationName = suppliedorganizationalUnitName =optional[ certificate_extensions ]basicConstraints = CA :false[ req ]default_bits = 2048default_keyfile =/opt/exampleca/private/cakey.pem

49



Conclusion


OpenSSL en ligne de commandeFichier de configuration de l’AC 2/2

default_md = sha1prompt = nodistinguished_name =root_ca_distinguished_namex509_extensions =root_ca_extensions[ root_ca_distinguished_name ]commonName = Example CAstateOrProvinceName = VirginiacountryName = USemailAddress = [email protected] = RootCertification Authority[ root_ca_extensions ]basicConstraints = CA :true

Créer l’AC

export OPENSSL_CONF =/opt/exempleCA

openssl req -x509 -newkey rsa-out cacert.pem -outform PEM

50



Conclusion


OpenSSL en ligne de commandeCréation de certificat

Effectuer une demande de certificat (certificate request) :unset OPENSSL_CONFopenssl req -newkey rsa :1024 -keyout testkey.pem -keyformPEM -out testreq.pem

Signer cette demande :export OPENSSL_CONF = /opt/exempleCAopenssl ca -in testreq.pem

Placer un certificat client et la chaîne des AC dans un conteneurPKCS#12 :

openssl pkcs12 -export -in testreq.pem -inkey testkey.pem-certfile CA.pem -out certificat.p12 -name "Certificat TPE"chmod 600 certificat.p12

51



Conclusion


TinyCA

Fig. 4: Interface graphique deTinyCA

Avantagestrès simpleidéal pour un VPN tel quecelui d’AFSOL

Inconvénientsinterface GTKrythme de développement ?

52



Conclusion


NewPKI

Fig. 5: Interface de newPKI

AvantagesTrès bien structuré enclasses réutilisablesRajout possible d’unecouche en PHP

Inconvénientsinterface GTKrythme de développement ?compatibilité MySQL 5Intégration stunnel/HSM ?

53



Conclusion


IDX-PKI

deux versions : une sous licence GPL, une « commerciale »(modules HSM supplémentaires. . .)engagement sur version libre en baisse ?haute modularitérépondeur OCSPinterface web

54



Conclusion


EJBCA

PKI en java (JBOSS) ⇒ un peu lourd et éloigné destechnologies usuelles de STAPdéveloppement actif et support HSMrépondeur OCSPinterface webauthentification web par certificat clienttrop orienté client HTTP ?moins modulaire qu’OpenCA

55



Conclusion


OpenCA

Fig. 6: Interface d’OpenCA

interface webtrès modulablesupport de HSMrépondeur OCSPimportation et exportationde données (par exemplepour Stunnel)authentification web parcertificat clientun tout petit peu compliquéà mettre en œuvre

56



Conclusion

Conclusion

Une technologie complexe, en plein déploiementUn aspect désormais important de la monétiqueIntégrer une PKI à STAP pour structures de taille réduite(moins de 200 TPE) : un projet en soi :

déploiement technique et simplification d’une applicationexistante (OpenCA pourrait être un bon choix)aspects légaux : AFSOL ne doit pas avoir connaissance de laclef privée de l’AC ⇒ génération automatique.nécessité d’une formation minimale pour le personnelnormalisation des TPE ? Sagem : « phase de test ».

57



Conclusion

Bibliographie

Cachat Ch., Carella D., PKI Open Source : déploiement etadministration, O’Reilly France, 2003Chandra P., Messier M., Viega J., Network Security withOpenSSL, O’Reilly, 2002Rescorla E., SSL and TLS : Designing and Building SecureSystems, Addison-Wesley Professional, 2000Menezes A. J., Van Oorschot P. C., Vanstone S.A., Handbookof Applied Cryptography, CRC Press, 2001 (5e tirage),disponible en PDF sur :http ://www.cacr.math.uwaterloo.ca/hac/

58



Conclusion

That’s all folks !

59

Une introduction à SSL - Set sivelles · 2017-02-04 · Introduction et concepts de base...

Documents

Transcript of Une introduction à SSL - Set sivelles · 2017-02-04 · Introduction et concepts de base...