Essuyez la RAM à l'arrêt pour empêcher une attaque de démarrage à froid

Mon système est chiffré à l'aide du chiffrement intégral du disque, c'est-à-dire que tout sauf / boot est chiffré à l'aide de dmcrypt / luks. Je suis préoccupé par les attaques de démarrage à froid , où les chercheurs ont démontré , que le contenu pouvait être extrait pendant environ 5 minutes .

Pouvez-vous fournir des instructions sur:

• comment déclencher kexec dans un nouveau noyau aux toutes dernières étapes du processus d'arrêt / redémarrage (pour assurer un démontage propre, pour éviter la corruption du système de fichiers, pour s'assurer que l'ancien noyau est écrasé)
• comment créer ce noyau, qui efface tout le bélier

ie pouvez-vous expliquer s'il vous plaît, comment faire de même sur Ubuntu?

Comment détecter l'arrêt? Comment démarrer le RAM Wipe? La RAM doit être effacée lorsque l'utilisateur clique sur "arrêt" ou s'il démarre un "script de panique".

Merci pour vos efforts!

Travail prioritaire:

• Présentation de Tails RAM Wipe
• Quelques informations supplémentaires sur la mise en œuvre de Tails RAM Wipe
• Présentation de Liberte Linux RAM Wipe
• Plus d'informations sur l'implémentation de Liberte Linux RAM Wipe
• memtest ne supprime pas tout
• Tester si RAM Wipe fonctionne
• Discussion sur la liste de diffusion de Tails
• Une autre discussion sur la liste de diffusion de Tails
• Rapport de bogue du noyau

Si vous voulez voir la fonctionnalité devenir réalité, votez sur Ubuntu Brainstorm!

http://brainstorm.ubuntu.com/idea/30076/

Si vous n'utilisez pas de la vieille RAM comme DDR2, 512 Mo ou 1024 Mo, alors ne vous inquiétez pas pour CBA.

Jetez un œil à la recherche originale ici (PDF).

Si vous le lisez attentivement, vous constaterez que seuls les DDR2 et les plus anciens sont sujets à cette attaque. La DDR3 perd trop de tension pour permettre la procédure de démontage et de gel du boîtier de l'ordinateur. Il suffit donc de débrancher la prise avant de répondre à la porte.

En outre, ce document confirme que la DDR3 n'est pas sensible à un CBA. Si en fait vous voulez vous sécuriser parce que vous avez de la RAM DDR2 alors activez dans le BIOS:

1. Démarrage automatique après une coupure de courant
2. Vérification de la RAM au démarrage

et faites la même chose qu'avec la DDR3, mais après avoir débranché la fiche, rebranchez-la. Votre ordinateur démarre et essuie le vérin en le vérifiant. S'il ne s'efface pas suffisamment efficacement, le processus de démarrage chargera à nouveau le système dans la RAM. Ce sera beaucoup trop rapide pour permettre l'ABC.

À partir du lien que vous avez fourni dans les commentaires:

Par conséquent, en conclusion, l'attaque de démarrage à froid ne doit pas être considérée comme la principale méthode d'acquisition de la mémoire d'un système informatique suspect. Au lieu de cela, d'autres techniques comprenant à la fois l'acquisition logicielle et matérielle (par exemple FireWire) doivent être tentées avant de lancer une attaque de démarrage à froid contre ledit système. Cependant, si une situation se produit où les techniques susmentionnées ne sont pas disponibles (c.-à-d. L'absence de connexion FireWire ou de console de connexion au système ou d'acquisition de mémoire à distance n'est pas possible) ou sont inefficaces, l'attaque de démarrage à froid peut être administrée en supposant que l'enquêteur comprend les deux. comment et où le problème peut survenir et tourner de travers.
Comme cette étude l'a montré, l'attaque de démarrage à froid ne peut pas être établie comme étant particulièrement solide et fiable, car dans la plupart des expériences menées ici, les clés de chiffrement résidant en mémoire n'ont pas pu être trouvées ou extraites de manière cohérente, alors qu'elles auraient dû l'être. La même chose peut également être dite pour les différentes chaînes et recherches de mots clés qui auraient dû générer beaucoup plus de chaînes et de mots clés que ceux trouvés pour la plupart des expériences. De plus, comme cela a été démontré, le simple fait de geler la mémoire d'un ordinateur ne garantit pas l'acquisition réussie de cette mémoire. D'autres facteurs et variables déjà examinés ont examiné de manière approfondie ces problèmes et leurs causes sous-jacentes. Donc,
Enfin, même une acquisition réussie qui n'a subi que peu ou pas de dégradation ne sera probablement pas considérée comme une preuve solide par un tribunal, du moins tant que la jurisprudence n'aura pas été établie et que l'intégrité de la mémoire acquise pourra être démontrée intacte à l'aide d'un son et méthodologie compréhensible. La recherche continue d'établir un moyen plus approprié et plus fiable d'acquérir la mémoire de l'ordinateur d'un suspect ...

De plus, si vous vérifiez les résultats de l'expérience, vous vous rendrez compte qu'ils ont réussi à extraire les clés AES uniquement dans le système 2 et 6 et qu'il s'agissait d'attaques de démarrage à chaud lorsque vous regardez les spécifications du système 2 - 1024 Mo de RAM 533 MHz - c'est vieux des trucs. L'autre système - système 6 avec 256 RAM / 128 RAM - je suppose que celui-ci est explicite.

C'est exactement pourquoi leur conclusion était:

La recherche continue d'établir un moyen plus approprié et plus fiable d'acquérir la mémoire de l'ordinateur d'un suspect ...

En fait, je pense que si vous avez des données très très importantes, vous devez non seulement utiliser Full Drive Encryption mais également les conserver dans un fichier crypté séparé. Chiffré avec des algorithmes en cascade et un mot de passe différent de celui utilisé lors du chiffrement du disque. Vous voulez un moyen sûr d'arrêter le PC? C'est ici:

1. Conserver les données sécurisées dans le fichier crypté de l'algorithme de cascade True Crypt
2. Utilisez Serpent
3. Créez un script pour gérer l'arrêt:

Pour les fenêtres:

truecrypt.exe /wipecache
shutdown -s -f -t 1

Pour Linux:

truecrypt /wipecache
shutdown -h now

L'effacement du cache garantit qu'aucune donnée vulnérable ne reste dans la RAM après l'arrêt. Si quelqu'un exécute Cold Boot Attack, il aura au mieux accès à votre système. Ils n'auront pas de données stockées dans un fichier chiffré séparément.

Peter AH Peterson à UCLA a écrit une technologie de preuve de concept et a développé la théorie pour faire fonctionner votre système en toute sécurité avec de la RAM cryptée, et la solution est expressément conçue pour empêcher les attaques de démarrage à froid. Le nom de son journal est Cryptkeeper. Je ne sais pas s'il rend le logiciel disponible au téléchargement ou s'il est possible de le concéder sous licence auprès de l'UCLA. Cependant, il est apparemment possible, au moins en principe, de concevoir un cryptosystème pour la RAM qui est sécurisé même si le contenu entier de la RAM est divulgué.

L'impact mesuré sur les performances de cette solution se situe entre 9% de frais généraux et un ralentissement d'un facteur 9 , selon le caractère «pathologique» du scénario. Le chiffre de 9% est cité comme s'appliquant à la navigation sur le Web avec Firefox, mais ils n'ont pas indiqué quel cas d'utilisation ralentirait les performances d'un facteur 9.

La solution de Peterson n'efface pas la RAM comme vous le suggérez. Il utilise plutôt un "mécanisme de masquage de clé sécurisé" pour empêcher la divulgation de la clé de déchiffrement juste en raison de l'obtention du contenu de la RAM. Je ne suis pas sûr des détails de la mise en œuvre, mais je suppose que cela est expliqué dans le document.

Le document a été publié en 2010.

Il est disponible à l'achat sur le site Internet ieeexplore de l'IEEE. Il est également disponible en téléchargement direct au format PDF sans frais à partir du site Web de quelqu'un; il est là-haut sur les résultats de recherche Google pour "cryptkeeper RAM" ... mais je ne sais pas combien de temps ce résultat restera là-haut.

J'ai été tenté d'en faire un commentaire plutôt qu'une réponse, car cette solution n'efface pas la RAM comme vous l'avez demandé. Cependant, je crois que si les recherches de Peterson sont techniquement correctes, cela aura le même effet pratique - ou peut-être même un "meilleur" effet - que d'essuyer la RAM. La raison en est qu'un attaquant physique qualifié pourrait probablement interrompre la tentative de votre programme système d'effacer la RAM s'il s'attendait à ce qu'une telle opération se produise - par exemple, retirer la batterie de l'unité ou maintenir enfoncé le bouton d'alimentation avant que l'opération ne puisse Achevée. La solution de Peterson est plus sécurisée car elle n'est pas basée sur une fenêtre de temps nécessaire dans laquelle l'ordinateur est autorisé à continuer d'exécuter des instructions afin de terminer l'effacement. Au lieu de cela, la mémoire est constamment protégé, même si le CPU lui-même est instantanément tué par un exploit technologique incroyable avant même que vous n'ayez la possibilité de réagir à l'attaquant.

Et par "exploit technologique incroyable", je veux dire quelque chose comme Stuxnet.

J'imagine que memtest86 serait assez bon pour effacer la RAM. J'ai toujours voulu essayer ce qui suit, mais je ne l'ai pas fait. Si je l'essaye, je le mettrai à jour.

Lisez la kexecpage de manuel . Et n'essayez pas kexecle .iso, mais vous devez déballer l'iso et accrocher le binaire amorçable. Sur le site memtest86 ci-dessus, vous pouvez simplement télécharger le binaire.

Vous devez d'abord utiliser une kexeccommande pour charger ce que vous démarrez.

Je pense donc que vous pouvez faire:

kexec -l {path-to-memtest86-bootable-binary} --append=console=ttyS0,115200n8

et lorsque vous êtes prêt à appuyer sur la gâchette:

kexec -e

Je pense (mais pourrait être faux) que le --append=console=ttyS0,115200n8memtest86 fonctionne sur le port série. Donc, si vous en avez un, vous pouvez vérifier qu'il fonctionne même s'il n'apparaît pas sur la sortie vidéo, ce qui est possible car memtest86 n'effectue pas l'initialisation vidéo. Tuer toutes les instances de X en cours d'exécution est probablement une bonne idée.

Le kexec-toolspaquet Debian (également disponible sur Ubuntu) le connecte dans les scripts d'arrêt, donc si vous modifiez, /etc/default/kexecvous pouvez dire au processus d'arrêt d'appeler kexecen dernier lieu au lieu de redémarrer. Autrement dit, si vous êtes intéressé par un arrêt propre.

En cas d'urgence, sync; kexec -ecela fonctionnerait.

Cependant, il est possible que certains chipsets, une fois initialisés, provoquent des blocages si certaines zones de mémoire sont adressées. Je ne sais pas comment cela fonctionnerait dans la pratique.

Un bon compromis si kexeccela ne fonctionne pas consiste à installer memtest86 sur votre chargeur de démarrage, à le mettre en tant qu'élément de démarrage par défaut et à avoir un délai de 1 seconde jusqu'au choix automatique (ou aucun délai et s'appuyer sur une touche pour faire apparaître le memu). Cela pourrait vous faire entrer dans memtest86 à partir d'une condition de "redémarrage" assez rapidement, mais pas instantanément.

Notez que cela ne tient pas compte de la RAM vidéo. Une solution pour cela consiste à configurer votre RAM vidéo en tant que périphérique de bloc , et la sortie /dev/randomvers le périphérique de bloc pour quelques itérations.

C'est une vieille question mais je pense que je peux y contribuer. Comme indiqué précédemment, un effacement de mémoire basé sur un logiciel n'est pas la meilleure solution, simplement parce que l'alimentation peut être coupée soudainement, de sorte que le logiciel d'effacement ne sera pas exécuté.

Je peux imaginer le meilleur scénario pour illustrer le problème: vous exploitez une entreprise illégale sur votre ordinateur à la maison. Un jour, l'alimentation électrique disparaît soudainement, puis une équipe du FBI prend d'assaut la porte de votre maison, vous arrête et un technicien nerd ouvre rapidement le boîtier de votre ordinateur et utilise à l'intérieur un gaz froid pour figer l'état de la mémoire pour en acheter le temps de faire une attaque de démarrage à froid.

Donc, la meilleure façon de résoudre ce problème est de rendre le boîtier de l'ordinateur plus sûr, en le rendant difficile à ouvrir (quelque chose comme un coffre-fort), ou même en détruisant la mémoire en chauffant la carte à l'aide d'une résistance alimentée par batterie, allumée par un sabotage commutateur dans le cas. Quelques secondes à des températures élevées peuvent détruire les données, voire détruire les puces, ce qui n'est pas un gros problème dans cette situation.

Le problème est que si votre ordinateur fonctionne et que l'écran est verrouillé. À ce stade, la clé AES est stockée dans la RAM et l'utilisateur est loin de l'ordinateur. Un intrus pourrait ouvrir le boîtier de l'ordinateur et retirer les modules de RAM, tout en les gardant sous tension et en les plaçant dans un appareil séparé qui lit leur contenu. Il n'est pas nécessaire d'arrêter le système ou de geler les modules avant l'extraction. La RAM n'est pas fiable pour contenir la clé AES, mais le cache du processeur l'est, comme la solution nommée TRESOR. Malheureusement, cela nécessite un ancien noyau Linux et une connaissance avancée de l'application de correctifs et de la compilation du noyau.

Désolé, mais vous êtes paranoïaque. Tout d'abord, comme d'autres utilisateurs l'ont indiqué, il semble que la Cold Boot Attack ne fonctionne que sur du matériel plus ancien.

Si vous pensez toujours que c'est une menace, l'essuyage n'est pas la solution.

La Cold Boot Attack implique:

• démarrage à froid de la machine
• démarrage d'un système d'exploitation léger pour récupérer les clés de chiffrement de la mémoire

Si quelqu'un réussit à effectuer le démarrage à froid, alors votre essuie-glace n'aura évidemment pas la possibilité de fonctionner. Il est donc inutile d'en installer un.

C'est le cas principal de l'attaque. Supposons maintenant que l'attaquant ne veuille pas redémarrer à froid le serveur en cours d'exécution (par exemple, car cela déclencherait une alerte de surveillance), mais il attend pour exécuter l'attaque dans les 5 'd'un arrêt net. Dans ce cas:

• Un essuie-glace RAM générique ne vous sera d'aucune utilité non plus. Étant donné que l'attaquant est supposé être physiquement présent pour mettre la machine sous tension et récupérer les clés, il peut également démarrer à froid la machine juste avant que l'essuie-glace ne démarre. (Des alertes de surveillance sont attendues à ce stade.)
• Un programme spécialisé qui efface d'abord l'emplacement exact des clés de chiffrement FS avant d'effacer le reste de la RAM (par exemple truecrypt /wipecachementionné par mnmnc) pourrait rendre le travail de l'attaquant plus difficile. Encore:
  • L'attaquant serait toujours en mesure de récupérer une partie du contenu de la RAM en ne laissant pas l'essuie-glace parcourir toute la RAM. Mais au moins la majeure partie des données sur le FS serait en sécurité.
  • La solution ne serait pas à 100% infaillible - cela rend seulement plus difficile pour l'attaquant de chronométrer le démarrage à froid.

Donc, si vous êtes vraiment inquiet de cette attaque, je vous suggère d'apprendre le kung-fu et de monter la garde à 5 'à côté de la machine chaque fois que vous l'éteignez. Ou peut-être utiliser un mot de passe de démarrage dans votre BIOS? Les deux mesures suggérées n'ont pas besoin d'être efficaces à 100%: les attaquants peuvent toujours vous battre et lire le mot de passe du BIOS depuis votre Mo en utilisant des moyens techniques. Vous avez juste besoin de les retarder de 5 'afin que la fenêtre temporelle d'attaque expire.

Enfin, si vous êtes inquiet à l'idée que quelqu'un exécute tout l'exploit à distance, vous êtes déjà très fort.