The electronic certificate is an essential element in setting up protected areas. It allows its holder to authenticate (authentication certificate), provide a signature (signature certificate), establish a secure connection, etc. For access and signature control functions, applications use a certificate to authenticate the holder and control information integrity. There are numerous certificate issuers today (banking sector, administration, companies ...).
The applications for the digitalisation of data streams are diverse and affect all sectors of the economy. They require the establishment of protected areas where it must be possible to technically identify and authenticate the various actors and verify the quality of the transactions and their issuers.
As a rule, an application must be able to accept certificates from different certification authorities, because in a global world it would be too costly and equally too restrictive to require one certificate per application from a holder.
EBICS and signed certificates
To communicate with financial institutions, EBICS users with a T or TS profile must use X.509 certificates. If the user has certificates signed by a certification authority (CA), these must be validated when downloading the keys and, for example, for orders of the order type FUL. The order types for the submission and amendment of certificates (INI, HIA, H3K, PUB, HCA and HCS) support both a single certificate and certificate chains.
Validation of the CA-based certificate
The validation of the CA-based certificate can be performed externally or internally (for EBICS TS). It is now possible to check internally submitted certificates in TRAVIC-Corporate. For this, the revocation list annotations are checked using certificate revocation lists (CRL). The certificate revocation lists must be downloaded from the Internet. To download the SWIFT certificate revocation lists, a client certificate is usually required for TLS communication.
Interface for checking internal certificates of TRAVIC-Corporate for EBICS TS
Among other parameters, TRAVIC-Corporate's provider interface includes the check of certificate, a caching strategy, the storage of non-repudiation files and a preliminary check of ES authorisations (EBICS TS) according to CFONB specifications. The provider can be specified and activated via the name of its class.
The certificates are checked against a truststore stored in TRAVIC-Corporate. The entire certificate chain is checked up to the valid root certificate. No external services are used to check certificates.
As components of TRAVIC-Corporate, a job server and a parser control this processing. The payment order is released if the signature profile of the EBICS user matches the signature profile configured at the level of the customer's order type.
The financial institution can thus rely entirely on its TRAVIC-Corporate solution without having to resort to third parties, thus simplifying the system architecture and reducing costs.
Zaher Mahfouz
Sources: PPI TRAVIC-Corporate, CFONB, X.509 standards
0 comments:
Post a Comment