Accueil > OpenID Connect OAuth Server par DnC > Développer > Proof of Possession (PoP)

Proof of Possession (PoP)

Répondant à la préoccupation exprimée dans la rubrique Authentifier l’application, la technique "preuve de possession" serait-elle ce dont nous avons besoin ?

La particularité de la PoP consiste à faire créer par l’application cliente une paire de clé publique-privée à chaque procédure d’authentification.

Il s’agit de certifier que l’application qui présente le JWT est bien celle qui a été identifiée au moment de l’authentification. Cependant, certifier que l’application est celle qui a initié l’authentification de l’utilisateur final n’est pas prouver que c’est l’application authentique. La preuve de possession n’est pas la preuve de l’identité de l’application et de son intégrité ( la conformité de son code au modèle d’origine ).

Le terme « preuve de possession » fait référence à des mécanismes de chiffrement qui atténuent le risque de vol de jetons de sécurité et d’utilisation par un attaquant.
Dans le cas des jetons "porteur" ( Bearer Token ), la simple possession du jeton permet à une application de l’utiliser vis-à-vis d’une ressource protégée.

Le document rfc7800 - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) - propose une implémentation associé au JWT.
Nota : Nous sommes dans OpenID Connect. Nous remplaçons donc dans le texte :
"émetteur (issuer)" par "serveur OIDC (OpenID Provider)" ou OP,
"présentateur (presenter)" par "application cliente ou client ou RP",
Nous conservons "destinataire (recipient)" en gardant à l’esprit que ce peut être une "ressource protégée" ou RS, une API ou n’importe quel autre ressource ou encore l’OP lui-même si le jeton lui est retourné pour ré-authentification silencieuse.

Cette spécification explique comment déclarer dans un jeton Web JSON (JWT) que le client présentant le JWT possède une clé particulière preuve-de-possession et comment le destinataire peut obtenir de manière cryptographique la preuve que le présentateur possède la clé.

Le document présente deux implémentations : avec preuve de possession à clé symétrique ou asymétrique. Nous ne considérerons que la deuxième, demandant moins d’échanges et paraissant plus simple de mise en œuvre.

Le client génère une paire de clés publique / privée et envoie la clé publique à l’OP. L’OP crée un JWT contenant la clé publique (ou son identifiant).

Lorsque le client présente le JWT au destinataire, il doit produire la preuve-de-possession. Il présente un nonce signé avec la clé privée dans une déclaration ’cnf’.

Le destinataire peut vérifier qu’il interagit avec le client authentifié en extrayant la clé publique de la demande de confirmation du JWT (après vérification de la signature numérique du JWT) et en en vérifiant la signature du nonce.

Questions ...

Dans l’état actuel du développement exploratoire ( pas encore sur GitHub ), voici quelques questions :

- Pourquoi un malware ne serait-il pas capable de générer un PoP acceptable avec la technique décrite, puisque le code nécessaire est exposé dans l’application originale ? On obtient bien la preuve que l’application est celle avec laquelle l’utilisateur final a été authentifié. Mais cela ne veut pas dire que l’application est la bonne. Dans le cas d’une application avec back-end, l’application peut être identifiée avec certitude comme étant le modèle original. Mais dans le cas d’une application sans back-end ( une copie de l’original fournie par le serveur ), un malware peut s’exécuter dans le même user-agent, ce qui ouvre notamment la possibilité de tromper l’utilisateur (physhing) auquel il revient d’identifier l’application.

- Cela permet-il de sécuriser un flux implicite ? La clé privée est exposée dans le cas d’une application "sans backend". Même si elle est calculée à chaque fois, exposer la clé privée serait contraire au principe même de la cryptographie asymétrique et semble ôter toute valeur au PoP.

Une direction de recherche de DnC vers la PoP

Notons que l’application pour mobile DnC DnC’s IdentMaster peut être utilisée comme base de la PoP des applications installées sur le mobile considéré.

En effet, si la finalité première de DnC’s IdentMaster est d’identifier de façon certaine l’utilisateur final, elle offre quelques pierres pour l’édifice de la PoP, notamment en faisant générer par le mobile une paire de clé publique/privée, le mobile conservant la clé publique dans un espace protégé et l’OP possédant la clé publique.
Les applications sont donc en mesure d’élaborer des signatures de jeton. Il ne reste "plus qu’à" intégrer la vérification de l’intégrité des applications. Android fournit des outils pour cela.

Il existe des informations complémentaires, connectez vous pour les voir.

Notes

[1Notons toutefois que la classe Java KeyStore ( implémentées par iOS et Android) permet de protéger les clés. Cependant, la sécurité de ce dispositif n’est bien réelle que si un stockage matériel externe

[2Notons toutefois que la classe Java KeyStore ( implémentées par iOS et Android) permet de protéger les clés. Cependant, la sécurité de ce dispositif n’est bien réelle que si un stockage matériel externe