Archive | PKI, ICP, IGC

ANSSI, Google et les hommes du milieu au milieu

Bon ok, j’ai vraiment eu du mal à prendre le train en marche, passionné que j’étais par l’élection de miss France.

Tout à commencé par le message de l’ANSSI annonçant la suppression de l’une des branches de son IGC, puis j’ai aperçu le communiqué de Google et le flot de commentaires plus ou moins éclairés sur ma TL avant de terminer par les articles des « Gala » de l’informatique (JdN, 01, ZDNet, …) ou pire, la presse nationale (Le Monde).

Heureusement, Olivier Laurelli nous a pondu une bonne synthèse sur reflets.info qui m’a permis de me remettre à niveau.

Du coup ce matin, de très bonne heure, j’ai attrapé mes crayons de couleurs pour essayer de griffonner ce que j’avais cru comprendre du bazar. Cela donne la synthèse suivante, qui confirme très bien les doutes émis par mes profs de dessin du collège sur mes talents de graphistes 😉

ANSSInTheMiddle_medium

ANSSInTheMiddle caught by Google

 J’ai aussi tenté de trouver un nom rigolo à l’image ainsi créée, mais une fois encore j’ai pu évaluer le chemin à parcourir pour rattraper Laurent Baffie ou comment s’appelle-t-il déjà celui qui essaie toujours de se faire passer pour plus beauf qu’il n’est réellement pour que son public se sente à l’aise à ses côtés ? Ah oui, Bigard (celui qui à un « e » près ne laissera pas de trace dans l’histoire).

Donc, traduction du gribouillis et explications de la situation:

Tout le monde sait aujourd’hui à Bercy comme au ministère des Finances ou chez ma mère que la messagerie c’est le diable.

C’est en effet par la messagerie que toutes les tares des SI se propagent et par ces mêmes tuyaux que tout fuite … d’autant plus si les systèmes utilisés s’appellent GMail ou Yahoo.

Pour tenter d’ y remédier, quelqu’un de de  la Direction Générale du Trésor à la bonne idée d’écouter les échanges entre ses utilisateurs et Google (en ayant apparemment pris soin de prévenir lesdits utilisateurs). Bref, jusque là un grand classique. Pour cela,  il insère donc un équipement de sécurité interne (boitier Netasq) sur le réseau dans lequel il place un certificat émis par l’une des branches de l’autorité de certification de l’ANSSI. Pour la très grande majorité des utilisateurs qui croient communiquer directement avec Google, c’est complètement transparent. L’espion/indiscret/contrôleur réalise un MITM classique.

Un quoi ?

Un « Man In The Middle » les amis … difficilement traduisible en France où on continue de s’arracher les cheveux entre l’Homme du milieu (typé pègre, Cosa Nostra, marseillais, politique …) ou l’Homme au milieu (plus orienté Marc Dorcel).

La page Wikipedia en français sur le sujet est d’ailleurs remarquablement légère …

Placé entre l’utilisateur et Goggle, il se fait passer pour l’un ou l’autre aux yeux de ces derniers pouvant ainsi observer leurs échanges.

Jusqu’au moment où Google dénonce l’imposture 😉 Alors là…, Google jouant les vierges effarouchées, ça vaut le meilleur de Jean Roucas !

Dès que la nouvelle apparaît sur la toile, quelques grand défenseurs des libertés individuelles peu inspirés (merci pour nous, il y en a qui font un réel bon boulot) crient au scandale : « L’ANSSI se lance dans le surveillance style NSA/Prism » et autres délires paranoïaques. Bahhh non les gars, le besoin n’est pas là, c’est quand on aura découvert que Orange fait la même chose qu’il faudra crier 😉

Jean-Pierre Pernaut n’ayant pas été alerté, le soufflet semble retomber… mais peu se posent aujourd’hui la bonne question : comprendre comment Google a été informé de tels agissements et pourquoi a-t-il dénoncé aussi rapidement publiquement le stratagème qui devait forcément gêner son business.

Des pistes de réponse à la première question :

– l’utilisation de Chrome qui enverrait (parfois à l’insu de notre plein gré) à Google des informations relatives aux certificats utilisés (et peut-être d’autres),

– des contrôles OSCP depuis le poste client pour vérifier en  ligne la non répudiation d’un certificat,

– l’information par des utilisateurs de la DGT,

– des plugins variés navigateurs remontant de l’info à Google…

Bref, pour l’instant on ne sait pas ! On confirme tout juste que Google en sait, pour sa part, vraiment beaucoup sur nos moindre faits et gestes… y compris les pseudo-boulettes avouées par l’ANSSI.

 

 

 

 

Posted in PKI, ICP, IGCCommentaires fermés sur ANSSI, Google et les hommes du milieu au milieu

SSL/TLS : Histoire, fonctionnement, sécurité et failles à La Cantine

SSL/TLS à La Cantine

SSL/TLS à La Cantine

J’ai assisté le  20 septembre 2013 de 19h00 à 23h00 avec une cinquantaine de personnes à la conférence donnée par Benjamin Sonntag (@vincib).

Je vous en relate l’ambiance ci-dessous :

J’arrive à18H45, un peu stressé et affamé. Je ne connais pas l’endroit et suis un peu intimidé par les pointures que je vais croiser.

Vu que je suis l’un des seuls en costard, les gus doivent penser que je suis de la NSA ou du service d’ordre. L’assemblée est en effet largement bigarrée, de 18 à 78 ans et rafraichie à la bière. Je n’ose pas aller au comptoir en commander une, de peur de perdre ma place privilégiée plein axe au troisième rang. On est loin de l’ambiance feutrée proutprout du salon « DSI  de l’année ». Ici, c’est cool attitude et coupe de cheveux hors standard. Les auditeurs arborent majoritairement le look hacktiviste assorti de l’ordinateur portable recouvert de stickers à l’effigie des grands rendez-vous du hacking. A côté d’eux, le moindre startuper de la Silicon Valley ferait BCBG coincé !

Je reconnais dans l’assemblée quelques visages révélés par Twitter.  Je remarque qu’il y a même quelques sujets féminins, un spectateur dont l’allure est quelque part entre clodo, Richard Stallman et Léo Ferré, un sosie du frère du père noël, quelques tronches de vieux hippies, une poignée d’étudiants en école d’informatique qui ont dû arrêter toute activité sportive en CE2, un couple de cinquantenaires visiblement égaré, quelques consultants encostumés, un extra-terrestre iroquois … et Benjamin Sonntag. On reconnait dans le regard de chacun d’eux la petite lueur de la passion.  On ne vient pas un vendredi soir après le boulot à la Cantine comme on va assister au dernier Workshop Microsoft Winbouse2013 ou au talk branché  Apple merde-I-5f pour se la couler douce une demi-journée.

Affairé à ses derniers préparatifs, Benjamin est serein et déterminé. On devine la maitrise du sujet à peine perturbée par les couacs du tcpDump.

Après avoir salué l’assistance, il nous embarque pour près de trois heures dans l’univers de TLS, des certificats et autorités de certification, des courbes elliptiques et de Diffie-Hellman… mais aussi dans le monde de la sécurité au sens large et du respect de la vie privée. Quelques centaines de minutes de discours posé, précis, argumenté, illustré d’exemples, de démos et d’anecdotes. Ca s’écoute comme une belle histoire… J’aurais pu venir avec ma mère. Ressurgissent régulièrement les références à son quotidien et ses activités au sein de La Quadrature de Net. Transparait le côté humaniste du personnage.

Dans l’assistance ça ne bronche pas, le bagage technique moyen étant élevé, on va pouvoir aborder une bonne partie de la technicité du problème sans lassitude. Je ne résumerai pas le contenu formel de la présentation, dont on retrouvera bientôt l’intégralité ici sur le web, de peur de le dénaturer et de ne pas en reproduire l’exhaustivité.

Reprenant Bruce Schneier et Snowden (Prix Nobel de la paix 2025 ?), Benjamin insiste largement sur le fait que la crypto nous apporte le niveau de sécurité et de confidentialité que l’on se doit d’attendre d’elle. Le chiffrement, malgré la fragilité du modèle de confiance fourni par les autorités de certification commerciales et les difficultés de protéger les sacro-saintes clefs privées est sûr ;  Même s’il est techniquement possible de casser du RSA 1024 pour quelques millions de dollars, le maillon faible est bien ailleurs … à la fois dans la faiblesse, l’inconsistance, et les motivations inavouables toutes malheureusement humaines. Ce sont celles-ci qui font qu’il existe aujourd’hui des implémentations de protocoles sécurisés pourries utilisant des algorithmes cassés ou conçus avec des portes dérobées ou pire, car de manière généralisée, fonctionnant sur des plateformes matérielles pour le moins dangereusement hermétiques.

Alors, pour se protéger, comment faire ?

Ne pas avoir une confiance aveugle envers les marchands de solutions de sécurité qui vous vantent/vendent leur « cryptage » propriétaire inviolable.  Faire confiance, avec un œil critique, à la crypto dont le code source est ouvert et auditable.  Comprendre les mécanismes mis en œuvre afin de vérifier que votre entreprise ne vous offre aussi gentiment que secrètement un joli certificat de chez Bluecoat qui lui permet de déchiffrer tous vos échange HTTPS. Etre en mesure d’expliquer à tout un chacun les objectifs de la sécurisation des échanges dans le  respect de la vie privée afin de ne pas tomber, sans s’en rendre compte dans le piège des Google, Paypal et consorts ou de se faire pirater ses comptes par le premier script kiddy en omettant le « s » de HTTPS.

@LauMarot

Toute la conf est disponible en vidéo et les diapositives du support sont téléchargeables ici. Du vraiment bon boulot !

Posted in Boulot, PKI, ICP, IGC1 Commentaire

Luna SA HSM Concepts

SafeNet Luna SA 1U

SafeNet Luna SA 1U

Bonne introduction à la présentation des HSM Luna SA : http://geekcredential.wordpress.com/2012/07/02/luna-sa-hsm-concepts/comment-page-1/#comment-131

Love the title : « Learn from my mistakes« 
Merci à Marc Silverboard.
Reste encore un peu de chemin pour accéder directement via keytool et PKCS11 au HSM !
Pour l’instant, il faut se conteneter du tradistionnel :
keytool -genkeypair -alias signingCert -keystore keystore.luna -storepass ***** -validity 365 -keyalg RSA -keysize 2048 -storetype Luna

Posted in PKI, ICP, IGCCommentaires fermés sur Luna SA HSM Concepts

Programme culturel du WE

Fête de la musique dans le 44

Fête de la musique dans le 44

Mince, j’ai loupé DJ Mosey au festiZad, le dernier apéro Facebouse à Notre Dame de la Glande … parait qu’il y avait un max de pervers pour pister les p’tites fugueuses 🙂

De Jack Lang à Depardieu, personne pour m’inviter à aller siffler quelques canettes dans la gadoue de Loire-Atlantique (d’habitude c’est plutôt le Loir-et-Cher, hein Michel Delpech). Du coup je suis resté soigner, sans trop de succès, ma vilaine bronchite.
Par solidarité avec Yves Michaud qui arrête Traverse sur le site de Libé (on pourra néanmoins le suivre sur son blog de Philosophie magazine: http://www.philomag.com/blogs/le-blog-d-yves-michaud ), j’arrête à compter de ce jour d’écrire des âneries sur Facebook et Tweeter (Résolution n°1). Au moins, ici je peux m’adresser en toute liberté et sans crainte de choquer mon public le plus fidèle : moi.
Côté spectacle, j’ai été ravi de revoir le stade d’Epinal où épaulé de mon Pote Jim Péralba, j’ai dézingué pas mal de tibias vosgiens dans un autre siècle. J’espère que la famille Q. de Saint Nic (que je ne peux pas citer de peur qu’ils ne soient poursuivis pour piratage), conservera religieusement le dernier numéro des Infos Dieppoises avec le dossier spécial Dieppe-Nantes. J’imagine que mon pote Franck Delo  a du se retourner dans sa tombe ne de pouvoir coacher les dieppois contre les miettes de la légende nantaise.
Allez, demain c’est vraiment 2013, va falloir taper dedans ! HSM et signature/horodatage PDF Safenet au programme.
Dernier petit extrait (que me rappelle @OhOceane) avant extinction :
« Le discours public contemporain est conçu pour être compris par un enfant de dix ans ou un adulte n’ayant fréquenté que l’école élémentaire. Nous parlons et réfléchissons presque tous à ce niveau, et le divertissement est à l’avenant. » Olé, vous pouvez continuer de regarder la télé en finissant votre partie de calofdutiBlackOPs sur votre tablette.
— Chris HEDGES, L’empire de l’illusion : la mort de la culture et le triomphe du spectacle

Posted in Boulot, Fête, PKI, ICP, IGCCommentaires fermés sur Programme culturel du WE

PKCS#12

certificat et pkcs12

certificat et pkcs12

En cryptographie, PKCS#12 est l’une des normes de la famille Public-Key Cryptography Standards (PKCS) ou standards de cryptographie à clé publique, publiée par les Laboratoires RSA en juin 1999. Il définit un format de fichier couramment utilisé pour stocker les clés privées X.509 accompagnant les certificats de clés publiques, protégé par mot de passe symétrique, et est le successeur du format PFX de Microsoft.

Comme le présente RSA : Personal Information Exchange Syntax Standard specifies a portable format for storing or transporting a user’s private keys, certificates, miscellaneous secrets, etc.

-> Télécharger le standard au format PDF

Le format PKCS#12 est utilisé pour stocker les clés privées et des certificats dans un seul fichier chiffré : par exemple Java l’utilise pour ses keystores.

L’extension de fichier pour les fichiers PKCS#12 est habituellement « .p12« , mais on les rencontre aussi en « .pfx« . Ces fichiers peuvent être créés, analysés et lus par exemple avec la sous-commande pkcs12 de OpenSSL.

Posted in PKI, ICP, IGCCommentaires fermés sur PKCS#12

Signature numérique : un petit schéma vaut mieux qu’un long discours :-)

Signature numérique

Signature numérique

  1. Calcul de l’empreinte (on dit aussi hash, ou parfois condensat/condensé ) des données à signer.
  2. Chiffrement de l’empreinte à l’aide de la clé privée de l’émetteur dont lui seul dispose et qu’il conserve précieusement. Le résultat de ces deux action produit la signature des données.
  3. => Envoi des données en clair et de la signature au destinataire (avec éventuellement le certificat de l’émetteur contenant sa clef publique)

  4. Déchiffrement de la signature avec la clé publique de l’émetteur qui est une information librement diffusée. Cela permet de retrouver l’empreinte associée aux données signées.
  5. Calcul de l’empreinte des données signées. On vérifie que cette empreinte correspond à la précédente, auquel cas la signature est valide : les données sont donc intègres et l’identité de l’expéditeur est vérifiée.

 

 

 

 

 

 

 

Posted in PKI, ICP, IGCCommentaires fermés sur Signature numérique : un petit schéma vaut mieux qu’un long discours :-)

Arrêtez de crypter !

Petite précision matinale suite à la lecture d’articles employant un vocabulaire approximatifs: on ne crypte pas, on CHIFFRE !

On chiffre avec une clé de chiffrement pour obtenir un cryptogramme.
Lorsque l’on a un cryptogramme à lire, deux possibilités s’offrent à nous… Soit on le déchiffre en employant la clé de chiffrement, soit on n’a pas la clé de chiffrement et dans ce cas, on le décrypte (on casse le code).
Cette explication étant donnée, on comprend que le terme –crypter– reviendrait à chiffrer sans clé … ce qui est impossible. Donc crypter n’existe pas (où alors peut être mettre dans une crypte mais cela n’a plus grand chose à voir avec notre sujet :-).

Voilà c’est dit, bonne journée à Bob et Alice !
Mais il y a un terme pire encore … : encrypter (une mauvaise traduction du mot -encryption- in english qui doit être traduit par -chiffrer-). Plus de détails sur wikipedia.

Posted in PKI, ICP, IGCCommentaires fermés sur Arrêtez de crypter !

Web sécurisé : création des certificats avec openSSL

Vous avez entendu parler de Firesheep, l’extension pour Firefox qui permet de collecter toutes les mots de passe de votre entourage sur les réseaux WIFI ouverts ?

Vous n’avez pas envie que votre site et ses utilisateurs en soient les prochaines victimes ? Une solution simple : sécuriser votre site avec SSL/TLS/HTTPs.

Connectez-vous en tant que root et allez dans le répertoire de configuration de votre serveur Apache2 (généralement /etc/apache2 mais on peut évidemment en choisir un autre) et créez un répertoire appelé ssl. Vous vous placerez dans ce répertoire afin que les clés et les certificats soient créés à l’intérieur avant d’effectuer les opérations suivantes.

Création du certificat serveur

Génération de la clé privée

On génère la clef privée avec la commande suivante en définissant un nom de fichier :

openssl genrsa 1024 > servwiki.key

La sortie attendue est la suivante :

Generating RSA private key, 1024 bit long modulus
 ..................++++++
 .................................................................++++++
 e is 65537 (0x10001)

Si vous souhaitez que cette clé ait un mot de passe (qui vous sera demandé à chaque démarrage d’apache, donc à éviter !), ajoutez « -des3 » après « genrsa « .

Ceci a pour effet de créer votre clé privée pour SSL [1], ne la perdez pas (ni le mot de passe éventuel) !

Vous pouvez observer son contenu :

less servwiki.key
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDQG9wvnuLC4aqzaJCAWGA1AxFzg00hjPObhq1mukzsGyuuWBFG
vj/k9vFNYX55DHctb/4cXtsZRWWvgcjtYnCVwRu+DAjFsk//kOMfhplmiv9xQ+ZL
8w/Xrnm8JWdSS+S4LCMnsuIiQtLbhMrQnUV02hAtbIZiSM3k6OjShEZhDQIDAQAB
AoGAHi0cBW+1k+qjFPbBlUq7UJSMUEKmyYmlvVSPCklTZB0gfVxZzPdDTpEcNks/
yo+rLFSD9Vsvy/9LGmLoXruadWlK67PCUnpM5/oRRGgy8t73YKrxflAU5Gtymjvc
ZCf0CAs6wBft3yLU31Qc4WqVM2vTyUH76jebVhxEw8k63OUCQQD/1OmAXV+TxBPG
ZTPFbzUeAE5rQqqOW4aoMNvM61Yn/19h6SzY2MfSQvF1BNns/efCRrqOMeyvPWUG
g1okfogTAkEA0D7pDf/D2Yu5msbOAGF4QBU1erLzpi/s6Rv6VEPYCGnHQlo3jbg9
FZbjHJ4UcYyYaA8jIrkY+FIJM88YlGbWXwJBAILEdvJ5R/CFCkKf2j2yIWmLaIol
En8fw43XI5L0PB7Hxx6KDLVu4XzVYQyahTZBdqR0eMlUNZJBhJE2tO3wi2cCQQCp
JkCFd3es0BrNxqfzlThozRFofcz88za7TldydL0YcFtC4Sb4vWsYizwktZ6jcPEm
rQz8Gl9W7MO+ynwLptB/AkEA1tsnFXoYzI71enmTdugGxbv0RqAd5iQpDYQkDSdn
2LImp/3YnXNJ9qpY91j87tKthh/Oetu6SHlmLg1LOYNIdw==
-----END RSA PRIVATE KEY-----

Protégez votre fichier en faisant : chmod 400 servwiki.key

De multiples autres options sont possibles mais il est inutile d’alourdir le sujet

A partir de votre clé, vous allez maintenant créer un fichier de demande de signature de certificat (CSR[2]).

On génère la demande de certificat avec la commande suivante :

openssl req -new -key servwiki.key > servwiki.csr

Le système va vous demander de saisir des champs ; remplissez-les en adaptant sauf le champ « Common Name » qui doit être identique au nom d’hôte de votre serveur virtuel :

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:BRETAGNE
Locality Name (eg, city) []:Sulniac
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Lostihuel Braz
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:www.laurentmarot.fr
Email Address []:

Ce n’est pas la peine de saisir d’autres extra attributes

La commande précédente crée le formulaire de demande de certificat (fichier servwiki.csr) à partir de la clé privée préalablement générée.

Ce fichier dont le contenu est visible ci-dessous contient la clé publique à certifier.

less servwiki.csr
-----BEGIN CERTIFICATE REQUEST-----
MIIBsTCCARoCAQAwcTELMAkGA1UEBhMCRlIxFTATBgNVBAgTDENvcnNlIGR1IFN1
ZDEQMA4GA1UEBxMHQWphY2NpbzEMMAoGA1UEChMDTExCMREwDwYDVQQLEwhCVFMg
SU5GTzEYMBYGA1UEAxMPcHJvZi5idHNpbmZvLmZyMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDSUagxPSv3LtgDV5sygt12kSbN/NWP0QUiPlksOkF2NkPfwW/m
f55dD1hSndlOM/5kLbSBo5ieE3TgikF0IktjBWm5xSqewM5QDYzXFt031DrPX63F
vo+tCKTQoVItdEuJPMahVsXnDyYHeUURRWLWwc0BzEgFZGGw7wiMF6wt5QIDAQAB
oAAwDQYJKoZIhvcNAQEEBQADgYEAwwI4UvkfhBvyRrUXtjrLfZXLxZlF9o+URmHJ
ysvrLKfesVBEzdA9mqk1OwIwLfe8Fw2fhip2LGqvcCPxDMoIE/0cDkqGRg9iKp7D
DMuy69lPTEB6UtpVKO/1eage0oug6VqdfGAYMMSGyWFuO9FE4UE6HspVodb20wGV
4H8qZuk=
-----END CERTIFICATE REQUEST-----

Maintenant, deux choix s’offrent à vous :

  • envoyer le fichier servwiki.csr à un organisme (le tiers de confiance ou l’autorité de certification aussi appelée AC ou encore CA pour certification authority ) et ainsi obtenir le certificat dûment signé par la clé privée de l’organisme (après avoir payé),
  • ou bien signer vous-même le certificat. (ce qui dans l’absolu est une hérésie puisque cela revient à certifier que nous sommes bien celui que nous prétendons être)

Ce dernier choix a notre préférence pour des raison de simplicité … et de coût.

 

Création du certificat de l’autorité de certification

Pour signer un certificat, vous devez créer votre propre autorité de certification, cela implique donc de générer une clé et un certificat auto-signé.

La création de la clé privée de l’autorité de certification se fait comme précédemment :

openssl genrsa -des3 1024 > ca.key

Ce qui a pour effet de créer la clé privée de l’autorité de certification. Dans ce cas, il vaut mieux rajouter l’option -des3 qui introduit l’usage d’une « passphrase » [3] car c’est cette clé privée qui signera tous les certificats que l’on émettra ; cette « passphrase » sera donc demandée à chaque utilisation de la clé.

Ensuite, à partir de la clé privée, on crée un certificat x509 auto-signé pour une durée de validité d’un an  :

openssl req -new -x509 -days 365 -key ca.key > ca.crt

Il faut saisir la passphrase… puisqu’on utilise « ca.key » que l’on a protégé. Et on donne les renseignements concernant cette fois-ci l’autorité de certification (c’est à dire nous-même).

Attention : le Common Name doit être différent de celui qui a été donné pour la clé.

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]: BRETAGNE
Locality Name (eg, city) []:SULNIAC
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Lostihuel Braz
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:myCA
Email Address []:

C’est notre certificat d’autorité de certification qui va permettre de signer les certificats créés.

La signature du certificat serveur par la CA [4]

La commande qui signe la demande de certificat est la suivante :

openssl x509 -req -in servwiki.csr -out servwiki.crt -CA ca.crt -CAkey ca.key\
-CAcreateserial -CAserial ca.srl

L’option CAcreateserial n’est nécessaire que la première fois.

Il faut saisir la passphrase…

Le certificat signé est le fichier servwiki.crt. La sortie de la commande attendue est la suivante :

Signature ok
subject=/C=FR/ST=BRETAGNE/L=Sulniac/O=Lostihuel Braz/OU=IT/CN=www.laurentmarot.fr
Getting CA Private Key
Enter pass phrase for ca.key:

Vous avez maintenant un certificat pour votre serveur se nommant servwiki.crt.

less servwiki.crt
-----BEGIN CERTIFICATE-----
MIICVDCCAb0CAQEwDQYJKoZIhvcNAQEEBQAwdDELMAkGA1UEBhMCRlIxFTATBgNV
BAgTDENvcnNlIGR1IFN1ZDEQMA4GA1UEBxMHQWphY2NpbzEMMAoGA1UEChMDTExC
MREwDwYDVQQLEwhCVFMgSU5GTzEbMBkGA1UEAxMSc2VydmV1ci5idHNpbmZvLmZy
MB4XDTA0MDIwODE2MjQyNloXDTA0MDMwOTE2MjQyNlowcTELMAkGA1UEBhMCRlIx
FTATBgNVBAgTDENvcnNlIGR1IFN1ZDEQMA4GA1UEBxMHQWphY2NpbzEMMAoGA1UE
ChMDTExCMREwDwYDVQQLEwhCVFMgSU5GTzEYMBYGA1UEAxMPcHJvZi5idHNpbmZv
LmZyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDSUagxPSv3LtgDV5sygt12
kSbN/NWP0QUiPlksOkF2NkPfwW/mf55dD1hSndlOM/5kLbSBo5ieE3TgikF0Iktj
BWm5xSqewM5QDYzXFt031DrPX63Fvo+tCKTQoVItdEuJPMahVsXnDyYHeUURRWLW
wc0BzEgFZGGw7wiMF6wt5QIDAQABMA0GCSqGSIb3DQEBBAUAA4GBALD640iwKPMf
pqdYtfvmLnA7CiEuao60i/pzVJE2LIXXXbwYjNAM+7Lov+dFT+b5FcOUGqLymSG3
kSK6OOauBHItgiGI7C87u4EJaHDvGIUxHxQQGsUM0SCIIVGK7Lwm+8e9I2X0G2GP
9t/rrbdGzXXOCl3up99naL5XAzCIp6r5
-----END CERTIFICATE-----

Il faut maintenant installer le certificat de l’autorité de certification dans chaque navigateur client. C’est ce dernier qui va valider le certificat reçu par le client lors de la requête https://www.laurentmarot.fr.

Installation du certificat d’autorité de certification

Pour installer sur votre navigateur le certificat de l’autorité de certification, fichier ca.crt :

  • Gardez le certificat disponible à partir du client (disquette, clé usb, ftp, ssh, répertoire partagé…)
  • Sous Windows, un clic droit ou double-clic sur le fichier devrait vous permettre de lancer l’assistant d’installation du certificat dans Internet Explorer. Vous devez l’installer en tant qu’autorité de certification. Vérifiez ensuite que le certificat s’y trouve bien sous le nom de myCA.
  • sur Mozilla :
    • Edition/Préférence/Confidentialité et Sécurité/Certificats
    • Bouton de commande : gestion des certificats
    • Onglet : autorité
    • Bouton de commande : importer
    • etc…

Vous pouvez alors passer à la configuration d’Apache2 pour supporter SSL.

  1. [1]fichier servwiki.key
  2. [2]Certificate Signing Request
  3. [3]mot de passe long qui peut même contenir des espaces
  4. [4]Certificate Autority

Posted in PKI, ICP, IGCCommentaires fermés sur Web sécurisé : création des certificats avec openSSL

Introduction à la notion de certificat

Les algorithmes de chiffrement asymétrique sont basés sur le partage entre les différents utilisateurs d’une clé publique. Généralement le partage de cette clé se fait au travers d’un annuaire électronique (souvent au format LDAP) ou bien d’un site web.

Toutefois, ce mode de partage a une grande lacune : rien ne garantit que la clé est bien celle de l’utilisateur a qui elle est associée. En effet, un pirate peut corrompre la clé publique présente dans l’annuaire en la remplaçant par sa clé publique. Ainsi, le pirate sera en mesure de déchiffrer tous les messages ayant été chiffrés avec la clé présente dans l’annuaire.

Ainsi, un certificat permet d’associer une clé publique à une entité (une personne, une machine, …) afin d’en assurer la validité. Le certificat est en quelque sorte la carte d’identité de la clé publique, délivré par un organisme appelé autorité de certification (souvent notée CA pour Certification Authority).

L’autorité de certification est chargée de délivrer les certificats, de leur assigner une date de validité (équivalent à la date limite de péremption des produits alimentaires), ainsi que de révoquer éventuellement des certificats avant cette date en cas de compromission de la clé (ou du propriétaire).

Structure d’un certificat ?

Les certificats sont des petits fichiers divisés en deux parties :

  • La partie contenant les informations  liées à l’entité et à la clef
  • La partie contenant la signature de l’autorité de certification

La structure des certificats est normalisée par le standard X.509 de l’UIT (plus exactement X.509v3), qui définit les informations contenues dans le certificat :

  • La version de X.509 à laquelle le certificat correspond ;
  • Le numéro de série du certificat ;
  • L’algorithme de chiffrement utilisé pour signer le certificat ;
  • Le nom (DN, pour Distinguished Name) de l’autorité de certification émettrice ;
  • La date de début de validité du certificat ;
  • La date de fin de validité du certificat ;
  • L’objet de l’utilisation de la clé publique ;
  • La clé publique du propriétaire du certificat ;
  • La signature de l’émetteur du certificat (thumbprint).

L’ensemble de ces informations (informations + clé publique du demandeur) est signé par l’autorité de certification, cela signifie qu’une fonction de hachage crée une empreinte de ces informations, puis ce condensé est chiffré à l’aide de la clé privée de l’autorité de certification; la clé publique ayant été préalablement largement diffusée afin de permettre aux utilisateurs de vérifier la signature avec la clé publique de l’autorité de certification.

Création du certificat

Lorsqu’un utilisateur désire communiquer avec une autre personne, il lui suffit de se procurer le certificat du destinataire. Ce certificat contient le nom du destinataire, ainsi que sa clé publique et est signé par l’autorité de certification. Il est donc possible de vérifier la validité du message en appliquant d’une part la fonction de hachage aux informations contenues dans le certificat, en déchiffrant d’autre part la signature de l’autorité de certification avec la clé publique de cette dernière et en comparant ces deux résultats.

Vérification de la validité du certificat

Signatures de certificats

On distingue différents types de certificats selon le niveau de signature :

  • Les certificats auto-signés sont des certificats à usage interne. Signés par un serveur local, ce type de certificat permet de garantir la confidentialité des échanges au sein d’une organisation, par exemple pour le besoin d’un intranet. Il est ainsi possible d’effectuer une authentification des utilisateurs grâce à des certificats auto-signés.
  • Les certificats signés par un organisme de certification sont nécessaires lorsqu’il s’agit d’assurer la sécurité des échanges avec des utilisateurs anonymes, par exemple dans le cas d’un site web sécurisé accessible au grand public. Le certificateur tiers permet d’assurer à l’utilisateur que le certificat appartient bien à l’organisation à laquelle il est déclaré appartenir.

Types d’usages

Les certificats servent principalement dans trois types de contextes :

  • Le certificat client, stocké sur le poste de travail de l’utilisateur ou embarqué dans un conteneur tel qu’une carte à puce, permet d’identifier un utilisateur et de lui associer des droits. Dans la plupart des scénarios il est transmis au serveur lors d’une connexion, qui affecte des droits en fonction de l’accréditation de l’utilisateur. Il s’agit d’une véritable carte d’identité numérique utilisant une paire de clés asymétriques d’une longueur de 512 à 1 024 bits.
  • Le certificat serveur installé sur un serveur web permet d’assurer le lien entre le service et le propriétaire du service. Dans le cas d’un site web, il permet de garantir que l’URL et en particulier le domaine de la page web appartiennent bien à telle ou telle entreprise. Par ailleurs, il permet de sécuriser les transactions avec les utilisateurs grâce au protocole SSL.
  • Le certificat VPN est un type de certificat installé dans les équipement réseaux, permettant de chiffrer les flux de communication de bout en bout entre deux points (par exemple deux sites d’une entreprise). Dans ce type de scénario, les utilisateurs possèdent un certificat client, les serveurs mettent en œuvre un certificat serveur et les équipements de communication utilisent un certificat particulier (généralement un certificat IPSec).

Posted in PKI, ICP, IGCCommentaires fermés sur Introduction à la notion de certificat

Le chiffrement symétrique

  1. Principes de base
    Contexte : Thierry veut envoyer à Jacques un message illisible par un tiers
    Solution : Thierry utilise une clé secrète pour chiffrer (autrement dit coder) son message
    La clé est un nombre, un mot ou une règle que seuls Thierry et Jacques connaissent et qu’ils se sont communiquée avant l’échange de leur message
    Le message codé n’est décodable qu’avec la clé secrète
  2. Règle
  3. On parle de cryptographie à clé secrète (chiffrement symétrique)
    crypt(key,crypt(key,msg))=msg

  4. Histoire
  5. Depuis la nuit des temps les hommes, et en particulier les militaires, ont pratiqué l’espionnage et le contre-espionnage. Le chiffrement des messages est donc né presque en même temps que l’écriture

     

    Faces B et A du Disque de Phaistos (Crète 1 700 av. JC )

    Faces B et A du Disque de Phaistos (Crète 1 700 av. JC )

    Le Scytale ou bâton de Plutarque (Sparte 400 av. JC)

    Le Scytale ou bâton de Plutarque(Sparte 400 av. JC)

  6. Exemples
    1. substitution de caractères (1)
    2. substitution de caractères (2)
    3. substitution de caractères (3) – Procédé de Vigenère
    4. amélioration du procédé de Vigenère
    5. chiffre à usage unique
  7. Synthèse
  8. Différents algorithmes
    1. Data Encryption Standard (DES)
    2. Triple DES
    3. Advanced Encryption Standard (AES)
    4. IDEA, RC4, Blowfish
  9. Les défauts

Il faut réussir à communiquer une clé secrète différente à chaque destinataire par un moyen sûr. Soit pour échanger:

  • entre 2 personne : 1 clé
  • entre 5 personnes: 10 clés
  • entre n personnes: n(n-1)/2 clés

Posted in PKI, ICP, IGCCommentaires fermés sur Le chiffrement symétrique