Principles related to Security

From documentation SEPAmail
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
This page is a translated version of the page Principes de sécurité and the translation is 92% complete.
Outdated translations are marked like this.

Modèle:TOC:security

There are several security-related principles in the SEPAmail system.

  • Independence of the security environments
    • Customer - bank / bank – bank / bank – customer
    • Each connection between security environments goes through a member belonging to the security environment (bank)
  • Authentication
    • SEPAmail missives must be signed in an S/MIME format (encryption with the secret key of the missive’s sender). This ensures the authentication of the missive’s sender and the integrity of the missive.
    • SEPAmail messages can be signed by the sender of the message and this signature is transported to the recipient, thereby ensuring the authentication of the sender of the message.
  • Digital signature
    • A digital signature, also called electronic signature, is possible for the message by harmonizing the common rules within the network of the SEPAmail members. This topic is addressed in the SAPPhire protocol.
  • Confidentiality
    • Confidentiality is ensured by encrypting the missives with the recipient’s S/MIME public key.
  • Traceability
    • All elements must be monitored and must be able to be produced as proof.
    • They must remain associated with their duly authenticated sender and recipient
  • Exchange of information
    • Web Service using SSL (HTTPS+SOAP or HTTPS+REST)
    • SMTP

Signature of messages

The possibility of signing the messages is performed by incorporating an XML schema signature, thereby enabling communication related to the feasibility of a principle.

The implementation of a technique for the signature of messages will depend on the type of message and especially how the application using the message is contractually performed:

  • GEMME Mandate (non-testing phase):
    • A signature of the response message - as an independent verification by the creditor - can be a positive point, providing the creditor has the necessary resources to implement the control of the signature.
    • However, a liability shift from the creditor’s bank to the debtor’s bank can also be used. In this case, there would be a contractual arrangement between banks and receiving a missive signed by the creditor’s bank could be sufficient. In the event of a dispute with the creditor, the debtor’s bank undertakes to accept the responsibility.
    • Ultimately perhaps both types of flows will be used, depending on customer needs.
  • RUBIS Settlement:
    • There is no need for a notion of signature for the response message. The transfer is irrevocable and this is sufficient in most cases.
    • Ultimately, a missive signed by the bank may be sufficient as the bank has made a contractual commitment to the other banks to honour the data in this missive. For example, sending back a missive in which there is a message to guarantee the transfer is a commitment by the debtor’s bank. It is that bank’s responsibility to have performed the appropriate verifications regarding its debtor.

The most important need for the signature of messages concerns the JASPE service. As this point is currently being studied, it may be said that the ' ' 'signature of messages' ' ' is not a function which is presently being considered.

Independence of the Security Zones

SEPAmail proposes to transport data along independent security zones as described below:

au moins trois espaces de sécurité indépendants
au moins trois espaces de sécurité indépendants

The security zones are the following:

  • the security zone between each member and its customer, according to the existing channels (e.g. ATM, remote banking, branch, call centre, mobile application)
  • the security zone between two SEPAmail members, implemented as defined in the SEPAmail standard.

Other languages: