1.2. Que sont SSL et les certificats�?

1.2.1. Clef publique�/ clef priv�e

Le chiffrement � base de clef publique garantit qu'une donn�e chiffr�e par une clef, publique ou priv�e, ne peut �tre d�chiffr�e que par la clef associ�e. Cela peut para�tre surprenant mais croyez moi, �a fonctionne. Les clefs sont de m�me nature et leurs r�les peuvent �tre invers�s�: ce que l'une chiffre est d�chiffrable par l'autre. La paire de clef repose sur des nombres premiers et leur longueur, exprim�e en digits binaires, traduit la difficult� qu'il y a � d�chiffrer un message sans connaissance � priori de la clef n�cessaire. L'astuce consiste � conserver une clef secr�te (la clef priv�e) et � distribuer l'autre clef (la clef publique) � tout le monde. N'importe qui peut vous envoyer un message chiffr� mais personne d'autre que vous ne peut le d�chiffrer tant que vous �tes le seul � conserver un des deux membres de la paire de clefs. On peut �galement prouver qu'un message provient de vous en le chiffrant avec votre clef priv�e�: seule la clef publique correspondante le d�chiffrera. Notez que le message n'est pas prot�g� parce que vous le signez. Tout le monde a acc�s � la clef de d�chiffrement, ne l'oubliez pas.

Le probl�me consiste � obtenir la clef publique du correspondant. En g�n�ral, vous lui demanderez de la transmettre via un message sign� qui la contiendra accompagn�e d'un certificat.

Message-->[Clef publique]-->Message chiffr�-->[Clef priv�e]-->Message

1.2.2. Le certificat

Qu'est-ce qui vous garantit que vous dialoguez bien avec la bonne personne ou le bon site web�? En principe, quelqu'un aura fait l'effort (s'il est s�rieux) de v�rifier que les propri�taires du site sont bien ceux qu'ils affirment �tre. On fait naturellement confiance � ce quelqu'un�: son certificat, un certificat racine, est incorpor� � votre navigateur. Un certificat contient des informations relatives � son propri�taire comme une adresse �lectronique, un nom, l'usage pr�vu du certificat, une dur�e de validit�, un identifiant de localisation ou un nom qualifi� (DN/Distinguished Name) qui comprend le nom d'usage (CN/Common Name) et l'identifiant du signataire du certificat. Le certificat comprend �galement la clef publique et un hach� pour garantir l'int�grit� du message. Comme vous avez d�cid� de faire confiance au signataire du certificat, vous accordez du cr�dit � son contenu. On parle d'arbre de confiance de certification ou de chemin de certification. En g�n�ral, le navigateur et les applications incluent d'office le certificat racine d'autorit�s de certification bien connues. L'autorit� de certification tient � jour une liste des certificats sign�s ainsi qu'une liste des certificats r�voqu�s. Un certificat n'est pas fiable tant qu'il n'est pas sign� puisque seul un certificat sign� ne peut pas �tre modifi�. Un certificat peut se signer lui-m�me. On parle alors de certificat auto-sign�. Tous les certificats de CA racines sont ce type.

Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 1 (0x1)
 Signature Algorithm: md5WithRSAEncryption
 Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/Email=administrator@sopac.org
 Validity
 Not Before: Nov 20 05:47:44 2001 GMT
 Not After : Nov 20 05:47:44 2002 GMT
 Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/Email=administrator@sopac.org
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 RSA Public Key: (1024 bit)
 Modulus (1024 bit):
 00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a:
 9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36:
 b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4:
 7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86:
 08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd:
 94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25:
 da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e:
 42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a:
 6c:14:e2:ae:62:e7:6b:30:e9
 Exponent: 65537 (0x10001)
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Comment:
 OpenSSL Generated Certificate
 X509v3 Subject Key Identifier:
 FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F
 X509v3 Authority Key Identifier:
 keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6
 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/Email=administrator@sopac.org
 serial:00
 Signature Algorithm: md5WithRSAEncryption
 34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd:
 aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57:
 2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96:
 34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62:
 e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5:
 0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06:
 ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af:
 bc:5a
-----BEGIN CERTIFICATE-----
MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox
DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww
CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B
CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy
MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD
VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD
Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv
cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB
0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI
2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2
JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ
YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud
DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl
uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp
amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx
FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0
cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw
VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb
xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b
Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa
-----END CERTIFICATE-----

Comme vous avez pu le remarquer, le certificat mentionne son �metteur, contient la clef publique de son propri�taire, la p�riode de validit� du certificat et une signature pour v�rifier qu'il n'a pas �t� modifi�. Le certificat ne contient PAS la clef priv�e qui ne doit jamais �tre r�v�l�e. Ce certificat contient tous les �l�ments n�cessaires pour envoyer un message chiffr� � son propri�taire ou pour v�rifier un message dont la signature lui est attribu�e.

1.2.3. La clef sym�trique

Les algorithmes de chiffrement � paire de clefs publique/priv�e sont int�ressants mais pas toujours pratiques. Ils sont asym�triques parce que des clefs diff�rentes sont requises au chiffrement et au d�chiffrement. La m�me clef ne peut remplir les deux r�les. Les algorithmes sym�triques actuels sont nettement plus rapides que les algorithmes asym�triques. Une clef sym�trique est toutefois potentiellement peu s�re. Il suffit qu'un individu nuisible se la procure et il n'y a plus d'information prot�g�e. La clef sym�trique doit donc �tre transmise au correspondant sans �tre intercept�e. Rien n'est s�r dans l'Internet. La solution consiste � envelopper la clef sym�trique dans un message chiffr� au moyen d'un algorithme asym�trique. Comme personne d'autre que vous ne conna�t la clef priv�e, le message chiffr� avec la clef priv�e est s�r (enfin, relativement, rien n'est garanti en ce bas monde sinon la mort et les imp�ts). La clef de chiffrement sym�trique est choisie al�atoirement de telle sorte qu'une compromission accidentelle n'ait pas d'impact sur les transactions futures.

Clef sym�trique-->[Clef publique]-->Clef de session chiffr�e-->[Clef priv�e]-->Clef sym�trique

1.2.4. Les algorithmes de chiffrement

Diff�rents algorithmes existent, sym�triques ou non, avec diverses longueurs de clef. En principe les algorithmes ne peuvent pas �tre brevet�s. Si Henri Poincar� l'avait fait, il aurait pu poursuivre Albert Einstein�… Les algorithmes ne peuvent donc pas �tre brevet�s, � l'exception toutefois des �tats-Unis. OpenSSL est mis au point dans des pays o� les algorithmes ne sont pas brevet�s et o� l'usage de la cryptographie n'est pas r�serv� � des agences d'�tat pour des fins militaires ou d'espionnage. Lors de la n�gociation entre le navigateur et le serveur web, les applications fournissent l'une � l'autre une liste d'algorithmes qu'elles peuvent traiter, class�s par ordre de pr�f�rence. L'algorithme pr�f�r� en commun est choisi. OpenSSL peut �tre compil� sans inclure la gestion de certains algorithmes de fa�on � rester utilisable dans des pays o� l'usage de la cryptographie est r�glement�.

1.2.5. Le hachage

Un hachage s'obtient par application d'une fonction, dite � sens unique, � un message. La fonction pr�sente cette propri�t� qu'il n'est pas possible de former un message initial � partir du hach�. En outre, le hach� est compl�tement modifi� en cas de changement, m�me mineur, du message d'origine. Il est donc pratiquement impossible de modifier un message � hach� constant. Les fonctions de hachage s'emploient dans des m�canismes � base de mot de passe, des v�rifications d'int�grit� (MD5) et en g�n�ral pour v�rifier que des donn�es n'ont pas �t� alt�r�es. L'IETF (Internet Engineering Task Force) pr�f�re apparemment SHA1 � MD5 pour diverses raisons techniques (cf RFC2459 7.1.2 and 7.1.3).

1.2.6. La signature

La signature d'un message consiste � associer une identit� � son contenu. Le plus souvent il s'agit de prouver qui en est l'auteur mais ce n'est pas toujours le cas. Le message peut �tre textuel ou �tre le certificat de quelqu'un d'autre. Pour signer un message, son hach� est d'abord cr�� puis ce dernier est chiffr� avec la clef priv�e. Le r�sultat et votre certificat accompagnent ensuite le message d'origine. Le destinataire de l'ensemble recalcule le hach� et le compare au r�sultat du d�chiffrement de la signature avec votre clef publique suppos�e. Il v�rifie ensuite la validit� de votre certificat.

Ce type de signature permet de transmettre la clef publique et le certificat � chaque correspondant.

Il y a deux fa�ons de signer, soit en incluant le message � la signature, soit en chiffrant le message et sa signature. Cette derni�re forme n'est qu'un chiffrement tr�s pauvre car n'importe quelle application qui dispose de la clef publique peut l'inverser. La premi�re forme permet de passer un contenu textuel � l'utilisateur en toute circonstance tandis que la deuxi�me l'interdit d�s que le message a �t� alt�r�.

1.2.7. Le mot de passe

Le mot de passe correspond � un mot de passe originel Unix � ceci pr�s qu'il est normalement plus long que 8 caract�res et ne se limite pas forc�ment � un seul mot. De nos jours les syst�mes Unix utilisent des hach�s MD5 ou autres qui n'imposent plus de limitation de longueur de mot de passe.

1.2.8. L'infrastructure de clefs publiques

L'infrastructure de clefs publiques (PKI/Public Key Infrastructure) d�signe le syst�me de gestion et la base de donn�es qui permettent de signer les certificats, de tenir � jour une liste de certificats r�voquer, de distribuer les clefs publiques, etc. Il est le plus souvent accessible via un site web ou un serveur LDAP. Certaines entit�s sont �galement charg�es de v�rifier que vous �tes bien qui vous pr�tendez �tre. On peut avoir recours � une PKI commerciale connue dont le certificat racine se trouve d�j� dans votre application. Un probl�me appara�t au niveau du courrier �lectronique pour lequel vous avez le choix entre l'emploi d'un certificat g�n�rique ou une facturation d'environ 100E par an pour chaque adresse �lectronique. De plus, il n'y a aucun moyen d'obtenir la clef publique de quelqu'un sans avoir re�u auparavant de ce correspondant son certificat (accompagn� de sa clef publique).