Réflexion – stabilité de l’identifiant

Je bouquine un livre en ce moment :
« Gestion des identités » de OCTO Technology, ISBN:978-2-9525895-1-2, avril 2007, www.octo.com

Au cours du développement de l’Identifiant Unique Personnel (IUP), il est noté que trois contraintes doivent absolument être respectées.
L’IUP doit être :

  1. unique (strictement lié à une personne) ;
  2. inaliénable (ne peut être réattribué à une autre personne) ;
  3. stable (dans le temps).

En référençant un utilisateur (une entité) par un bi-clé cryptographique, respecte-t-on ces contraintes?

Cet identifiant doit répondre à la problématique de la reconnaissance universel d’un utilisateur particulier au sein d’un système d’information (SI) délimité. Sa première fonction est donc l’identification. Il peut éventuellement servir aussi d’authentification via un annuaire de sécurité faisant le lien entre identité et méthode d’authentification. Les multiples applications du SI peuvent s’en servir pour l’identification/authentification (SLO – Single Log-On) en fonction de leurs capacités de gestion de ces identifiants.

1/ Unique

L’unicité de l’IUP est défini dans le sens où, dans tout le SI, il n’existe pas deux identifiants identiques attachés à deux personnes différentes. De même, dans la mesure du possible, une unique personne ne devrait avoir qu’un seul et unique IUP. En clair :

un IUP = une personne

L’identification par un bi-clé permet de respecter cette unicité de l’identifiant au sein du SI. La longueur d’une clé cryptographique permet même de respecter (statistiquement fort probable) cette unicité de façon universelle, et donc plus seulement unique au sein d’un « unique » SI. Par contre, rien n’empêche un utilisateur (une entité) de disposer de plusieurs identifiants. Ces multiples identifiants sont à gérer comme potentiellement autant de personnalités différentes. Donc si cette méthode d’identification par bi-clé à la qualité d’être universelle, elle ne restreint pas l’usage de plusieurs identités par une même entité.

2/ Inaliénable

Lorsque une personne quitte sa société, son identifiant n’est plus utilisé de façon active. Mais il peut être utilisé pour identifier ses actions passées (imputabilité). Il ne faut pas que cet identifiant soit réaffecté à une autre personne sur le SI, il doit être inaliénable. Il ne doit pas non plus être purement et simplement supprimé tant qu’il subsiste sur le SI des droits ou des actions imputables à cet identifiant (cet utilisateur).

L’identification par un bi-clé, et plus encore le lien des objets par nebule, résout ce problème. La clé publique servant d’identifiant étant par défaut unique mais surtout non reproductible, elle ne peut être réattribué à une autre personne. Il faudrait pour cela disposer de la clé privée qui est… privée à l’utilisateur. Elle est intrinsèquement inaliénable sauf à voler la clé privée.

3/ Stable

La stabilité de l’identifiant doit être assurée tout le temps que l’utilisateur passe dans la société, mais aussi tout le temps que des données ou des droits liés à cet identifiant subsisteront sur le SI. Il permet de reconnaître cet utilisateur, et perdrait donc tout intérêt s’il n’était pas stable, constant.

Un IUP sous forme de bi-clé semble stable dans le temps puisqu’il est universellement unique et intrinsèquement inaliénable. Il se pose en fait un problème technologique. En cryptographie, la force d’une clé de chiffrement (symétrique ou asymétrique) repose sur sa méthode de génération et sur sa longueur (en bits). Si la méthode ne varie pas ou peu dans le temps, et si la longueur d’une clé est figé lors de sa création, la puissance de calcule nécessaire pour la casser (retrouver la clé privé à partir de la clé publique) est constante. Mais la puissance des machines est en perpétuelle évolution. Une clé générée il y a dix ans, c’est à dire sur des critères de sécurité d’il y a dix ans, est peut-être aujourd’hui vulnérable parce que trop petite (indépendamment de découvertes de failles dans la méthode). Ceci dit, ce qui avait été chiffré il y a dix ans a-t-il encore de la valeur aujourd’hui? Ce que l’on veut protéger aura-t-il de la valeur dans dix ans? Si oui, il faut prévoir des tailles de clés suffisantes pour résister aux capacités de calculs prévisibles dans dix ans… voir plus…

Donc, il faut prévoir de renouveler les bi-clés cryptographiques de tout de monde régulièrement, dès que celles-ci deviennent obsolètes par leur taille (au minimum) ou au bout d’un certain temps d’utilisation (mieux). Et donc la contrainte de stabilité est rompue. Mais elle peut être remplacée par le mécanisme de parenté, en effet celui-ci permet de définir de façon forte quel nouvel identifiant succède à votre ancien identifiant périmé. Reste à déclarer publiquement votre ancien identifiant comme périmé, un autre débat…

Maintenant, faisons un petit exercice. Imaginons qu’une personne enregistre intégralement toutes les données chiffrées que vous produisez, même si elle ne peut pas les déchiffrer. Dans dix ans, imaginons qu’elle réussisse à obtenir la puissance nécessaire pour le déchiffrement. Jusqu’au moment ou vous avez changé de clé, les données de l’époque deviennent lisible, pas de problème me direz-vous, quoique… Imaginez que votre nouvelle clé, soigneusement générée par votre service informatique, vous ai été envoyé par message (chiffré) avec son mot de passe… ce message devient lisible, et votre nouvelle clé avec!
Le mécanisme de parenté doit exclure impérativement tout lien de validation automatique vers les identifiants enfants, et prévoir un mécanisme de révocation.

Tags: , , , , ,

Comments are closed.