Hack my cipher

R&D
,
21

Bonne question.
J’ai fourni dans mon poste principal tout ce qu’un attaquant pourrait dérober si il avait directement accès à la mémoire du téléphone, en principe.

Si vous voulez je vous donne mon phone pour en être certain. Vous n’aurez que pour seule règle de ne pas ouvrir l’app (je rajouterai une protection inapp de timer incrémentale, puis de suppression du mnemonic chiffré au bout d’un certain nombre d’essaies incorrects), mais tous les autres coups sont permis.

Ca ou tout autre moyen de récupérer le mnemonic.
Pour le moment Tuxmain a battu en retraite.

22

Ahah, si j’avais bien compris justement.
C’est impossible par force brute. En tout cas, pas avec les technologies que nous possédons, ni la puissance de calcul que nous avons aujourd’hui.
La couille de Poka est saine et sauve.

23

La meilleure façon de procéder est de te faire installer un Key logger.

En théorie, pour être certain de ton coup, il faudrait que l’utilisateur tape les nombres sur un pad à l’écran qui est composé d’images générées des 10 chiffres et qui changent de place aléatoirement.
Sinon, utiliser un passkeys.

24

Non ça ne sera pas suffisant. Tu pourra trouver mon code à 4 chiffres, mais tu ne pourra toujours pas exploiter mon trousseau.

Si un key lgger aurait suffit, avec un code à 4 chiffres, alors un brute force aurait été tout à fait accessible via n’importe quelle machine en quelques heures tout au plus.

En réalité je pourrais même retirer la partie entrée utilisateur sans réelle perte de sécurité.
Que ce soit sur mobile, desktop ou web (en l’occurence ce trousseau a été généré via app desktop linux).

25

Dans ce cas autant la retirer.

Mais comment fais-tu ?

26

Je me dis que ça protège au moins l’accès via l’app. Mais bon en réalité tous les phones sont protégés par leurs propres code ou empreinte donc bon, je ne sais pas.

J’utilise un système de communication quantique basé sur l’intrication des qubits mnémoniques dans un champ tensoriel holographique à 11 dimensions. Les clés sont générées par un processeur quantique topologique qui exploite la superposition et l’enchevêtrement des états de spin des anyons non-abéliens. Le tout est sécurisé par un protocole de distribution quantique de clés basé sur les inégalités de Bell-Kochen-Specker dans un espace de Hilbert de dimension transfinie selon la théorie des nombres surréels p-adiques twistés.

Plus précisément, les qubits sont encodés dans les degrés de liberté topologiques d’un réseau d’anyons non-abéliens de type Fibonacci, plongés dans un espace de Calabi-Yau de dimension 6 compactifié selon une variété de Kähler holomorphe. Ça permet d’exploiter la correspondance AdS/CFT pour stocker de l’information dans les trous noirs BTZ à la frontière conforme de l’espace-temps.

J’ai fait une lib Dart pour ça.

27

Euh… La date du 1er avril est passée :stuck_out_tongue_winking_eye:

2 Likes
28

Avec ça, je peux te garantir que tes tentatives de décryptage tomberont à plat, comme une variété Calabi-Yau dégénérée ! :wink:

1 Like
29

… enfin ça c’était le plan de base.

Finalement j’ai opté pour une autre approche qui consiste à chiffrer la box Hive avec un secret aléatoire stocké sur l’appareil en utilisant la lib flutter_secure_storage: GitHub - mogol/flutter_secure_storage: A Flutter plugin to store data in secure storage

  • iOS: Keychain is used for iOS.
  • Android: AES encryption is used for Android. AES secret key is encrypted with RSA and RSA key is stored in KeyStore.
  • Linux: libsecret is used for Linux.
  • Web: Uses an experimental implementation using WebCrypto. Use at your own risk at this time. Feedback welcome to improve it. The intent is that the browser is creating the private key, and as a result, the encrypted strings in local_storage are not portable to other browsers or other machines and will only work on the same domain…
  • voir la lib pour windows et macos j’en ai rien à foutre

En gros ça utilise les fonctions système de keystore pour stocker le secret.
Ce secret chiffre une boxe Hive, ce qui permet de structurer le model de cette Box comme on veut pour y stocker des objets Dart, et de n’avoir à stocker via le secure_storage que le secret généré via un algo de génération aléatoire “sécurisé”.

30

Je suis content qu’on en soit arrivé à la même conclusion :

  • il me faut obligatoirement ton téléphone + ton code
  • comme tu es malin et que tu empêches l’attaque par force brute avec ta suppression au bout de 3 tentatives erronnées, il me faut passer par un autre système
  • le key logger est le plus efficace pour récupérer ton code, mais je peux aussi le regarder discrètement d’où une technique pour bypasser cette méthode.

Encore une fois, d’un point de vue UX, le mieux est de se passer de code, au pire d’utiliser un passkeys pour des points vulnérables (ex: certifs, transferts importants).

On avait eu une discussion hyper intéressante à ce sujet avec @tuxmain .
Pour l’instant, ta solution n’a toujours pas été craquée. Et celui qui trouve la faille n’hérite pas seulement de tes quelques DU, mais de milliards de MNL !!

1 Like
31

Oui et mon téléphone déverrouillé, car le seul moyen d’utiliser mon wallet sera via l’app installée, le keypair étant chiffré avec un long secret stocké via le keystore/keychain du système, donc extrêmement compliqué à bypass (voir impossible si on n’exploite pas de faille du système).
Voir les specs des stockages en question pour ceux qui en doutent, qui sont listés dans mon message précédent.

Et bien là-dessus j’ai un doute :slight_smile:
Pour moi par exemple (je sais que je suis biaisé par mon expérience), une app qui gère mon wallet sans code comme g1nko, je ne suis pas bien je panique. Je me dis qu’il y a un problème.
Même si ce n’est qu’un code à 4 chiffres que j’ai moi-même choisi, avec un input fluide et bien intégré, je suis rassuré, j’ai l’impression que mon wallet est mieux protégé.

Et je pense (mais je peux me tromper) que c’est un sentiment partagé par pas mal de monde.
Mais il n’empêche que j’ai été pas mal influencé par g1nko sur ces sujets :wink:

D’ailleurs je prépare discrètement Durt2 qui servira à utiliser la Ğ1v2 en Dart.
Mais je passe par un long chemin de refonte de Ğecko, qui s’appelle Ğazelle pour le moment (qui utilise Polkadart à la place de polkawallet-sdk), car j’en profite pour prendre le temps de refactorer encore et encore cette app encore simple, en appliquant tout ce que j’ai appris en 3 ans de dev Flutter, pour tenter de trouver la meilleure architecture pour cette app et cette lib Durt.
Rassurez-vous Ğazelle n’est qu’un nom de code provisoire pour cette refonte pour m’aider à le différencier de Ğecko, dont la code base n’a plus grand-chose à voir.

Mais je n’en dis pas plus car c’est un gros chantier et je ne sais pas trop où je vais ni par quel chemin, donc voilà.
Je pourrais aller beaucoup plus vite et avoir déjà fini la lib, mais encore une fois, je veux éviter les erreurs d’architecture que j’ai pu faire sur Ğecko, notamment en termes de séparation des responsabilités, mais aussi d’UX, donc je suis encore au stade de refactorer encore et encore avant de cristalliser cette app et cette lib.
Vu que la migration n’est visiblement pas pour tout de suite, je profite de ce timing.

Je vous tiendrai au jus lorsque la lib sera ok à utiliser.

Pour les curieux qui veulent voir où j’en suis en termes de rendu vous pouvez installer l’app sur Linux et Android ici : Releases · clients / Ğazelle · GitLab

La CI gitlab de cette app a été écrite par Claude 3 opus via Perplexity

32

Donc ta sécurité est une backdoor pour Google, Apple, la NSA, etc. :stuck_out_tongue:

Les TPM (modules de sécurité matériels) rendent les attaques plus difficiles mais sont des cibles de choix pour les constructeurs et les états. Comme ils sont probablement très opaques, seuls des groupes avec de grands moyens pourraient découvrir des failles, qui risquent donc de n’être jamais corrigées.

33

Tu as raison, rien n’est infaillible et on ne peut pas faire confiance aux constructeurs et aux états.
C’est bien pour ça que tu n’as pas de téléphone ni appareil électroménager chez toi. La facture de campingaz doit être salé d’ailleurs.

Je pense quand même que stocker les secrets dans les enclaves sécurisées des OS, c’est ce qu’on a de mieux à l’heure actuelle. Déjà ça oblige à avoir un accès physique au téléphone pour tenter quoi que ce soit. Ensuite au moins sur Linux avec libsecret, le code est auditable donc on peut vérifier qu’il n’y a pas de backdoor.
Ceux sur Linux phone peuvent l’installer en natif linux ainsi étant donné que je fourni le build linux. Ca devrait satisfaire les plus libristes frileux.

Et puis les constructeurs ont quand même plus à perdre qu’à gagner s’ils se font choper à mettre des portes dérobées. Ça ruinerait direct la confiance dans leurs systèmes.

Après c’est sûr que c’est pas parfait, mais ça complique sérieusement la tâche de ceux qui voudraient les récupérer, surtout à distance.

Et je rappel que c’est un secret qui chiffre la vrai donnée qui est stocké en TPM, pas la donnée elle même. Donc si comme tu dis ya des backdoor spécifiquement sur ces TPM, ils récupéreront un secret qui chiffre une donnée, qui elle est stocké ailleurs sur le phone. Ca leur fera une belle jambe.

Enfin il reste je rappel aussi un code pin rentrée par l’utilisateur, dernier rempart au déchiffrement, brouillant un peu plus l’accès au secret.

Bref, je pense que c’est un bon compromis pour l’instant. Si on part du principe qu’on peut rien faire car les constructeurs/états peuvent potentiellement tout voir, autant revenir au papier et au crayon !

On reste sur des systèmes non-custodiaux, les compromis sont indispensables.
De mon point de vue, la solution que je propose demeure bien plus sécurisé que la proposition d’ @elois d’un simple code à 5 caractères alphanumériques.
Le but étant au niveau UX de ne pas faire plus compliqué qu’un code PIN à 4 chiffres, propose moi mieux comme solution et je prends, ce poste est là pour ça :slight_smile:

1 Like
34

Entièrement d’accord avec ça : les deux se défendent. Il y en a qui préfèrent porter ceintures et bretelles, tandis que d’autres se contentent de l’un ou de l’autre. Libre à chacun de pouvoir choisir.
Le meilleur des mondes : proposer une option toute simple qui propose de mettre un mot de passe à 4 chiffres ou de ne rien mettre. Et si la motivation te prends, de rajouter passkeys.

Bravo pour tout le travail accompli et heureux de te retrouver au top :smiley:

1 Like
35

Peux-tu repréciser ce que tu appels un passkeys dans ce contexte ?

Entre le mnemonic, le code pin, le secret stocké en TPM, on commence à s’y perdre un peu niveau des pass ^^

1 Like
36

Oui, bien sûr. C’est ça : Passkeys : à quoi ça sert, comment ça marche et pourquoi ils vont remplacer les mots de passe

1 Like
37

Ok donc c’est ce que je fais déjà non ?
Tu proposes simplement de pouvoir remplacer le code pin par de la biométrie optionnellement ?
Pour la sync entre appareil, on pourrait simplement généré le qrcode du mnemonic et l’importer de la même manière de l’autre côté (secret en secureStorage + pin/biometrie) ?

Ou c’est que tu proposes d’utiliser les services de Google et Apple pour partager la passkey entre appareils ?

J’ai besoin de précision sur ta vision :slight_smile:

1 Like
38

Oui, c’est déjà un peu ce que tu fais !!
Effectivement, passkeys ajoute en plus la biométrie optionnellement.
Pour la synchro, je préfère également la qrcode. J’utilise Brave et c’est déjà la stratégie qu’ils utilisent.
Utiliser Google/Apple, pourquoi pas, ça simplifierai pour certains, mais ça en rebuterait d’autres.

Perso, je serai donc plutôt pour biométrie / pin, tous deux optionnels + partage par QR code, éventuellement, s’il y a demande, Google / Apple.

1 Like