Archive | PKI, ICP, IGC

Public Key Cryptography Standards

base : https://en.wikipedia.org/wiki/PKCS / https://fr.wikipedia.org/wiki/Public_Key_Cryptographic_Standards

In cryptography, PKCS stands for « Public Key Cryptography Standards ». These are a group of public-key cryptography standards devised and published by RSA Security LLC, starting in the early 1990s. The company published the standards to promote the use of the cryptography techniques to which they had patents, such as the RSA algorithm, the Schnorr signature algorithm and several others. Though not industry standards (because the company retained control over them), some of the standards in recent years have begun to move into the « standards-track » processes of relevant standards organizations such as the IETF and the PKIX working-group.

Les PKCS (Public-Key Cryptography Standards), ou standards de cryptographie à clé publique, sont un ensemble de spécifications conçues par les laboratoires RSA en Californie. La société RSA Security est spécialisée dans les solutions de sécurité cryptographiques. Elle est également propriétaire de licences d’exploitations de plusieurs algorithmes (dont RSA avant l’expiration de son brevet le ). C’est pour ces raisons que la société a développé et promu les PKCS, permettant l’implantation des techniques de cryptographie à clé publique.

La société RSA Security n’est pas un organisme de normalisation, et pourtant, elle contrôle complètement l’élaboration et l’évolution des PKCS. L’appellation des PKCS comme standards au sens strict est donc abusive. Répondant à un réel besoin technique, les PKCS ont néanmoins été très largement adoptés par le milieu informatique. Le groupe de travail PKIX de l’IETF a depuis reformulé certains des PKCS dans des RFC, les standards Internet. L’abus de langage confondant le PKCS au lieu de la RFC correspondante est très répandu.

1- revenir sur la place de la cryprographie dans dans le cadre plus large de la cryptologie.

2- flash back sur l’histoire de l’entreprise RSA (https://fr.wikipedia.org/wiki/RSA_Security) ( y compris le leak de 2011)

3- faire une lecture croisée de ressources francophones et internationales

RSA Security

RSA Security

 

Version Nom Commentaires
PKCS#1 2.1 Standard de cryptographie RSA RFC 34471. Définit le chiffrement et la signature RSA (notamment les schémas de remplissage OAEP, PSS et PKCS1-v1.5).
PKCS#2 Obsolète Décrivait le chiffrement RSA de condensés de message, mais a été intégré dans PKCS#1.
PKCS#3 1.4 Standard d’échange de clés Diffie-Hellman
PKCS#4 Obsolète Décrivait la syntaxe de clé RSA, mais a été intégré dans PKCS#1.
PKCS#5 2.0 Standard de chiffrement par mot de passe cf. RFC 28982 (rendu obsolète par la RFC 80183) et PBKDF2.
PKCS#6 1.5 Obsolète Définissait les extensions de l’ancienne spécification de certificat X.509 v1.
PKCS#7 1.5 Standard de syntaxe de message cryptographique Cf. RFC 23154. Utilisé pour signer et/ou chiffrer des messages dans le cadre d’une infrastructure à clés publiques. Sert également à la transmission de certificats (notamment en réponse à un message PKCS#10). À l’origine de S/MIME, qui est désormais décrit sous le nom Cryptographic Message Syntax (CMS) dans la RFC 56525.
PKCS#8 1.2 Standard de syntaxe d’information de clé privée Cf. RFC 59586.
PKCS#9 2.0 Types d’attributs sélectionnés RFC 29857
PKCS#10 1.7 Standard de requête de certificat Cf. RFC 29868. Format des messages envoyés à une autorité de certification et demandant la signature d’une paire de clés.
PKCS#11 2.20 Interface de périphérique cryptographique (cryptoki) Une API définissant une interface générique pour périphérique cryptographique.
PKCS#12 1.0 Standard de syntaxe d’information personnelle Définit un format de fichier généralement utilisé pour stocker la clé privée et le certificat de clé publique correspondant en les protégeant par un mot de passe.
PKCS#13 Standard de Cryptographie sur les courbes elliptiques (En cours de développement)
PKCS#14 Générateur de nombres pseudo-aléatoires (En cours de développement)
PKCS#15 1.1 Standard de format d’information sur les périphériques cryptographiques Définit un standard permettant aux utilisateurs de périphériques cryptographiques de s’identifier auprès des applications, indépendamment de l’implantation de la cryptoki par l’application (PKCS #11) ou une autre API. La partie de cette spécification concernant les cartes IC a été intégrée dans le standard ISO/IEC 7816-15. [1] [archive]

#PKCS1 se prête très bien à l’illustration d’un des « standards »

Posted in Boulot, PKI, ICP, IGC0 commentaire

Mais pourquoi ma clé commence toujours par MIGf… ?

Read that f… RFC 1421 : Privacy Enhancement for Internet Electronic Mail

and follow those precious links :

https://lapo.it/asn1js
https://docs.microsoft.com/en-us/windows/win32/seccertenroll/about-encoded-length-and-value-bytes
http://javadoc.iaik.tugraz.at/iaik_jce/current/iaik/x509/PublicKeyInfo.html
https://medium.com/@bn121rajesh/understanding-rsa-public-key-70d900b1033c

# Generate 1024 bit Private key
$ openssl genrsa -out myprivate.pem 1024
# Separate the public part from the Private key file.
$ openssl rsa -in myprivate.pem -pubout > mypublic.pem
# Display the contents of private key
$ cat myprivate.pem

-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDRFNU++93aEvz3cV8LSUP9ib3iUxT7SufdVXcgVFK9M3BYzvro
A1uO/parFOJABTkNhTPPP/6mjrU2CPEZJ1zIkpaSNJrrhpp/rNMO9nyLYPGs9Mfd
BiWUPmHW5mY1oD0ye4my0tEsHOlgHC8AhA8OtiHr6IY0agXmH/y5YmSWbwIDAQAB
AoGAAj/IH3pUI6FqqTrF+/gYzCRsL4AXTLC8l8vwkR93GGPyRHJNjqtik8I3WrXJ
zUiBGZ0iNouIsL/+QQuNlGiw/c5i2X3nTntREDS9xs2M0x+MWD/5qI1sn0Qk0HNP
BbDczlvO8wXNFGIHiTiPVEawoeNwhMqJDyGcbsEOZp2pLokCQQDvlMBU6dOeOP9a
jnENFSlrvzNR0nugFeoGmfq6s4Czz2QtUd9baKqBfEBSdJskwFVHgxbFA1Dc7iFu
rJkoQEeFAkEA32j9ibSVryxLvWUZngKNwo2xE+wcYDAYVBMsYC3OBU3FXhVkFD06
ZVnJsY/4bd2VdQI+bI2KV99aHutMJG2WYwJABMn2ZjweTMVa5VZ/kAFiSJMT1Yjd
i7+kY+lkB6Na6T02BWnjixI2hkwThRJrn3pwufM2201Lqn7gEDRHA3T1eQJBAKZG
1RUNo6558HEo8vUIf4vCu33RaJkqkqDYmFmJHeISrQfGMfNiUrkmJ5iRR9w1ZExu
/Bj9C281XDTQ+Z3PNnMCQQCan+pvj0OZH6o0PAMJGBBwRECPpfZ6mUjwA2YD3g61
MHjtIYmKKGmn64Qs8zQ4mNEDboQqyaov3Ij/I6c0ZQlc
-----END RSA PRIVATE KEY-----

Privacy Enhanced Mail (PEM)

Privacy Enhanced Mail (PEM) is a Base64 encoded Distinguished Encoding Rules(DER)
PEM file is human readable as it uses 64 printable characters for encoding.
It is easy to share PEM file.

 

Display the contents of public key PEM file

# Display the contents of public key PEM file
$ cat mypublic.pem

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRFNU++93aEvz3cV8LSUP9ib3i
UxT7SufdVXcgVFK9M3BYzvroA1uO/parFOJABTkNhTPPP/6mjrU2CPEZJ1zIkpaS
NJrrhpp/rNMO9nyLYPGs9MfdBiWUPmHW5mY1oD0ye4my0tEsHOlgHC8AhA8OtiHr
6IY0agXmH/y5YmSWbwIDAQAB
-----END PUBLIC KEY-----

 

Distinguished Encoding Rules (DER) format of public key

DER is encoded in Type-Length-Value (TLV) format.
DER is in binary format for PEM file and follows certain structure for public key.

# Convert PEM file to DER format using openssl rsa
$ openssl rsa -pubin -inform PEM -in mypublic.pem -outform DER -out mypublic.der
# Dump the DER file in hex format.
$ xxd -g 1 -u mypublic.der | cut -c -57
00000000: 30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
00000010: 05 00 03 81 8D 00 30 81 89 02 81 81 00 D1 14 D5
00000020: 3E FB DD DA 12 FC F7 71 5F 0B 49 43 FD 89 BD E2
00000030: 53 14 FB 4A E7 DD 55 77 20 54 52 BD 33 70 58 CE
00000040: FA E8 03 5B 8E FE 96 AB 14 E2 40 05 39 0D 85 33
00000050: CF 3F FE A6 8E B5 36 08 F1 19 27 5C C8 92 96 92
00000060: 34 9A EB 86 9A 7F AC D3 0E F6 7C 8B 60 F1 AC F4
00000070: C7 DD 06 25 94 3E 61 D6 E6 66 35 A0 3D 32 7B 89
00000080: B2 D2 D1 2C 1C E9 60 1C 2F 00 84 0F 0E B6 21 EB
00000090: E8 86 34 6A 05 E6 1F FC B9 62 64 96 6F 02 03 01
000000a0: 00 01

 

Structured DER file content

1:30 81 9F // Type: 30 (SEQUENCE) Length: 0x9F
2:| 30 0D // Type: 30 (SEQUENCE) Length: 0x0D
3:| | 06 09 // Type: 06 (OBJECT_IDENTIFIER) Length: 0x09
4:| | - 2A 86 48 // 9 bytes OID value. HEX encoding of
5:| | - 86 F7 0D // 1.2.840.113549.1.1.1
6:| | - 01 01 01
7:| | 05 00 // Type: 05 (NULL) Length: 0x00
8:| 03 81 8D // Type: 03 (BIT STRING) Length: 0x8D
9:| | - 00 // Number of unused bits in last content byte
10:| | 30 81 89 // Type: 30 (SEQUENCE) Length: 0x89
11:| | | 02 81 81 // Type: 02 (INTEGER) Length: 0x81
12:| | | - 00 // Leading ZERO of integer
13:| | | - D1 14 D5 3E FB DD DA 12 FC F7 71 5F 0B 49 43 FD
14:| | | - 89 BD E2 53 14 FB 4A E7 DD 55 77 20 54 52 BD 33
15:| | | - 70 58 CE FA E8 03 5B 8E FE 96 AB 14 E2 40 05 39
16:| | | - 0D 85 33 CF 3F FE A6 8E B5 36 08 F1 19 27 5C C8
17:| | | - 92 96 92 34 9A EB 86 9A 7F AC D3 0E F6 7C 8B 60
18:| | | - F1 AC F4 C7 DD 06 25 94 3E 61 D6 E6 66 35 A0 3D
19:| | | - 32 7B 89 B2 D2 D1 2C 1C E9 60 1C 2F 00 84 0F 0E
20:| | | - B6 21 EB E8 86 34 6A 05 E6 1F FC B9 62 64 96 6F
21:| | | 02 03 // Type: 02 (INTEGER) Length: 0x3
22:| | | - 01 00 01 // Public Exponent. Hex for 65537

 

DER file contains Object Identifier, Modulus and Public exponent in HEX format.

Lines 4, 5, 6 is the HEX encoding of OID.
Lines 13 to 20 is the modulus (n).
Line 22 is the public exponent.

You can also have a look at Lapo ASN.1 javascript decoder :

Javascript ASN.1 decoder

Javascript ASN.1 decoder

Modulus and Public exponent from public key using openssl

# Get Modulus and Public exponent from public PEM file
$ openssl rsa -pubin -inform PEM -text -noout < mypublic.pem

Public-Key: (1024 bit)
Modulus:
00:d1:14:d5:3e:fb:dd:da:12:fc:f7:71:5f:0b:49:
43:fd:89:bd:e2:53:14:fb:4a:e7:dd:55:77:20:54:
52:bd:33:70:58:ce:fa:e8:03:5b:8e:fe:96:ab:14:
e2:40:05:39:0d:85:33:cf:3f:fe:a6:8e:b5:36:08:
f1:19:27:5c:c8:92:96:92:34:9a:eb:86:9a:7f:ac:
d3:0e:f6:7c:8b:60:f1:ac:f4:c7:dd:06:25:94:3e:
61:d6:e6:66:35:a0:3d:32:7b:89:b2:d2:d1:2c:1c:
e9:60:1c:2f:00:84:0f:0e:b6:21:eb:e8:86:34:6a:
05:e6:1f:fc:b9:62:64:96:6f
Exponent: 65537 (0x10001)

Exponent and modulus printed by openssl rsa matches with the Public exponent and modulus from DER file content.

More information on recommended syntax for interchanging RSA public keys between implementations is given in Appendix A.1.1 of rfc3447 ( PKCS#1);

RSA key representation

RSA key representation

 

Object Identifier

OID describes the object. It is a series of nodes separated by period.

OID Value: 1.2.840.113549.1.1.1

OID description: Identifier for RSA encryption for use with Public Key Cryptosystem One defined by RSA Inc.

OID Encoding rules:

1 – The first two nodes of the OID are encoded onto a single byte. The first node is multiplied by the decimal 40 and the result is added to the value of the second node.
2 – Node values less than or equal to 127 are encoded on one byte.
3 – Node values greater than or equal to 128 are encoded on multiple bytes. Bit 7 of all bytes except the rightmost byte is set to one. Bits 0 through 6 of each byte contains the encoded value.

OID Encoding Example © Rajesh Bondugula

OID Encoding Example © Rajesh Bondugula

 

Representing length in ASN.1 encoding

If number of value bytes is < 128 (0x80) then length is represented in 1 byte. In this case most significant bit is 0. (Ex: Line 2: 0x81=10000001 => 1 octet, Line 3 in structured DER content above)

If number of value bytes is >= 128 (0x80) then length is represented in multiple bytes. Most significant bit (bit 7) of first byte is 1 indicating multiple byte length. Bits 0–6 represent number of subsequent bytes for length. (Ex:  Line 1: 0x82=10000010 => 2 octets, Line 4 in structured DER content above)

 

References

DER encoding of ASN.1 types (MSDN)
Public Key Info structure (Java doc)

 

[ajout de août 2021 suite plaintes]

– Mais du coup … tu n’as pas répondu  la question ?
[lm] C’est pas faux, mais si tu révises le fonctionnement de l’encodage base 64, à partir d’un contenu DER qui commence toujours par la même syntaxe:

xxd -r -p <<<30819F | base64
MIGf

 

Posted in Crypto, PKI, ICP, IGC1 Commentaire

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, IGC0 commentaire

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, IGC0 commentaire

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, IGC0 commentaire

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, IGC0 commentaire

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, IGC0 commentaire

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, IGC0 commentaire

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, IGC0 commentaire