Séquestre de clés : mise en pratique du « Shamir's Secret-Sharing Scheme »

Magazine
Marque
MISC
HS n°
Numéro
6
|
Mois de parution
novembre 2012
|
Domaines


Résumé
Ou comment livrer vos secrets à la postérité tout en vous prémunissant des faux frères grâce à un astucieux partage de clé secrète de Shamir exécuté depuis un live CD et accompagné d'un chouia de procédures.

Body

1. Introduction

Nos pauvres petits neurones conservent tant bien que mal toujours plus de sésames. Mais nous ne sommes pas éternels et il serait dommage qu'avec nous disparaissent les accès à un héritage numérique, par exemple le mot de passe d'un disque chiffré ou d'un hypothétique site web commençant par « F » ou « G » qui contiendrait nos courriels, notre agenda, nos photos, nos fichiers, voire des musiques, films et jeux chèrement acquis.

Au sein d'une PME, la perte subite d'un collaborateur pourrait même devenir dommageable à l'entreprise peu prévoyante qui verrait alors la continuité de ses activités (business continuity) mise à mal. Nous continuerons à utiliser l'exemple de la PME par la suite, mais les principes de base restent transposables à un cercle familial ou d'amis.

Une réponse à cette problématique est ce qu'on appelle le séquestre de clé (key escrow), qui permet à un tiers « sous certaines conditions » d'accéder à ces clés. Mais quel tiers, sous quelles conditions, et comment lui accorder notre confiance morale mais aussi technique ? L'autorité de séquestre doit en effet être en mesure de garantir en toute sécurité la confidentialité des clés sous séquestre.

2. Clé de séquestre asymétrique

La première pièce du puzzle sera assez logiquement la création d'une paire de clés publique et privée propre à l'autorité de séquestre (entité qui reste à définir pour l'instant). Ainsi, toute personne désireuse de confier ses sésames n'aura qu'à les chiffrer elle-même avec cette clé publique et à les mettre à disposition voire à les rendre publiquement accessibles vu que seule l'autorité possède la clé privée correspondante.

La clé privée de séquestre sera protégée par une passphrase sur laquelle repose donc toute la sécurité du système. Mais qui sera le détenteur de cet ultime secret ?

3. Règle des deux hommes

Cette règle (two-man rule) est utilisée dans des domaines sensibles tels la commande d'envoi de missiles nucléaires afin d'éviter tout dérapage accidentel ou malicieux. En cryptographie, les Américains emploient la locution « two-person integrity » (TPI) quand il s'agit d'empêcher qu'une personne seule ait accès aux clés cryptographiques assurant la sécurité des communications (COMSEC).

Voici donc un concept intéressant qui nous aiderait à résoudre ces problèmes de confiance et de sécurité envers l'autorité de séquestre. En exigeant que deux individus collaborent pour révéler les données sous séquestre, nous nous mettons à l'abri d'un acte malveillant isolé, voire d'une faille de sécurité isolée.

Divisons donc la passphrase de la clé de séquestre et remettons les morceaux à un groupe de personnes de confiance constituant ce que nous appellerons dorénavant la business continuity team(BCT).

Comment morceler cette passphrase ? Répartir simplement N morceaux entre les N membres de la BCT les oblige à se réunir tous ensemble pour pouvoir utiliser la clé privée de séquestre, mais si l'un d'eux est indisponible ou est justement le collaborateur disparu dont on souhaite récupérer les sésames, comment faire ?

4. Shamir's Secret-Sharing Scheme

Nous allons donc être amenés à répartir la passphrase de la clé privée de séquestre entre les personnes de confiance qui constituent la BCT, mais de sorte qu'il suffisse de réunir une fraction d'entre elles pour accéder à nouveau à la clé privée.

A priori, le problème n'est pas aisé. Pourtant, il a été résolu élégamment par Adi Shamir dès 1979 [SHAMIR] et la solution peut s'illustrer par une simple parabole.

Non, non, il ne s'agit pas d'allégorie, mais bien de mathématiques et de polynômes.

Deux points sont suffisants pour définir une ligne, trois pour définir une parabole, quatre pour une cubique, etc. Si maintenant nous voulons partager un secret, disons la valeur 1234, entre six individus et que trois d'entre eux soient nécessaires pour retrouver le secret, nous choisirons au hasard une parabole parmi celles passant par le point (0, 1234) et nous donnerons les coordonnées de six de ses points à ces six individus (cf. Figure 1).

ssss1

Figure 1 : Parabole passant par (0, 1234) et six de ses points.

Si seulement deux d'entre eux, les n° 2 et 4, venaient à partager leurs coordonnées, ils ne pourraient retrouver la parabole originale et donc la valeur du point secret en x=0(cf. Figure 2).

ssss2

Figure 2 : Paraboles passant par les points des participants n°2 et 4.

Il faut donc bien qu'un troisième individu accepte de partager ses coordonnées pour parvenir à définir une et une seule parabole et révéler la valeur secrète 1234 (cf. Figure 3).

ssss3

Figure 3 : Une seule parabole peut passer par les points des participants n°2, 4 et 5.

Les amateurs retrouveront les équations correspondant à cet exemple sur Wikipédia [WIKIPEDIA].

Cet exemple illustré donne une idée du principe de ce protocole qui utilise en réalité des polynômes dans un corps fini, non représentable dans le plan.

Une implémentation libre existe [SSSS] et est disponible dans les principales distributions, notamment dans Debian/Ubuntu par un simple apt-get install ssss.

Deux commandes sont alors disponibles : ssss-split et ssss-combine.

Pour partager le secret « 1234 » de l'exemple précédent en six morceaux dont trois sont nécessaires à sa reconstruction, on exécutera ssss-split avec les options -n 6 (six morceaux) et -t 3 (dont trois nécessaires) :

$ ssss-split -t 3 -n 6

Generating shares using a (3,6) scheme with dynamic security level.

Enter the secret, at most 128 ASCII characters: 1234

1-44eb879e

2-36abde94

3-43726a38

4-8eabfa4b

5-fb724ef5

6-893217db

Et pour le reconstituer, on utilisera ssss-combine avec les morceaux numéros 2, 4 et 5 :

$ ssss-combine -t 3

Enter 3 shares separated by newlines:

Share [1/3]: 2-36abde94

Share [2/3]: 4-8eabfa4b

Share [3/3]: 5-fb724ef5

Resulting secret: 1234

Mais pour mettre le tout en musique, il nous faut encore quelques procédures et moyens techniques garantissant qu'à aucun moment quelqu'un n'ait un accès intégral à la clé privée de séquestre ou à sa passphrase.

5. Assemblage

Afin d'éviter toute fuite, l'ensemble des opérations sensibles s'effectue sur un ordinateur sans unité de stockage ni réseau qui démarre sur un live CD contenant les quelques scripts nécessaires.
Toutes les communications digitales se feront via des mémoires flash USB labellisées USBPUBLIC, USBSECURE1 et USBSECURE2. Ces dernières sont dédoublées pour offrir une redondance matérielle et ne pourront jamais être utilisées que via le live CD.

5.1. Génération de la clé de séquestre

Les clés publiques des membres de la BCT sont copiées sur USBPUBLIC après vérification de leurs signatures ou de leur empreinte. Ensuite, le live CD est démarré, les trois mémoires flash sont insérées et les clés publiques sont copiées de USBPUBLIC vers les deux mémoires USBSECURE.

Une passphrase aléatoire est générée et partagée en quatre secrets de Shamir (ssss-split -t 2 -n 4), un par membre de la BCT. Chaque membre chiffre son secret partagé de Shamir avec un mot de passe de son choix. Les secrets chiffrés sont alors sauvés sur les mémoires USBSECURE tandis que les mots de passe sont chiffrés à l'aide des clés publiques des membres correspondants et sauvés sur USBPUBLIC et USBSECURE.

La paire de clés de séquestre peut enfin être créée et la clé privée protégée par la passphrase aléatoire. La paire de clés est sauvée sur les USBSECURE et la clé publique sur USBPUBLIC.

L'empreinte (fingerprint) de la clé publique de séquestre est recopiée manuellement sur un papier et un certificat de révocation est généré et sauvé sur les trois mémoires.

Toutes ces étapes sont bien entendu semi-automatisées par un script idoine, les interactions avec les membres étant limitées à la saisie des mots de passe et l'affichage de l'empreinte (cf. Figure 4).

ssss4

Figure 4 : Les étapes initiales de la création de la clé de séquestre

Le live CD est arrêté et USBPUBLIC est insérée dans un autre ordinateur. La clé publique de séquestre en est récupérée, son empreinte extraite, imprimée quatre fois et comparée à la transcription manuelle. Les copies imprimées sont remises à chaque membre de la BCT pour qu'il puisse signer en toute confiance cette nouvelle clé. Les mots de passe chiffrés sont expédiés aux membres correspondants. Le certificat de révocation est imprimé deux fois après quoi USBPUBLIC est effacée de manière sécurisée.

Deux copies du live CD, les mémoires flash USBSECURE1 et USBSECURE2 et les certificats de révocation sont répartis dans deux coffres dont les accès doivent être réglementés par une procédure adéquate.

La clé publique de séquestre est signée par l'ensemble des membres de la BCT et mise à disposition de toute personne qui en aurait besoin.

5.2. Mise sous séquestre

L'individu désireux de placer sous séquestre une information récupère la clé publique de séquestre.

Il la valide en vérifiant que la clé est bien signée par les membres de la BCT et qu'il existe une chaîne de confiance entre ces membres et sa propre clé.

$ gpg --check-sigs --list-options show-uid-validity escrow@ma_petite_entreprise.com

La sortie doit indiquer [marginal] (voire [full] s'il est lui-même membre de la BCT) devant l'uid.

S'il ne possède pas de clé OpenPGP ou que l'entreprise n'est pas adepte du Web-of-Trust, il peut toujours vérifier la clé de séquestre par son empreinte.

$ gpg --fingerprint escrow@ma_petite_entreprise.com

Il peut alors chiffrer en toute confiance l'information souhaitée et la placer là où la BCT l'aura convenu.

Les détails de la mise sous séquestre de chaque type d'information sensible (clé OpenPGP, certificat Outlook, mot de passe Truecrypt, slot d'une partition LUKS, etc.) doivent être documentés et expliqués aux utilisateurs ainsi que les conventions de nommage et de stockage choisies. Si certaines informations doivent d'abord être déchiffrées avant séquestre, il faut être très prudent : ne pas laisser de trace sur les disques, privilégier les pipes en ligne de commandes et s'il est inévitable de créer un fichier temporaire, l'effacer de manière sécurisée (avec wipe, shred, srm ou encore Heidi Eraser sous Windows).

Nous approfondirons le cas des clés OpenPGP, mais voyons d'abord comment se déroule l'opération inverse.

5.3. Récupération de données mises sous séquestre

La donnée à récupérer, donc chiffrée avec la clé de séquestre, sera placée sur la mémoire flash USBPUBLIC ainsi qu'éventuellement la clé publique du récipiendaire de cette donnée si on veut éviter que la donnée ne circule en clair.

Le live CD est démarré sur un ordinateur dépourvu d'unité de stockage et de réseau. La clé privée de séquestre et les secrets de Shamir chiffrés sont lus depuis une des deux mémoires USBSECURE. Deux membres de la BCT introduisent tour à tour le mot de passe qu'ils avaient choisi lors de la génération de la clé de séquestre. S'ils l'ont oublié, ils peuvent toujours se rafraîchir la mémoire en consultant la copie chiffrée qu'ils avaient reçue avant de venir participer à la procédure de récupération. La passphrase de la clé de séquestre est reconstituée et la donnée à récupérer est déchiffrée. Si nécessaire, elle sera re-chiffrée avec la clé publique du récipiendaire avant d'être copiée sur USBPUBLIC.

5.4. Particularités de la mise sous séquestre d'une clé OpenPGP

Si vous êtes amené à utiliser des clés OpenPGP dans un contexte professionnel avec une mise sous séquestre, il est préférable de ne pas utiliser votre clé personnelle mais de créer une nouvelle paire réservée à cet effet, voire deux paires : une pour le chiffrement et une pour la signature. Seule la clé de chiffrement est mise sous séquestre, et ce, sans passphrase. Ainsi, en cas de nécessité, vos communications chiffrées seront déchiffrées sans que personne n'apprenne votre passphrase ni ne soit en mesure de signer des messages en votre nom.

La mise sous séquestre se fera de la sorte :

$ gpg --export-secret-subkey --armor --export-options \
export-reset-subkey-passwd export-minimal alice@ma_petite_entreprise.com | \
gpg --encrypt --armor --recipient escrow@ma_petite_entreprise.com --trust-model always > \

gnupg_private_yourname_pgpID_date.gpg

Si la clé devait être extraite du séquestre et rechiffrée avec la clé publique de la personne habilitée, celle-ci exécuterait :

$ gpg --decrypt gnupg_private.gpg |gpg --import --allow-secret-key-import

N'importe quel message se déchiffre alors le plus simplement du monde, sans passphrase :

$ gpg --decrypt anyfile.gpg

À noter que si vous êtes obligé par exemple par un tribunal de fournir le moyen de déchiffrer un message OpenPGP précis, ne donnez jamais votre clé secrète, mais bien la clé de session symétrique de ce message :

$ gpg --show-session-key --output /dev/null message.gpg

You need a passphrase to unlock the secret key for

user: "Philippe Teuwen (Doegox) <phil@teuwen.org>"

2048-bit ELG-E key, ID 9A4A59B9, created 2002-05-05 (main key ID 9AD7E3DB)

gpg: encrypted with 2048-bit ELG-E key, ID 9A4A59B9, created 2002-05-05

      "Philippe Teuwen (Doegox) <phil@teuwen.org>"

gpg: session key: `9:8B4AD21DBF4AAACF3166DC0449211A2D523FAA2ED1F9C3EEBF7EC332C5B18A60'

La chaîne obtenue est alors utilisée pour déchiffrer directement le message :

$ gpg –override-session-key \ '9:8B4AD21DBF4AAACF3166DC0449211A2D523FAA2ED1F9C3EEBF7EC332C5B18A60' \message.gpg

5.5. Cas particuliers

La procédure et les scripts doivent également couvrir certains aspects de maintenance.

Un changement de constitution de la BCT amène à la création d'un nouveau partage et à l'invalidation de l'ancien, le tout en deux temps pour éviter qu'une erreur sur le nouveau partage n'efface à jamais l'accès à la passphrase : seule la mémoire USBSECURE1 sera modifiée et la procédure de récupération de données testée, et en cas de succès, le contenu de USBSECURE2 remplacera celui de USBSECURE1. L'effacement sécurisé des anciens secrets de Shamir sur les USBSECURE suffit à invalider l'ancienne BCT puisqu'il n'y a pas d'autre copie disponible.

D'autres cas particuliers sont par exemple la perte du mot de passe chiffré d'un des membres de la BCT dont la version chiffrée est alors simplement récupérée d'un des USBSECURE et recopiée sur USBPUBLIC.

Enfin, il est sage de tester régulièrement les différentes procédures, par exemple des essais de récupération de données de test mises sous séquestre.

Conclusions et derniers conseils

Le séquestre de clé en entreprise est avant tout destiné à assurer la continuité des activités, il serait regrettable qu'une fausse manœuvre, un support défectueux ou un bug ruine ce bel échafaudage. En pratique, chaque étape intégrera la redondance et les validations nécessaires pour éviter toute perte ou corruption de données. En outre, il est intéressant de prévoir une trace de l'ensemble des opérations effectuées sur le live CD qui sera retranscrite sur chacune des mémoires USB en fin de session.

La création d'un tel séquestre n'est pas qu'une affaire d'ingénieurs, de crypto et de live CD. C'est avant tout un élément à intégrer à la vie de l'entreprise et à faire accepter aux collaborateurs. Sur ces aspects une documentation claire et exhaustive des procédures à l'usage des membres de la BCT mais aussi de tout un chacun est primordiale et comme on dit : « le diable se cache dans les détails ».

Quelle information placer sous séquestre, quand, sous quelle forme, avec quelle étiquette, à quel endroit ? Qui peut activer la BCT pour récupérer une donnée ? En quelles circonstances ? Quelles procédures appliquer à l'accès physique aux live CD et USBSECURE si on souhaite garantir la règle des deux hommes? Autant de questions qui dépendent de l'environnement dans lequel le déploiement est envisagé.

Nous voici à la fin de cet article qui a tenté de vous montrer une solution de séquestre dont l'autorité est décentralisée ou du moins oligarchique grâce à un partage de Shamir qui devrait gagner la confiance de ses utilisateurs tout en garantissant une certaine résilience quant à son exécution.

Les scripts du live CD sont à disposition dans un projet Google [ESSSSCROW] créé pour l'occasion. Toute collaboration ou retour d'expérience sont les bienvenus.

Note sur les générateurs d'aléa :

Un ordinateur dépourvu d'unité de stockage et de réseau n'a que peu de sources d'entropie à sa disposition s'il n'a pas de composant matériel spécifique (TRNG) pour créer la clé de séquestre. Il peut donc être utile d'intégrer au live CD le paquet haveged. Il s'agit d'une implémentation de l'algorithme HAVEGE (HArdware Volatile Entropy Gathering and Expansion) [HAVEGE] qui collecte un maximum d'entropie, notamment par une mesure du temps d'exécution d'une séquence d'instructions, sensible aux prédictions de branchement, à l'état des caches et de divers états internes hautement volatiles du processeur.

Références

[SHAMIR] Shamir, Adi (1979), "How to share a secret", Communications of the ACM 22 (11): 612–613

[WIKIPEDIA] https://fr.wikipedia.org/wiki/Partage_de_clé_secrète_de_Shamir

[SSSS] http://point-at-infinity.org/ssss/

[HAVEGE] http://www.irisa.fr/caps/projects/hipsor/

[ESSSSCROW] https://code.google.com/p/esssscrow/


Sur le même sujet

Auditer la sécurité d'une application iOS

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Auditer la sécurité d'une application iOS n'est toujours pas une tâche aisée. Force est de constater que la plupart des auditeurs, amateurs de bug bounty ou autres curieux préfèrent travailler sur les applications Android malgré les récentes protections ajoutées au système d'exploitation de Google. Nous allons malgré tout essayer de présenter une méthodologie qui rend possible l'analyse orientée sécurité d'une application iOS, même sans jailbreak. Un bref rappel sera effectué pour ensuite introduire quelques outils et documentations apparues ces derniers mois.

Sondes de détection : performances, évaluations et biais

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

En avril 2019, l’ANSSI a qualifié les premières sondes pour assurer la supervision de sécurité de réseaux. Les opérateurs d’importance vitale (OIV), les opérateurs de services essentiels (OSE) et, d’une manière générale, les organismes opérant des fonctions sensibles disposent ainsi de produits français de confiance : Cybels Sensor de Thales et Trackwatch Full Edition de Gatewatcher.La méthodologie d’évaluation des sondes n’est, hélas, pas publique. Les ingénieurs sécurité et réseau devant intégrer ces sondes ne disposent donc pas de guides pour effectuer la recette de leur efficacité en production. Cet article propose un retour d’expérience sur l’évaluation des sondes, notamment sous l’angle de la performance. Cet aspect est, en effet, particulièrement significatif puisque le taux de détection d’une sonde diminue si elle est submergée, quand bien même elle serait équipée des meilleurs signatures et moteurs d’analyse.

Richelieu : solution du challenge de la DGSE

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

En mai 2019, la DGSE (Direction Générale de la Sécurité Extérieure) a organisé pour la première fois un challenge de sécurité informatique ouvert au public, qu’elle a baptisé Challenge Richelieu. Je vous invite à écouter la bande originale du Bureau des Légendes en fond sonore. Imprégnez-vous de cette atmosphère pleine de tension où les secrets sont rois, puis regardons ensemble ce que nous réservait ce challenge.

Aléa et cryptanalyse de générateurs

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

La plupart des applications en cryptographie moderne nécessitent à un moment ou un autre une source d’aléa [1]. Que ce soit pour chiffrer, générer des nonces, des clés ou même des sels cryptographiques. Mais comment générer de l’aléa sur nos ordinateurs qui sont des machines déterministes ?Dans cet article, nous allons nous intéresser à la place de l’aléa dans les algorithmes de chiffrements modernes. Puis nous verrons trois CTF ou le but est de cryptanalyser des générateurs de nombres aléatoires ; cela nous permettra d’en comprendre le fonctionnement et de voir quelques attaques sur des générateurs de nombres aléatoires.

Contournement de l'API Google Play Billing

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

D'après le blog [INVESP], le montant global des paiements dits « in-app » représentait environ 37 milliards de dollars (USD) en 2017 pour les applications mobiles (Android et Apple). Ce montant représente quasiment la moitié des revenus générés par les applications mobiles (48,2%), dépassant les revenus générés par les régies publicitaires (14%), ainsi que l'achat d'applications (37,8%). Il est donc important que la sécurité de ces paiements soit correctement implémentée afin d'éviter un manque à gagner pour les développeurs des applications. Dans le cadre de cet article, nous avons passé en revue 50 applications Android afin d'étudier le fonctionnement de l'API Google Play Billing et d'identifier les vulnérabilités liées à une mauvaise implémentation. Nous détaillerons en exemple des applications vulnérables.

Par le même auteur

Des attaques en boîte grise pour casser des implémentations cryptographiques en boîte blanche

Magazine
Marque
MISC
Numéro
97
|
Mois de parution
mai 2018
|
Domaines
Résumé
Les techniques d'attaques en boîte grise sur du matériel peuvent être transposées avec succès à un domaine bien plus immatériel, la cryptographie en boîte blanche. Nous verrons ainsi comment adapter les attaques par DPA et par DFA aux implémentations logicielles en boîte blanche.

Banques en ligne : à la découverte d'EMV-CAP

Magazine
Marque
MISC
Numéro
56
|
Mois de parution
juillet 2011
|
Domaines
Résumé
La plupart des banques belges déploient actuellement à grande échelle (certaines depuis plusieurs années déjà) un nouveau mode d'authentification pour autoriser leur clientèle d'accéder à leurs services via Internet. Elles distribuent un petit appareil ressemblant à une calculette pourvu d'un clavier numérique, d'un écran et d'un lecteur de carte à puce. Cet appareil, en combinaison avec la carte bancaire, offre la possibilité de s'authentifier sur le site web de la banque et de signer des transactions en ligne, sur ce même site ou sur un site marchand. Cet article vous entraîne dans la découverte du fonctionnement et de l'implémentation du protocole EMV-CAP, puisque tel est son nom. Dans de nombreux pays, les banques distribuent un appareil semblable, qui a fait l'objet de plusieurs études par des experts reconnus en sécurité, notamment en Angleterre et aux Pays-Bas. Nous comparerons ainsi le fonctionnement et les options prises par les banques de ces pays. Nous passerons en revue certaines attaques publiées contre EMV afin de déterminer si elles s'appliquent également dans le cadre d'EMV-CAP. Grâce à la compréhension du protocole EMV-CAP, nous dissiperons certaines incertitudes quant au fonctionnement interne de ces appareils et nous montrerons qu'il existe des moyens qui rendent ce système encore plus sûr. Une émulation logicielle est également mise à disposition pour ceux qui désirent expérimenter.