Le 30 juillet, un attaquant a vidé 1 196 adresses Bitcoin en 41 minutes. Un peu plus de 1 082 bitcoins, environ 70 millions de dollars. Aucune des victimes n'avait cliqué sur quoi que ce soit.

Elles avaient acheté un Coldcard, le portefeuille matériel de la société canadienne Coinkite, l'appareil que les puristes du bitcoin recommandent depuis des années précisément parce qu'il ne se connecte jamais à Internet.

Un portefeuille matériel fabrique une seed, la suite de mots dont dérivent toutes vos clés. Toute la sécurité repose sur un seul point : que cette suite soit réellement imprévisible. La puce embarque pour ça un générateur d'aléatoire physique.

En mars 2021, le firmware 4.0.0 a introduit une erreur d'intégration. Coldcard voulait désactiver le générateur intégré de MicroPython pour utiliser le sien, et a donc défini le paramètre MICROPY_HW_ENABLE_RNG à zéro. Sauf que la bibliothèque libngu vérifiait seulement si ce paramètre existait, pas la valeur qu'il portait. Il existait. Le test passait.

Pendant cinq ans, chaque tirage est donc passé par Yasmarang, un générateur pseudo-aléatoire non cryptographique dont l'état de départ venait de trois choses : l'identifiant 32 bits de la puce, un registre de minuterie et l'horloge interne. Rien de secret là-dedans, et plus la moindre entropie fraîche ensuite.

Les Mk3 se retrouvaient avec une quarantaine de bits d'imprévisibilité au lieu des 128 promis, les Mk4, Mk5 et Q avec 72. Pour ces derniers, l'ensemble des clés que l'appareil pouvait produire tombait à quelques milliards de combinaisons.

À ce niveau, il n'y a plus rien à pirater. L'attaquant génère les seeds candidates sur sa propre machine, calcule les adresses que chacune produirait, et les compare à la blockchain, publique par construction. Quand une adresse contient des fonds, il tient la clé. Aucun appareil n'a jamais été touché.

Coinkite a publié un firmware d'urgence le 31 juillet pour tous les modèles concernés. Attention au contresens qui coûte cher : la mise à jour ne répare pas une seed déjà créée. Il faut en générer une nouvelle et y déplacer les fonds. Les configurations multisignature, où le Coldcard n'est qu'une clé parmi plusieurs, sont largement épargnées.

Rodolfo Novak, le patron de Coinkite, a écrit qu'il était désolé et dévasté, et assume. Il avance aussi que l'attaquant a peut-être déniché la faille avec une IA, sans en apporter la preuve, tout en reconnaissant que sa propre revue de code assistée par IA était passée à côté.

Cinq ans qu'un zéro traînait dans un fichier de configuration, sur l'appareil vendu comme le plus sûr du marché. Le pire endroit possible pour ce genre d'oubli.

Source : The Hacker News

Si vous avez déjà envoyé un lien à usage unique qui est arrivé mort chez votre collègue, c'est probablement la prévisualisation de la messagerie qui a ouvert le lien en premier et qui a cramé le secret accompagnant le lien.

La bonne nouvelle c'est que Oğuzhan Karacabay vient de publier une grosse mise à jour d' OTI , son service open source auto-hébergeable qui génère des liens de partage consultables une seule fois, avec chiffrement dans le navigateur.

Vous collez un mot de passe, une clé d'API ou un bout de config dans OTI, le navigateur chiffre, le serveur lui ne stocke que du charabia, et le destinataire reçoit une jolie URL qui ne fonctionnera bien qu'une fois.

Ce qui change, c'est que le lien ne meurt plus tout seul. En chargeant la page, votre destinataire voit un compte à rebours et un bouton "Decrypt Message", rien d'autre. Du coup, tant que personne ne clique, le message continue son roupillon.

Comme ça, un bot qui déroule les URLs pour fabriquer une jolie vignette repart bredouille. Après si c'est un vrai scanner de sécurité qui charge vraiment la page dans un navigateur automatisé, vous ne pourrez pas éviter le problème.

L'autre nouveauté dans OTI c'est à la création d'un nouveau lien. Le service vous génère en fait 2 liens. Il y a celui que vous envoyez et un second que vous gardez pour vous. Ce dernier vous permettra de consulter l'état du message sans jamais afficher son contenu.

Côté crypto, le contenu est chiffré en AES-256-GCM via WebCrypto, et cette clé AES est elle-même emballée dans une paire RSA-2048 générée dans votre navigateur. La clé privée voyage dans le fragment de l'URL, la partie après le #, que les navigateurs n'envoient jamais au serveur.

Le principe zero-knowledge utilisé par OTI est quasi le même que celui de PrivateBin ou d' Enclosed où la clé ne quitte jamais le navigateur.

Par contre, ça donne des liens obèses puisque le mien faisait 1825 caractères, dont 1728 rien que pour le fragment, et c'est déjà compressé en zlib. Bon courage donc pour le dicter au téléphone ^^ (il y a un QR code, heureusement !)

Le reste, c'est du confort... Fichiers .txt jusqu'à 100 Ko validés dans le navigateur avant chiffrement, mot de passe optionnel par-dessus, expiration au choix entre 5 minutes et 7 jours, limitation de débit via Redis et une tâche planifiée qui balaie les secrets périmés toutes les 30 minutes.

Pour l'héberger, c'est de l'AdonisJS 6 en TypeScript avec Dockerfile, docker-compose et migrations fournis, en licence MIT. Redis peut céder sa place au limiteur en mémoire si vous montez juste un petit truc perso.

Notez quand même que pour le moment, le projet n'a pas été audité et est maintenu par un gars tout seul, donc évitez de l'utiliser pour des secrets d'État.

La démo est en ligne si vous voulez essayer avant d'installer.

Ryan Walker, le gars derrière Rootkit Labs, vient de sortir un truc que je trouve super malin. C'est une clé USB, baptisée Phantomdrive, qui se déverrouille en écrivant dans un simple fichier texte stocké dessus. Vous la branchez, vous ouvrez un bloc-notes, vous tapez password:votremotdepasse dans un fichier que vous enregistrez à la racine, et hop, une partition cachée apparaît.

Et y'a pas de logiciel pour faire tourner ça ! Au branchement, votre système voit une clé de 8 Go tout ce qu'il y a de plus banale, et il est incapable de deviner qu'il existe le moindre octet au-delà. Le firmware, lui, n'a aucune notion de système de fichiers, et se contente d'intercepter les commandes USB brutes (les WRITE10 et READ10 que votre ordi envoie pour lire et écrire des blocs) et de les traduire pour la carte SD planquée à l'intérieur.

Et quand il repère le motif password: qui passe, il dérive alors une clé, démonte la partition visible et remonte la seconde, chiffrée en AES-256, le tout en trois secondes chrono.

L'idée derrière ce bricolage, c'est le modèle de menace que ça vient contrer. Par exemple, un volume caché VeraCrypt vous sauve si on vous force à donner votre mot de passe, car vous pouvez mettre en place 2 niveaux de mot de passe. Le premier est un leurre qui ne révèle pas grand-chose et le second ouvre la vraie partition avec tous vos secrets. Mais bon, tout le monde connaît le truc et le simple fait d'avoir un conteneur chiffré sur vous suffit à vous faire passer pour un suspect. Phantomdrive répond donc à ça, puisque rien n'est détectable donc il n'y a rien à vous reprocher... Exactement ce qui se joue aux frontières, où les appareils se font fouiller sans se gêner .

Évidemment, cette invisibilité tient uniquement face à une inspection logicielle, et pas face à un labo qui démonterait la clé. Ryan le reconnaît lui-même, on peut retrouver la carte SD en cassant le boîtier, même s'il l'a noyée dans l'époxy et que la partition cachée, elle, restera chiffrée quoiqu'il arrive.

Sauf que si on dessoude la puce et qu'on lit la mémoire brute, on tombera forcément sur bien plus que les 8 Go annoncés, à cause de ce gros bloc de données illisibles qui trahit l'existence de la partition cachée. La déniabilité joue donc contre un contrôle "pressé" mais pas contre un forensique très motivé. Autre limite rigolote, si vos vraies données contiennent par hasard la chaîne password:, la clé peut alors se déverrouiller toute seule au mauvais moment.

Et surtout, le projet n'a pas été audité. C'est du hardware expérimental fait par une seule personne, sous licence MIT certes, mais pas un coffre-fort certifié. C'est rigolo pour bidouiller, mais pas encore pour lui confier de vrais secrets.

Côté matos, Ryan a utilisé une puce que je ne connaissais pas, la CH569, qui embarque de l'USB3 et un bloc de chiffrement AES matériel. Les débits restent modestes mais suffisants pour de l'usage courant, autour de 9 Mo/s en écriture et 20 Mo/s en lecture. Sachez aussi que s'il est parti sur une carte SD plutôt que de l'eMMC, c'est parce que cette dernière est devenue hors de prix à cause de la flambée des mémoires dopées par l'IA.

Hé oui, même les bidouilleurs hardware se prennent la bulle de l'IA dans les pattes. Voilà, tout est sur GitHub , électronique, mécanique et firmware compris, avec une page de précommande si vous préférez ne pas sortir le fer à souder.

Source : Rootkit Labs

Le 26 février dernier, lors d'une réunion d'Austin Hackers Anonymous au Texas, le chercheur Andreas Makris a fait la démo d'un outil qui permet de générer de faux firmwares Unitree, que le robot avale sans broncher comme s'ils sortaient de l'usine de Hangzhou...

Car oui, Mesdames et Messieurs, les robots Unitree ne sont pas capables de déterminer si le firmware avec lequel ils se mettent à jour a été créé par Unitree ou par quelqu'un d'autre.

C'est ouf, non ? Le problème en fait, c'est que les paquets de mise à jour d'Unitree, c'est-à-dire les fichiers .upk qu'un Go2 ou un G1 télécharge tout seul, sont chiffrés avec TEA, un algo hyper minimaliste sorti de Cambridge en 1994.

La clé de chiffrement issue de cet algorithme se calcule ensuite à partir de trois constantes planquées dans le binaire du robot, + une graine aléatoire qui est stockée dans le paquet lui-même. Hop, comme ça vous avez la clé... Tout le monde a la clé, en fait !

Les trois constantes, en clair dans la doc de l'outil.

Et comme TEA est un algo symétrique, la clé qui déchiffre est aussi celle qui chiffre. Unitree s'en sert pour cacher le contenu de ses mises à jour, sauf que le robot, lui, comme il a été programmé avec les pieds, il en déduit que le paquet est légitime. C'est con, hein ? Une vraie signature, avec une clé privée gardée au chaud chez le fabricant, rendrait la contrefaçon impossible même en connaissant tout le reste.

Alors avant que vous ne débranchiez votre robot, je tiens à préciser un truc que Makris dit lui-même dans son dépôt : il n'existe pas de moyen public de livrer un firmware maison au robot. En effet, le canal de mise à jour passe par MQTT et n'accepte pas les paquets persos.

Cette faille a une belle note de 7,8 sur 10 mais exige un accès local et une action du propriétaire. Donc rassurez-vous, personne ne va reflasher votre chien robot qui fait des petits tours dans votre usine depuis un van garé sur le parking.

Le scénario réaliste, c'est plutôt le firmware véreux qu'on vous refile via un prestataire qui "met à jour" votre flotte, ou la clé USB d'un labo partenaire. Vous l'installez, votre robot le valide et vous n'avez aucun moyen de vérifier qu'il sort bien de chez Unitree. Bref, pour du matériel qu'on retrouve dans des labos de recherche et sur des sites industriels, c'est pas terrible !

Les firmwares décortiqués couvrent les gammes Go2 et G1, du Go2 Air au G1 Edu+, plus les modules moteur. Le NVD (National Vulnerability Database), lui, considère que toute l'offre actuelle du constructeur est concernée et surtout gag, y'a pas de correctif !!

On est quand même près de 5 mois après la publication, et y'a toujours rien. Je pense quand même qu'Unitree devrait revoir ses priorités et surtout revoir complètement la façon dont ils protègent leurs mises à jour.

De son côté, Makris n'a pas prévenu le fabricant. C'est pas un oubli, mais un choix car comme il l'explique dans son avis de publication , Unitree a montré une certaine hostilité face aux communications de divulgation. Donc, autant dire que le divorce est acté entre les chercheurs et l'entreprise chinoise.

Du coup ça nous fait quand même un quatrième épisode sur tout ce bordel. Le hack Bluetooth en 1 minute dont je vous parlais en décembre , les deux CVE sur le Go2 que je vous ai remis en mars , le backdoor vers un cloud chinois que Benn Jordan a popularisé en mai, et maintenant les mises à jour.

À l'époque, je me souviens que Benn Jordan conseillait carrément de ne plus jamais toucher au firmware pour garder l'accès root et surveiller ce que le robot envoie, sauf qu'on sait maintenant qu'une mise à jour officielle ne prouve rien, et que chacun peut forger la sienne. Breeeeef... pour du matos vendu à des labos et des industriels, je trouve ça vraiment pas sérieux.

Merci à Sammy pour le tuyau !

Source

314 députés européens ont voté jeudi pour enterrer Chat Control et 276 ont voté pour le garder.

Et c'est quand même passé OKLM.

Et oui, pas la peine de vous frotter les yeux, je vais vous expliquer tout ça. En seconde lecture, le Parlement a besoin d'une majorité absolue de ses membres pour rejeter un texte du Conseil, soit 360 voix. Et cette "majorité", c'est pas une majorité des présents dans l'hémicycle, mais une majorité d'élus, absents compris.

Du coup les 314 sont tombés à 46 voix du compte, 17 députés se sont abstenus, et 112 qui n'ont pas pris part au vote ont terminé le boulot à leur place puisque leur chaise vide valait pour un oui.

Je rappelle quand même que ces 112 là touchent 359 euros d'indemnité journalière, et qu'il leur suffit de signer un registre le matin pour encaisser leur thune. Je pense que si ces feignasses d'absentéistes faisaient correctement leur boulot en étant là, au moins pour les choses importantes, on n'aurait pas des problèmes comme ça qui impactent tous les citoyens européens. Ils ne méritent vraiment ni leur poste, ni leurs indemnités de merde.

Maintenant que ça c'est dit, je vous propose qu'on fasse une petite séance de cohérence cardiaque tous ensemble pour se détendre, car y'a quand même un peu de positif dans cette seconde lecture.

Le texte voté, c'est Chat Control 1.0, c'est à dire la dérogation qui autorise les plateformes à scanner volontairement les messages de leurs utilisateurs. Ce n'est donc pas un scan obligatoire, ni des ordres de détection, ni de la vérification d'âge qui vous ferait montrer vos papiers pour ouvrir un compte sur une messagerie. Tout ça, c'est prévu dans Chat Control 2.0, un règlement séparé, qui n'est toujours pas adopté, mais qui revient à l'automne !!

L'autre bonne nouvelle dans notre malheur, c'est que les députés (ceux qui bossent hein, pas les autres paresseux) ont arraché un amendement qui exclut du texte tout ce qui est chiffré de bout en bout. Donc Signal, WhatsApp, iMessage, et les salons Matrix que vous avez pris soin de chiffrer vont passer entre les mailles du filet de Big Brother.

Restent quand même Gmail , Outlook, Discord, Snapchat, iCloud Mail, les publications et les groupes Facebook, et tout ce qui transite en clair sur des serveurs... C'est-à-dire là où vous comme moi, écrivons la plupart de nos trucs.

Cette dérogation "temporaire", Chat Control 1.0, est née en 2021 et a expiré le 3 avril dernier, quand le Parlement avait refusé de la prolonger. Alors le Conseil l'a renvoyée au Parlement et ils veulent maintenant qu'elle coure jusqu'au 3 avril 2028. Ça c'est du bon gros provisoire reconduit à coups de 2 ans... Ce genre de provisoire, moi j'appelle ça du permanent mais bon, bref...

Et le pire, les amis, c'est que ce scan qu'on vous vend comme une protection contre tous les criminels et autres pédophiles nazis terroristes NE FONCTIONNE PAS. Et c'est pas moi qui le dis !

En effet 807 chercheurs et cryptographes dans 37 pays ont signé une lettre ouverte, la quatrième depuis 2023, où ils écrivent qu'il est "tout simplement impossible de détecter, avec un niveau de précision acceptable, les contenus pédopornographiques connus et nouveaux pour des centaines de millions d'utilisateurs.".

C'est donc simplement pas faisable à cette échelle, avec une suffisance de précision. Et les chiffres leur donnent raison puisque quand l'Irish Council for Civil Liberties a épluché les signalements automatiques atterris chez la police irlandaise, à peine 20 % étaient réellement des contenus pédocriminels, et moins de 10 % étaient exploitables par un enquêteur.

Le reste, bah c'est du bruit... Ce sont vos photos de vacances, vos consultations médicales, vos ados qui s'écrivent entre eux. Et chaque faux positif, c'est un inconnu payé pour regarder vos photos à la plage ou vos sextapes. Sans parler des erreurs humaines ou IA qui viendront se glisser là-dedans et qui vous enverront en zonzon pour pédocriminalité pour une photo de Sphinx (les chats sans poil, vous savez) ou autre...

Quatorze pointures de la crypto, dont Ron Rivest, Whitfield Diffie et Bruce Schneier, ont posé le diagnostic dans un document, Bugs in our Pockets où ils expliquent que le scan côté client "ne garantit pas une prévention efficace de la criminalité et n'empêche pas la surveillance".

Et c'est à nous de payer toutes ces conneries avec notre vie privée.

Puis j'sais pas si vous vous souvenez, mais Apple s'y est cassé les dents en public. Ils avaient annoncé un système de détection en août 2021, et des chercheurs ont conçu dans la foulée, des collisions de hash (deux images différentes, même empreinte), qui a poussé Apple à enterrer le projet en décembre 2022 parce qu'ils se sont rendu compte que ce n'était pas suffisamment fiable et efficace.

Reste la question qui nous intéresse tous : Comment se protéger de ce viol de notre vie privée ?

D'abord, débarrassez-vous de deux illusions. Votre VPN ne sert à rien contre ce truc, parce qu'il chiffre le tuyau, mais pas votre message au moment où vos doigts le tapent. Et votre navigation privée non plus.

Le scan côté client en fait, c'est un mouchard qui lit sur votre appareil, avant le chiffrement et ni le VPN ni le chiffrement de bout en bout ne peuvent faire quoi que ce soit si l'application ou le système d'exploitation coopère. Et une app dont vous ne pouvez pas lire le code, bah vous n'avez aucun moyen de savoir ce qu'elle regarde avant d'envoyer.

Quitter Gmail, c'est vrai, tout le monde y pense. Pour ma part, c'est fait depuis très longtemps, mais c'est vrai qu'abandonner des années et des années de mails, de factures, de photos, etc., tout ce qu'on a reçu, il n'y a personne qui est très motivé pour ça. Alors il y a bien sûr des possibilités de transférer, mais c'est toujours un peu la galère.

Toutefois, j'ai une bonne nouvelle pour vous. Il y a Tuta qui vient de dégainer One-Click Migration , un outil de migration automatique de votre ancienne boîte, pour l'instant en bêta fermée.

Si vous débarquez, Tuta c'est anciennement TutaNota et c'est une messagerie allemande qui chiffre tout de bout en bout par défaut. Et sa nouvelle fonction permet de lier votre ancienne boîte mail, donc ça peut être Gmail, Outlook, tout ce qui cause en IMAP. Et une fois que c'est fait, tout l'historique de vos e-mails se déverse dans Tutamail, avec même la structure des dossiers qui est répliquée à l'identique.

Et ce n'est pas juste un simple import puisque la synchro tourne ensuite en continu à sens unique. Ça veut dire qu'un nouveau mail qui arrive dans votre Gmail atterrira aussi dans votre nouvelle boîte tuta. Tant que vous n'avez pas coupé ce lien ou fermé l'ancien compte, les mails seront acheminés de manière tout à fait transparente. Et vous pourrez les ranger par exemple dans un dossier dédié type "Archives" si vous préférez repartir vraiment sur un compte propre.

Maintenant côté sécurité, c'est comme d'hab avec Tuta, c'est du solide. Le chiffrement se fait directement sur votre ordinateur avant même que vos vieux e-mails ne partent chez eux sur leur serveur. Donc comme ça, il n'y a rien qui se balade en clair sur les serveurs. Tout ce que vous faites chez TUTA est chiffré en respectant des principes de zéro knowledge.

Notez que Proton propose déjà son Easy Switch, avec le même type de connexion continue pour Gmail, mais comme Tuta supporte l'IMAP au complet, ils sont compatibles avec n'importe quel fournisseur. C'est d'ailleurs assez marrant quand on sait que Tuta ne propose pas d'IMAP, de POP3 et ce genre de choses nativement sur ses services... Il faut soit passer par une app dédiée, soit passer par le site web pour accéder à ses emails sur Tuta.

Voilà pour la bonne nouvelle, donc en attendant si l'envie de larguer Gmail comme une vieille chaussette vous démange, sachez que j'ai déjà fait le tour des messageries sécurisées qui tiennent la route . Et pour les impatients, la bonne vieille migration IMAP à la main fonctionne toujours. Ah et en même temps que cette annonce, Tuta en a aussi profité pour annoncer l'arrivée de son application native Tuta Drive sur iOS et Android, pour ceux qui veulent aussi déménager leurs fichiers.

Voilà, la dernière bonne excuse pour rester chez Google vient de sauter ! Je vais surveiller ça de près.

Votre Nextcloud sait tout de vous. L'admin du serveur (vous, ou pire, quelqu'un d'autre) peut ouvrir n'importe quel fichier stocké dessus, parce que le chiffrement de bout en bout reste une option planquée dans un plugin.

C'est pourquoi Hoodik , un projet de Tibor Hudik, prend le problème à l'envers. Parce que chez lui, le chiffrement, ce n'est pas une case à cocher, c'est l'architecture au complet.

Grâce à sa solution, vos fichiers sont chiffrés dans votre navigateur, avant même de partir sur le réseau, et à aucun moment le serveur ne voit vos fichiers en clair, ni ne reçoit les clés de chiffrement.

Votre clé privée ne quitte donc pas votre machine, et comme ça, même une intrusion sur le serveur ou un vol ne livrera jamais vos fichiers en clair.

L'interface web, sobre et sans fioritures

Et là où beaucoup d'outils chiffrés deviennent pénibles à l'usage, celui-ci garde les trucs du quotidien super pratiques. Y'a du partage entre comptes avec des rôles (lecture, édition, co-propriétaire), des notes Markdown chiffrées avec historique de versions, et même des aperçus photo et vidéo sans rien déchiffrer côté serveur, HEIC de l'iPhone compris.

La recherche fonctionne aussi alors que le serveur ne voit rien… En fait, votre navigateur découpe les noms de fichiers en petits morceaux, les hashe, et le serveur ne compare que ces empreintes, et jamais de texte en clair. Quant au partage public, la clé de déchiffrement voyage dans le fragment de l'URL, cette partie après le # que votre navigateur n'envoie jamais au serveur.

Au niveau de la crypto, le boulot se divise en deux, il y a d'un côté une paire RSA 2048 qui ne sert qu'à faire circuler les clés, et de l'autre, AEGIS-128L qui chiffre vos données, calculé en direct par le navigateur grâce à WebAssembly (du code quasi natif quoi...). Et avant que vous leviez un sourcil sur ce cipher au nom de Pokémon, AEGIS-128L est finaliste de CAESAR, un concours international de crypto, et est en cours de standardisation à l'IETF. Vous pouvez par exemple le retrouver implémenté dans libsodium . C'est du sérieux, donc.

L'autre bonne surprise, c'est le poids plume de l'app. Le serveur est écrit en Rust (Actix-web) avec un front en Vue 3 et il tourne autour de 20 Mo de RAM au repos, alors que votre Nextcloud réclame ses 200 à 500 Mo pour afficher 3 photos de vacances.

Hoodik est dispo sous la forme d'une image docker pour AMD64 et ARM donc vous pouvez l'installer sur n'importe quoi, un Raspberry Pi , un vieux NAS, un vieux PC, ce que vous voulez...

docker run --name hoodik -d \
-e DATA_DIR='/data' \
-e APP_URL='https://my-app.example.com' \
--volume "$(pwd)/data:/data" \
-p 5443:5443 \
hudik/hoodik:latest

Pour vos téléphones, il y a également des applications Android et iOS dont le chiffrement tourne en Rust compilé dans l'appli elle-même (et pas une page web déguisée en application, on a assez donné...). Par contre elles passent en payant après 30 jours d'essai, sans tarif affiché publiquement sur le site... c'est le modèle économique du projet.

Autrement, c'est sous licence Creative Commons, le code est dispo sur GitHub , mais par contre notez bien que l'usage commercial est interdit sans l'accord de l'éditeur. Ajoutez à ça un projet encore jeune et aucun audit de sécurité indépendant publié, contrairement à Cryptomator qui est en GPLv3 et audité. Après ma comparaison s'arrête là par contre, parce que Cryptomator chiffre par-dessus un cloud existant alors que Hoodik c'est vous qui l'hébergez.

Quoi qu'il en soit, pour votre dossier de photos de famille, vos sauvegardes ou vos documents sensibles, le compromis se défend largement. Et si vous voulez explorer d'autres pistes, jetez un œil à OpenCloud pour du Nextcloud-like allégé, ou à Picocrypt pour chiffrer des fichiers à l'unité.

Allez, y'a plus qu'à ressusciter le vieux NAS qui prend la poussière et suivre le guide d'installation pour lancer votre docker compose up.

Votre nuage perso vous attend !

Merci à Camille Roux pour le lien !

Snif, snif, macOS 28 ne lira plus vos disques chiffrés en Mac OS Étendu . C'est écrit dans un document de support Apple publié le 7 juillet, alors si vous stockiez là-dessus vos photos de 2014, vos factures, votre mémoire de fac ou une sauvegarde Time Machine chiffrée de l'ancienne époque, bah c'est grave le moment de vous en occuper.

Pas de panique cela dit, seul le chiffrement dégage. Un volume HFS+ non chiffré restera donc lisible sous macOS 28 et après. Ce qui part à la benne, c'est surtout CoreStorage, la couche qui chiffre ces volumes... Et c'est aussi elle qui fait tourner les Fusion Drives avec lesquels j'aimais bien m'amuser à l'époque. Mais hormis ça, rien ne change.

Et vu qu'APFS est le format par défaut depuis High Sierra en 2017, les disques concernés ont, pour la plupart, grosso modo 9 ans au compteur, donc ce sont des disques d'archives que vous ne branchez jamais j'imagine... jusqu'au jour où vous en avez vraiment besoin évidemment !

Alors pour vérifier si vous êtes concerné, ouvrez l'Utilitaire de disque et regardez le libellé sous le nom de vos volumes externes. S'il affiche "CoreStorage Logical Volume" avec la mention "Encrypted", c'est lui. Et si vous êtes sous macOS 26, le système peut aussi vous envoyer une notification quand il détecte un disque qui ne passera pas le cap. Même si ça fait chier, c'est quand même assez réglo de la part d'Apple de prévenir 1 an à l'avance.

Côté solutions, Apple vous laisse 2 portes de sortie. La douce d'abord... Vous faites un clic droit sur le volume dans le Finder pour le déchiffrer, et si le cœur vous en dit, vous le convertissez ensuite en APFS sans perdre le moindre fichier. Ou alors la radicale ensuite où vous reformatez le volume direct en APFS. Attention hein, ça efface tout, et définitivement donc on sauvegarde bien avant de jouer à ça, les amis ^^.

Apple prévient aussi que le déchiffrement prend beaucoup de temps, spécialement si le volume est gros. Du coup lancez la machine avant d'aller vous coucher, et vous pourrez ensuite faire un petit diskutil cs list dans le Terminal pour savoir où ça en est !

Malheureusement, la méthode douce, vous pouvez l'oublier pour les disques de sauvegarde Time Machine chiffrés. Howard Oakley en parlait déjà sur Eclectic Light Company 3 semaines avant que les gros sites américains ne captent le truc et il a expliqué pourquoi dans son article. En fait, ces vieilles sauvegardes s'appuient sur des liens en dur de répertoires, et c'est un mécanisme qu'APFS ne sait tout simplement pas reproduire.

Du coup, ces sauvegardes-là, c'est impossible de les convertir, donc... il faudra repartir de zéro avec une sauvegarde toute neuve. Rassurez-vous, vos fichiers actuels ne craignent rien. Par contre, tout votre historique de versions restera coincé sur le vieux disque, que vous pourrez encore lire sous macOS 26 et 27, et après, ce sera terminé.

Donc si vous êtes motivé (et avez-vous bien le choix ?), vous branchez vos vieux disques, vous faites des backups, vous checkez le format, vous déchiffrez ou reformatez ce qu'il faut puis vous relancez une sauvegarde propre, que vous pouvez d'ailleurs accélérer avec cette astuce . Allez, un petit week-end là-dessus à le laisser tourner et c'est plié !

Bref, prenez 10 minutes maintenant, plutôt que de vous retrouver dans 1 an devant un disque qui refusera de répondre. Votre moi du futur vous dira merci !!

Source

Vous branchez une clé USB sur un PC, vous démarrez dessus, et le temps de vous servir un petit café, hop, tout le contenu de la mémoire vive est recopié sur la clé. Le rêve pour les gens qui font du forensic, car dans la RAM on trouve des mots de passe, des clés de chiffrement et tout ce qui traîne. De quoi choper de sérieux indices !

Parce que oui, si vous pensiez être bien tranquille avec votre disque chiffré grâce à BitLocker, FileVault ou LUKS, sachez que la clé de déchiffrement se balade en clair dans la RAM. Pas la peine de casser de la crypto quand il suffit d'aller cueillir la clé là où elle traîne. C'est cet angle mort qu' ElcomSoft exploitait déjà en 2012 pour cracker TrueCrypt et BitLocker .

Sauf que pour aller cueillir cette clé, encore faut-il que la machine soit allumée, non ?

Eh bien pas forcément car contrairement à ce qu'on croit, la RAM ne s'efface pas d'un coup quand on coupe le courant.

Hé oui, les données restent lisibles plusieurs secondes, voire une minute, ce qui est largement suffisant pour récupérer des infos importantes. Et si vous refroidissez les barrettes (par exemple jusqu'à -60°C avec de l'azote liquide), le contenu peut tenir plusieurs heures !!

Ce phénomène n'a rien de neuf. On appelle ça une cold boot attack, et ce sont des chercheurs de Princeton qui l'ont mise en lumière dès 2008, en révélant un truc totalement contre-intuitif : une mémoire vive censée se vider dès qu'on l'éteint, garde en réalité ses secrets bien après.

Alors on va me dire que tout ça, c'est mitigé depuis des lustres : Le scrubbing mémoire au boot, où le firmware écrase la RAM au démarrage, les clés planquées dans les registres du CPU façon TRESOR, le chiffrement mémoire chez Intel et AMD, les barrettes carrément soudées à la carte mère... les parades existent, c'est vrai. Sauf qu'en 2018, deux chercheurs de F-Secure ont remis une pièce dans la machine en montrant comment désactiver ce fameux scrubbing sur quasiment tous les ordi portables modernes, Dell, Lenovo et même les Mac.

Et c'est là qu'arrive BareMetal RAM Dumper, un outil signé pIat0n qui rejoue justement cette vieille attaque de 2008. Le truc tient dans 5 Ko d'assembleur x86 et démarre directement sur le BIOS en mode legacy, avant de basculer en unreal mode pour aller taper dans toute la mémoire au-dessus de 1 Mo.

La récupération totale ne dépassera pas 4 Go par contre, car l'unreal mode ne grimpe pas plus haut, mais en général c'est bien suffisant pour repêcher quelques clés d'accès. Et surtout, ça fait gagner un temps fou aux gens qui font du forensic : plus besoin d'un labo dédié, une clé USB et le tour est joué. Ça rejoint donc la longue liste des façons d'ouvrir un disque soi-disant blindé, comme BitPixie qui déverrouille BitLocker en cinq minutes .

Bref, c'est aussi une bonne piqûre de rappel qu'un chiffrement ne protège vraiment vos données que quand la machine est éteinte pour de bon. Le code est sur GitHub sous licence AGPL !