Une application Etebac5 aujourd’hui est basée techniquement sur les composantes suivantes :

• Application de gestion qui génère les ordres ou récupère les relevés,
• Application de signature qui valide les ordres,
• Application de télécommunication qui échange les fichiers avec les banques en utilisant le protocole PeSIT-E,
• Composante de sécurité pour sécuriser le transfert des fichiers. Cette composante est formée d’un lecteur de cartes (généralement le OC144), une carte à puce (DX) et une DLL de sécurité.

Les applications ETEBAC5 ont su prouver leur robustesse mais posent les problématiques suivants :

• Applications qui sont surtout utilisées par les trésoriers des grandes entreprises, compte tenu du coût de l’application totale.
• Intégration avec le système d’information existant, qui nécessite des imports/exports.
• Une certaine complexité des paramétrages.
• Communications relativement lentes.

Sans mettre en cause la sécurité offerte par la norme elle-même, EASEIT propose la gamme EB/EDI*SEC qui offre les requêtes de haut niveau ETEBAC5/EDI5 et qui essaie de résoudre les problématiques cités.

• Les fichiers en sortie/entrée du système d’information, peuvent être directement signés ou vérifiés.
• Les fichiers ainsi signés offrent les services de sécurité de base, grâce à l’utilisation d’une enveloppe de sécurité.
• Les preuves sont compatibles GSIT.
• Les paramétrages sont réduits aux identités nécessaires pour une preuve.
• Les fichiers sécurisés peuvent êtres échangés par mail, ftp, …

Le format des enveloppes de sécurité peut être de type au format XML/DSIG , XML/EDI5, PKCS7, DSMS, ISIL ou S/MIME. 

Simple d'utilisation la librairie EB/EDI*SEC permet en quelques requêtes de signer et chiffrer ou de vérifier des objets signés et éventuellement chiffrés.

Comme EB/EDI*SEC utilise la librairie multiprotocolaire EDI5X, les dispositifs Etebac5, CryptoAPI, PKCS11 ou OpenSSL sont facilement utilisables. Les techniques de sécurité sont offerts par EDI5X, CryptoAPI, PKCS11 et OpenSSL. Les dispositifs de sécurité peuvent être de type carte à microcircuit, token, fichiers ou autre.

EB/EDI*SEC offre les interfaces Java, C et applets et peut être utilisé côté postes clients ou sur les serveurs.

En 1999 EASEIT reçut la label d'innovation "OPPIDUM" pour sa proposition de la sécurité par XML , qui a résulté par l'implantation du premier produit de sécurité par XML sur le marché. La première implantation de ce projet fut pour la sécurité par Etebac5 (XML/EDI5).

Le produit peut être fourni sous la forme d'une librairie C, Java ou applet (uniquement sous Windows ) pour le Web.

Caractéristiques XML/EDI5:

• Requêtes de haut niveau de signatures multiples sur fichiers et données par Etebac5 et X509.
• Support simultané X509 et Etebac5.
• Scellement DES-CBC, DES-MDC, SHA1 et MD5.
• RSA Etebac5 et RSA-PKCS1.
• Signature détachée et enveloppante.
• Chiffrement DES(56 bits) et DES3 (112 bits).
• Gestion multi-dispositifs en mode serveur.
• Génération des éléments de preuve au format Etebac5 étendu (X509 et Etebac5 ).
• Vérification d'un fichier signé et de données.
• Génération d'accusé de réception.
• Vérification d'accusé de réception.
• Indépendant des moyens de communication.
• Convient aux projets d'entreprises et bancaires avec support ou non simultané de X509 et Etebac5.

EB/EDI*SEC peut être utilisé dans diverses architectures. Les architectures suivantes sont données à titre d'exemple et peuvent être appliquées au commerce électronique, banque, ou EDI. 

• Architecture par transfert de fichiers:

  

  Le client prépare hors connexion ses données (Virements, Commandes, Déclarations, ...) . Une fois ces données saisies, formatées et validées le ou les signataires autorisés les signent.  Les données sont transmises chez le partenaire par transfert de fichiers ou par messagerie. Les avantages sont bien sûr la préparation des données hors connexion, les informations sont locales chez le client; et le volume des données peut être relativement important. L'un des inconvénients de cette architecture est la mise à jour des logiciels du client.

  EB/EDISEC peut être utilisé soit sous la forme de librairie ou de commandes batch côté client, serveur ainsi que sur les back-offices.

• Architecture full Web:

  

  Le client se connecte par le Web au serveur du partenaire et  prépare ses données (Virements, Commandes, Déclarations, ...) en mode connecté . Une fois ces données saisies, formatées et validées le ou les signataires autorisés les signent. Les diverses bases sont sur le serveur.  Les données sont transmises lors de la soumission de la page les contenant. L'avantage est la maintenabilité de l'application au point central sur le serveur; ainsi que la réduction des équipes techniques côté client.  L'un des inconvénients de cette architecture est la quantité réduite des données qui peuvent être transmises par page.

  EB/EDISEC peut être utilisé soit sous la forme Applets Java côté client. Sur le serveur et les back-offices EB/EDISEC est utilisé sous la forme librairie ou commandes batch.

• Première Architecture mixte Web et transfert de fichiers:

  

  Dans cette architecture le client ou prestataire prépare ses données (Virements, Commandes, Déclarations, ...) hors connexion, puis les transfère au serveur par transfert de fichiers ou messagerie (1). 

  Le serveur de fichiers met à disposition du serveur Web les données reçues (2). 

  Le client peur se connecter par le Web par la suite pour valider et signer les données initialement transmises (3). 

  EB/EDISEC peut être utilisé soit sous la forme de librairie ou de commandes pour les transferts des fichiers, sur les serveurs et les back-offices;  et sous la forme d'Applets Java côté client en mode Web.

   

• Deuxième Architecture mixte Web et transfert de fichiers:

  

  Les diverses données du client sont saisies ou importées sur le serveur du client, validées et signées en Intranet. 

  Les données signées peuvent être ensuite transmises au serveur du partenaire par transfert de fichiers.

  EB/EDISEC peut être utilisé soit sous la forme de librairie ou de commandes pour les transferts des fichiers, sur les serveurs et les back-offices;  et sous la forme d'Applets Java côté client en mode Web.