Assurez-vous qu'un fichier ne peut être déchiffré qu'après une date spécifique
Existe-t-il des schémas/protocoles cryptographiques qui me permettraient de crypter un fichier, de le rendre public, mais de veiller à ce qu'il ne puisse être décrypté qu'après une date spécifique?
Je suppose que ce serait presque impossible sans une autorité de confiance (notaire). Ou existe-t-il un moyen?
J'ai été inspiré par l'idée de "triggers sécurisés" , qui est un schéma pour décrypter les données après qu'un événement spécifique s'est produit. Mais cet "événement déclencheur" n'est connu que de l'auteur.
En revanche, je suis intéressé par un schéma cryptographique qui permettrait le déchiffrement des données à (ou après) une date spécifique qui est connue du public.
Le temps est relatif. La cryptographie vit dans le monde éthéré des machines informatiques abstraites: il y a des machines qui peuvent faire des opérations. Les machines plus grandes peuvent effectuer des opérations plus rapidement. Il n'y a pas d'horloge que vous puissiez appliquer; le temps physique n'a pas de sens. En d'autres termes, si un attaquant veut récupérer votre fichier plus tôt, il n'a qu'à acheter un ordinateur plus rapide.
Maintenant, on peut encore faire un effort. Vous pourriez être intéressé par puzzles à verrouillage temporel . L'idée est de pouvoir créer une instance de problème facile à construire mais coûteuse à ouvrir, dont le coût est configurable. La solution trouvée par Rivest, Shamir et Wagner (à ma connaissance, c'est le seul puzzle de verrouillage temporel pratique connu à ce jour) fonctionne comme ceci:
- Générer un module RSA aléatoire n = pq où p et q sont de grands nombres premiers (et aussi p = 3 mod 4, et q = 3 mod 4).
- Générez un modulo aléatoire x n .
- Pour un entier w , définissez e = 2 w et calculez y = x e mod n .
- Hachage y avec une fonction de hachage, produisant une chaîne [~ # ~] k [~ # ~] que vous utilisez comme clé pour crypter le fichier que vous souhaitez verrouiller dans le temps.
- Publier x , n , w et le fichier crypté. Jeter p , q , y et [~ # ~] k [~ # ~] .
Le point délicat est que le calcul y , en général, a un coût qui est proportionnel à w : c'est une succession de w quadrillages modulaires. Si w est de l'ordre de milliards ou plus, alors cela va coûter cher. Cependant, lorsque les facteurs p et q sont connus, alors on peut calculer e modulo p-1 et q-1 , qui sera beaucoup plus court, et le calcul de y peut être effectué dans un quelques millisecondes.
Bien sûr, cela ne garantit pas une sortie à une date spécifique ; il garantit plutôt un effort minimum pour déverrouiller le puzzle. La conversion entre l'effort et la date dépend de la façon dont les attaquants tentent ...
Le casse-tête temporel exprimé ci-dessus présente certaines caractéristiques niçoises, notamment étant insensible au parallélisme. Si vous essayez de briser un tel casse-tête et que vous avez deux ordinateurs, vous n'obtiendrez pas plus vite que ce que vous pourriez faire avec un seul ordinateur.
Dans un contexte quelque peu similaire, ce casse-tête à verrouillage temporel est utilisé dans la fonction de hachage de mot de passe Makwa , candidat à la [~ # ~] phc [~ # ~] . Dans le hachage de mot de passe, vous voulez un effort d'ouverture configurable (quoique dans un délai beaucoup plus court, généralement moins d'une seconde).
Si vous ne souhaitez pas impliquer un tiers, vous (la partie chiffrant le fichier) pourriez simplement libérer la clé pour déchiffrer le fichier à la date cible.
J'ai vu cela pour les sorties de jeux vidéo. Les clients sont autorisés à télécharger à l'avance une copie cryptée du jeu. Ensuite, lorsque le moment de la sortie arrive, la société de jeux libère simplement la clé. De cette façon, les gens peuvent commencer à jouer immédiatement après la sortie du jeu, sans avoir besoin d'attendre un téléchargement.
Placez soigneusement un vaisseau spatial diffusant la clé de déchiffrement en orbite autour d'un trou noir. L'attraction de la gravité retardera le message jusqu'au moment approprié.
Ou vous pouvez simplement faire comme des gens normaux et placer le vaisseau spatial de radiodiffusion clé à un nombre approprié d'années-lumière du public visé.
Utilisez le partage secret pour diviser une clé de chiffrement privée en N parties, paramétrée pour permettre la reconstruction de la clé avec K ou plusieurs parties, où K <= N. Il est préférable d'utiliser CRM, comme décrit sur la page suivante:
http://en.wikipedia.org/wiki/Secret_sharing
Envoyez ensuite chaque partie à des services indépendants qui acceptent de publier à une date donnée dans le futur.
Jusqu'à K-1 des services peuvent "faire défaut" en publiant tôt sans affecter le schéma.
Jusqu'à N-K des services peuvent ne pas publier complètement, sans affecter le schéma.
Je crois que pour bien concevoir votre système, vous devez définir ce que "temps" signifie dans votre contexte, et pourquoi vous avez choisi une heure spécifique. En supposant que votre message doit être déchiffré le 29 août 1997 à 02h14, quelle différence y a-t-il entre le moment avant et le moment après la date limite? Pourquoi spécifiquement cette date? Vous pourrez peut-être utiliser cet événement en tant que composant de votre schéma.
Par exemple, si vous vous attendez à ce que Skynet devienne conscient de lui-même à la date en question et que vous souhaitez que le message soit décrypté uniquement après que Skynet est devenu conscient de lui-même, la clé de déchiffrement pourrait être 'skynet_became_self_aware'. Il est peu probable qu'il soit forcé brutalement, d'autant plus qu'il contient un mot non-dictionnaire. Cependant, il devient très probable qu'il sera essayé après que l'événement se soit produit, surtout s'il existe des systèmes automatisés essayant de le forcer brutalement qui ajoutera le mot 'skynet' à leurs dictionnaires au bon moment.
Ce schéma n'est pas parfait, car le risque de forcer brutalement la clé existe toujours et même après la date à laquelle il n'y a peut-être pas de ressources appropriées à utiliser pour essayer de se fissurer il. Cependant, ce schéma présente l'avantage supplémentaire que si l'événement dont vous choisissez la date se produit plus tôt ou plus tard que prév, le message ne sera pas déchiffré trop tard/trop tôt.
Si la seule partie de confiance est vous-même et que vous ne pouvez pas garantir d'être disponible lorsque le contenu du message doit être rendu public, alors vous pouvez plutôt créer un périphérique (physique ou virtuel) qui rendra automatiquement la clé publique à l'adresse l'heure requise, puis masquez l'appareil.
Un moyen simple serait d'acheter un serveur virtuel d'Amazon ou de l'une des centaines d'autres sociétés - peut-être plusieurs serveurs à l'étranger - sous une identité différente, non traçable à l'identité de la personne qui a publié le message. Idéalement, vous achèteriez ce serveur plusieurs années avant de publier le message. Ces serveurs restent simplement assis et attendent, ne faisant rien (peut-être hébergeant un courrier électronique ou un serveur FTP d'apparence innocente), jusqu'à la date spécifiée, puis publient la clé de déchiffrement via plusieurs canaux publics afin de satisfaire votre définition de rendre les informations "publiques". "
Personne ne saurait même que ces serveurs existent, donc personne ne les recherche; et leur but peut être suffisamment obscurci pour que personne qui tombe par hasard sur eux ne sache à quoi ils servent. Il existe plusieurs millions de serveurs connectés à Internet - les vôtres sont tout simplement perdus dans le bruit.
Cela serait suffisant à moins que le message ne soit considéré par le public comme suffisamment important pour que la clé soit déployée dans le monde entier, à une échelle qui inciterait les gouvernements à effectuer une analyse de trafic sophistiquée pour chaque serveur virtuel et physique mis en ligne. au cours de la dernière décennie, puis examinez manuellement tous les fichiers et le code de chacun (des millions) de suspects, à la recherche d'informations cachées.
Dans ce cas, vous pouvez masquer encore plus l'appareil. Si vous voulez vraiment faire ce style James Bond, mettez le message sur une bande connectée à un émetteur radio à ondes courtes avec un batterie de réserve en Antarctique (où il pourrait être enterré dans la neige), ou sur un Brésil éloigné jungle (où il pourrait être endommagé par des animaux), ou au fond de l'océan, avec un airbag gonflé chimiquement pour le faire remonter à la surface à la date et à l'heure spécifiées (où il pourrait se corroder - peut-être que le lac Supérieur est plus sûr? ), ou enterré peu profondément sous terre, avec une antenne de type périscope.
Bien sûr, la difficulté et le coût de l'une de ces options dépendent de la durée pendant laquelle vous souhaitez garder l'appareil caché. Si c'est un siècle, il est probable que les protocoles Internet auront changé, et quelque chose de plus complexe que la radio analogique à ondes courtes pourrait être irréalisable. (Et il se peut que personne n'écoute plus les ondes courtes non plus.) Si ce n'est que quelques mois, votre appareil pourrait simplement être un smartphone prépayé connecté à une batterie externe et déposé quelque part modérément obscur. Il existe déjà de nombreux capteurs à distance basés sur les cellules sur le marché, qui passent automatiquement un appel téléphonique ou une connexion Web lorsque certains critères sont remplis, donc cela serait presque indétectable - il ressemblerait à la société de téléphonie mobile comme à un autre ces dispositifs de plus en plus omniprésents.
Je ne sais pas vraiment si cet article sur le chiffrement à verrouillage temporel a été inspiré par cette discussion, mais ce serait le solution la plus formelle à la question "Comment créer un chiffrement à verrouillage temporel?", qui est une reformulation de "Comment protéger les données afin qu'elles ne puissent être déchiffrées qu'après une date spécifique?"
Mais maintenant, entrons dans les détails sur la façon dont cela fonctionne.
On construit essentiellement une horloge de référence à l'aide de calculs disponibles publiquement (comme les calculs Bitcoin). Donc, pour autant que je comprends cela, cela dépend de la blockchain Bitcoin pour atteindre une certaine taille (elle augmente toutes les 10 minutes, relativement précisément). Lorsque cela se produit "le cryptage des témoins" permettra à tout le monde de décrypter les données (où la blockchain contient un témoin, qui n'est disponible que lorsque la chaîne obtient une certaine Taille). Comme il est impossible de briser les schémas de cryptage des témoins et d'être plus rapide que l'ensemble du réseau bitcoin (effectuant plus de 300PHashes/s pour l'instant), il est peu probable que un attaquant pour pouvoir obtenir les données déchiffrées (qui peuvent être une clé) avant l'expiration du verrouillage temporel.
On peut également noter que ce schéma ne souffre pas de coûts élevés (voyage dans l'espace), il n'a pas besoin de tiers de confiance (vous n'avez pas besoin de faire confiance au réseau Bitcoin) et le la partie chiffrée n'a pas besoin d'être disponible au moment du déchiffrement et les parties avec des ressources de calcul élevées ont peu de chances de connaître le secret plus tôt .
On peut également vouloir lire cet article , en suivant une approche similaire et en réduisant la sécurité au sous-ensemble-problème, qui est considéré comme difficile.
Chiffrez le fichier avec une clé très longue, divisez-le en parties et donnez chaque partie à une personne de confiance avec des instructions pour ne pas restituer ladite partie jusqu'à la date indiquée. Vous pouvez ajouter une certaine redondance en distribuant chaque partie à plus de personnes, au cas où l'une d'entre elles serait heurtée par un bus.
Bien sûr, un réseau d'ordinateurs pourrait faire cela tout comme les humains. En fait, l'algorithme de retargeting basé sur le temps de Bitcoin, bien qu'il serve un objectif différent, repose sur des principes similaires. Cependant, je ne sais pas si un programme existe à cet effet.
Une approche hypothétique est donnée dans le document cité dans la question (qui est très intéressant BTW, malgré la grammaire maladroite occasionnelle) qui consiste à utiliser un logiciel contenant une charge utile chiffrée, déclenchant une valeur extérieure comme une nouvelle, et d'avoir des gens dans le monde entier l'exécuter jusqu'à ce que la charge utile soit exécutée. Cela ne répond pas à l'exigence de "date/heure connue du public", mais la prémisse est un bon point de départ. Un service distribué, tout comme TOR/Bitcoin, pourrait être exécuté de manière P2P par de nombreuses personnes à travers le monde dans le seul but de maintenir des versions de clés dépendantes du temps. Ceci est connu comme la tolérance aux pannes byzantine (alias le problème des généraux byzantins, voir http://en.wikipedia.org/wiki/Byzantine_fault_tolerance pour une explication complète) mais dans ce cas, la "faute" doit être la diffusion prématurée des informations ne serait donc pas une application directe, mais une application tangentielle qui nécessiterait un nouvel ensemble de techniques.
Un codage minutieux pourrait être utilisé pour créer un schéma dans lequel chaque utilisateur détient un petit morceau de la clé, de nombreux utilisateurs ont des copies redondantes de morceaux individuels, et il existe un moyen puissant d'empêcher la "récolte" prématurée, y compris l'évasion de logiciels malveillants et le support multiplateforme ( où les clés sont intentionnellement réparties également entre les utilisateurs exécutant le logiciel sur Windows, IOS, Android, OS X, Linux, etc.)
Cela devrait presque fonctionner comme un inverse de la blockchain bitcoin, où au lieu que chaque utilisateur ait une copie vérifiable de ce qui s'est passé, chaque utilisateur a une tranche unique de ce qui se passera à l'avenir, et uniquement en tant que les tournants futurs vers le présent sont chaque bloc libéré dans le monde pour la consommation. Une technique d'oignon à la TOR pourrait être utilisée dans ce cas, où chaque morceau de votre clé secrète a été envoyé à un ensemble d'utilisateurs, ils l'ont transfiguré et l'ont envoyé en ne conservant qu'une clé de traduction, et cela a continué pour N tours en amont. Chaque couche pourrait avoir son propre minuteur aléatoire pour passer plus tard le matériau en aval, se rapprocher de l'origine où le dernier minuteur décompte et déclenche la libération des éléments clés pour se réunir sur un ensemble de pairs convenus et être envoyés par e-mail, ou quelque chose.
La seule pièce manquante serait de savoir comment éviter la collusion de masse, comme une prime mise en place pour inciter suffisamment d'utilisateurs à renoncer à leur matériel clé en échange d'une division du pot, car on ne peut pas supposer que beaucoup d'entre eux considèrent leur engagement informations pour avoir une valeur> 0 si elles restent intactes. Un moyen d'obscurcir complètement le matériel serait souhaitable, de sorte que chaque utilisateur ait un gros bloc de données sans savoir quelles tranches d'événements étaient à sa charge. C'est effectivement un problème intéressant.
Comme d'autres l'ont dit, on ne peut pas fournir le décryptage à une date précise, mais par un effort spécifique. Quant à un algorithme à usage unique, l'effort est fortement lié à l'intérêt des parties qui tentent de le déverrouiller plus tôt et donc assez inconnu.
La meilleure solution peut donc consister à relier le puzzle à un intérêt beaucoup plus vaste et inerte. Le plus réalisable qui m'est venu à l'esprit ces jours-ci est la chaîne de blocs Bitcoin. Comme les bitcoins sont une réalité depuis quelques années et que leur génération implique de grandes quantités de matériel aujourd'hui, nous avons de bonnes chances de prédire leur taux de génération sur une durée raisonnable (peut-être des semaines à des mois).
Je me demande si cela pourrait être fait. Ce qui serait nécessaire, c'est un lien entre les bitcoins générés et la clé nécessaire. Nous ne pouvons pas compter sur un seul bitcoin pour être généré, mais devons utiliser quelque chose comme un petit n d'une grande quantité précédemment choisie de m les bitcoins possibles fourniront le décryptage. Cela est possible avec le "partage secret" ( https://en.wikipedia.org/wiki/Secret_sharing ). Comme les hachages bitcoin dépendent des transactions effectuées auparavant, il serait assez difficile de construire des puzzles m qui résoudraient un jour le hachage bitcoins.
En utilisant des sources pas complètement fiables, vous pouvez envoyer la clé de déchiffrement par courrier postal à la personne de confiance. Cela ne fait pas entièrement confiance à la partie car elle ne peut pas publier tôt, mais elle ne peut pas du tout poster, donc pour minimiser le risque, plusieurs sources fiables peuvent être utilisées.
Pour augmenter le délai, vous pouvez utiliser un service en ligne pour leur demander d'envoyer la carte postale de l'extérieur du pays (mais cela la rendrait vulnérable à l'homme au milieu des attaques), par exemple http: // mijnkaart. bpost.be/fotokaarten-maken pour les locuteurs néerlandais, mais je suis sûr que des services similaires existent ailleurs.
Cela fonctionne pour se déclencher lors d'un événement que vous provoquez.
Faites une automatisation (voir la réponse de Peter Wone) qui vérifie si vous avez une page wikipedia à votre nom. et déclenche si c'est le cas.
Ceci est évidemment très sensible aux déclencheurs et ne fonctionne que si vous êtes inconnu au moment de la construction.
Vous pouvez résoudre les deux problèmes en incluant la condition que certaines informations sur l'événement soient contenues dans l'entrée Wikipedia.
Je suis sûr qu'en utilisant Google, il y a quelques autres déclencheurs intéressants à trouver
En fin de compte, la deuxième loi de la thermodynamique vous gêne. Regardez votre texte en clair comme un système fermé; elle ne peut que croître en entropie.
Le cryptage des informations augmente son entropie, mais le fait d'avoir la clé le compense. L'entropie totale de la clé + du texte chiffré est la même que l'entropie du texte brut.
Lorsque vous détruisez la clé, l'entropie globale du système augmente. Ce qui signifie que vous ne pouvez jamais revenir en arrière (sauf avec un apport massif d'énergie grâce à une puissance de calcul par force brute).
Cela signifie que vous devez conserver la clé; vous ne pouvez pas le détruire temporairement.
Bien sûr, vous pouvez masquer la clé, la crypter à nouveau, la conserver avec un tiers de confiance, etc. Mais la clé doit toujours être quelque part.
Cryptez avec un seul XOR pad et disposez d'une sorte d'automatisation pour envoyer le flux de chiffrement à l'heure indiquée. Une fois XOR les pads sont complètement résistants à attaques de modèle parce qu'il n'y a pas de modèle.
Pour que cela réussisse, vous devez
- produire la clé vous-même et ne pas la partager avec n'importe qui
- construire une automatisation de la livraison temporisée infalsifiable
- dissimuler le véritable objectif du système de distribution chronométré en veillant à ce qu'il accomplisse un travail d'infrastructure extrêmement ennuyeux mais essentiel, de sorte que personne n'essaye de l'étudier, de le débrancher, de le modifier ou de le redéfinir
- détruire tous les copies du tampon XOR en dehors du système de distribution temporisé inviolable
Notez que pour être vraiment inviolable, il doit répondre à l'altération en brouillant très soigneusement le XOR pad. Heureusement depuis XOR pads contiennent des données aléatoires, il n'y a aucun moyen pour dire s'il s'est auto-détruit ou non.
Vous pouvez en outre masquer le pavé XOR stéganographiquement pour empêcher le curieux de se demander pourquoi quelqu'un cacherait un grand nombre de données apparemment aléatoires.
Je me rends compte qu'il y a des éléments de sécurité par obscurité dans cette approche. C'est inévitable; si je connaissais un tel système et que je voulais l'attaquer, je commencerais par le priver de puissance et dessouder tout ce qui ressemblait à du stockage afin de pouvoir en examiner le contenu sans lui permettre de répondre aux manipulations. Même alors, vous pouvez intégrer un onduleur.
L'attaque éclairée dépend de a priori connaissance du système, en commençant par son existence. Si seul l'expéditeur connaît son existence, cela peut être robuste. Une stratégie courante consiste à éviter qu'une partie ne construise un fragment suffisamment grand pour avoir un objectif cohérent.