AS4 for Dummies - Part IV: Security

• Part I: Introduction
• Part II: Messaging Overview
• Part III: Reliability
• Part IV: Security
• Part V: Are you ready for AS4?

Security is a crucial aspect of every messaging standard, so it is for AS4! This section describes the most common mechanisms to establish a secure AS4 communication.

Non-repudiation of origin

In order to guarantee message integrity, it’s important to have non-repudiation of origin. This means that the receiver is a 100% sure that the message originates from the sending party and that the message was unmodified during the exchange.

AS4 provides this evidence by applying the WS-Security signing feature on User Messages. This message signing is performed via asymmetric keys: the sender of the message signs with its own private key and the receiver authenticates the sender via the public key, which could be included in the message as a BinarySecurityToken.

According to the AS4 usage profile, the following parts of the ebMS message must be signed:

• The ebMS Messaging Header
• The SOAP Body
• All SOAP Attachments

The receiving MSH checks if the hash values within the signature correspond to the actual received payloads. If not, an ebMS Error is generated and sent to the sending MSH, according to the agreed P-Mode configuration.

Non-repudiation of receipt

Another important aspect is non-repudiation of receipt. This means that the sender is a 100% sure that receiver has received the message, without being modified during the message exchange.

AS4 provides legal proof for this non-repudiation of receipt, by applying the WS-Security signing feature on Receipts. The exchanged Receipts are signed by the receiving MSH, which authenticates the originator of the receipt. The signature of Receipts must be applied on the ebMS Messaging Header.

In addition to this signature, the ebMS Messaging Header must include Non Repudiation Information within the Receipt element. This Non Repudiation Information contains the hashes of the signed payloads of the referenced User Message. This information is verified again at the sending MSH, in order to establish evidence for non-repudiation of receipt.

Data confidentiality

Data confidentiality can be ensured on both the communication and message level.

Encryption, which ensures data confidentiality, on the communication channel could be applied by using Transport Layer Security (SSL). Due to known vulnerabilities in this HTTPS protocol, it is recommended to use TLS 1.1 or higher. TLS may be offloaded to specific infrastructure components (e.g. proxy), so an AS4 MSH does not need to explicitly offer this functionality.

Data confidentiality on the message level could be achieved by leveraging the WS-Security encryption feature on User Messages. This message encryption is performed via asymmetric keys: the sender of the message encrypts with the public key of the receiver, so the message can only be decrypted by the receiver, who owns the private key. Encryption must be applied on:

• The SOAP Body
• All SOAP Attachments

In case the receiving MSH is unable to decrypt the message, an ebMS Error is generated and sent to the sending MSH, according to the agreed P-Mode configuration.