UDID : hash de l'identité civile

@jbar dans @Open_UDC décrit un format (même plusieurs) destiné à dériver de l’identité civile un hash permettant de vérifier l’unicité simplement, sans révéler l’identité civil publiquement. Voici sa RFC

En l’étudiant, je trouve le concept très intéressant, à partir du moment où il existe une méthode alternative pour gérer les cas de figure qui bloquerais (sans papier par exemple).

Ceci dit, je vois aussi des failles, selon le modèle de menace qu’on envisage :
D’un point de vue confidentialité, les hash permettent de s’anonymiser aux yeux du grand public, mais pas des états : de la même manière qu’une rainbow table, un état peut prendre l’ensemble des identités sous sa juridiction, y appliquer le même formalisme et conversion d’udid que décrit dans les RFC, et aboutir aux mêmes hash (c’est tout l’intérêt pour pouvoir vérifier l’unicité), et de cette manière pouvoir à partir de n’importe quel udid de citoyen de son pays, remonter à l’identité civile.

Utiliser scrypt pour rendre plus couteux la création de rainbow table me semble une excellente idée (mais je ne pense pas qu’elle arrête un état).

Dans la même idée, je me pose la question de s’il existe des algos qui soit très lent à générer le hash à partir des données sources, mais rapide pour vérifier le hash si on a déjà donné source et hash. De cette manière il faudrait, disons, de l’ordre d’1h pour générer le hash lors d’une première certification, mais seulement disons une seconde pour les certificateurs suivant pour vérifier qu’il s’agit de la bonne personne. Pour l’état, pour identifier depuis un hash qui est le propriétaire, il faudrait soit faire une rainbow table extrêmement couteuse, soit pour chaque hash à désanonymiser, tester avec l’ensemble des identités civiles jusqu’à trouver la bonne, ce qui ramène la complexité à un seuil qui permet le suivi ciblé, mais pas l’identification de masse (ou plus difficilement). Reste à voir si un tel algo existe.

@tuxmain une idée d’algo qui pourrait avoir cette propriété ?

1 Like

Ma copine porte le même nom et prénom qu’une personne née le même jour qu’elle dans la même ville.

2 Likes

3- The second given name at birth.

Elles ont également le même second prénom ?

Les 2e et 3e prénom sont juste inversé. Coup de bol…

3 Likes

Le chiffrement asymétrique a cette propriété : un sens facile (chiffrement pour une clé publique) et un sens très difficile (décryptage sans la clé privée).

On peut essayer avec un chiffrement peu robuste, qui serait rapide à chiffrer, mais lent à casser. Par exemple une petite clé RSA ou du ed25519 avec de mauvais paramètres. Sauf qu’on veut l’autre sens (difficile à produire, rapide à vérifier). Je pense que RSA fonctionne encore à l’envers, càd déchiffrer une donnée qui n’a pas été chiffrée. Du moins la version “textbook” simplifiée, pour le standard (avec padding, nécessaire pour la sécurité) je ne sais pas.

Sinon la version bricolage : on génère un hash habituel peu coûteux des données, et on le factorise en nombres premiers (ce qui est très coûteux). Notre “hash” est alors une liste de nombres premiers. Pour vérifier, il suffit de les multiplier, ce qui est rapide.

Cependant l’inégalité de puissance de calcul entre une personne lambda qui a un téléphone à 200€ ou un i3, et l’état ou un GAFAM, ferait que pour avoir assez de sécurité on rende le calcul bien trop lent sur un petit appareil. Si une grosse machine est 3600 fois plus performante qu’un pauvre téléphone qui met 1h à calculer le hash, et que l’attaquant a quelques machines, en un mois il calcule 60 millions de hashes.

On peut ajouter par exemple plusieurs passes de scrypt (ou plutôt argon2) pour empêcher de paralléliser et prendre plein de mémoire, mais ça risque de rester insuffisant. Surtout qu’on sera bien moins nombreux, et qu’il n’y aura pas besoin de tout calculer (si seuls les opposants politiques sont ciblés par exemple).

2 Likes