L’AS2, la sécurité de l’EDIINT.

L’AS2, la sécurité de l’EDIINT.

15 avril 2022 0

L’ EDIINT est un terme générique signifiant simplement « EDI via INTernet ». Il permet la combinaison pratique des syntaxes de l’EDI traditionnel avec les protocoles IP d’Internet. Finalement, on peut dire que l’EDIINT a été conçu par des utilisateurs EDI pour le transport des données via Internet.

Rappelons que l’EDI est le terme commun définissant un échange d’informations automatique entre deux entités informatiques à l’aide de messages dits « standardisés ». Pour plus d’information, nous vous invitons à consulter notre ebook et la vidéo dédiés à l’EDI.

Les données sont des informations sensibles qui nécessitent un transfert fiable et sécurisé. Pour répondre à ces exigences, il est important de cerner les mécanismes et entités qui œuvrent dans le cycle d’acheminement de ces contenus.

Qu’est-ce que l’AS2 ?

AS2

AS2 signifie Applicability Statement 2 et constitue un protocole de messagerie B2B utilisé pour transmettre des documents sécurisés d’une organisation à une autre à travers Internet.

L’AS2 se présente aujourd’hui comme une norme par sa capacité à assurer la sécurité dans l’EDI. Il implique deux ordinateurs, un client et un serveur, se connectant en ligne de manière « point à point ». C’est un protocole universel de transport de données utilisé par des millions d’entreprises à travers le monde.

Historiquement, l’AS2 est un protocole EDI deuxième de sa génération, créé par l’Internet Engineering Task Force (IETF) en 2002 pour remplacer l’AS1 (moins rapide, moins sûre et moins pratique).

Technologie et caractéristiques de l’AS2

L’AS2 est un protocole dont l’intérêt s’articule sur quatre caractéristiques fondamentales :

  • Authentification : l’identité de l’émetteur et du récepteur est assurée dans l’ensemble des processus.
  • Confidentialité : les échanges de donnée sont sécurisés de sorte à être visible uniquement par l’entité ciblée.
  • Intégrité : le contenu est protégé contre toute menace de falsification externe. Les données échangées à travers les processus demeurent strictement authentiques de « bout en bout ».
  • Non-répudiation : la bonne réception et la prise en compte des données envoyées sont justifiées et constituent une preuve valable.

point définition : La non-répudiation signifie la possibilité de vérifier que l’envoyeur et le destinataire sont bien les parties qui disent avoir respectivement envoyé ou reçu le message. De ce fait, la non-répudiation de l’origine permet de prouver que les données ont été envoyées, et la non-répudiation de l’arrivée prouve qu’elles ont été reçues.

Voici de manière simplifiée le processus :

schéma fonctionnement AS2

1. La préparation des documents EDI.

Bien que l’AS2 ne soit pas soumis à une limitation de format, les données à envoyer sont d’abord préparées dans un format EDI standard.

2. L’emballage AS2.

Avant d’être expédiées, ces données sont soumises à un processus de transformation plus ou moins variable en fonction de leurs natures.

– Facultativement, en fonction de la taille des données, le message peut être compressé à travers un algorithme afin d’accélérer son acheminement et éviter certaines attaques de cryptanalyse (qui se basent sur des analyses statistiques du contenu). 

– La signature : les données sont signées avec une clé privée de l’expéditeur afin de garantir son identité en tant que émetteur du message.

– Le chiffrement : le module AS2 « encapsule » le message dans une enveloppe sécurisée grâce un protocole de cryptographie S/MIME spécifique. Les données à transférer sont chiffrées avec une clé publique à disposition du système destinataire, de sorte qu’il soit l’unique récepteur en mesure de les lire.

3. La transmission des messages.

La capsule ainsi engendrée est transmise en toute sécurité via les protocoles de communications http (un renforcement supplémentaire peut être acquis en utilisant le https) que nous traitons dans cet article.

4. L’étape du déballage AS2

Le serveur destinataire du message qui est constamment en ligne, reçoit alors un paquet qui lui a été désigné. Ce paquet encapsulé intègre alors un processus de « déballage » dans lequel intervient un double contrôle :

  • la signature du document est vérifiée à l’aide de la clé publique de l’expéditeur pour confirmer sa bonne identité.
  • Les données jusque-là chiffrées sont décryptées grâce à la clé privée du destinataire.
  • Si une compression a été réalisée à l’émission, le message est décompressé.

À l’issue de ces étapes, les données EDI deviennent enfin accessibles et exploitables.

5. Le traitement EDI.

Le module AS2 récepteur transmet le document exploitable à votre système EDI afin d’exécuter la logique métier attribuée.

6. Envoie de l’accusé de réception par le Destinataire.

L’organisation réceptrice ayant finalement reçu les données, émet un MDN (Message Disposition Notification, voir ci-dessous) pour informer le système expéditeur de la bonne réception du paquet.

7. Traitement de l’accusé de réception par l’expéditeur.

L’expéditeur initial des données valide la signature de réception et vérifie à l’occasion l’intégrité du message en comparant le MIC (Message Integrity Check) du contenu renvoyé avec celui qu’il a calculé à l’origine.

Focus sur l’accusé de réception (MDN) et le principe de non répudiation

Les reçus, ou notifications de disposition de message (MDN), confirment que les partenaires commerciaux ont bien reçu les données. Ceci permet alors d’obtenir un non-déni de réception.

Il existe cinq options pour traiter les reçus, notamment :

  • Pas de reçus – un mauvais choix qui ne fournit aucune piste d’audit et peut conduire à de faux positifs pour la transmission. L’équivalent de sécurité est le retrait des piles d’un détecteur de fumée.
  • Reçus simples – reçus non signés retournés immédiatement à l’expéditeur pour afficher un reçu de message. Aussi un mauvais choix, car il est sujet à l’usurpation d’identité.
  • Reçu signé – retourné immédiatement et signé, fournissant la piste d’audit la plus solide
  • Réception simple asynchrone – un reçu simple qui est envoyé plus tard, pas immédiatement
  • Reçu signé asynchrone – un reçu signé qui est envoyé plus tard, pas immédiatement. Ceci est utile dans les situations où le message est plus volumineux et que l’expéditeur peut donc ne pas souhaiter laisser la connexion initiale ouverte en attendant qu’un MDN qui prend plus de temps à générer soit renvoyé.

L’expéditeur peut paramétrer la forme du reçu que le destinataire doit renvoyer, vous devez donc vous assurer que votre logiciel prend en charge les cinq options, car chaque partenaire peut exiger des reçus différents.

De plus, le reçu MDN contient le MIC calculé sur la « charge utile » reçue de la transmission initiale. Lorsque l’expéditeur d’origine valide le MDN, ce MIC est comparé au MIC qui a été calculé à l’origine sur la transmission AS2, de sorte que l’expéditeur reçoive une garantie que le contenu a été reçu comme emballé et sans falsification. L’utilisation de signatures sur le message et le reçu constitue alors une preuve légale de non-répudiation de réception.

Focus sur la sécurité

Le chiffrement

Les mécanismes de sécurité sont basés sur des couples de clés publiques/privées.

  • La clé publique est transmise dans un certificat de sécurité.
  • La clé privée est connue et détenue uniquement par son propriétaire.

En utilisant le certificat public du destinataire, le contenu du message AS2 est chiffré afin de sécuriser les données. Seul le destinataire pourra déchiffrer le contenu, à l’aide de son certificat privé.

Chiffrement clé publique privée

Pour chiffrer vos données au fur et à mesure que vous les transmettez via AS2, vous et votre partenaire devez utiliser et prendre en charge le même algorithme de cryptage. Les options populaires sont :

  • 168 Bit Triple DES (3DES) :
  • AES (plus récent et plus utilisé)

La signature électronique

Le rôle de cette signature réside dans sa capacité à garantir :

  • L’intégrité des données
  • L’identité de l’émetteur (authentification)

Pour y parvenir, il est question de calculer par un algorithme de « hachage » un checksum (une courte séquence de données numériques calculée à partir du texte initial à signer). Cela va permettre de vérifier par la suite que l’intégrité de ce bloc a été préservée lors de l’opération de transmission. Ce même checksum est chiffré avec la clé privée de l’émetteur et constitue alors une signature unique qui sera attachée au fichier à envoyer.

signature électronique

De l’autre côté, le destinataire reçoit le message avec la signature.
Il calcule le « hash » sur la partie donnée du message.
Ensuite, il déchiffre la signature en utilisant la clé publique de l’expéditeur.
Il compare le résultat avec ce qu’il a calculé et s’assure ainsi de l’intégrité du message original et de l’identité de son émetteur.
 
Voici le fonctionnement des opérations avec les clés :

message chiffré et signé

La clé privée de l’expéditeur permet de signer et sa clé publique disponible chez le destinataire permettra de le vérifier.
La clé publique du destinataire disponible chez l’expéditeur permet de chiffrer le message. Seule la clé privée du destinataire va permettre de le déchiffrer.

Les certificats, partie constituant de la sécurité.

certificat

Un certificat est un ensemble de données associé à la clé publique. Il contient des informations sur le propriétaire tels que le nom, l’adresse mail, la société et d’autres. Le certificat même est caractérisé par un numéro de série et des indications spécifiques à son usage.

N’importe qui peut créer un certificat. En revanche, pour qu’il soit plus fiable, il doit être crée (signé) par un organisme de confiance comme une Autorité de certification (AC) connue qui répond à critères précis.

Esalink s’engage à vous accompagner et assurer le succès de vos projets EDI au sein de votre entreprise Pour toutes questions sur l’EDI, nous vous invitons à contacter notre équipe d’experts ici.


Retour

Partager :