Notre argent doit devenir plus numérique

 

Imaginez le scénario suivant : une entreprise est à court d’un certain type de matériel , très spécifique qui n’est disponible que chez un fournisseur à l’étranger. Le réapprovisionnement du matériel doit se faire dans les 24 heures au plus tard, sinon la production est arrêtée. Ce problème est détecté par le système informatique. Il commande alors de nouveaux matériaux de manière totalement autonome auprès du système du fournisseur, lequel expédie les matériaux , également de manière totalement automatique. Déclaration en douane, organisation du transport – tout fonctionne sans intervention humaine. À la douane, un ordinateur scanne les matériaux, conclut, sur la base de paramètres prédéfinis, que tout est en ordre et demande au système informatique envoyant la commande des droits de douane. Le système paierait immédiatement, mais il ne peut pas, tout au moins pour le moment. En effet, une personne doit autoriser le paiement et, normalement, il faut attendre au moins un jour ouvrable pour que la douane enregistre la réception du transfert.

Cet exemple illustre les limites de notre système de paiement actuel : des durées de traitement relativement longues, des procédures d’autorisation compliquées et un manque de fonctionnalités de livraison-paiement. Si cette situation était peut-être encore acceptable par le passé, elle pose de sérieux problèmes pour l’avenir. Car l’avenir appartient – entre autres – à l’Internet des Objets (IdO), communément appelé en anglais Internet of Things (IoT). Dès 2025, on estime que 75 milliards d’appareils seront interconnectés.  Le potentiel des nouveaux modèles commerciaux est énorme, qu’il s’agisse du dédouanement automatique sans intervention humaine, des frais de location de machines agricoles facturés en fonction de la charge utile réellement conduite ou de la commande automatique d’un réfrigérateur.

Cependant un grand nombre de ces modèles commerciaux ne pourra guère être réalisé, si les limites actuelles des systèmes de paiement persistent. Les monnaies numériques peuvent constituer la base de l’automatisation et permettre de surmonter ces limites. La Banque centrale européenne (BCE) discute l’introduction d’un euro numérique public, c’est-à-dire une forme numérique de la monnaie de la Banque centrale, destinée à favoriser l’inclusion financière et permettant aux citoyens de disposer d’un moyen de paiement numérique et sécurisé. Toutefois, même si cela devait être décidé en 2021, une telle monnaie ne sera guère une réalité avant 2026, selon le directeur de la BCE, Fabio Panetta , d’autant qu’il n’est pas certain que l’euro numérique ait les caractéristiques nécessaires aux modèles commerciaux de l’IoT. Compte tenu de la croissance de l’IoT, cette monnaie arrivera trop tard et sera trop incertaine.

La solution à ce dilemme réside dans les initiatives privées. Il est déjà possible aujourd’hui de connecter le système SEPA à une application basée sur la technologie DLT (Distributed Ledger Technology) via une solution de pont technique. Cette méthode peut être utilisée, par exemple, pour mettre en œuvre des solutions « pay per use » : le système SEPA déclenche des paiements et les paiements programmables peuvent être cartographiés sur un DLT. Cette solution de déclenchement ne supprime cependant pas les limites de SEPA. En effet, l’autorisation humaine est toujours nécessaire. La machine ou le dispositif IoT ne peut pas régler de manière autonome. Cette discontinuité des systèmes lors du traitement des paiements peut être évitée si un moyen de paiement numérique est émis et traité directement sur une DLT, plutôt que par le biais de paiements conventionnels.
La monnaie numérique basée sur DLT ne doit pas nécessairement être émise par une Banque centrale. Les banques ou les institutions financières peuvent également créer des solutions pour les paiements dits programmables. Les stablecoins basés sur l’euro – des jetons numériques adossés à une valeur monétaire donnée – en sont un exemple. Cependant, il n’existe actuellement aucune base réglementaire pour des euro stablecoins qui présentent un risque élevé de contrepartie. Néanmoins, le projet de directive européenne « Markets in Crypto-Assets » (MiCA) devrait changer cette situation et les stablecoins pourraient être transformés en monnaie électronique tokenisée. Une alternative est la monnaie scripturale tokenisée, que les institutions financières pourraient émettre. Contrairement aux stablecoins, elle aurait l’avantage de ne pas avoir une couverture à 100 %. Toutefois, en vertu des règles actuelles, une telle monnaie ne serait pas non plus multibancaire, ce qui entraîne des restrictions très importantes.

Finalement, la monnaie numérique deviendra réalité, quelle que soit la forme qu’elle prendra. C’est l’unique façon pour que l’industrie allemande puisse pleinement profiter du potentiel de l’IoT. Les automatisations plus sophistiquées dans le domaine de la logistique des marchandises ou les modèles de plus en plus courants de type « asset as a service » sont difficiles à imaginer à long terme sans paiements entièrement autonomes en temps réel. Vous trouverez des informations sur les cas d’application et plus de détails sur la conception des monnaies numériques dans le livre blanc commun intitulé « The future of payments: programmable payments in the IoT sector », que nous avons rédigé chez PPI avec nos partenaires Partnern Cash on Ledger, Digital Euro Association et Frankfurt School Blockchain Center. Cliquez ici pour télécharger gratuitement la version anglaise.


Auteurs : Anja Kamping, Philipp Schröder

Clé EBICS : quelle est la durée de la clé du succès ?

Le 21 avril 2021, un atelier de fabricants EBICS a été organisé par la Deutschen Kreditwirtschaft (DK). Les principaux ajustements apportés à EBICS inclus dans la version 3.0.1 ont été présentés. Pour moi, les adaptations cryptographiques présentées en même temps sont beaucoup plus intéressantes. Elles deviennent obligatoires pour les systèmes clients EBICS à partir de 2021. EBICS utilise 3 paires de clés RSA dans la communication : une paire pour les signatures bancaires, une paire pour l’authentification du fragment EBICS et une paire pour le chiffrement/déchiffrement des messages.

Pour EBICS V2.5, cette adaptation signifie que les signatures bancaires (clés A) doivent posséder au moins une profondeur de clé de 2 048 bits. Pour l’authentification (clé X) et le chiffrement (clé E) un compromis d’au moins 1 984 bits a été décidé, probablement du fait que les cartes à puce Seccos avec des clés de cette longueur existent sur le marché. La clé DS de ces cartes Seccos possède une longueur de clé de 2 048 bits et se trouve dans la zone spéciale de la puce de carte protégée par un PIN alternatif. 

En outre, il a été à nouveau confirmé à tous les participants qu’avec l’utilisation d’EBICS 3.0.1, toutes les clés utilisées pour l’authentification (X00x), le chiffrement (E00x) et la signature bancaire (A00x) ne peuvent plus être plus courtes que 2 048 bits.

Cela signifie pour les fabricants de produits clients qu’un processus de prolongation des clés doit être lancé prochainement, afin que tous les clients puissent facilement migrer vers la nouvelle version EBICS 3.0.1 dès novembre. Si cela n’est pas effectué, la migration vers EBICS 3.0.1 avec les clés existantes – mais trop courtes – ne sera pas possible.

Les produits clients qui n’offrent pas de changement de clé seront du retard. En effet, leurs utilisateurs doivent alors générer de nouvelles clés plus longues dans le cadre d’un processus complexe, puis faire réinitialiser leur accès à l’institution financière et ensuite procéder à une nouvelle remise des clés, y compris la remise d’une lettre INI auprès de leur institution financière. Ensuite, il faut attendre que l’accès EBICS soit à nouveau activé.

Les produits clients EBICS qui offrent à leurs clients un changement de clé doivent relever le défi que seuls les certificats X509 peuvent être utilisés dans la communication EBICS avec EBICS 3.0.1. De nouveaux processus internes sont utilisés dans les produits clients. La mise en œuvre doit donc être bien planifiée et, ne sera généralement pas facile. Cependant, TRAVIC-EBICS-Kernel de PPI AG y contribue, car le progiciel fournit les fonctions nécessaires à un changement facile. Il est recommandé de migrer également de l’ancien format de clé (RDH2) au format PKCS#12 (fichier p12) pour les fichiers clés.

Les cartes à puce représentent également un défi, car elles ne possèdent souvent pas les longueurs de clé nécessaires et doivent être remplacées – si cela est possible. 

Conclusion :
Il est temps de contacter les utilisateurs EBICS utilisant des clés courtes pour mettre à jour les clés avant la migration vers EBICS 3.0.1 ou avant novembre 2021, pour générer leurs nouvelles clés et, dans l’idéal, pour les remettre signées à leurs institutions financières avec les anciennes clés. Les utilisateurs qui ne veulent pas communiquer les exigences de clés applicables à partir de novembre 2021 risquent de faire face à un dysfonctionnement catastrophique de leurs accès EBICS.

Auteur : Michael Schunk