Vue lecture

Protégez vos clés SSH avec Touch ID sur macOS

Vous utilisez probablement des clés SSH pour vous connecter à vos serveurs et vous savez aussi qu'elles sont stockées sur votre disque, bien au chaud dans ~/.ssh/, accessibles à n'importe quel malware qui passerait par là. Pas très rassurant quand on y pense...

Mais bonne nouvelle les amis ! Sur macOS, il existe une fonctionnalité méconnue qui permet de stocker des clés cryptographiques directement dans le Secure Enclave de votre Mac, et de les utiliser pour SSH. Du coup, la donnée de la clé privée est conçue pour ne pas être exportable, reste enfermée dans cette puce dédiée, et les opérations de signature peuvent être protégées par Touch ID selon la configuration choisie. Arian van Putten , un chercheur indépendant, a documenté cette fonction qui est pourtant native dans macOS.

Le principe c'est que macOS expose une bibliothèque (/usr/lib/ssh-keychain.dylib) qui permet à OpenSSH d'interfacer avec le Secure Enclave via l'API CryptoTokenKit d'Apple. C'est un peu comme avoir une YubiKey intégrée dans votre Mac, sauf que vous n'avez rien à acheter.

Pour créer une identité protégée par le Secure Enclave, y'a une commande un peu obscure :

sc_auth create-ctk-identity -l ssh -k p-256-ne -t bio

Ensuite pour générer les fichiers de référence compatibles SSH :

ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N ""

Et pour injecter tout ça dans l'agent SSH :

ssh-add -K -S /usr/lib/ssh-keychain.dylib

À chaque connexion SSH, Touch ID vous demandera de poser votre doigt pour autoriser la signature. Impossible d'exporter la clé, impossible de la voler, même si quelqu'un a accès à votre machine.

Maintenant si vous préférez une interface graphique plutôt que de taper des commandes cryptiques, y'a Secretive qui fait exactement ça mais avec une jolie app native. Elle crée des clés dans le Secure Enclave, vous notifie quand elles sont utilisées, et depuis la version 3.0 , elle supporte même les clés post-quantiques ML-DSA (FIPS 204) sur macOS Tahoe pour ceux qui veulent anticiper l'ère post-quantique. Pour les vieux Mac sans Secure Enclave, l'app peut aussi utiliser une YubiKey.

Et pour ceux qui ont plein de clés SSH existantes et qui veulent juste ajouter l'authentification Touch ID par-dessus, y'a aussi fssh . Ce petit outil chiffre vos clés avec AES-256-GCM (avec HKDF et salt unique par fichier) et stocke la clé maître dans le Keychain de macOS avec les flags d'accès appropriés pour exiger Touch ID. Du coup à chaque connexion, votre empreinte déverrouille tout ça temporairement et c'est hyper pratique pour naviguer entre plusieurs serveurs sans se retaper les passphrases.

Bref, que vous passiez par les commandes natives, Secretive, ou fssh, l'idée c'est de ne plus jamais laisser vos clés SSH en clair sur le disque. Votre empreinte digitale devient la seule façon de les utiliser, et ça c'est quand même bien plus secure que de faire confiance aux permissions de fichiers...

Merci à Lorenper pour le tuyau !

Source

  •  

Les clés BootROM de la PS5 ont fuité et Sony ne peut pas patcher

Alerte rouge chez Sony ! En ce début d'année 2026, la scène hacking vient de faire sauter le bouchon de champagne d'une façon que le constructeur japonais n'apprécie vraiment pas. Les clés BootROM de la PlayStation 5, c'est à dire ces secrets cryptographiques stockés dans la mémoire en lecture seule du processeur, se baladent maintenant en liberté sur le net.

Tout a commencé le 31 décembre, quand des figures bien connues de la scène comme @BrutalSam_ et @Shadzey1 ont commencé à partager des infos sur cette fuite massive. Leurs posts ont rapidement été supprimés, mais le mal était fait puisque les clés et leurs "keyseeds" sont maintenant listées publiquement sur psdevwiki.com .

Pour comprendre pourquoi c'est si grave, il faut plonger un peu dans les entrailles de la bête. Ces clés BootROM, qu'on appelle aussi clés "Level 0", sont utilisées pour déchiffrer les premières étapes du démarrage de la console. Elles font partie de ce qu'on appelle la "Chain of Trust", la chaîne de confiance qui vérifie que chaque composant logiciel est bien légitime avant de passer la main au suivant. Le bootloader, le kernel, le système d'exploitation, tout repose sur cette fondation cryptographique.

Et le problème, c'est que ces clés résident dans la mémoire morte du processeur AMD de la PS5, définie lors de la fabrication. Sony ne peut pas les modifier avec une simple mise à jour firmware puisque la BootROM est par définition immuable. La seule solution serait de fabriquer de nouveaux APU avec des clés différentes, ce qui ne concernerait que les futures consoles. Les PS5 déjà vendues conserveront cette même clé, ce qui les rend potentiellement exposées à de futurs exploits.

Ça me rappelle l'exploit fusée-gelée de la Nintendo Switch. Dans ce cas-là, c'était une faille dans le code du bootROM Tegra (un bug permettant l'exécution de code) plutôt qu'une fuite de clés, mais le principe reste le même... une fois le processeur sorti d'usine, impossible de patcher. La PS3 avait connu un sort similaire en 2010-2011 avec l'incident fail0verflow .

Mais ne vous précipitez pas encore pour sortir vos tournevis car cette fuite ne constitue pas un jailbreak en soi. Avoir les clés permet d'analyser le processus de démarrage en détail, de comprendre ce qui était jusqu'ici une boîte noire. Mais pour exécuter du code non signé sur une console retail, il faut encore trouver un point d'entrée, un exploit, puis construire toute une chaîne de privilèges. C'est un travail de fond qui va prendre du temps...

On pourrait quand même voir apparaître des custom firmwares et des loaders de backups plus sophistiqués courant 2026. Ça va aussi faciliter le travail des équipes qui bossent sur l'émulation PS5 sur PC, puisqu'elles auront enfin une documentation complète du boot flow.

Sony n'a pas communiqué sur le sujet pour le moment, mais une révision matérielle avec de nouvelles clés reste une option possible pour les futures PS5, comme Nintendo l'avait fait après fusée-gelée. En attendant, tous les possesseurs actuels sont dans le même bateau, avec une console dont le cadenas vient de perdre sa clé maître !

Si vous avez acheté votre PS5 récemment en pensant qu'elle serait la plus sécurisée du lot, c'est raté. Mais si vous êtes du genre à bidouiller et que vous patientez sagement pour un futur jailbreak, 2026 s'annonce plutôt prometteur de ce côté-là...

Source

  •  

Tor CGO - Quand chaque attaque se transforme en auto-sabotage

Bonne nouvelle, les amis, Tor vient d’implémenter CGO (Counter Galois Onion) !

Si ça ne vous dit rien, c’est normal, moi non plus je ne connaissais pas, mais je vais tout vous expliquer !

Jusqu’à maintenant, le réseau Tor protégeait votre anonymat avec du chiffrement en oignon. Plusieurs couches de crypto, une par relais et ça marche bien… sauf qu’il existe une technique vicieuse qu’on appelle les attaques par tagging.

Le tagging c’est quand un attaquant modifie votre trafic chiffré à différents endroits du réseau (genre en ajoutant un marqueur invisible dans certains noeuds), puis il observe ce qui sort de l’autre côté pour vous tracer. C’est comme quand vous collez un traceur GPS dans votre voiture, sauf que là c’est des bits dans du trafic chiffré.

Et de son côté, CGO fait encore mieux que de bloquer cette attaque. En effet, il transforme chaque attaque en auto-sabotage ! Si quelqu’un modifie ne serait-ce qu’un seul bit de votre trafic chiffré, tout le message devient illisible. Et pas seulement ce message… tous les messages futurs de la session deviennent du bruit blanc irrécupérable.

Avec ça en place, l’attaquant se tire une balle dans le pied à chaque tentative.

Derrière ce système, il y a 4 cryptographes qui ont bossé très dur : Jean Paul Degabriele, Alessandro Melloni, Jean-Pierre Münch et Martijn Stam. Ils ont publié leur recherche cette année et ça a été implémenté dans Arti, la version Rust de Tor et l’implémentation C arrive bientôt.

Ce qui change tout, c’est le calcul risque/bénéfice pour les attaquants car avant, tenter de tracer quelqu’un avait peu de conséquences si ça échouait. Mais maintenant, tenter de tracer quelqu’un détruit définitivement votre capacité à surveiller cette personne. Et vous vous en doutez, les agences de surveillance détestent perdre leur accès… Elles préfèrent observer en silence plutôt que de tout casser dans une tentative maladroite. Du coup CGO les force à choisir. Soit rester invisibles, soit tout perdre.

Et puis il y a un autre aspect génial à cette techno, c’est le forward secrecy renforcé que ça engendre car à chaque message, CGO transforme les clés de chiffrement de façon irréversible. Même si un attaquant récupère vos clés actuelles, il ne peut pas déchiffrer les messages précédents car les clés précédentes ont été broyées et remplacées à chaque étape.

CGO remplace aussi l’ancien système d’authentification qui utilisait un digest de 4 bytes par un authenticateur de 16 bytes. C’est donc bien plus costaud et plus difficile à falsifier ainsi qu’à contourner.

Comme d’hab, Tor publie l’algorithme en open source donc vous pouvez vous plonger dans le code si ça vous amuse.

Cette implémentation de CGO est encore expérimentale pour le moment, mais une fois que cela aura été éprouvé par la communauté et testé pendant plusieurs mois, voire des années, ce sera déployé officiellement dans les futurs relais, puis dans les services onion de Tor.

Voilà donc comment Tor fait de chaque tentative de surveillance un auto-sabotage irréversible, et ça les amis, c’est un message qui devrait faire réfléchir pas mal de gens dans des bureaux sans fenêtres.

Source

  •