As shared in How Asymmetric Cryptographic approaches enhance Security and Accountability of Data in Web Applications / REST Web Services?, Authenticated Encryption as a concept, is considered to be the Holy Grail, when addressing Data Security and Authenticity concerns, and it works by combining an Encryption Scheme and a Message Authentication Code (MAC), in either Symmetric or Asymmetric Cryptographic approach, to enhance the security of the overall ecosystem, all depending on how the system is implemented.

Target Audience

Solution Architects and Application Developers, who use different programming languages like PHP, Java, Python, Node.js etc… and who work in Fintech / Healthcare and any other industry where Data Security & Privacy is of utmost importance.

Purpose

The purpose is to create a brief outline of how Authenticated Encryption technique can be implemented when using Asymmetric Cryptographic approaches.

The Asymmetric Key Pairs and corresponding Certificates can be generated using any of the following algorithms, or some others too:

a) RSA as both Encryption & Digital Signature Algorithm (with 2048 bit key as a minimum requirement, and up to 4096 bit key, as a recommended option), when Integer Factorization Cryptography is chosen.

b) Curve 25519 as Encryption Algorithm and ED25519 as Digital Signature Algorithm, when Elliptic Curve Cryptography is chosen.

The following procedure outline is created by considering RSA Algorithm, as an Example Choice, to the explain the applicable procedure.

Arsenal of a Payment Gateway

1. Two Asymmetric Key Pairs, i.e., one for Encryption (A Certificate and a Private Key) and another for Digital Signature (A Public Key and a Private Key).
2. A Secure Key Storage Solution (like A Software Vault / Key Management Service (KMS) / Hardware Security Module (HSM) etc…).
3. A Server-side Programming Language, to handle the Security Keys, along with rest of the Payment Gateway Application.

Arsenal of a Merchant

1. Two Asymmetric Key Pairs, i.e., one for Encryption (A Certificate and a Private Key) and another for Digital Signature (A Public Key and a Private Key).
2. A Secure Key Storage Solution (like A Software Vault / Key Management Service (KMS) / Hardware Security Module (HSM) etc…).
3. A Server-side Programming Language, to handle the Security Keys, along with rest of the Merchant Application.

Internals

I. When Merchant initiates Transaction Request to the Payment Gateway,

• Encrypt the Transaction Request, with the Encryption specific RSA Certificate of the Payment Gateway.
• Digital Sign the Transaction Request, with the Digital Signature specific RSA Private Key of the Merchant.

II. How Payment Gateway handles the Transaction Request, that is received from the Merchant,

• Verify the Digital Signature of the Transaction Request, with the Digital Signature specific RSA Public Key of the Merchant.
• Decrypt the Transaction Request, with the Encryption specific RSA Private Key of the Payment Gateway.

III. When Payment Gateway sends Transaction Response to the Merchant,

• Encrypt the Transaction Response, with the Encryption specific RSA Certificate of the Merchant.
• Digital Sign the Transaction Response, with the Digital Signature specific RSA Private Key of the Payment Gateway.

IV. How Merchant handles the Transaction Response, that is received from the Payment Gateway,

• Verify the Digital Signature of the Transaction Response, with the Digital Signature specific RSA Public Key of the Payment Gateway.
• Decrypt the Transaction Response, with the Encryption specific RSA Private Key of the Merchant.

Which Certificates and Keys will have to be Exchanged between the Payment Gateway & Merchant?

For Transaction Requests / Response to happen, the following RSA Keys / Certificates will have to be shared by the Merchant, and with the Payment Gateway.

• Digital Signature specific RSA Public Key of the Merchant.
• Encryption specific RSA Certificate of the Merchant.

For Transaction Requests / Response, the following RSA Keys / Certificates will have to be shared by the Payment Gateway, and with the Merchant.

• Digital Signature specific RSA Public Key of the Payment Gateway.
• Encryption specific RSA Certificate of the Payment Gateway.

Summary:

“Encrypt then Mac” is the recommended Authenticated Encryption approach, and while there are algorithms that does both Encryption and Digital Signature in a single step, my personal choice is to do this separately, in most of the scenarios and suggest the same to all Solution Architects and Application Developers out there.

P.S. This article was originally posted on Linkedin Pulse on May 17, 2019. https://www.linkedin.com/pulse/how-authenticated-encryption-using-asymmetric-secures-dendukuri/