Tu peux détailler pourquoi tu penses que "lien opération/montant/destinataire" n'est pas établi avec webauthn/TOTP ? (Sachant que les applis mobiles utilisent les mêmes principes...).
Le principe final de génération du code peut être basé sur TOTP. C’est la chaîne complète qui fait que les systèmes standard reposant uniquement sur TOTP ne répondent pas aux obligations légales.
Si tu prends par exemple Aegis sur Android, une banque ne pourrait pas s’en servir.
La seule présence de la fonction de backup de Aegis annihile la certification DSP2. Il requalifie le facteur de possession en facteur de seule connaissance, et donc la 2FA en 1FA.
Le secret est accessible « en clair » dans le téléphone et n’est pas write-only comme dans les applications mobiles bancaires (enclave matérielle généralement) ou en tout cas avec des mesures de protection interdisant l’export du secret sur un autre téléphone.
Ensuite parce que Aegis ne permet pas, ou vraiment pas facilement, d’afficher à côté de l’OTP les données contextuelles (opération réalisée, montant, destinataire...).
Il n’existe aucun moyen, et encore moins certifié permettant à la banque d’envoyer ces infos à Aegis, et de garantir à cette banque que l’accès à l’OTP a été impossible sans voir ces informations, et des informations correctes (typiquement que Aegis n’a pas un bug qui affiche les montants en centimes au lieu d’euro, ou des dollars à la place des euro, ou que le nom d’affichage a été tronqué ou modifié...).
Même à supposer que Aegis ait une telle fonction, étant modifiable par l’utilisateur (puisque logiciel libre), tu pourrais très bien supprimer cette obligation vérifiée/auditée/certifiée par la banque. En cas de contestation, tu reporterais alors la responsabilité pénale et financière sur ta banque, puisque tu pourrais très facilement prouver que tu n’avais pas l’info au moment de l’OTP, ou en tout cas démentir que c’était bien le cas.
Tu comprends maintenant pourquoi les banques veulent aussi s’assurer et de l’authenticité du téléphone (non root) et de l’authenticité de l’application (certification Google ou Apple).
Pour éviter un soft modifié et donc avoir la certitude que ce qu’elles attendent est bien ce qu’il va se passer.
Elles en obtiennent la garantie que l’OTP a été validé par une application certifiée par elles, et dont elles ont même la preuve crypto au moment de la validation de l’OTP que l’application était légitime et non modifié. Elles peuvent donc prouver en cas de contestation que tu ne pouvais qu’avoir connaissance du contexte au moment où tu as validé l’OTP et donc que tu en étais dorénavant le seul responsable pénal et financier. C’est un process littéralement impossible, sinon extrêmement complexe, sur un écosystème libre.
On pourrait très certainement « en théorie » envisager des solutions libres répondant aux problèmes (non répudiabilité, qualification, non modification, envoi et affiche des données contextuelles...), mais « en pratique » complexes, difficiles à certifier, posant des problèmes de compatibilité (Une banque change son SI ? Une législation évolue ? Ah ben va falloir requalifier tout ça...).
Et « en pratique » la banque a du coup tout intérêt à faire sa solution à elle, dans son application à elle, qu’elle maîtrise elle-même, qu’elle certifie elle-même, qu’elle peut modifier quand elle le souhaite, pour y intégrer ce qu’elle veut, le niveau de détail qu’elle veut, plutôt que de se limite au PPCM de l’intégralité du marché. Tout est plus simple, plus contrôlable par elle, etc.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 2.
Le principe final de génération du code peut être basé sur TOTP. C’est la chaîne complète qui fait que les systèmes standard reposant uniquement sur TOTP ne répondent pas aux obligations légales.
Si tu prends par exemple Aegis sur Android, une banque ne pourrait pas s’en servir.
La seule présence de la fonction de backup de Aegis annihile la certification DSP2. Il requalifie le facteur de possession en facteur de seule connaissance, et donc la 2FA en 1FA.
Le secret est accessible « en clair » dans le téléphone et n’est pas write-only comme dans les applications mobiles bancaires (enclave matérielle généralement) ou en tout cas avec des mesures de protection interdisant l’export du secret sur un autre téléphone.
Ensuite parce que Aegis ne permet pas, ou vraiment pas facilement, d’afficher à côté de l’OTP les données contextuelles (opération réalisée, montant, destinataire...).
Il n’existe aucun moyen, et encore moins certifié permettant à la banque d’envoyer ces infos à Aegis, et de garantir à cette banque que l’accès à l’OTP a été impossible sans voir ces informations, et des informations correctes (typiquement que Aegis n’a pas un bug qui affiche les montants en centimes au lieu d’euro, ou des dollars à la place des euro, ou que le nom d’affichage a été tronqué ou modifié...).
Même à supposer que Aegis ait une telle fonction, étant modifiable par l’utilisateur (puisque logiciel libre), tu pourrais très bien supprimer cette obligation vérifiée/auditée/certifiée par la banque. En cas de contestation, tu reporterais alors la responsabilité pénale et financière sur ta banque, puisque tu pourrais très facilement prouver que tu n’avais pas l’info au moment de l’OTP, ou en tout cas démentir que c’était bien le cas.
Tu comprends maintenant pourquoi les banques veulent aussi s’assurer et de l’authenticité du téléphone (non root) et de l’authenticité de l’application (certification Google ou Apple).
Pour éviter un soft modifié et donc avoir la certitude que ce qu’elles attendent est bien ce qu’il va se passer.
Elles en obtiennent la garantie que l’OTP a été validé par une application certifiée par elles, et dont elles ont même la preuve crypto au moment de la validation de l’OTP que l’application était légitime et non modifié. Elles peuvent donc prouver en cas de contestation que tu ne pouvais qu’avoir connaissance du contexte au moment où tu as validé l’OTP et donc que tu en étais dorénavant le seul responsable pénal et financier. C’est un process littéralement impossible, sinon extrêmement complexe, sur un écosystème libre.
On pourrait très certainement « en théorie » envisager des solutions libres répondant aux problèmes (non répudiabilité, qualification, non modification, envoi et affiche des données contextuelles...), mais « en pratique » complexes, difficiles à certifier, posant des problèmes de compatibilité (Une banque change son SI ? Une législation évolue ? Ah ben va falloir requalifier tout ça...).
Et « en pratique » la banque a du coup tout intérêt à faire sa solution à elle, dans son application à elle, qu’elle maîtrise elle-même, qu’elle certifie elle-même, qu’elle peut modifier quand elle le souhaite, pour y intégrer ce qu’elle veut, le niveau de détail qu’elle veut, plutôt que de se limite au PPCM de l’intégralité du marché. Tout est plus simple, plus contrôlable par elle, etc.