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.

openssl genrsa 1024 > servwiki.key

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

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-----

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

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 []:

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-----

openssl genrsa -des3 1024 > ca.key

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

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 []:

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

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:

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-----

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↩

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.

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.

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).

Dassault Aviation ne s’opposerait pas à ce que Thales, dont il est l’actionnaire industriel de référence, prenne plus de 50 % du leader européen du naval militaire.

Thales pourrait prendre le contrôle de DCNS, le constructeur français de porte-avions, sous-marins et autres frégates. Le groupe de défense et de sécurité, détient déjà 25 % du capital de DCNS. Au terme d’un pacte signé entre l’État et Dassault Aviation lorsqu’il est devenu l’actionnaire industriel de référence de Thales, ce dernier détient une option d’achat sur 10 % supplémentaire du capital de DCNS. Dassault Aviation ne s’opposerait pas à ce que Thales puisse monter plus haut encore jusqu’à en prendre plus de 50 % donc le contrôle.

Mais Charles Edelstenne, PDG de Dassault Aviation, pose un préalable: « traiter le problème des ouvriers d’état » surtout si «on veut entrer en compétition à l’internationale». Mis à disposition de DCNS, les quelque 6 000 ouvriers d’état relèvent de l’État par exemple en matière de d’augmentation de salaires. Pour 2011, le décret pris a gelé les augmentations de salaire en 2011, « hormis celles liées à l’avancement des personnels concernés », précise DCNS dans lequel se côtoient plusieurs statuts: fonctionnaire, salariés de droit privé et ouvriers d’état dont le statut est un héritage de l’époque où le constructeur était un arsenal.

Afin de laisser à l’État le temps pour mener la réflexion sur ce sujet, Luc Vigneron, PDG de Thales, a proposé de décaler d’un an la levée de l’option qui amène Thales à détenir 35 % du leader européen du naval militaire.

17/03/2011 – Véronique Guillermard – Le Figaro

Trop bon, je ne résiste pas à reproduire cet édito de Jean-Jacques Salomon

Le PISA (Programme international pour le suivi des acquis des étudiants) est un dispositif d’évaluation des systèmes scolaires dans les pays de l’OCDE. Il s’appuie sur des tests de deux heures proposés, dans chaque pays, à des échantillons représentatifs d’élèves de 15 ans, en lecture, mathématiques et sciences. Pour 2010, la Finlande arrive première en sciences, et deuxième en mathématiques et en lecture, chaque fois derrière la Corée du sud. Les Etats-Unis occupent la 17ème place en sciences, la  27ème en mathématiques, et la 12ème en lecture. Ils figuraient en tête du palmarès il n’y a pas si longtemps. La France est en position intermédiaire.

Une enquête révèle que les enseignants américains du secondaire sont issus des 30% d’étudiants les moins bien notés à l’université. En Finlande, ils sont recrutés parmi les 10% les plus performants. L’idée fait son chemin, outre-Atlantique, qu’il pourrait y avoir une relation de cause à effet entre la qualité des professeurs et les résultats des élèves. Beaucoup, semble-t-il, en doutaient !

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

On parle de cryptographie à clé secrète (chiffrement symétrique)
crypt(key,crypt(key,msg))=msg

3. Histoire

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 )



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

4. 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
5. Synthèse
6. Différents algorithmes
   1. Data Encryption Standard (DES)
   2. Triple DES
   3. Advanced Encryption Standard (AES)
   4. IDEA, RC4, Blowfish
7. 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

Familles

Usuellement, on distingue deux familles de certificats numériques :

• les certificats de signature, utilisés pour signer des documents ou s’authentifier sur un site web, et
• les certificats de chiffrement (les gens qui vous envoient des courriels utilisent la clef publique de votre certificat pour chiffrer le contenu que vous serez seul à pouvoir déchiffrer avec votre clef privéé)

Mais cette typologie n’est pas exhaustive ; un découpage plus orienté applicatif pourrait être envisagé. L’intérêt de la séparation des usages découle notamment des problématiques de séquestre de clés et de recouvrement. En effet, lorsqu’il y a chiffrement, il peut y avoir nécessité de recouvrer les informations chiffrées. Alors que lorsqu’il y a signature, il est indispensable de s’assurer que la clé privée n’est possédée que par une seule partie.

Nature et composition

Un certificat électronique est une donnée publique. Suivant la technique des clés asymétriques, à chaque certificat électronique correspond une clé privée, qui doit être soigneusement protégée.

Un certificat numérique porte les caractéristiques de son titulaire : si le porteur est un être humain, cela peut être son nom et son prénom, le nom de sa structure (par exemple, son entreprise ou son… État !) et de son entité d’appartenance. Si c’est un équipement informatique (comme une passerelle d’accès ou un serveur d’applications sécurisé), le nom est remplacé par l’URI du service. À ces informations d’identification s’ajoute la clef publique du biclé.

L’ensemble de ces informations (comprenant la clé publique) est signé par l’Autorité de Certification de l’organisation émettrice. Cette Autorité a la charge de :

• s’assurer que les informations portées par le certificat numérique sont correctes ;
• s’assurer qu’il n’existe, pour une personne et pour une même fonction, qu’un et un seul certificat valide à un moment donné.

Le certificat numérique est donc, à l’échelle d’une organisation, un outil pour témoigner, de façon électroniquement sûre, d’une identité.

L’usage conjoint des clés cryptographiques publique (contenue dans le certificat) et privée (protégée par l’utilisateur, par exemple au sein d’une carte à puce), permet de disposer de fonctions de sécurité importante.

Gestion

Un certificat numérique naît après qu’une demande de certificat a abouti.

Une demande de certificat est un fichier numérique (appelé soit par son format, PKCS#10, soit par son équivalent fonctionnel, CSR pour Certificate Signing Request) qui est soumis à une autorité d’enregistrement par un utilisateur final ou par un administrateur pour le compte d’un utilisateur final.

Cette demande de certificat est examinée par un Opérateur d’Autorité d’Enregistrement. Cette position est une responsabilité clé : c’est lui qui doit juger de la légitimité de la demande de l’utilisateur et accorder, ou non, la confiance de l’organisation. Pour se forger une opinion, l’Opérateur doit suivre une série de procédures, plus ou moins complètes, consignées dans deux documents de référence qui vont de pair avec la création d’une IGC qui sont la Politique de Certification (PC) et la Déclaration des Pratiques de Certification (DPC). Ces documents peuvent exiger, en fonction des enjeux de la certification, des vérifications plus ou moins poussées : rencontre en face-à-face, validation hiérarchique, etc. L’objectif de l’Opérateur d’AE est d’assurer que les informations fournies par l’utilisateur sont exactes et que ce dernier est bien autorisé à solliciter la création d’un certificat.

Une fois son opinion formée, l’Opérateur de l’AE valide la demande ou la rejette. S’il la valide, la demande de certificat est alors adressée à l’Autorité de Certification (AC). L’AC vérifie que la demande a bien été validée par un Opérateur d’AE digne de confiance et, si c’est le cas, signe la CSR. Une fois signée, une CSR devient… un certificat. Le process de signature est exactement le même qu’une signature électonique de document (hash puis chiffrement par la clef privée de l’AC).

Le certificat, qui ne contient aucune information confidentielle, peut par exemple être publié dans un annuaire d’entreprise : c’est la tâche du Module de Publication, souvent proche de l’AC.

Modes de création

Il existe deux façons distinctes de créer des certificats électroniques : le mode centralisé et le mode décentralisé.

• le mode décentralisé est le mode le plus courant : il consiste à faire créer, par l’utilisateur (ou, plus exactement par son logiciel ou sa carte à puce) le biclé cryptographique et de joindre la partie publique de la clef dans la CSR. L’infrastructure n’a donc jamais connaissance de la clé privée de l’utilisateur, qui reste confinée sur son poste de travail ou dans sa carte à puce.

• le mode centralisé consiste en la création du biclé par l’AC : au début du cycle de la demande, la CSR ne contient pas la clé publique, c’est l’AC qui la produit. Elle peut ainsi avoir de bonnes garanties sur la qualité de la clé (aléa) et peut… en détenir une copie protégée. En revanche, il faut transmettre à l’utilisateur certes son certificat (qui ne contient que des données publiques) mais aussi sa clé privée ! L’ensemble de ces deux données est un fichier créé sous le format PKCS#12. Son acheminement vers l’utilisateur doit être entrepris avec beaucoup de précaution et de sécurité, car toute personne mettant la main sur un fichier PKCS#12 peut détenir la clé de l’utilisateur.

Le mode décentralisé est préconisé pour les certificats d’authentification (pour des questions de coût, parce qu’il est plus simple de refaire un certificat en décentralisé qu’à recouvrer une clé) et de signature (parce que les conditions d’exercice d’une signature juridiquement valide prévoit que le signataire doit être le seul possesseur de la clé : en mode décentralisé, l’IGC n’a jamais accès à la clé privée).

Le mode centralisé est préconisé pour les certificats de chiffrement, car, lorsqu’un utilisateur a perdu sa clé (par exemple, sa carte est perdue ou dysfonctionne), un opérateur peut, au terme d’une procédure de recouvrement, récupérer la clé de chiffrement et la lui remettre. Chose qui est impossible à faire avec des clés qui n’ont pas été séquestrées.

Scénario de fin de vie

Il existe deux scénarios possibles de fin de vie d’un certificat numérique :

• le certificat numérique expire (chaque certificat numérique contient une date de « naissance » et une date de « péremption »).
• le certificat est révoqué, pour quelque raison que ce soit (perte de la clé privée associée, etc.) et dans ce cas, l’identifiant du certificat numérique est ajouté à une liste de certificats révoqués (CRL pour Certificate Revocation List) pour informer les applications qu’elles ne doivent plus faire confiance à ce certificat. Il est aussi possible que les applications s’informent en quasi temps réel de l’état du certificat avec le protocole OCSP.

1- plusieurs appellations pour un même outil :

• Infrastructure à Clés Publiques (ICP)
• Infrastructure de Gestion de Clés (IGC)
• Public Key Infrastructure (PKI)

2- définition : une ICP est un ensemble

• de composants physiques: des ordinateurs, des équipements cryptographiques logiciels ou matériel type HSM ou encore des cartes à puces
• de procédures humaines (vérifications, validation)
• de logiciels (systèmes et applications) en vue de gérer le cycle de vie des certificats numériques aussi appelés certificats électroniques.

3- remarque : la notion de PKI est souvent  galvaudée et  présentée sous une forme complexe accessibles à seuls quelques gourous de la technologie: Le traditionnel écran de fumée derrière lequel certains informaticiens pas si  experts que ça aiment à se protéger. Attention, on oublie souvent l’aspect « procédures humaines » sans quoi la PKI se limite souvent à une brique technique nébuleuse permettant une génération ponctuelle de certificats auto-signés.

Une infrastructure à clés publiques délivre les services suivant pour le compte de ses utilisateurs:

• enregistrement des utilisateurs (ou équipement informatique) ;
• génération de certificats ;
• renouvellement de certificats ;
• révocation de certificats ;
• publication de certificats ;
• publication des listes de révocation (comprenant la liste des certificats révoqués) ;
• identification et authentification des utilisateurs et équipements (administrateurs ou utilisateurs qui accèdent à l’IGC) ;
• archivage, séquestre et recouvrement des certificats (option).

Rôle d’une infrastructure de gestion des clés

Une IGC délivre des certificats numériques. Ces certificats permettent d’effectuer des opérations cryptographiques, comme le chiffrement et la signature numérique qui offrent les garanties suivantes lors des transactions électroniques :

• confidentialité : seul le destinataire (ou le possesseur) légitime d’un bloc de données ou d’un message pourra en avoir une vision intelligible ;
• authentification : lors de l’envoi d’un bloc de données ou d’un message ou lors de la connexion à un système, on connaît sûrement l’identité de l’émetteur ou l’identité de l’utilisateur qui s’est connecté ;
• intégrité : on a la garantie qu’un bloc de données ou un message expédié n’a pas été altéré, accidentellement ou intentionnellement ;
• non-répudiation : l’auteur d’un bloc de données ou d’un message ne peut pas renier son œuvre.

Les IGC permettent l’obtention de ces garanties par l’application de processus de vérification d’identité rigoureux et par la mise en œuvre de solutions cryptographiques fiables (éventuellement évaluées), conditions indispensables à la production et à la gestion des certificats électroniques.

Composants de l’infrastructure de gestion des clés

Les IGC (comme définies par l’IETF) se scindent en 4 entités distinctes :

• L’autorité de certification (AC ou Certificate Authoirity: CA) qui a pour mission de signer les demandes de certificat (CSR : Certificate Signing Request) et de signer les listes de révocation ( Certificate Revocation List: CRL). Cette autorité est la plus critique.
• L’autorité d’enregistrement (AE ou Registering Authority: RA) qui a pour mission de générer les certificats, et d’effectuer les vérifications d’usage sur l’identité de l’utilisateur final (les certificats numériques sont nominatifs et uniques pour l’ensemble de l’IGC).
• L’autorité de dépôt (Repository) qui a pour mission de stocker les certificats numériques ainsi que les listes de révocation (CRL).
• L’entité finale (End Entity: EE). L’utilisateur ou le système qui est le sujet d’un certificat (En général, le terme « entité d’extrémité »  est préféré au terme « sujet » afin d’éviter la confusion avec le champ Subject).

En complément, on pourra ajouter l’autorité de séquestre, qui n’est pas définie spécifiquement par l’IETF :

• L’autorité de séquestre (Key Escrow), a un rôle particulier, en effet lorsqu’on génère des certificats de chiffrement, on a l’obligation légale [en France] de fournir aux autorités un moyen de déchiffrer les données chiffrées pour un utilisateur de l’IGC. C’est là qu’intervient le séquestre, cette entité a pour mission de stocker de façon sécurisée les clés de chiffrement qui ont été générées par l’IGC, pour pouvoir les restaurer le cas échéant.

Précautions pour le déploiement

Certains experts pensent aujourd’hui que, dans un monde ouvert, il faut prendre certaines précautions avant de déployer une PKI, faute de quoi il y a des risques de pillage. Avant d’aborder les questions techniques, il faut par exemple se demander quels sont les utilisateurs, et si le cadre juridique est prêt.

Lorsque l’entreprise échange beaucoup de données avec des partenaires en extranet, comme c’est le cas des entreprises étendues ou des pôles de compétitivité, la question de la sécurisation de l’interopérabilité se pose.

Dans ces grandes communautés, l’information d’autorité doit être gérée dans des registres de métadonnées publics. Le certificat électronique peut alors être associé, dans le registre, à l’identifiant, afin de circonscrire le patrimoine informationnel partagé par la communauté de pratique.

Voir par exemple : Dictionnaire de métadonnées pour le référentiel des publications CNRS

Par ailleurs, Il est conseillé de déployer les certificats sur support matériel (carte à puce) car le vol de certificat logiciel fait désormais partie des possibilités des malwares.

Preuves:

Le rapport annuel des Sages de la rue Cambon enfonce Chorus, le nouveau PGI (progiciel de gestion intégré) de l’Etat. Tour d’horizon des principales critiques de la Cour et des réponses apportées par le ministère du Budget.

Voir l’article de Vincent Berdot dans 01net le 18/02/11 à 13h07

La Cour des comptes tacle Chorus

Continue Reading

C’est clair ça sonne mieux en anglais: Access Control and Certification: Critical Steps on the Road to Compliance.

Adapté de « Worldwide Identity and Access Management 2010–2014 Forecast: A First Look in 2010 » by Sally Hudson, IDC #222455
Sponsorisé par Courion Corp.

logo Courion

Introduction:

Le revenu mondial du marché de la gestion d’identité et des accès était de 3,4 milliard de dollars en 2009 et il est prédit qu’ils atteignent 5 milliard de dollars en 2014. Cette augmentation est essentiellement portée par le besoin mondial et généralisé à tous les secteurs d’atteindre les exigences de conformité règlementaire.

Dans les faits, le domaine de la conformité règlementaire représenterait 85 % du marché en 2009 et cette tendance devrait se poursuivre pour les années à venir.

C’est même mon site de l’année 🙂 On narrive finalement à faire des choses sympas avec Joomla et Community Builder

http://www.reserve.marine.defense.gouv.fr/