Question:
Schémas / mécanismes qui pourraient fournir un décryptage unique?
DaveIdito
2019-12-02 19:41:55 UTC
view on stackexchange narkive permalink

Je connais assez bien la plupart des fondations courantes de sécurité de premier cycle / diplôme; mais je n'ai rien trouvé en rapport avec ce scénario:

Un schéma / système dans lequel une donnée ne peut être «décryptée» ET lue qu'une seule fois (potentiellement dans un programme informatique).

Est-ce même possible? J'ai entendu dire que de telles choses existent dans le «monde du matériel» (?). Si ma question est imprécise / incomplète, je suis prêt à mettre à jour. Mais je suis en fait intéressé par une conception / protocole générique en même temps.

Placez l'utilisateur dans une boîte scellée, blindée et verrouillée, contenant à la fois le message et la clé.Ne laissez jamais l'utilisateur quitter la boîte.Déjà.Enterrez la boîte sur l'océan.
@ThoriumBR Sûrement, lancer la boîte au soleil serait plus sûr?
N'avez-vous jamais regardé Mission Impossible?* Votre mission, si vous décidez de l'accepter ... *
Quel système d'accès envisagez-vous pour ce scénario?Plus précisément, s'agit-il d'un paramètre où l'utilisateur a accès au matériel ou au système d'exploitation sur lequel les données cryptées restent?
@mars cette méthode a lamentablement échoué, quelqu'un a enregistré la mission et des millions de personnes dans le monde savent déjà quelle était la mission.
Les Pads (chiffrement) une fois ne sont censés être utilisés qu'une seule fois, mais ce n'est pas forcé
OTP est destiné à chiffrer une seule fois.Si vous conservez à la fois le pavé et le texte chiffré disponibles, il peut être déchiffré autant de fois que vous le souhaitez.Ou faites des copies et tout le monde avec une copie peut faire de même.OP veut décrypter une fois et une seule fois.
Si l'utilisateur * ne s'y attend pas *, vous pouvez simplement supprimer les données après le décryptage.Cela fonctionnera une fois.La prochaine fois, ils le copieront en premier.
Le cryptage refusable peut être utilisé pour quelque chose de similaire.Après la première lecture, distribuez toutes les fausses clés avec la vraie clé mélangée. Seul le lecteur d'origine sait quel est le texte clair correct, mais il ne peut le prouver à personne d'autre, même en révélant tout ce qu'il sait.https://en.wikipedia.org/wiki/Deniable_encryption
À l'instar d'@usual,, si vous donnez à quelqu'un une clé symétrique, il peut déchiffrer vos données, mais il peut également chiffrer et déchiffrer tout ce qu'il veut, de sorte qu'il ne peut prouver à personne d'autre que les données proviennent de * vous * et ne l'étaientt juste inventé par eux.
Vous pouvez marquer les données (par récepteur) afin que quiconque les fuit puisse être retracé.Bien sûr, cela n'a rien à voir avec la cryptographie.
La communication quantique a inspiré https://qlink.it.N'est pas au niveau du protocole mais utilisable.Le serveur détruit le message après la lecture.
Six réponses:
Rory Alsop
2019-12-02 20:04:10 UTC
view on stackexchange narkive permalink

Il n'y a aucun moyen de le faire - c'est un sous-ensemble de ce que les schémas DRM tentent de faire.

Si un utilisateur final peut déchiffrer quelque chose une fois pour le voir, il peut le voir à nouveau. L'une des choses suivantes peut être possible:

  • commencez par prendre une copie et décrypter que
  • copier l'écran
  • modifier l'application

La seule façon de vous rapprocher serait d'avoir un contrôle total sur le matériel et le logiciel, donc vous pouvez supprimer une fois qu'il a été montré, mais même dans ce cas, quelqu'un pourrait utiliser un appareil photo pour prendre des photos de l'écran etc.

Je voudrais donc plutôt vous demander à quoi vous comptez utiliser un tel schéma - car il existe des moyens d'avoir le même effet dans de nombreux scénarios.

Bien répondu par Rory, comme d'habitude.Les failles mentionnées dans cette réponse sont souvent appelées le «trou analogique» (voir https://en.wikipedia.org/wiki/Analog_hole), ce qui est inévitable dans la plupart des systèmes DRM et de protection contre la copie.
@mti2935 Le trou analogique n'est abordé que par le deuxième des exemples de scénarios de Rory.Le scénario «faire une copie au préalable» est le plus difficile à contrôler car il est généralement complètement en dehors de l'influence de tout type de schéma de chiffrement.
Même si vous parvenez d'une manière ou d'une autre à empêcher toutes les formes logicielles / matérielles de copie (y compris les caméras, etc.), les données parviendront toujours dans le cerveau de l'utilisateur.Ils peuvent le copier à partir de là.
La procédure habituelle pour les données secrètes pour empêcher "quelqu'un pourrait utiliser un appareil photo pour prendre des photos de l'écran, etc."est d'avoir ce matériel dans une installation sécurisée où toute personne entrant est recherchée à la fois à l'entrée et à la sortie pour tout ce qui pourrait être utilisé pour enregistrer ou transmettre des données, et le processus réel d'accès aux données sensibles peut être supervisé par des gardes armés qui essaierontet empêchez la plupart des méthodes de falsification du matériel.Ce n'est pas non plus sécurisé à 100%, rien ne l'est, mais c'est assez efficace et il y a des installations comme ça.
@Peteris et même alors quelqu'un avec une bonne mémoire pourraient simplement tout mémoriser et l'écrire une fois à l'extérieur de l'établissement.
`mais même dans ce cas, quelqu'un pourrait utiliser un appareil photo pour prendre des photos de l'écran, etc.` ==> [FUN OBLIGATOIRE AVEC CAPS ON] (https://thedailywtf.com/articles/copy-protected)
@usr-local-ΕΨΗΕΛΩΝ Il semble qu'ils auraient pu éviter tout cela en rendant impossible de tout capturer dans une seule image.Les CRT appliquent cette technique depuis plus de deux décennies.
@Peteris Puisqu'ils peuvent le stocker dans leur cerveau, ceux-ci doivent également être supprimés à la sortie de l'installation (-:
Tom
2019-12-03 06:01:36 UTC
view on stackexchange narkive permalink

Comme vous l'avez déjà dit, une telle chose n'est possible que dans le matériel. Un logiciel ou une solution de données cryptées souffrirait toujours de la possibilité de faire une copie avant le décryptage.

Dans le matériel, le schéma serait de détruire les informations sur le décryptage. Une approche naïve consisterait simplement à lire un bloc en mémoire, à le détruire sur le stockage, puis à le déchiffrer.

Cette approche, bien sûr, peut être victime de falsification - un attaquant pourrait manipuler le système afin que le la suppression échoue, mais quoi que ce soit, le décryptage croit qu'il a réussi et procède ainsi au décryptage.

Une approche plus sophistiquée serait d'exploiter une propriété physique de telle sorte que la lecture des informations les détruit également. C'est, en fait, ce qui rend la cryptographie quantique largement théorique sécurisée - vous ne pouvez pas écouter (écouter) sans détruire les informations, révélant ainsi le fait que quelqu'un intercepte le message.

En dehors du domaine quantique, il peut y avoir des solutions utilisant des procédés chimiques ou d'autres processus physiques, mais elles seront également sujettes à des altérations.

+1 pour la seule réponse mentionnant le quantum.
+1 pour les produits chimiques.Je pensais à un stript chimique qui va s'oxyder et afficher le texte brut pendant une durée limitée
@usr-local-ΕΨΗΕΛΩΝ Il y avait un programme de location de DVD qui faisait exactement cela.Les disques deviendraient sombres (rendus illisibles) après une exposition à l'oxygène.Vous avez eu environ 48 heures pour regarder le film
@slebetman Ce n'est pas la même chose que le décryptage ponctuel.Je pourrais, pendant ces 48 heures, vider le DVD dans un fichier et le regarder autant que je veux.Non pas que j'aie jamais fait ça avec des DVD de location à l'époque où redbox était une chose et que vous pouviez obtenir un DVD pour quelques dollars.Quoi qu'il en soit, le fait est que je n'ai qu'un temps limité avec le support, sans protection contre la copie en place.
Le stockage quantique peut également ne pas être sécurisé, car il existe un moyen possible de consulter l'état sans le déranger: https://www.livescience.com/schrodingers-cat-can-be-peeked-at.html
@DanielFrużyński qui exagère la recherche, je pense.La phrase clé est * "et si ce changement est réversible" * - ce qui n'est pas le cas chez le chat.Pour le stockage quantique, cela peut ou non être, selon la technologie utilisée.
John Wu
2019-12-03 06:30:28 UTC
view on stackexchange narkive permalink

Si un réseau est disponible, vous pouvez décharger la procédure de décryptage (et la clé privée) vers un service s'exécutant sur un serveur sécurisé. Vous pourriez alors appliquer les règles que vous voulez sur le serveur.

Le client soumettrait le texte opaque au service et lui demanderait de le déchiffrer et de renvoyer le contenu en clair, et le serveur pourrait décider si le client devrait être autorisé en fonction de l'historique de déchiffrement - bloquant potentiellement plus d'une opération de déchiffrement.

Cependant, rien n'empêcherait l'appelant d'utiliser le résultat du déchiffrement encore et encore, ce qui revient plus ou moins à le déchiffrer encore et encore. Il y a eu des tentatives de le faire pour la musique et les films (voir chemin multimédia protégé) mais c'est une bataille perdue. Si rien d'autre, un pirate informatique pourrait usurper le matériel du moniteur et enregistrer le signal d'entrée, ou même simplement pointer une caméra vidéo HD vers le moniteur et enregistrer le contenu pendant sa lecture. Une technique d'interception similaire pourrait être utilisée pour tout type de contenu numérique. Donc, l'essentiel est ... non, ce n'est pas vraiment possible.

Une approche plus faisable consisterait à intégrer un numéro de série au contenu lui-même et à le suivre dans un serveur d'autorisation, ou à le faire horodatage d'expiration. Vous devrez ensuite appliquer cela à l'extrémité de réception, qui devrait être une application sécurisée. C'est ainsi que fonctionne un mot de passe à usage unique, par exemple. Mais cela vous oblige à posséder les deux extrémités du chemin des données et que les données elles-mêmes soient inutiles en dehors de celui-ci.

Notez que si l'enregistrement de l'écran est toujours possible, cela vous laisserait une ** copie déchiffrée **.Cela satisferait toujours la demande OP d'un décryptage unique car vous n'avez pas de copie cryptée.Dans certains cas d'utilisation, cela compte, par exemplelors de la présentation de la copie cryptée est une méthode d'authentification.
@Tom L'exigence stipule également "ET lecture une seule fois".
Damon
2019-12-03 21:30:16 UTC
view on stackexchange narkive permalink

Ce n'est en aucun cas pratique, et fondamentalement impossible (de manière fiable), mais cela peut être possible dans une certaine mesure.

L'obstacle évident qui rend le l'effort fondamentalement impossible est que tout ce que vous décryptez, une fois que vous l'avez lu, c'est dans votre tête. Donc, pour être sûr que le secret reste secret, il faudrait qu'il y ait une sorte de mécanisme de pilule empoisonnée. Peut-être une capsule qui contient un moteur TTS et qui vous transmet le message par conduction osseuse, puis qui explose en vous faisant sauter la tête.
Parce que, vous savez, tant que vous respirez, vous pouvez simplement le dire à quelqu'un. Cependant, espérons que vous ne répéterez pas à haute voix ce que le TTS vous dit en tête.

Cela mis à part, il existe des systèmes de stockage de données qui ne peuvent être lus qu'une seule fois. La DRAM et la RAM ferroélectrique en tant qu'alternative non volatile en sont deux exemples. Ceux-ci ont besoin soit d'une écriture intégrée explicite après lecture, soit de quelque chose de différent (par exemple, un circuit de condensateur). Sinon, la lecture des informations détruit les informations. Laissez cela de côté, et vous avez fait un grand pas en avant.
Maintenant, à tout le moins, il faudrait faire deux copies (une sur un stockage à lecture non destructive, puis un autre pour en avoir une copie). Pourtant, c'est tout à fait dans le domaine du "faisable", mais en fonction de la compatibilité matérielle, cela peut être un peu un fardeau de toute façon (pas sûr que vous puissiez simplement câbler deux types de stockage totalement différents et incompatibles et copier des données comme dans Star Trek, pourrait très ben soit que ça se révèle un peu plus difficile que ça!). Mais nous n'en sommes pas à la fin.

La clé de déchiffrement, et même une partie de l'exécutable de déchiffrement ou l'intégralité de l'exécutable de déchiffrement (en supposant que les boucles sont déroulées) pourraient tout aussi bien être stockées sur un stockage à lecture destructive à l'intérieur du déchiffrement Matériel. La clé de déchiffrement n'a jamais besoin de quitter la puce, donc à part pour les "données", il n'y a pas besoin de voies pour la transmettre. Il est lu pendant le décryptage, et après cela, il est parti. Alors ... voilà.

À moins que vous ne supposiez que quelqu'un pourrait percer des trous de la taille de quelques dizaines de nanomètres dans la puce et utiliser des nano-fils pour écouter en quelque sorte le stockage, il n'y a aucun moyen d'accéder aux données. Je ne dis pas que c'est impossible, juste ... que c'est un peu fou. Aucune information n'est suffisamment précieuse pour le justifier. De plus, je suppose que cela pourrait être une procédure assez risquée car une fuite accidentelle d'une petite charge ou aller de quelques nanomètres trop à gauche ou à droite détruira inévitablement la clé.

Comme la clé de décryptage est généralement très petit (32 octets ou moins), il pourrait en fait être stocké dans un processeur enclave sécurisé ou similaire, comme cela se fait couramment dans de nombreux appareils mobiles de nos jours. Ce stockage pourrait aussi avoir des lectures destructrices (et aucun accès externe aux données enclavées, un peu comme sur tous les téléphones modernes). Mais ce n'est même pas nécessaire.
Vous pouvez avoir des fusibles comme dans Knox de Samsung ou SEP d'Apple, qui vous permettent en principe de décrypter les données N fois (pas exactement une fois, mais exactement N fois, autant que vous aimez). Après cela, le processeur n'actualise tout simplement pas (ou écrase explicitement) la clé. Ou, beaucoup moins sécurisé (mais probablement encore assez bon), il ne fait que refuse de déchiffrer.
Ainsi, faire une copie des données chiffrées ne fera vraiment pas grand-chose car vous ne pouvez pas déchiffrer le copie.

Bien sûr, quelqu'un peut encore copier de manière triviale les données décryptées , s'il existe un moyen de le faire. Il y en a généralement, à la fois numériques et analogiques. Si rien d'autre, vous pouvez avoir deux ou trois personnes qui regardent l'écran simultanément ou prendre une photo.

C'est cependant un problème que vous ne pouvez fondamentalement pas résoudre (sauf par un appareil qui explose ou un appareil libérant un gaz neurotoxique).

mtraceur
2019-12-04 00:09:17 UTC
view on stackexchange narkive permalink

D'un point de vue purement théorique - cela n'est possible que si vous pouvez vous assurer qu'après le premier décryptage, il n'y a pas de copies existantes des deux

  1. le décrypté les données, et
  2. soit les données chiffrées, soit la ou les clés nécessaires pour les déchiffrer.

En principe , vous ne pouvez le faire qu'avec la coopération (volontaire ou forcée) des parties qui gèrent ces informations qui doivent être supprimées.

En pratique , cela peut suffire en fonction de ce que vous voulez réaliser et des composants du système auxquels vous êtes prêt à faire confiance.

Par exemple, si vous faites confiance à un iPhone classique (vous ne devriez pas , au sens absolu, mais comme pour tout ce qui concerne la sécurité, il y a peu d'absolus, il n'y a généralement que la probabilité et le risque que vous êtes prêt à accepter), vous pouvez choisir de supposer qu'une application iPhone que vous avez écrite et ses données ne peuvent pas être trafiqué par un logiciel malveillant ou par l'utilisateur humain, parce que c'est le genre de chose qu'Apple semble essayer de garantir, et ainsi vous pouvez effectuer le décryptage et vous assurer de supprimer les données de votre code après.

(Vous pouvez toujours imaginer un appareil méticuleusement sécurisé et audité qui vous avez créé vous-même si l'iPhone vous semble trop peu sûr ou non fiable.)

Cela ne supprime pas le "trou analogique" si vous montrez ces données à l'utilisateur ou si vous les divulguez d'une manière observable, mais cela pourrait être acceptable pour certains cas d'utilisation - par exemple, peut-être que vous ne le montrez pas à l'utilisateur, mais que vous n'utilisez que les données décryptées dans le cadre d'un schéma de sécurité dans les détails d'implémentation que l'utilisateur n'a pas directement besoin de voir.

Nous pouvons étendre cet exemple à la transmission de données: vous pouvez envoyer les données cryptées via un canal de données, la clé via un autre, et tant que vous faites confiance à au moins l'un de ces canaux pour être sécurisé et de ne pas conserver les données qui y sont passées, ou vous pouvez être sûr que tout intermédiaire qui peut espionner sur un canal ne sera jamais en mesure de transmettre des informations à quiconque peut espionner l'autre, alors vous avez une garantie décente que le seul la chose qui le déchiffre est votre code client coopérant.

TL; DR : Si vous comprenez pourquoi il n’existe pas de solution parfaite à ce problème en principe, vous pouvez identifier certaines situations où vous pouvez y parvenir avec des cotes suffisamment élevées pour être à l'aise dans la pratique. Mais ces situations peuvent ne pas chevaucher ce que vous espériez faire.

Filips Jelisejevs
2019-12-11 14:35:36 UTC
view on stackexchange narkive permalink

C'est l'une des promesses de la communication quantique - en théorie, puisque l'observation modifie fondamentalement les états quantiques, il serait possible de créer un protocole de communication «à lecture unique».

Bien sûr, des problèmes pratiques tels que "l'utilisateur peut toujours prendre une photo de son écran avec son téléphone" persistent.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...