Archives de catégorie : Chiffrement, clés & stockage

Chiffrement ubiquitaire

Qu’est-ce que c’est encore que cette bestiole ? On n’arrête pas les nouveautés, qu’on souhaite pour le meilleur mais qui aboutissent en sécurité souvent sur le pire, comme SGX. Sans compter les nouveautés qui n’inventent rien, à part l’inculture de leurs promoteurs qui ne savent pas que la solution en question a déjà été inventée. Regardons donc.

Continuer la lecture →

Chiffrement cloud

Calcul multipartite sécurisé

Le calcul multipartite sécurisé est un problème où chacune des parties veut effectuer une opération commune sur des données qui doivent rester privées (aucun des participants ne connaît les données de l’autres) et exactes (non compromises). Il faut aussi qu’un tiers extérieur (attaquant) ne puisse pas accéder lui non plus aux données privées, ni les falsifier.

Participons

Une des applications pratiques est celle du classement de fortunes de millionnaires, sans rendre publics les montants de ces fortunes. Pour deux millionnaires cela revient à savoir lequel est le plus riche sans connaître la fortune de l’autre. La réduction à deux participants n’est pas anodine car elle permet, dans certaines méthodes, une généralisation à plusieurs participants.

Un cas d’usage similaire est celui d’enchères anonymes, ou du comptage des voix dans une élection : il faut savoir qui a gagné sans connaître le vote de chacun (note : ceci est réalisable dans le cas du vote papier, et beaucoup plus difficile dans un vote électronique).

Mathématiquement, cela peut aussi être la création d’un entier aléatoire N que deux parties ne peuvent reconstituer que conjointement. Si N = pq avec p et q étant des facteurs de N, alors aucune des deux parties ne connaît (p,q). Les deux parties peuvent ainsi effectuer des calculs sur des fonctions polynomiales sans révéler les valeurs utilisées en entrée, qui restent donc secrètes, ce qui a des applications en cryptographie.

Les Yao Garbled Circuits sont une solution possible permettant le calcul multipartite sécurisé.

Garbled circuits, secure multi-party computation

Références externes

Autres informations

Google Releases Encrypted Multi-Party Computation Tool(June 19, 2019)
Google has rolled out its open-source Private Join and Compute (PJC) secure multi-party computation tool. PJC can be used in studies that require data sets containing sensitive information from two separate parties. PJC will allow two sets of data to be used in computations without exposing the data each set contains. The data are encrypted during the computation; all parties can see the result. 
Read more in:
– security.googleblog.com: Helping organizations do more without collecting more data
– www.wired.com: Google Turns to Retro Cryptography to Keep Data Sets Private
– www.theregister.co.uk: Google takes the PIS out of advertising: New algo securely analyzes shared encrypted data sets without leaking contents
– www.zdnet.com: Google open sources Private Join and Compute, a tool for sharing confidential data sets

GnuPG

GnuPG est un système de chiffrement (ou cryptosystème) indépendant des grands acteurs de la sécurité et de la surveillance (lesquels se confondent parfois). Il se base sur l’utilisation de clés de chiffrement asymétriques, ce qui permet de les échanger plus facilement.

Principes

A quoi ça sert un crypto-machin ?

Ça sert à masquer vos très chères données à nos très chers GAFA et autres acteurs du web et de l’internet. Accessoirement, Mme Michu ne pourra pas non plus lire ce que vous échangez avec vos correspondants.

En gros, vous créez une paire de clés de chiffrement qui vous seront associée à vous personnellement. Un des clés sera publique, l’autre sera privée ; elles vous permettront de chiffrer vos données ou vos mails. La clé publique pourra et devra être diffusée partout, et la clé privée devra rester secrète et donc, au contraire, être la plus cachée possible. Le gros inconvénient est que lorsqu’on perd sa clé privée, et bien c’est foutu, ça marche plus ! Il n’y a plus qu’à en recréer une, et diffuser la nouvelle clé auprès de vos correspondants, car il n’existe aucun moyen de la récupérer.

Comment ça s’installe ?

Sur les systèmes Linux, les outils nécessaires sont généralement installés par défaut. Après, le plus important est de stocker la clé privée en lieu sûr. La première opération à réaliser est la génération d’une paire de clés avec la commande --gen-key :

gpg --gen-key

On aura besoin durant cette procédure de disposer d’une quantité d’aléa (ou entropie) suffisante. Afin de voir l’entropie disponible sur un système Linux, on peut utiliser la commande suivante1 :

watch cat /proc/sys/kernel/random/entropy_avail

S’il vous en manque, il peut être judicieux d’utiliser le package rng-tools (sur Ubuntu).

apt-get install -y rng-tools

Pour générer un peu d’entropie supplémentaire, on peut utiliser la commande suivante :

/usr/sbin/rngd -r /dev/urandom

La seconde mesure consiste à générer un certificat de révocation pour toute une nouvelle paire de clés. La raison de procéder ainsi est qu’il vous faut disposer de la clé privée pour générer son certificat de révocation. Générer le certificat de révocation le plus tôt possible vous met à l’abri de l’oubli de votre clef. Vous devrez bien sûr conserver ce certificat à l’abri. En outre, il doit rester facile et rapide de révoquer une clé, en cas de compromission.

Comment ça marche pour chiffrer/déchiffrer ?

Pour chiffrer :

gpg -e destinataire [message]

Pour déchiffrer :

gpg [-d] [message]

Et pour signer ?

Pour signer et chiffrer un message, la syntaxe complète est :

gpg [-u expéditeur] [-r destinataire] [--armor] --sign --encrypt [message]

On peut faire un chouïa plus simple, pour signer un message avec l’identité par défaut de votre trousseau de clé :

gpg --sign|--clearsign|--detach-sign [message]

L’option --sign vous construit un fichier .gpg illisible, --clearsign produit un fichier au format texte avec le contenu en clair suivi de la signature, et enfin --detach-sign ne fournit que la signature dans un fichier .sig. Ajoutez l’option --armor pour avoir un fichier signature en clair, suffixé par .asc. Si vous prenez l’option --clearsign, cela vous construira un fichier de type :

root@rasp-janiko:/jean/test# cat essai.txt.asc 
-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 
Ceci est un test. 
-----BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.4.12 (GNU/Linux) 
iQEcBAEBAgAGBQJV+WSgAAoJEN+s4kEe3i4xT6AH/RlkQZyQQ5XkdGmIQGgk8H6h 
C8zK7/RO1XzzP4xyqA59yHfgPgwGJ9PASaaUlOHgLcIbbiTRTrow8ZIPNhBdF4fC 
gEvZfu9p27X6SXXRa/94Lt1uIHDVFhtzWf9YNoytToxRSIf/CvPpTXcHPbnYP7YD 
Gwdz+Qxz8u2vhKJKLk4uXHgJb97IvsgoSfpb7e7TMMqCRIKV2S6T1LyouW+Tyy1Y 
ZerF5rGIWle2rYVQoM5ujuM77q/XaxAZyGQ7fp5rndBSVMBWptK5W9k8Ji4vhCqa 
FqhVdzTvq+DwmsjigCUtLk9uxSdqBhNQ+xb3sSRlyXG1PmnQtigXlUnUs/wBVds= 
=t6tc 
-----END PGP SIGNATURE-----

Pour vérifier la signature, il suffit de taper :

gpg --verify [message]

Si tout va bien, vous aurez :

root@rasp-janiko:/jean/test# gpg --verify essai.txt.asc 
gpg: Signature faite le mer. 16 sept. 2015 14:46:24 CEST avec la clef RSA d'identifiant 1EDE2E31 
gpg: Bonne signature de « Jean GEBAROWSKI (statodynamicien) <jean@geba.fr> » </jean@geba.fr>

Et si la signature est mauvaise ou que le fichier est modifié :

root@rasp-janiko:/jean/test# gpg --verify essai.txt.asc 
gpg: Signature faite le mer. 16 sept. 2015 14:46:24 CEST avec la clef RSA d'identifiant 1EDE2E31 
gpg: MAUVAISE signature de « Jean GEBAROWSKI (statodynamicien) <jean@geba.fr> » </jean@geba.fr>

Ce qu’il faut vérifier

Comme toujours, ça ne sert à rien d’utiliser des moyens sûrs si on ne vérifie pas leur validité. Quand on reçoit une alerte sur un certificat, il ne faut pas cliquer sur OK sans réfléchir. Pour les clés PGP, on a vu des tentatives d’usurpation reposant sur l’identifiant court (ou short id), qui peut parfois être dupliqué ! Donc en utilisant et/ou important des clés, il ne faut pas de limiter à cet identifiant mais aussi vérifier l’adresse mail23…

Où vérifier ?

Le réseau SKS Keyserver (Synchronizing Key Server) a été historiquement le principal système de distribution des clés publiques. Le réseau SKS est en déclin (relatif) car il est vulnérable à des attaques comme l’empoisonnement de clés (« key poisoning »). On a, par exemple :

Sinon vous pouvez vous tourner vers :

  • keys.openpgp.org qui s’est modernisé, et qui est intégré par défaut dans plusieurs outils GPG.

Pour importer une clé : 

gpg --keyserver hkps://keys.openpgp.org --recv-keys

Outils et sites utiles

Site officiel

Failles

Une faille a été découverte en mai 20184 dans de nombreux outils de messagerie ou dans leurs plugins mettant en oeuvre PGP et S/MIME. Il s’agirait plus d’une mauvaise implémentation de ces protocoles dans les clients de messagerie que d’autre chose, mais le résultat est le même : il y a danger, même sil l’exploitation n’est pas triviale5.

Le seul conseil pour l’instant est de désactiver le déchiffrement automatique des messages dans les clients de messagerie concernés (tels que Outlook, Thunderbird, Apple Mail, etc.) en supprimant les clés qui y sont stockés, et de désactiver l’affichage HTML. Le déchiffrement ne doit être effectué que dans une application tierce, jusqu’à production du correctif.

Une autre faille a été mise au jour en juin 20186 permettant d’usurper n’importe quelle signature, ce qui est gênant. La version 2.2.8 de GnuPG corrige le tir de cette anomalie qui existait depuis très longtemps, apparemment !

TrueCrypt

Que penser de TrueCrypt ? C’est l’un des plus étonnants mystères de ces dernières années dans le petit monde de l’informatique.

TrueCrypt est un utilitaire permettant de chiffrer ses documents, voire des volumes entiers sur vos disques plus ou moins durs. Très utilisé, et même recommandé par des personnes de confiance, l’utilitaire a disparu du jour au lendemain (littéralement), sans donner d’explication convaincante1. D’autant plus étonnant que des initiatives avaient abouti à la réalisation d’un audit du code (qui est à peu près en open source), sans que l’on trouve en première approche de grosse faille ou de faiblesse particulière, à peine un mois plus tôt. Par ailleurs, en 2013, l’ANSSI avait fait réaliser une certification de premier niveau (CSPN), c’est-à-dire que fonctionnellement il répond bien à la cible de sécurité choisie.

Attention : Une vulnérabilité critique a été découverte après son abandon, et ne sera donc pas corrigée. Il est conseillé de se tourner vers VeraCrypt, un fork sérieux du projet, qui lui a pu corriger les problèmes relevés, afin de chiffrer correctement vos données.

Continuer la lecture →

Clé SSH

Une clé SSH est en réalité une bi-clé (un couple clé publique et clé privée) permettant de renforcer la sécurité d’une connexion utilisant le protocole SSH (à condition bien sûr de respecter quelques règles de base).

L’idée de base est qu’on chiffre la connexion à l’aide de la bi-clé, la clé publique étant sur la machine cible, la clé privée étant chez l’utilisateur (ou la machine source éventuellement).

Principe

L’idée de ce type d’authentification est de ne pas faire circuler de secret directement pour l’établissement de la connexion (tel que le couple utilisateur/mot de passe). Ainsi, le mot de passe ne peut pas être intercepté lors de la communication !

Nous utiliserons donc une bi-clé. Pour se connecter sur un serveur (machine 2) avec une identité donnée, il faut (il suffit) d’associer la clé publique à l’identité voulue sur le serveur, et de prouver qu’on est en possession de la clé privée correspondante.

Pour établir la connexion, les deux machines qui parlent ensemble (la machine 1 de l’utilisateur, et la machine 2 où l’on souhaite se connecter de façon sécurisée) vont s’envoyer des messages chiffrés grâce à cette bi-clé. Toute la subtilité revient dans le mécanisme d’échange sécurisé entre les deux machines,

Pour envoyer des éléments chiffrés lors de l’échange, l’utilisateur sur la machine 1 doit donc utiliser sa clé privée, qu’il vaut mieux bien sûr protéger par une passphrase (il faut qu’elle soit protégée en accès afin que tout le monde ne puisse pas lire cette clé). La capacité que l’on a d’utiliser cette clé privée permet donc de prouver qu’on est bien l’utilisateur correspondant à la clé publique, ce qui assure l’accès à la machine 2, avec l’identité à laquelle on a associée la clé publique.

En pratique

Création de la bi-clé

La première étape est de construire la bi-clé, et différents outils le permettent.

ssh-keygen

Tout en ligne de commande. Il y a tout de même une astuce si vous souhaitez ensuite vous connecter à partir de PuTTY sous Windows (cf ci-dessous).

PuTTYgen

Très pratique sous Windows.

Installation de la clé publique

La clé publique doit être positionnée dans un fichier spécial, spécifique à l’identité demandée sur le serveur cible. Si vous souhaitez utiliser le mode de connexion par clé SSH pour l’utilisateur root, il faudra donc installer la clé publique dans le répertoire utilisateur de root (qui est en général /root). Si vous souhaitez utiliser une clé pour un utilisateur user, il faudra installer la clé publique dans le répertoire de l’utilisateur user (qui est en général de la forme /home/user).

Une fois dans le répertoire de l’utilisateur voulu sur la machine cible, il faut aller dans le répertoire .ssh puis modifier le fichier authorized_key (il peut y avoir des variantes, selon les configurations).

machine2$ vi /home/user/.ssh/authorized_key

Ce fichier contient les clés publiques autorisées pour cet utilisateur, au format ssh-rsa (ou ssh-dsa). Par exemple :

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAjMMXnPG6n5j39K924xSAdsxQ6KD0QS55sdw+
s/AB+EkfNJ4l5rWAesm1KhyjsTTb399lOAhDr26qmHt4Zt8yXZzfuwWA+MQI6QL0
PwR2gL6B9F7ogJtqqTmPiXTXu8fTLvzFYW+1VejHfSNBEBuE0Td5R4LjEXcmxorf
vrODeIzQaz5wk2anXaCjRVBiiPi69l4n8YCHyqVPcuiHBxRxAfQMjLpo2RYL6ofb
ZzaxHnQfvfs0h+YntFXDTVL3sMuU8zhyGrGdfI9MpYymDb8Y3hd/4MAUhUrgtg57
88Pbp/xfX79b+qB4QRjnvNLTLi4biPKqU1pbYlvkuhx/aO36qQ==

Installation et utilisation de la clé privée

Connexion sous Linux

La connexion se fait en ajoutant quelques paramètres à la commande ssh.

Connexion sous Windows

PuTTy fait sous Windows un petit caprice au sens où il va demander un format particulier pour la clé privée.

Sources

Voir également

Clé de chiffrement

Une clé de chiffrement est le code secret permettant de chiffrer ou déchiffrer un message codé. Il existe des clés symétriques et asymétriques, qui ont chacune leurs propriétés et leur utilité.

Clé symétrique

Une clé est dite symétrique quand la même clé permet de chiffrer et de déchiffrer un message. On parle aussi d’algorithme symétrique pour un algorithme utilisant des clés symétriques.

Un des principaux inconvénients est la difficulté de transmission de cette clé, car il faut s’assurer que les deux parties s’échangeant un message chiffré par cette clé soient bien les seules à la connaître. Cette clé doit restée privée pour que le secret soit conservé.

L’avantage pratique principal de ce type de clé (et de ce type de chiffrement) est qu’informatiquement, le chiffrement ou déchiffrement à partir d’un algorithme symétrique est très rapide, surtout en comparaison des clés asymétriques.

Clé asymétrique

Le principe est que la clé servant à chiffrer et à déchiffrer sont différentes. L’utilisation de ce type de clé a permis une avancée considérable en cryptographie, car on peut ainsi chiffrer et déchiffrer des messages sans avoir à communiquer de clé privée. L’utilisation de certificats repose sur l’usage de telles clés, tout comme la connexion SSH par clé.

Le principal inconvénient est la lenteur des calculs nécessaires à ce type de chiffrement. Ainsi, lorsqu’on a de longs messages à échanger, on utilise en pratique une clé symétrique ad hoc échangée entre les deux parties par un mécanisme asymétrique.

Voir aussi