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.

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

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

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

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

• lien nᵒ 1 : Ackify.eu
• lien nᵒ 2 : Github
• lien nᵒ 3 : Documentation

curl -fsSL https://raw.githubusercontent.com/btouchard/ackify-ce/main/install/install.sh | bash
cd ackify-ce
nano .env  # Configurer OAuth2
docker compose up -d

Commentaires : voir le flux Atom ouvrir dans le navigateur

Les courbes elliptiques, c’est la promesse de la robustesse des communications chiffrées de TLS sans la lourdeur des tailles de clés utilisées avec l’algorithme RSA. Il ne sera pas question de mathématiques aujourd’hui (je suis trop mauvais pour ça, vous avez qu’à voir Wikipedia pour ça), juste de quelques notes sur leur utilisation, pour du certificat autosigné, de la vérification, et un micro rappel de Let’s Encrypt.

Faites une petite recherche rapide, et 99,9% des tutos pour générer un certificat, que ça soit pour de l’auto-signé, ou dans le cadre de la commande chez une autorité « classique », et vous aurez du RSA avec un panel de 2048 à 4096 bits de taille de clé. Sans faire de benchmark, je peux vous assurer que si 2048bits est assez classique, 4096 ça commence à être assez lourd à gérer. Les courbes elliptiques sont des objets mathématiques qui promettent de garder la complexité mathématique, clé de la robustesse en matière de cryptographie, mais avec une taille de clé beaucoup plus réduite, ce qui permet d’améliorer la consommation de ressources et la performance du chiffrement des communications, parce que c’est le contexte dans lequel elles ont été envisagées et déployées.

Le certificat auto-signé

Typiquement, pour déployer un virtualhost « par défaut » sur mon serveur web Nginx, j’ai voulu générer un certificat auto-signé certes, mais avec les courbes elliptiques comme base cryptographique. C’est plutôt simple au final, ça se joue en à peine plus de temps, ça repose sur l’incontournable OpenSSL, malgré les problèmes qu’il pose ces dernières années, surtout en tant que bibliothèque applicative. On commence par lister les courbes disponibles :

openssl ecparam -list_curves

Vous choisissez ce que vous voulez, pour des raisons de compatibilité, j’ai sélectionné secp384r1 qui est la plus utilisée derrière sa petite sœur en 256bits et qui est nommée prime256v1 (parce que nique la cohérence, hein). C’est au passage celle que j’utilise sur le blog

Ensuite, on fait les étapes classiques pour un autosigné :

openssl ecparam -genkey -name secp384r1 -out key.pem
openssl req -new -sha256 -key key.pem -out csr.csr
openssl req -x509 -sha256 -days 365 -in csr.csr -out certificate.pem

Pendant la phase de création du CSR, vous répondez comme vous le souhaitez aux questions, comme on est sur de l’autosigné vous pouvez être créatif si ça vous chante

Et voilà, vous n’avez plus qu’à renseigner la clé et le certificat dans votre Virtualhost par défaut, comme ça, si vous interrogez l’IP de votre serveur web, c’est ce certificat « placeholder » qui apparaitra (autosigné certes, mais certificat quand même) et ça masquera le reste de vos virtualhosts, parce que sinon le serveur web présente le premier chargé dans les configurations incluses (je me demande si j’en ferai pas une démo en live tiens…).

Vérifier la correspondance clé/certificat

Oui je sais ça parait con, mais ça m’est déjà arrivé une quantité beaucoup trop importante de fois de ne pas être certain qu’un nouveau certificat à installer correspond encore à la clé qui est déjà déployée, ou si une nouvelle clé à été générée pour l’occasion. La joie de l’infogérance et des tickets traités par plusieurs admins successivement.

Idem, quand on cherche les manipulations à effectuer, on trouve quasi systématiquement la méthode basée sur le modulus. Sauf que cette méthode est propre à l’algorithme RSA, et n’est donc pas applicable pour des courbes elliptiques. Malgré tout, on peut s’en sortir. L’astuce consiste cette fois à comparer la clé publique entre la clé et le certificat. D’abord pour la clé :

openssl ec -in key.pem -pubout |openssl md5

openssl x509 -in certificate.pem -noout -pubkey |openssl md5

Si les deux résultats sont identiques, vous pouvez les charger dans le serveur web (ou dans l’interface de votre fournisseur d’infrastructure, si vous êtes dans le claude).

La génération pour Let’s Encrypt via acme.sh

Let’s Encrypt (et certainement d’autres fournisseurs) supporte les courbes elliptiques depuis un moment déjà. Personnellement, je préfère utiliser le léger acme.sh plutôt que l’officiel certbot, que je trouve particulièrement lourd. La génération est plutôt simple :

acme.sh --issue --ecc -k ec-384 -d www.domain.tld -w /var/www/ --debug

Évidemment c’est à adapter au domaine, et au dossier par lequel il va bosser le challenge. Perso je préfère ensuite faire une installation dans un dossier dédié pour inclure la commande de rechargement du serveur web derrière :

acme.sh --install-cert -d domain.tld --fullchain-file /etc/nginx/ssl/domain.tld.crt --key-file /etc/nginx/ssl/domain.tld.key --reloadcmd "systemctl reload nginx"

Voilà, comme on le voit, il ne faut pas grand chose pour passer à cette méthode cryptographique, et investiguer à son sujet est à peu près aussi simple qu’avant. Juste je trouve qu’il y a vraiment peu d’articles qui incluent les courbes dans les manipulations. Bon ben voilà