An Etebac5 application uses the following technical components:

• Application for orders and status management,
• Signature application to validate the orders,
• Teclommunication application for exchanging files with banks by using the PeSIT-E protocol,
• Security component for securizing the file exchange. This component is made of a smart card reader(usually the DE144), a smart card (DX) and a security DLL .

ETEBAC5 applications have already prooved their strength but have the following inconvenients:

• Applications specially used by big compagnies because of the cost of the solution.
• Integration with the Information system which implies multi-format imports/exports.
• Parameters are not easy to use.
• Slow Communications .

By using the power of the security technics of Etebac5, EASEIT provides the EB/EDI*SEC products which resolve the preceeding inconvenients.

• The files can be directily signed or checked at the output/input of the Information System.
• The signed files offer all the security services because of the the security enveloppe.
• The prroves are compatible with the GSIT format.
• The number of parameters are only the identities neededfor prooves .
• The securized files can be exchanged by mail, ftp, …
• By utilizing the PC/SC smart card readers the cost is reduced to its minimum. Finally the Etebac5 security can be utilized by SOHO.

Easy to use EB/EDI*SEC enables to sign/check or encrypt/decrypt files or data with a reduced number of requests.

EB/EDI*SEC uses the EDI5X multi-formats library, security devices such as Etebac5, CryptoAPI, PKCS11 or OpenSSL can be used. Security technics are offered directily by EDI5X, CryptoAPI, PKCS11 and OpenSSL. The security devices can be smart cards, tokens, files or other type.

EB/EDI*SEC offers Java, C interfaces and applets and can be used on client side or servers.

In 1999 EASEIT received the "OPPIDUM" innovation label for his security proposal by XML. The first implementation of this project was for the Etebac5 (XML/EDI5).

The product is provided as C library, Java interface or applet for the Web .

XML/EDI5 Specifications:

• ETEBAC5 File security for communication by internet media (Mail, Ftp,...).
• Files format independancy.
• Mutual authentication can be reached because of the security enveloppe.
• Security : integrity by SHA1, signature by RSA 1024 bits and encryption byTriple-DES (112 bits).
• Devices: floppies and smart cards.
• Smart card readers: Usual ETEBAC5 smart card readers or PC/SC.
• Utilize XML as enveloppe.
• Prooves are compatible with GSIT format.
• XSL can be used for displaying security elements.
• API as script and Java classes.
• This product should be used by compagnies and banks which developp their own applications and communications.
• Client and Server.
• Suites projects with combined Etebac5 & X509 devices.

EB/EDI*SEC can be used in multiple types of architectures. Following are some examples of these architectures. These examples can be applied to e-business, electronic banking, EDI, ....

File Transfer Architecture:

In this architecture the customer prepares his data in a connectionless mode(Payorders, Commands, Declarations, ...) . When data is prepared and  validated it can be signed by authorised signers. The data is then tarnsmitted to the partner via File Transfer or a MHS. 

The advantages of this architecture is the data preparing in the  connectionless mode, all the information is local at the customer side and the huge volumes of information which can be treated and transmitted. One of the inconveniences is the update of software modules at the customer side.

In this architecture EB/EDISEC can be utilized as library or batch commands components at the customer side, server and  the back-offices.

Full Web Architecture:

In this architecture the customer accesses to the partner via the Web and prepares its data (Payorders, Commands, Declarations, ...). When data is prepared and  validated it can be signed by authorised signers. All the (customer) databases  are located at the (partner) server side. Data are transmitted by submission. The advantanges of the architecture is the central maintenance of the application at the partner server side as well as the reduced number of the customer technical staff . One of the inconveniences of this architecture is the reduced information volume which can be submitted.

In this architecture EB/EDISEC is utilized as Java Applets at the customer side. At the server side and  back-offices EB/EDISEC can be utilized as library or batch commands components.

Mixed Web/File Transfer Architecture:

In this architecture the customer prepares its data in a connectionless mode (Payorders, Commands, Declarations, ...), then transfers the data to the partner server side by File Transfer or MHS(1).

The partner Web  server  picks the received data from the files server(2). 

The customer can then connect to the  Web server in order to validate and sign the transmitted information(3). 

In this architecture EB/EDISEC is utilized as Java Applets at the customer side (Web Access). For files transfer,  the partner server side and  back-offices EB/EDISEC can be utilized as library or batch commands components.

Alternative Mixed Web/File Transfer Architecture:

In this architecture the customer information is prepared, validated and signed via Intranet on the customer server. 

The signed data can be then transmitted to the partner server by File Transfer or MHS.

In this architecture EB/EDISEC is utilized as Java Applets at the customer side (Web Access). For files transfer,  the partner server side and  back-offices EB/EDISEC can be utilized as library or batch commands components.