C'est le titre d'un article du Heral Tribune
http://www.iht.com/articles/2008/02/22/technology/chip.php
Des scientifiques de Princeton ont développé une technique simple: il faut mettre le chip à - 196 degrés Celsius...
Reste à tester...
Journal Comment voler facilement des données chiffrées
25
fév.
2008
# Froid
Posté par nonas . Évalué à 3.
Le principe c'est que la RAM ne perd pas ses données immédiatement à l'arrêt de son alimentation, c'est juste l'agitation thermique qui "efface" les données.
Alors oui en refroidissant on diminue les possibilités de perte de données mais même sans ça leur méthode fonctionne pendant quelques dizaines de secondes.
# pas forcément -196
Posté par briaeros007 . Évalué à 5.
http://arstechnica.com/news.ars/post/20080221-researchers-cr(...)
).
Et -50 c'est relativement simple à avoir : eux ils utilisaient des "spray" d'air comprimé (utilisé pour nettoyer les clavier,...), mais dans les magasin d'électronique il existent aussi des spray dont le seul but est de refroidir à -50°c pour les recherches de pannes thermiques.
(
http://www.conrad.fr/givrant_kf_p_19500_19514_206919
http://www.conrad.fr/givrant_freez_it_p_19500_19514_206917
)
[^] # Re: pas forcément -196
Posté par Zorro (site web personnel) . Évalué à 3.
Il paraît que le métal ainsi refroidi devient très cassant, puis un bon coup de marteau dedans, et c'est cassé.
Du coup, y a des antivols en U qui sont censé résister à ça, m'a dit le vendeur, en me montrant les plus chers... :-(
[^] # Re: pas forcément -196
Posté par briaeros007 . Évalué à 2.
XD
[^] # Re: pas forcément -196
Posté par Zorro (site web personnel) . Évalué à 3.
# Parade
Posté par Serge Julien . Évalué à 5.
[^] # Re: Parade
Posté par Anonyme . Évalué à 4.
[^] # Re: Parade
Posté par Serge Julien . Évalué à 6.
Je vais à l'instant aller me chercher un bon café, en n'oubliant pas de mettre hors tension mon ordina
[^] # Re: Parade
Posté par M . Évalué à 3.
On peut aussi imaginer une fonction de verouillage du pc qui stocke la RAM dans un swap crypté et l'efface(en fait c'est un suspend to disk) qui est fait avant de quitter le PC ou au bout d'un timeout.
[^] # Re: Parade
Posté par Sébastien B. . Évalué à 3.
# facilement
Posté par B16F4RV4RD1N . Évalué à 3.
Il est possible également d'encrypter la ram, en ce cas je ne sais pas si leur technique fonctionne toujours...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: facilement
Posté par Antoine (site web personnel) . Évalué à 1.
Pour la ram chiffrée je veux bien, mais la clef elle est stockée où ? Dans un composant supplémentaire (c'est donc une protection matérielle) ?
[^] # Re: facilement
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: facilement
Posté par ribwund . Évalué à 4.
[^] # Re: facilement
Posté par Jerome Herman . Évalué à 4.
Ca s'appelle TPM (ex TCPA) et c'est livrée en standard sur l'immense majorité des portables modernes. On en trouve aussi sur quasiment tous les PC de bureau à base de chips Intel.
[^] # Re: facilement
Posté par briaeros007 . Évalué à 2.
voir mon commentaires plus bas ;)
# Une autre attaque
Posté par khivapia . Évalué à 8.
Sinon les attaques par des moyens détournés rappellent l'importance des principes suivants :
1) avoir un algorithme cryptographique robuste est nécessaire
2) avoir une bonne implémentation de cet algorithme l'est tout autant
3) enfin maitriser le plus possible l'environnement dans lequel cet algorithme s'exécute est très important (carte à puce, salle de serveurs protégée, moyens de destruction rapide sinon du matériel, au moins des données... )
À noter que les solutions "modernes" de type Hardware Security Module comportent des mécanismes de destructions de clefs en cas de changement trop brutal de la température.
En général c'est pour protéger contre les attaques de type "Je fais chauffer la puce, comme ça elle fait des erreurs et j'en déduis de l'information sur le contenu", mais c'est également couplé à des mesures de protection physique comme "Si on tente d'ouvrir ça s'autodétruit".
Malheureusement dans le domaine de la protection physique des moyens cryptographiques, la sécurité par l'obscurité joue à plein : souvent une implémentation physique est bien protégée contre certains types d'attaques, mais absolument pas contre d'autres. Les secrets industriels sont ici très utilisés.
# La parade !
Posté par kowalsky . Évalué à 10.
# l'interret ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: l'interret ?
Posté par Thomas Douillard . Évalué à 2.
En cas d'accès physique en tout cas.
[^] # Re: l'interret ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: l'interret ?
Posté par Thomas Douillard . Évalué à 4.
[^] # Re: l'interret ?
Posté par Larry Cow . Évalué à 4.
Un peu moins efficace que le passage au frigo, mais tellement plus pratique.
[^] # Re: l'interret ?
Posté par M . Évalué à 2.
Tu oublis le bios qui remet la RAM à 0...
C'est d'ailleurs ce qui empeche de recupérer des données d'un kernel panic. Par contre la RAM video n'est pas remise à 0.
[^] # Re: l'interret ?
Posté par Larry Cow . Évalué à 2.
C'est loin d'être systématique, manifestement.
Ce qui est remis à zéro de manière certaine, c'est ce qui est réutilisé par l'OS au reboot suivant.
# et aussi
Posté par z a . Évalué à 2.
# Il y a bien une solution...
Posté par briaeros007 . Évalué à 3.
Il s'agit des puces TPM, où la clé est censé ne jamais sortir...
Inconvénients :
- Mis en place de TCPA/Palladium/...
- D'après la norme TCPA, le fabricant peut migrer d'un TPM à un autre toutes les clés, y compris les non migrables. => possibilité de récupérer les clés contenues dans la puce. -> Absolument nul si c'est implémenté.
[section 13 , maintenance, de la norme https://www.trustedcomputinggroup.org/specs/TPM/tpmwg-mainre(...)
spec retrouvé grace à a_capsi ]
[^] # Re: Il y a bien une solution...
Posté par Jerome Herman . Évalué à 4.
C'est pas parce que tu migres les clefs, que tu as accès aux clefs. Déjà pour que les clefs soient migrables par le fabriquant il faut que l'endorsement key ait été activée en plein. C'est à dire mise en place ET non révoquée lors de l'initialisation du TPM ET associée à tous les profils.
Ensuite on ne peut migrer les clefs que d'un TPM à un autre. On peut bien sur imaginer que le fabriquant est capable de construire un simulateur de TPM et de lire les clefs "en clair" dans la ram du simulateur.
Les mécanismes de migrations sont nécessaires pour éviter que la mort d'une puce n'implique la mort de toutes les clefs associées à cette puce. Et il faut des droits assez élevés vis à vis du TPM ET vis à vis de la clef à migrer pour lancer une migration. Typiquement sur un TPM initialisé ou réinitialisé à la main, un fabriquant ne pourra migrer aucune clef sans l'assistance du TPM owner pour lui ouvrir les portes.
[^] # Re: Il y a bien une solution...
Posté par briaeros007 . Évalué à 3.
Vu qu'on parle du fabricant, avec le rtl du code, il a même DUT en faire (ie , emuler la puce sur un fpga, avec la facilité de debug qu'offre un fpga).
C'est donc même pas "on peut imaginer", c'est "il est forcé de le faire" (à 99.9%).
un fabriquant ne pourra migrer aucune clef sans l'assistance du TPM owner pour lui ouvrir les portes.
Tant que je n'ai pas de rapport de sécurité de la puce, j'évite d'être si affirmatif.
On parle du CONCEPTEUR de la puce, pas du pekin moyen.
Donc
1°) un fabricant de puce TPM peut être considéré comme un attaquant niveau III : fond (presque) illimité et connaissance exemplaires.
2°) rien ne l'empêche de mettre une backdoor style "autorisation owner ... ou tel clé", vu que par définition, c'est lui qui met ce qu'il veut dedans !
Encore une fois, tu me sort un rapport de sécurité d'une puce TPM par un labo spécialisé dans ce genre de test, ok je pourrais avoir confiance.
Mais croire que "le fabricant est quelqu'un de gentil" est une erreur dans le domaine de la sécurité.
Surtout quand le fabricant vient de l'exterieur.
Ps ne crois pas que je suis 100% contre le TPM, j'adorerais avoir un coprocesseur crypto sur lequel je puisse me fier, mais désolé la sécurité par l'obscurité (c'est proprio, on sait pas comment ils l'ont fait, c'est donc bon) ça n'a JAMAIS été de la sécurité.
[^] # Re: Il y a bien une solution...
Posté par Jerome Herman . Évalué à 2.
En l'occurrence pour ma part là je parle de la norme. Il n'y a pas plus de raisons de faire confiance à une puce TPM qu'à une puce de carte bleue par exemple.
Après effectivement on peut imaginer que le fabriquant de la puce a une backdoor qui lui permet de passer au travers des 4 ou 5 mécanismes de sécurisation (nécessité d'ownership, nécessité de présence physique, validité des hashs etc.) ou de lire toutes les clefs en clair.
En fait on peut toujours l'imaginer. On peut imaginer une backdoor dans les CPU qui permet de forcer les suites aléatoires à des valeurs prédéfinies, on peut imaginer une copie en zone cache de l'ensemble des opérations demandées aux fonctionnalités cryptographiques etc.
Les CPU étant eux même proprios, on ne sait pas trop comment ils sont fait. D'après ton raisonnement il serait donc extrêmement dangereux de faire de la crypto avec.
Evidement je prefererais que le specs du TPM soient libres. Elles l'étaient à une époque avant que que la levée de boucliers TCPA=Lagrande=Palladium n'ait lieu. Maintenant je reste persuadé que sur un PC surveillé raisonnablement (pas d'accès physique facile sur la machine pour un Intrus, surveillance des émissions réseau), TPM apporte un vrai plus. Bien sur on peut imaginer qu'à la demande de certains gouvernements la puce TPM ne soit pas tout à fait aussi inviolable que çà, auquel cas il faut faire des partages de secrets et rajouter des protections par dessus TPM.
[^] # Re: Il y a bien une solution...
Posté par briaeros007 . Évalué à 3.
Les CPU ont comme but de stocker des clés, et d'éviter qu'elle puisse tomber entre n'importe quel main ?
Non.
On peut imaginer une backdoor dans les CPU qui permet de forcer les suites aléatoires à des valeurs prédéfinies
Ce qui se remarque tout de suite. "Tiens c'est marrant, mais les valeurs de mon sha-256 ne correspondent pas à la norme (cas d'un générateur pseudo aléatoire par ex)."
Sans compter que le CPU ne peut pas savoir si une suite de donnée c'est de l'aléas ou pas.
on peut imaginer une copie en zone cache de l'ensemble des opérations demandées aux fonctionnalités cryptographiques etc.
Fonctionnalitées qui connaissent pas les principaux CPU modernes (excepté le VIA). Et même si elles existent, tu peux toujours chiffrer en utilisant le CPU de façon "normal" sans recourir à leur instruction hard.
Après effectivement on peut imaginer que le fabriquant de la puce a une backdoor qui lui permet de passer au travers des 4 ou 5 mécanismes de sécurisation (nécessité d'ownership, nécessité de présence physique, validité des hashs etc.)
Euh pas vraiment besoin, vu que la norme dis "il faut que des clés non-migrables soit migrables".
Regardons donc la norme TPM (et plus TCPA)
:https://www.trustedcomputinggroup.org/specs/TPM/
Maintenance is different from backup/migration, because maintenance provides for the migration of both migratory and non-migratory data. Maintenance is an optional TPM function, but if a TPM enables maintenance, the maintenance capabilities in this specification are mandatory – no other migration capabilities shall be used. Maintenance necessarily involves the manufacturer of a Subsystem.Donc déjà on migre pas les clés "pour une sauvegarde", mais pour une maintenance.
Effectivement ils disent
The owner and users of TCG platforms need assurance that the data within protected storage is adequately protected against interception by third parties or the manufacturer.... en permettant une interception par le constructeur (ie puce tpm sur fpga).
et comment ils comptent mettre ça en place ?
Any maintenance process must have certain properties. Specifically, any migration to a replacement Subsystem must require collaboration between the Owner of the existingSubsystem and the manufacturer of the existing Subsystem. Further, the procedure must have adequate safeguards to prevent a non-migrational key being transferred to multiple
Subsystems.
Ah, on dis qu'on doit avoir une collaboration entre le possesseur et le constructeur, et qu'il doit y avoir des gardes fous... Sans plus de précisions!
Après effectivement on peut imaginer que le fabriquant de la puce a une backdoor qui lui permet de passer au travers des 4 ou 5 mécanismes de sécurisation
D'après le principes de conceptions : seulement 2 (dont 1 est automatique), le reste c'est du technique :
Any migration of non-migratory data protected by a Subsystem SHALL require the cooperation of both the Owner of that non-migratory data and the manufacturer of that Subsystem. That manufacturer SHALL NOT cooperate in a maintenance process unless the manufacturer is satisfied that non-migratory data will exist in exactly one Subsystem. A TPM SHALL NOT provide capabilities that support migration of non-migratory data unless those capabilities are described in the TCG specification.
Bref, comme je disais:
- on autorise un gouffre.
- on dis "mettez bien des barrières hein"
=> on dois avoir une entière confiance dans le constructeur.
Si le standard TPM est bien respecté, ok... mais ce ne sera pas la première fois qu'une entreprise respecte pas complètement un standard pour son propre intérêt... et la on parle de sécurité, pas de "bien afficher une page web" !
Bien sur on peut imaginer qu'à la demande de certains gouvernements la puce TPM ne soit pas tout à fait aussi inviolable que çà, auquel cas il faut faire des partages de secrets et rajouter des protections par dessus TPM.
Je pense que je peux te rappeler le gouvernement chinois, et ses méthodes.
Si la puce TPM "n'est pas si inviolables que ça", alors elle sert A RIEN.
Si elle est vraiment inviolable, alors elle représente un vrai plus.
Evidement je prefererais que le specs du TPM soient libres.
Pas tant les specs que des véritables certifications de sécurité.
Car si les specs ne sont pas respectée, c'est pas tellement plus cools.
J'ai demandé ça à asus (une vérification de la sécurité de leur puce par un labo spécialisé), on verras ce qu'ils répondent.
Pc : pour montrer que "on te cache tout" n'est vraiment pas une bonne politique de sécurité meme sur des puces, je t'invite à lire ce journal :
https://linuxfr.org//~BlueBird/25926.html
[^] # Re: Il y a bien une solution...
Posté par Jerome Herman . Évalué à 2.
Les CPU modernes possèdent leurs propres générateurs aléatoires. Si ceux-ci sont plombés, il y a moyen de faire des trucs rigolos.
Euh pas vraiment besoin, vu que la norme dis "il faut que des clés non-migrables soit migrables".
Les psecs insistent aussi lourdement sur le fait qu'avant de lancer uen procédure de migration ou de maintenance le TPM doit s'assurer de la présence physique de l'opérateur.
Ensuite les specs insistent aussi lourdement sur le fait que les clefs non migrables sont à usage strictement interne (en d'autres termes ce sont des clefs qui sont utilisés par le TPM pour le chiffrement en interne et elles ne doivent en aucun cas interagir avec des demandes de chiffrement ou du déchiffrement venant de l'extérieur)
Toutes les clefs utilisables par les profils TPM sont migrables.
Donc déjà on migre pas les clés "pour une sauvegarde", mais pour une maintenance.
C'est normal, il s'agit ici de réinitialiser un TPM et de le remettre en état de marche. C'est le seul cas ou l'on peut avoir besoin de toucher aux clefs non migrables.
on doit avoir une entière confiance dans le constructeur.
Ou alors on casse l'init du TPM en enregistrant un endorsement key bidon (possible depuis TPM 1.2) et là même le constructeur ne peut plus rien pour nous d'après les specs. Il suffit ensuite de s'arranger pour ne jamais avoir à migrer des clefs non migrables. Pour cela il suffit de ne jamais utiliser les mécanismes d'authentification par tiers de confiance du TPM. A noter qu'à l'heure actuelle aucun fabriquant de TPM n'a mis en place de système d'authentification par tiers, s'en passer ne devrait donc pas poser de problèmes.
Si la puce TPM "n'est pas si inviolables que ça", alors elle sert A RIEN.
La puce TPM est un coffre à données. En tant que paranoïaque de première plutôt que de sauvegarder la clef privée chiffrée, protégée par mot de passe des liaisons SSL de mon serveur apache sur le disque dur, je décide de la rentrer dans un block TPM. A noter qu'il faut TOUJOURS que je tape mon mot de passe, simplement je n'ai accès au contenu de la clef que si je suis dans un environnement certifié. Si le TPM fonctionne bien : personne n'a accès a ma clef car elle n'est pas sur disque dur et qu'elle n'est disponible que si la séquence de boot convient au TPM. Si le TPM a des back-doors je me retrouve alors dans la même situation que si j'avais sauvegardé ma clef sur disque dur. En cas d'accès à mon disque dur, je n'ai plus qu'à prier que mon mot de passe résiste aux attaques.
On peut imaginer que le nombre de gens ayant accès à la back door TPM est infiniment plus réduit que le nombre de gens ayant accès à la lecture du système de fichier EXT3 ou UFS. De fait je me sens plus en sécurité derrière un TPM. Maintenant je suis d'accord qu'il ne faut pas lui faire une confiance aveugle non plus.
[^] # Re: Il y a bien une solution...
Posté par briaeros007 . Évalué à 1.
Le chiffrement de dd ça existe... [c'était meme un peu le sujet de ce journal]
et qu'elle n'est disponible que si la séquence de boot convient au TPM.
Génial pour la rescue ça \o/
Et ton ordi crash (mb défaillante) , tu fais comment? un RMA ?
Si ton ordi crash avec un dd/svg chiffré ... ben tu change de pc, tu rentre le mdp / autre clé (smartcard ou autre) et hop tu à de nouveau accès à tout.
Voir, comme proposé autre part dans ce thread, de la crypto distribuée.
On peut imaginer que le nombre de gens ayant accès à la back door TPM est infiniment plus réduit que le nombre de gens ayant accès à la lecture du système de fichier EXT3 ou UFS.
Et infiniment plus élevé que ceux ayant accès à une backdoor d'un dd chiffrée sérieusement ou d'une smartcard conçu pour la sécu et vérifiée comme il se doit par des labos indépendants.
Pour moi, l'intérêt principal de TPM c'est de fournir un coprocesseur cryptographique , ie pouvoir chiffrer on the fly les dd en ayant presque aucune perte de perfs.
[^] # Re: Il y a bien une solution...
Posté par briaeros007 . Évalué à 1.
Quand je parlais de chiffrement du DD, je parlais bien entendu "avant que cette attaque soit révélé", ou alors du chiffrement du DD, mais non persistent (tu monte ton dd en chiffré, tu écris, tu démonte, tu attend n minutes pour que les clés n'existent plus. Sauf "storm" du gign à ce moment là... XD).
[^] # Re: Il y a bien une solution...
Posté par khivapia . Évalué à 5.
Note au sujet des générateurs aléatoires à usage cryptographique :
Un générateur aléatoire doit se composer de deux phases :
1) l'initialisation par un aléa fourni par un générateur physique (ex : quantique, agitation thermique, temps d'accès disque, agitation de la souris/frappe au clavier, etc.)
2) d'un retraitement algorithmique type chiffrement à flot qui va servir à fournir l'aléa à proprement parler.
La phase 2), comme tous les algorithmes de cryptographie, se doit d'être totalement transparente et publique.
En fournissant soi-même l'initialisation qui correspondrait au générateur physique, on peut facilement vérifier que les algorithmes sont correctement implémentés. En faisant des analyses statistiques rapides on peut se rendre compte que le générateur physique ne fournit pas des valeurs constantes, ou trop régulières.
Étant donné que l'aléa physique ne sert pas beaucoup (initialisation et quelques ajout de temps à autre, pas souvent), on s'assure ainsi de la sécurité du générateur.
En revanche, faire confiance à une solution clefs en mains est hasardeux : si on ne peut pas vérifier les algorithmes utilisés, rien ne garantit la sécurité du système en effet.
[^] # Re: Il y a bien une solution...
Posté par khivapia . Évalué à 3.
C'est un (faux) problème, qui a été résolu de plusieurs façons :
1) Chiffrer les clefs secrètes & privées utilisées avec la clef publique de quelqu'un d'autre en qui on a confiance, et ne lui donner le chiffré associé à déchiffrer qu'en cas de problème
2) La cryptographie distribuée, où on peut partager un secret entre plusieurs personnes sans qu'elles n'apprennent rien dessus, tout en étant capable de le reconstruire dès qu'on récupère les informations auprès de chacun
On peut ajouter que
1) on ne sait pas avec précision dire quand une puce va mourir -> il faut migrer les informations suffisamment tôt
2) une puce fonctionne en général parfaitement, ou bien elle est totalement morte (sauf analyse forensic poussée, ce qui n'est pas le cas ici vu qu'on s'intéresse à un fonctionnement normal et prévu) et donc une fois qu'elle donne des signes de faiblesse elle est en fait totalement morte
Et conclure qu'il faut sécuriser les clefs en amont exclusivement, les dupliquer uniquement au départ le cas échéant et insérer la clef de fonctionnement une bonne fois dans la puce jusqu'à sa mort/la fin de la validité de la clef, et protéger les copies proprement. On ne devrait jamais avoir à récupérer une clef d'une puce une fois celle-ci en fonctionnement.
[^] # Re: Il y a bien une solution...
Posté par khivapia . Évalué à 2.
À noter que ceci n'empêche pas une procédure "remise à zéro et insertion d'une nouvelle clef" (ou de l'ancienne si on voulait la récupérer). C'est juste le principe de vouloir pouvoir récupérer une clef qui est étrange et doit être mûrement réfléchi.
# Jolie démonstration mais...
Posté par Ellendhel (site web personnel) . Évalué à 2.
Si le malfaisant veut vraiment récupérer des données, il trouvera une possibilité moins ardue...
Reste toujours un rempart contre ce genre de chose : la protection physique du matériel, donc ne nous affolons pas.
[1] : http://www.schneier.com/blog/
[^] # Re: Jolie démonstration mais...
Posté par palm123 (site web personnel) . Évalué à 2.
Dans ce cas, voler un PC allumé est facile.
ウィズコロナ
[^] # Re: Jolie démonstration mais...
Posté par briaeros007 . Évalué à 1.
Bref rien de vraiment voyant.
Ensuite la copie de la ram, tu n'as pas besoin d'attendre les 4h, ca peut aller très vite (grosso modo la vitesse de ton support d'écriture)
[^] # Re: Jolie démonstration mais...
Posté par Ellendhel (site web personnel) . Évalué à 6.
Oui, c'est quelque chose dont j'ai déjà entendu parler, mais là on revient à un vieux problème élémentaire : l'utilisateur est un boulet qui ne prend pas en compte la sécurité informatique (ou qui n'a pas été sensibilisé sur le problème).
Le chiffrement des disques n'est pas une mesure permettant de pallier à cela (hélas).
[^] # Re: Jolie démonstration mais...
Posté par eon2004 . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.