Data being the Oil of today’s and tomorrow’s economy, when Compliance gets the limelight w.r.t. Data Security, the immediate thing that people look for is,

• How Data is Securely Stored?
• How Data is Securely Transmitted?

The popular phrases for the above are Data at Rest and Data in Transit and while Symmetric Cryptographic options serve well in resisting aggressive cryptanalytic attacks (specifically when AES kind of well vetted Symmetric Encryption Algorithms are used in conjunction with appropriate key length, Un-predictable IV and encryption mode choices), Asymmetric Cryptographic options fare well too, despite their resource hungry nature and relative slow performance, when easy key sharing options takes the priority, with appropriate algorithms and reasonable key length choices in place.

In this Connected World, one might think, which Encryption Strategy is promising enough, that simultaneously provides Data Confidentiality, Integrity and Authenticity, for Individuals / Businesses / Governments to trust and depend upon?

Authenticated Encryption as a concept, is considered to be the Holy Grail, when addressing these concerns, that works by combining an Encryption Scheme and a Message Authentication Code (MAC) and a right set of choices can drastically enhance the security of the overall ecosystem, all depends on how the system is implemented.

Irrespective of whether the Authenticated Encryption process is handled in a single step or in two different steps, and beyond the debate of which Authenticated Encryption mode is better for a general purpose application, the following are the modes, that are used in several popular applications:

• Encrypt and MAC
• MAC then Encrypt
• Encrypt then MAC

While making a choice among the above, is Subjective to the Application Requirements and Architect’s preferences, a brief info about the different approaches is being shared below, before a convention is suggested, for a general purpose application.

Encrypt and MAC:

In this approach, the Plaintext is first encrypted to obtain Ciphertext and a MAC is generated based on the same Plaintext. Then, both Ciphertext and MAC are sent as part of the communication. This concept is popularly used in SSH Protocol, whose daemon is designated to run on Port 22 as per Internet Assigned Numbers Authority (IANA).

MAC then Encrypt:

In this approach, a MAC is generated based on the Plaintext, and then, both Plaintext and the previous generated MAC are encrypted to obtain Ciphertext in the second step. Then, this Ciphertext, that already contains the MAC of the Plaintext, is sent as part of the communication. This concept is popularly used in SSL/TLS Protocol.

Encrypt then MAC:

In this approach, the Plaintext is first encrypted to obtain Ciphertext and as a latter action, a MAC is generated based on the obtained Ciphertext (in previous step). Then, this Ciphertext and MAC are sent as part of the communication. This concept is popularly used in IPSec (a site to site VPN solution Framework).

To Summarize, Encrypt then MAC , is the only Authenticated Encryption approach, that can be considered as the most secure option available, for all general purpose applications provided, a very strong and unforgeable MAC generating algorithm is used in the mix, that prevents Chosen Ciphertext Attacks.

When it comes to Asymmetric Cryptography, there are many popular approaches like Integer Factorization Cryptography (example: RSA Algorithm), Elliptic Curve Cryptography (example: Curve25519), that has potential to serve in the scope of Authenticated Encryption.

The following is a Use case wherein, Easy Key Exchange is among the high priority concerns and Asymmetric Cryptographic Algorithms (RSA / Curve25519 etc…), in conjunction with the chosen “Encrypt then MAC” Authenticated Encryption approach, when executed in a two-step process, helps store / transmit data in a secure way, while ensuring Confidentiality, Integrity and Authenticity through out, that became a basic expectation of Customers, in today’s Web Applications and all connected Internet of Things experiences.

In Asymmetric Cryptography, Digital Signature is performed in the scope of MAC generation on the subject (Plaintext / Ciphertext, as per chosen Authenticated Encryption approach).

Securing Data at Rest using Elliptic Curve Cryptography

Encryption Algorithm: Curve25519

Digital Signature Algorithm: ED25519

• Separate Keypair Generation: This requires a Separate Keypair each, to be generated, among which, one is for the Encryption purpose and the other is for the Digital Signature purpose, using respective algorithms.
• Encrypt and Create Digital Signature: The process is simple, and as explained in the Encrypt then Mac Authenticated Encryption approach in the above, all incoming Plaintext is subjected to the described two-step process, using the Encryption Public Key, to obtain the Ciphertext and the Signature Private Key for creating the Digital Signature of the Ciphertext and the result will be stored in the Data store (file system / databases etc…).
• Verify Digital Signature and Decrypt: When retrieving Content, from the Data store, the Digital Signature of the Ciphertext is first validated using the Signature Public Key and only if it is correct, corresponding Ciphertext will be subjected to the Decryption process, using Encryption Private Key and the resultant Plaintext be delivered as response to the initial request. Any anomaly with the Digital Signature Verification, when noticed, the application can simply consider the case in the scope of Data manipulation and immediately log the event and trigger necessary alerts (Email / SMS etc… as deemed necessary) to all concerned personnel and systems, as per the application operating procedures.

Securing Data in Transit using Integer Factorization Cryptography

Encryption Algorithm: RSA

Digital Signature Algorithm: RSA

• Separate Keypair Generation: This requires a Separate Keypair each, among which, one is for the Encryption purpose (wherein, a Self Signed Certificate is among the additional requirements), and the other is for the Digital Signature purpose, using designated algorithms.
• Encrypt and Create Digital Signature: The process is simple, and as explained in the Encrypt then Mac Authenticated Encryption approach in the above, all incoming Plaintext is subjected to the described two-step process, using the Encryption specific Self Signed Certificate, to obtain the Ciphertext and the Signature Private Key for creating the Digital Signature of the Ciphertext and the result will be stored in the Data store (file system / databases etc…).
• Verify Digital Signature and Decrypt: When retrieving Content, from the Data store, the Digital Signature of the Ciphertext is first validated using the Signature Public Key and only if it is correct, corresponding Ciphertext will be subjected to the Decryption process, using Encryption Private Key and the resultant Plaintext be delivered as response to the initial request. Any anomaly with the Digital Signature Verification, when noticed, the application can simply consider the case in the scope of Data manipulation and immediately log the event and trigger necessary alerts (Email / SMS etc… as deemed necessary) to all concerned personnel and systems, as per the application operating procedures.

While the above setup can secure the Data in Transit and at Rest, it is advisable to always use HTTPS for all endpoints as that can surely act as a standard abstraction, preventing possible data leaks, when / if encryption libraries and / or programming language level issues arise and it’s worth it, as I believe, Prevention is always Better than Cure.

As shared above, while Encrypt then Mac is a recommended strategy for general purpose applications, sometimes using a combination of Authenticated Encryption approaches like “Encrypt then Mac” and any other one like “Encrypt and Mac” may be helpful, for specialized use case scenarios only.

The above concepts can be implemented in the application scope, using any supported Algorithm, in the programming language the application is implemented in (example: PHP / Java / Node.js etc…), all with out any dependency on the Data store (example: MySQL / MariaDB / MongoDB etc…).

In addition to the above, there are many other concepts like Secure Key Storage, Security Keys Life Cycle Management, Secure Storage of Database Access Credentials & API Keys, Secure Programming Practices, Secure Devops Practices, Role Based Access Control for Application requirements and Server Infrastructure, optional Web Application Firewall usage in the server etc, all has to be handled in an accountable way, for security of the data and trust of the customers to prevail. This can serve as a minimal guideline, for Secure Application Development activity in Fintech, Healthcare and many other sectors, where compliance requirements are mandated in the name of PCI Compliance, HIPAA Compliance and adherence to Aadhaar Act (applicable for applications, that store 12 digit Aadhaar Number of Indian Nationals).

Accountability is the Keyword of 21st Century.

This article is written more in the application architect and developer perspective than with a Cryptographer / Cryptanalyst’s experience. I do welcome everyone to share your feedback.

P.S. This article was originally posted on Linkedin Pulse on August 11, 2018. https://www.linkedin.com/pulse/how-asymmetric-cryptographic-approaches-enhance-data-web-dendukuri/