Je continue cette série par le standard récent 2DDoc, inventé par la société AriadNext et porté par Cyril Murié de l'Agence Nationale des Titres Sécurisés (ANTS).
Les concepteurs de ce standard le présente ainsi : "Le standard à codes barres bidimensionnel 2D-Doc consiste en la sécurisation de données dans un code à barres signé électroniquement par la clé privée correspondant à une clé publique placée dans un certificat du type cachet serveur."
Premier constat : la fraude documentaire est facile à réaliser.
Un cas d'usage consiste à retoucher à l'aide d'une application la numérisation d'un document utilisé à des fins officielles afin de changer un élément important de ce document : une adresse, un nom, une date... tout en conservant un aspect "authentique" au document sans que cela soit facile à démontrer.
Deuxième constat : la numérisation ne veut pas dire dématérialisation et encore moins automatisation.
Beaucoup d'entreprises numérisent les documents qu'elles manipulent afin de les stocker, les reproduire, les sauvegarder plus facilement.
En sus de la numérisation, il est souvent configuré une reconnaissance de caractères afin de permettre des choix sur reconnaissance d'étiquettes identifiants, références, etc...
Cependant, numériser et la reconnaissance de caractères ne signifie pas qu'il est plus facile d'automatiser des procédés. La notion d'encodage sous forme de code barre permet une lecture plus fiable et souvent plus facile.
Pour automatiser les procédés à la réception d'un document matérialisés ou numérisés, la présence de code barre permet une meilleure réussite et moins de cas à traiter avec un agent humain.
Troisième constat : pour dématérialiser de façon efficace une chaîne complète de traitement, il faut pouvoir articuler un tronçon matérialisé.
Quand on pense dématérialisation, on doit aussi penser à rester interopérable avec des agents qui ne disposent pas de la possibilité de lire ou écrire un support dématérialisé.
Ceci est connu des éditeurs de billets électroniques. Il faut pouvoir aussi imprimer ce billet dans certains cas.
Fort de ces trois constats, la société AriadNext a proposé d'encoder dans un code à barre 2D les informations utiles du document pour un automate, comme le nom, le montant, la date, l'adresse etc..., signées cryptographiquement par l'éditeur du document qui, par cette signature, authentifie ces informations.
Ce code à barre devient ainsi un sceau d'information photocopiable, imprimable, infalsifiable, lisible par un automate avec un fort taux de réussite.
Le principal inconvénient du code barre 2D est le peu d'information que l'on peut encoder.
l'ANTS a donc standardisé cette information sur le principe :
- d'un entête de type nomenclature à tiroir
- d'un corps de message de type liste de paires clés/valeurs en normalisant les clés, le type des valeurs.
- d'une signature des informations
Les informations 2DDOC sont compatibles avec les types de l'iso 20022 et les relevés d'identité bancaire et les relevés d'identité SEPAmail (RIS) sont des documents reconnus par le standard.
Ainsi, le RIS peut être encodé comme un 2DDOC : il s'appelle alors un RIS2D.
Voici mon RIS2D 2DDoc de test avec lequel vous pouvez essayer de m'envoyer un message SEPAmail.
Quels sont les avantages ?
Ils sont nombreux :
- la fraude par retouche infographique est difficile
- l'échange d'identifiant authentifié est automatisable et plutôt ergonomique avec un smartphone
- le standard propose une structuration des documents et des informations sensibles
- la vérification peut-être déshumanisée, ce qui peut augmenter la sécurité pour les agents
- la photocopie de l'identifiant authentifiable est possible
Quels sont les inconvénients ?
L'un des plus gros inconvénients, selon moi, tient dans un des avantages.A ne plus pouvoir frauder par la retouche graphique, la fraude interne aux producteurs privés et publics de justificatifs va devenir visible.
Est-ce qu'un opérateur d'énergie ou de téléphonie va vraiment vouloir faire plus qu'authentifier un document et un montant et devenir responsable, sous son sceau et son organisation, de l'authentification d'une personne, d'une domiciliation, d'une date de naissance ?
On peut reprocher aussi au standard de ne pas expliciter suffisamment les limites d'utilisation d'une clé privée, notamment l'usure de la clé utilisée par rapport à l'usage.
Pour ceux qui liront la spécification technique, ils verront qu'il n'est pas possible de donner autre chose qu'une date limite d'utilisation, ce qui n'est pas très international. La norme possède également une limite intrinsèque liée au nombre maximum de jours depuis le 1er janvier 2000, à savoir 65535 jours donc elle ne sera plus valable en 2180 !
Enfin, par manque de place, il n'a pas été prévu de pouvoir insérer une clé publique liée à l'identifiant, ce qui aurait résolu nombre de difficultés cryptographiques d'inscription, notamment pour les relevés d'identité bancaire.
