Vous mourrez. Votre crypto meurt avec vous. Et votre famille n'a aucune idée de comment récupérer vos Bitcoins, vos Ethereum ou vos autres actifs numériques. Sympa l'héritage !

C'est exactement le problème que Deadhand vient résoudre avec une approche plutôt bien pensée : le partage de secret de Shamir (Shamir's Secret Sharing pour les intimes). En gros, au lieu de refiler votre seed phrase à quelqu'un en lui faisant confiance les yeux fermés, l'outil la découpe en 3 morceaux qu'il éparpille intelligemment.

Vous gardez le Shard A. Votre bénéficiaire reçoit le Shard B. Et le serveur Deadhand stocke le Shard C. Et là, c'est mathématiquement prouvé : n'importe quelle combinaison de 2 shards permet de reconstruire la phrase complète, mais un seul shard tout seul = zéro info utilisable.

Le truc cool avec ce système c'est surtout le système d'homme-mort automatique. Tous les 30 jours, Deadhand vous envoie un mail "T'es toujours vivant ?". Vous cliquez sur le lien, le timer se réinitialise, et hop c'est reparti pour un tour. Simple, non ? Mais si pendant 90 jours vous ne donnez pas signe de vie (RIP), le serveur envoie alors automatiquement le Shard C à votre bénéficiaire qui peut alors le combiner avec son Shard B pour récupérer la seed phrase originale.

Du coup, personne n'a le contrôle total à aucun moment. Si le serveur se fait hacker ? Les pirates récupèrent que le Shard C, TOTALEMENT INUTILE sans les autres. Si votre bénéficiaire devient malveillant ? Il a juste le Shard B, pareil, ça sert à rien tout seul. Et si vous perdez votre Shard A ? Pas de panique, votre bénéficiaire peut toujours combiner B + C pour récupérer l'accès.

Techniquement, c'est du FastAPI côté backend avec PostgreSQL pour la base de données. Le frontend reste sobre avec du HTML, TailwindCSS et HTMX. Et surtout, tout le chiffrement se passe côté client dans votre navigateur via la bibliothèque secrets.js, donc vos clés ne transitent jamais en clair sur le réseau. Architecture zéro-trust comme on dit... même les administrateurs du serveur ne peuvent pas accéder à vos données.

Bon, faut quand même préciser que c'est un MVP (minimum viable product). Les développeurs sont honnêtes là-dessus : ça demande du durcissement avant la prod. Il faut implémenter HTTPS comme il faut, auditer la lib secrets.js, sécuriser l'infrastructure de la base de données et remplacer le mock email par un vrai fournisseur genre SendGrid ou AWS SES. Donc attention, c'est pas encore prêt pour mettre vos millions de Bitcoin dedans, hein.

Niveau installation, rien de bien compliqué si vous voulez tester en local. Vous clonez le repo GitHub, vous installez les dépendances avec pip install -r requirements.txt, puis vous lancez python -m uvicorn app.main:app --reload --port 8000 et vous accédez à http://localhost:8000. Bon, évidemment faut avoir Python 3.9+ installé, mais ça vous le savez déjà. Et le projet est sous licence MIT donc complètement open source, ce qui fait que vous pouvez auditer le code vous-même si vous en avez les capacités (ce n'est pas mon cas).

Perso, je trouve le concept vraiment intelligent par contre. Pas besoin de faire confiance à une boîte centralisée ou de refiler vos clés à un proche en croisant les doigts pour qu'il ne se fasse pas pirater ou qu'il ne perde pas le bout de papier. Le partage de secret de Shamir, c'est pas nouveau mais l'appliquer à l'héritage crypto avec un dead man's switch automatisé, c'est pas mal du tout !

Bref, si la question de l'héritage de vos cryptos vous turlupine (et elle devrait), Deadhand propose une piste sérieuse à creuser. Et si vous cherchez aussi à sécuriser physiquement vos seed phrases , jetez un œil à SeedKeeper.

Microsoft vient de confirmer qu'ils filent les clés de chiffrement BitLocker au FBI quand celui-ci débarque avec un mandat. Et même si on s'en doutait fooort, c'est la première fois qu'on a la preuve que ça arrive vraiment.

L'affaire s'est passée à Guam (une île américaine dans le Pacifique), où des agents fédéraux enquêtaient sur une histoire de fraude. Ils avaient besoin d'accéder aux ordis de suspects, sauf que les disques étaient chiffrés avec l'outil BitLocker , le chiffrement intégré à Windows. Du coup, ni une ni deux, le FBI a envoyé un mandat à Microsoft pour récupérer les clés de récupération stockées dans le cloud.

Et Microsoft a dit oui, bien sûr, voilà les clés, servez-vous, c'est cadeau !

Le truc, c'est que par défaut, quand vous activez BitLocker sur un PC avec un compte Microsoft, Windows envoie automatiquement une copie de votre clé de récupération sur les serveurs de Redmond. C'est présenté comme une fonctionnalité pratique, genre "au cas où vous oubliez votre mot de passe". Sauf que du coup, Microsoft a accès à vos clés.

Et si Microsoft a accès, le gouvernement aussi.

Côté Apple, c'est une autre histoire. J'sais pas si vous vous souvenez de l'affaire de San Bernardino en 2016 mais le FBI avait demandé à Apple de créer un firmware spécial pour désactiver les protections anti-bruteforce de l'iPhone d'un terroriste. Tim Cook avait dit non. Pas parce qu'Apple ne pouvait pas techniquement le faire, mais parce que créer cet outil aurait ouvert une brèche pour tout le monde.

Microsoft, eux, ont fait le choix inverse. Leur architecture permet explicitement de conserver une copie des clés côté serveur. Alors oui, c'est pratique si vous perdez votre mot de passe, mais c'est aussi une porte d'entrée pour quiconque a un mandat... ou autre chose.

Microsoft dit recevoir environ 20 requêtes par an pour des clés BitLocker, et qu'ils ne peuvent pas toujours y répondre, genre quand l'utilisateur n'a pas activé la sauvegarde cloud.

On s'en serait douté...

Bref, si vous utilisez BitLocker et que vous tenez vraiment à ce que vos données restent privées, désactivez la sauvegarde automatique de la clé sur le compte Microsoft.

Concrètement, pour cela vous avez deux options : utiliser un compte local au lieu d'un compte Microsoft (la clé ne sera jamais envoyée dans le cloud), ou si vous êtes sur Windows Pro/Enterprise, passer par les stratégies de groupe (gpedit.msc → Configuration ordinateur → Modèles d'administration → Composants Windows → Chiffrement de lecteur BitLocker) pour forcer la sauvegarde locale uniquement.

Autrement, vous pouvez aussi simplement sauvegarder votre clé sur une clé USB ou l'imprimer. C'est moins pratique, mais au moins elle reste chez vous.

Source

-- Article en partenariat avec LockSelf --

Il faut bien se rendre à l'évidence qu'une bonne partie des fuites de données en entreprise passent par des fichiers mal sécurisés. Par exemple ce fameux document Excel avec les salaires qui traîne sur le serveur depuis 2019, le ZIP envoyé via WeTransfer "parce que c'est plus simple", ou encore le dossier client partagé sur Google Drive avec le lien accessible à quiconque a l'URL.

Bref, c'est le Far West total en matière de sécurité et de confidentialité !

Maintenant si vous avez lu mon article sur LockPass (le gestionnaire de mots de passe certifié ANSSI), vous savez déjà que LockSelf fait les choses sérieusement. Et c'est pourquoi, aujourd'hui je vais vous présenter deux autres de leurs outils : LockTransfer pour les fichiers en transit, et LockFiles pour les fichiers au repos.

Devinette du soir : Qu’est-ce qui est pire qu'un secret que vous avez oublié de cacher ?

Réponse : Des dizaines, des millions de secrets qui traînent sur GitHub parce que quelqu'un a eu la flemme de configurer un vrai gestionnaire de variables d'environnement !

Hé oui, les amis ! On a tous fait cette boulette au moins une fois (ou alors vous mentez, ou vous êtes un robot). On crée un petit fichier .env, on oublie de le rajouter au .gitignore, et paf, vos clés AWS se retrouvent à poil. Selon GitHub, c'est plus de 39 millions de secrets qui ont été détectés en fuite sur leurs dépôts en 2024. C'est du délire !

Envmap - Le gestionnaire de variables d'environnement qui tue les fichiers .env ( Source )

Du coup, au lieu de continuer à se farcir du bricolage avec des fichiers qui traînent en clair sur le disque, je vous propose de jeter un œil à Envmap .

C'est un outil écrit en Go dont l'objectif est de réduire au maximum l'écriture de vos secrets sur le disque dur. En mode normal, il va les pomper directement chez les grands manitous du stockage sécurisé comme AWS Secrets Manager, HashiCorp Vault, 1Password ou encore Doppler (même si pour l'instant, certains de ces providers sont encore en cours d'intégration).

Comme ça, au lieu de faire un vieux source .env qui laisse traîner un fichier sensible, vous lancez votre application avec envmap run -- node app.js. L'outil récupère les variables en RAM et les injecte dans le process. C'est propre, c'est net, et ça évite surtout de pousser par erreur votre config sur un repo public.

Pour ceux qui se demandent s'il faut quand même envoyer ses fichiers .env sur GitHub (spoiler : non, jamais !), Envmap propose une commande import pour ingérer vos vieux secrets. Et pour ceux qui ont besoin d'un stockage local, sachez qu'Envmap peut aussi chiffrer vos variables en AES-256-GCM, ce qui est quand même plus sérieux qu'un fichier texte lisible par n'importe qui. Notez aussi qu'il existe une commande sync si vous avez vraiment besoin de générer un fichier .env temporaire.

Perso, ce que je trouve vraiment cool, c'est l'intégration avec direnv. On rajoute une ligne dans son .envrc, et hop, les secrets sont chargés automatiquement quand on entre dans le dossier du projet. C'est magique et ça évite les crises cardiaques au moment du push.

D'ailleurs, si vous voulez aller plus loin dans la sécurisation de vos outils, je vous recommande de lire mon article sur SOPS ou encore ma réflexion sur l'usage de GitLab pour vos projets sensibles.

Bref, c'est open source (sous licence Apache 2.0), et avec ça, vous dormirez sur vos deux oreilles !

Vous vous souvenez de Moxie Marlinspike ?

Mais si, le créateur de Signal qui a, grosso modo, appris au monde entier ce qu'était le chiffrement de bout en bout accessible à tous.

Hé bien, le garçon est de retour et cette fois, il ne s'attaque pas à vos SMS, mais à vos conversations avec les Intelligences Artificielles.

Son nouveau projet s'appelle Confer et autant vous le dire tout de suite, c'est du lourd car son idée c'est de faire pour les chatbots IA ce que Signal a fait pour la messagerie instantanée. C'est-à-dire rendre le tout réellement privé, avec des garanties techniques tellement fortes que personne, ni lui, ni les hébergeurs, ni la police, ne puisse (en théorie) mettre le nez dans vos prompts.

Alors pour ceux d'entre vous qui se demandent "Quelle est la meilleure alternative privée à ChatGPT ?", vous tenez peut-être la réponse.

Car le problème avec les IA actuelles c'est que quand vous papotez avec ChatGPT, Gemini ou Claude, c'est un peu comme si vous confessiez tous vos secrets dans un mégaphone au milieu de la place publique. Ces modèles ont soif de données et Sam Altman d'OpenAI a lui-même souligné que les décisions de justice obligeant à conserver les logs (même supprimés) posaient un vrai problème, allant jusqu'à dire que même des sessions de psychothérapie pourraient ne pas rester privées.

Et c'est là que Confer change la donne.

Alors comment ça marche ? Hé bien Confer utilise une approche radicale puisque tout le backend (les serveurs, les modèles LLM) tourne dans ce qu'on appelle un TEE (Trusted Execution Environment). En gros, c'est une enclave sécurisée au niveau du processeur de la machine qui empêche même les administrateurs du serveur de voir ce qui s'y passe. Et pour prouver que c'est bien le bon code qui tourne, ils utilisent un système d'attestation distante .

Les données sont chiffrées avec des clés qui restent sur votre appareil et Confer utilise les Passkeys (WebAuthn) pour dériver un matériel de clé de 32 octets. Ainsi, la clé privée reste protégée sur votre machine (dans le stockage sécurisé type Secure Enclave ou TPM selon votre matos).

Du coup, quand vous envoyez un message à l'IA, le flux est conçu pour être :

1. Chiffré depuis chez vous.
2. Traité dans l'enclave sécurisée du serveur (TEE).
3. Déchiffré uniquement dans la mémoire volatile de l'enclave.
4. Rechiffré immédiatement pour la réponse.

C'est propre, c'est élégant, c'est du Moxie à 100% !

Bien sûr, Confer n'est pas le seul sur le créneau. J'ai vu passer des initiatives comme Venice (qui stocke tout en local) ou Lumo de Proton. Si vous utilisez déjà des outils comme OnionShare pour vos fichiers, cette approche "zéro trust" vous parlera forcément.

Mais la force de Confer, c'est l'expérience utilisateur car comme Signal à son époque, ça marche tout simplement. Suffit de 2 clics, une authentification biométrique, et boum, vous êtes connecté et vos historiques sont synchronisés entre vos appareils (de manière chiffrée, vérifiable via le log de transparence). En plus vous pouvez même importer votre contenu depuis ChatGPT.

L'outil est open source et le code auditable. De plus le support natif est dispo sur les dernières versions de macOS, iOS et Android. Je l'ai testé et ça répond vite et bien. Après je ne sais pas si c'est un LLM from scratch ou un modèle libre fine tuné. Et je n'ai pas fait assez de tests pour tenter de lui faire dire des choses qu'il n'a pas envie mais il a l'air pas pour le moment.

Pour l'utiliser sous Windows, il faudra passer par un authentificateur tiers pour le moment et pour Linux... une extension existe déjà pour faire le pont en attendant mieux. Par contre, c'est limité à 20 messages par jour et si vous en voulez plus, faudra passer au payant pour 35$ par mois. Mais on a rien sans rien. Après si vous vous inscrivez avec mon code KORBEN vous aurez 1 mois gratuit et moi aussi ^^

Bref, si vous cherchiez comment mettre un peu de vie privée dans vos délires avec l'IA, je vous invite grandement à jeter un œil à Confer. J'sais pas vous mais moi je trouve que ça fait du bien de voir des projets qui remettent un peu l'utilisateur aux commandes.

Source

Vous connaissez ce moment relou où vous copiez un truc sur votre PC et vous vous retrouvez comme un idiot devant votre Mac parce que le presse-papier ne suit pas ? Hé bien y'a une solution open source qui règle ce problème, et elle s'appelle CrossPaste .

Vous installez l'app sur tous vos appareils (Windows, macOS, Linux) et hop, tout ce que vous copiez sur l'un se retrouve automatiquement disponible sur les autres. Du texte, des images, des URLs, du HTML, du RTF, des fichiers... Tout y passe. Et le truc cool c'est que ça fonctionne sur votre réseau local en mode "LAN-only serverless", donc vos données ne transitent pas par un serveur central quelque part dans le cloud de Donald Duck, euh Trump.

Car oui, la sécurité c'est pas en option avec CrossPaste. Toutes les données sont chiffrées de bout en bout avec un système de chiffrement asymétrique. Du coup, même si quelqu'un sniffe votre réseau local (votre voisin super haxxor par exemple), il ne verra que du charabia incompréhensible. Et comme y'a pas de serveur central, y'a rien à pirater côté infrastructure non plus.

L'interface est unifiée sur toutes les plateformes grâce à Compose Multiplatform (c'est du Kotlin sous le capot pour les curieux) et vous avez un historique de tout ce que vous avez copié, avec une gestion automatique du stockage pour pas que ça finisse par bouffer tout votre disque dur. Pratique pour retrouver ce lien que vous aviez copié y'a 3 jours et que vous avez oublié de sauvegarder quelque part...

Le projet est sous licence AGPL-3.0, donc c'est du vrai open source avec le code disponible sur GitHub. Si vous êtes du genre à vouloir bidouiller ou simplement vérifier qu'il n'y a pas de cochonneries planquées dedans, vous pouvez compiler vous-même. Y'a juste besoin de Gradle et d'un ./gradlew app:run pour compiler et lancer le tout.

Bref, si vous jonglez entre plusieurs machines au quotidien et que vous en avez marre de vous envoyer des trucs par email ou par Slack juste pour les avoir sur un autre ordi, CrossPaste ça va vous faire économiser pas mal de temps et d'énergie. Et en plus c'est gratuit \o/

Merci à Lorenper pour l'info !

Source