Security Services in the RNIF
Adapter
The RNIF 2.0 protocol provides measures to enforce the following security aspects, authentication, authorization, confidentiality and message integrity.
The RNIF Adapter therefore provides the following services:
For Confidentiality
· Encryption Service
· Decryption Service
For Authentication and Authorization and Message Integrity
· Signing Service
· Signature validation Service
For Accountability
· Non-Repudiation Service
Confidentiality
Confidentiality is ensured by encryption of the message. There are two levels of encryption that are supported namely:
· Payload only: In this type of encryption, the service content as well as the optional message attachments are encrypted.
· Payload container: In this type of encryption, the service header and the service content together with the optional message attachments are encrypted.
In order to encrypt and outbound message, the public key certificate of the trading partner needs to be known and stored in the J2EE Keystore of the particular adapter engine [reference …]. The receiving party decrypts the message using the corresponding private key.
To decrypt an inbound message, the partner needs to encrypt the message using your public key certificate before sending, whereas the RNIF Adapter decrypts the payload using the corresponding private key. The public key certificate must be exchanged with the partner and the private key must be stored in the local J2EE Keystore [reference …].
Authentication and Authorization
Authentication is the act of making sure that the sender of a RosettaNet business message is the same sender claiming to send the message. during authorization, you also make sure that the sender of the message is permitted or authorized to send the subject message to the receiving partner.
A sender authenticates its identity with respect to the receiver by digitally signing a message. The signature encompasses the service header and the payload. The receiver of the message validates the authenticity of the message by verifying the signature to be valid and the subject of the signer to match the expected identity of the sender. If the identity of the sender is authenticated, the existence check against a matching receiver agreement provides for authorization. A digital signature is created using the private key, which must be maintained in the J2EE Keystore.
For signature validation of inbound messages, the public key certificate of a partner needs to be maintained, depending on the trust model in use.
In the hierarchical trust model, the identity of the sender is authenticated by validating the signature and the issuer chain of the signer’s certificate and additional checking of the subject name of the issuer against the expected partner’s identity.
In the direct trust model, the identity of the sender is authenticated by verifying the signature to be valid and by additional comparison of the signer’s public key certificate against the locally maintained, expected public key certificate of the partner. Therefore the direct trust model requires offline exchange of public key certificates, which can be self-signed or issued by a Certification Authority.
Message Integrity is ensured by digital signatures that encompass a digest of the headers and payload of the message (action or signal message).
Accountability
Non-Repudiation of Receipt Acknowledgement for outbound business action messages provides measures that allow to prove to a third party that a partner has acknowledged the receipt of a particular message and cannot deny having received that message. This option requires the business action messages and the business signal to be digitally signed. The RNIF Adapter stores the outbound action and the inbound signal in the message security archive along with the relevant agreement parameters and the certificates pertaining to the agreement.
Non-Repudiation of Origin and Content for inbound business action messages provides measures that allow to prove to a third party that a partner has in fact sent a particular business action message. This means that the partner cannot deny having sent this message. The RNIF Adapter stores the inbound action in the message security archive along with the relevant agreement parameters and the certificates pertaining to the agreement.