The product offers C and Java interfaces as well applets (under Windows) for the Web.

XML/EDI5 Specifications:

• High level security requests for Etebac5 & X509 signatures,
• XML/EDI5 envelop,
• Data, file & hash values signature by RSA ,
• Supports X509 (PKCS11 & CryptoAPI) and Etebac5 devices.
• Hash algorithms: DES-CBC, DES-MDC, SHA1 et MD5.
• Etebac5 and RSA-PKCS1 RSA mechanisms.
• Detached and attached signatures.
• Encryption: DES(56 bits) and DES3 (112 bits).
• Supports multiple devices simultaneously.
• Etebac5 Extended Proof format (X509 and Etebac5 ).
• Secured files end data security checking.
• Receipts generation.
• Receipts checking.
• Secured Files and data checking.
• Secured objects can be transmitted by any communication means
• Suitable for corporate and banking projects using both or either X509 or Etebac5 devices.

PKCS7 et derivate formats Specifications:

• High level security requests for X509 signatures.
• PKCS7,DSMS & S/MIME envelops.
• Utilizes CryptoAPI and PKCS11.
• RSA-PKCS1 Signature  on files, data & hash values.
• Simple and double signatures.
• SHA1 & MD5 hashing.
• Detached and attached signatures.
• Signature including or not timestamping.
• Supports multiple devices simultaneously.
• Signed Files and data checking.
• Receipts generation.
• Receipts checking.
• Signed objects can be transmitted by any communication means.
• Suitable for e-business, corporate and banking projects .

XML/DSIG format Specifications:

• High level security requests for X509 signatures,
• XML/DSIG envelop,
• Utilizes CryptoAPI and PKCS11.
• SHA1-RSA-PKCS1  on files and data.
• SHA1 hashing.
• Minimal Canonical Transformation.
• Detached and attached signatures.
• Base64 Presentation.
• Supports multiple devices simultaneously.
• W3C/DSIG format proofs generation.
• Signed Files and data checking.
• Receipts generation.
• Receipts checking.
• Signed objects can be transmitted by any communication means.
• Suitable for e-business, corporate and banking projects .

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.