Nonrepudiation overview

Nonrepudiation is a security mechanism that is used in business-to-business transactions to establish the sender, the receiver, and the contents of the file that is transmitted.

If a trading partner repudiates the sending or receiving of messages or receipts, nonrepudiation enables your organization to prove to have received or sent a message from or to a trading partner. Nonrepudiation involves two levels of security as follows:
  • Nonrepudiation of the messages that are received or sent - Both the sending and the receiving parties save the message that is exchanged (the business document and the attachments) in its original format. The sending message service handler (MSH) saves a message before it sends the message, and the receiving MSH saves the message before it processes the message.
  • Nonrepudiation of the receipts that are sent after a message is received - To acknowledge the receipt of a message, the receiver of a message sends a receipt. You can agree to send or receive a signed receipt, adding more security. With signed receipts, you can verify the authenticity of the responding organization or individual, and also verify the content integrity.

When signed messages are exchanged with the trading partner, the receipt contains the ebbpsig:NonRepudiation-Information (nonrepudiation element). The nonrepudiation element contains the digest of the message that was sent, to the trading partner. The sender validates the digest with the original message that was sent to ensure that the message was not modified by an intruder during the transmission.

Nonrepudiation storage

In AS4 Microservice, you can configure a nonrepudiation storage bucket (from the command line by using the storage provisioning wizard command) to store the raw request and response (for both inbound and outbound flows). During a transaction, the raw request and response are stored in the nonrepudiation bucket irrespective of inline payload setting for the AS4 receiver.

Additionally, you can divulge the raw request and response that is stored in the nonrepudiation bucket to a custom archiving location (a file system location) at specified time intervals. For information about configuring the nonrepudiation storage bucket and the divulge parameters, see the following topics:
  • Provisioning storage from the command line
  • Planning buckets and variants
  • Setting up divulging
  • Divulge storage blobs as files
  • system properties file

Audit logging for nonrepudiation

Visibility events that are related to the following audit events (emitted during a transaction) are stored (for nonrepudiation purposes):
  • Security audit events - Certificates that are used in a message exchange are logged in the audit log. You can use the certificates in the audit log (whenever required) to verify the integrity of the message that was exchanged during the transaction. The following properties are logged in the audit log for security audit events:
    • Signature hash algorithm
    • User name (if user name token authentication is enabled)
    • Subject ID
    • Credential ID
  • Raw request and raw response audit events - The raw request and the raw response that are received and sent are logged in the audit log. You can use the raw request and raw response to prove nonrepudiation. The following properties are logged in the audit log for raw request and raw response audit events:
    • Source IP address - In an inbound flow, this is the IP address of the source from which the request was received and from where the response was generated is logged.
    • Destination IP - In an outbound flow, this is the IP address of the destination to which the request or response is sent is logged.