Symmetric Encryption
There are two primary forms of cryptography in use today: symmetric and asymmetric cryptographies. Symmetric algorithms operate with a single cryptographic key that is used for both encryption and decryption of the message. For this reason, it is often called single, same, or shared key encryption. It can also be called secret or shared key encryption because the key factor in secure use of a symmetric algorithm is to keep the cryptographic key secret.
The advantages of symmetric key algorithms are that they are usually very fast, secure, and cheap. There are several symmetric algorithm products available on the internet at no cost to the user. The disadvantages include the problems of key management and the limitation that a symmetric algorithm does not provide many benefits beyond confidentiality, unlike most asymmetric algorithms, which also provide the ability to establish nonrepudiation, message integrity, and access control. Symmetric algorithms can provide a form of message integrity—the message will not decrypt if changed. Symmetric algorithms also can provide a measure of access control—without the key, the file cannot be decrypted.
Asymmetric Encryption
When someone wishes to communicate using an asymmetric algorithm, they would first generate a key pair. Usually, this is done by the cryptographic application of the public-key infrastructure (PKI) without user involvement to ensure the strength of the key generation process. One half of the key pair is kept secret, and only the key holder knows that key. For this reason, it is often called the private key. The other half of the key pair can be given freely to anyone who wants a copy. In many companies, it may be available through the corporate website or access to a key server. That is why this half of the key pair is often referred to as the public key.
Asymmetric algorithms are one-way functions, that is, a process that is much simpler to go in one direction (forward) than to go in the other direction (backward or reverse engineering).
The process to generate the public key (forward) is simple, and providing the public key to anyone who wants it does not compromise the private key because the process to go from the public key to the private key is computationally infeasible.
Hashing
Hashing, which is defined as one-way encryption, can be very useful in addressing integrity of stored and transmitted information. It uses a mathematical function to generate a value or values from a string of text. If a user wishes to send a secure message, a hash of the intended message is generated, encrypted, and sent with the message. The receiver then decrypts the hash and the message. The receiver also creates another hash from the message. If the two hashes are identical, then a secure transmission has occurred, ensuring that the message has not been altered in any way. The hashing algorithm is called the hash function.
The hash function accepts an input message of any length and generates, through a one-way operation, a fixed-length output. This output is referred to as a hash code, or sometimes called a message digest. It uses a hashing algorithm to generate the hash but does not use a secret key.
There are several ways to use message digests in communications, depending on the need for the confidentiality of the message, the authentication of the source, the speed of processing, and the choice of encryption algorithms. The requirements for a hash function are that they must provide some assurance that the message cannot be changed without detection and that it would be impractical to find any two messages with the same hash value.
Transparent Encryption
Transparent encryption is specific to databases. It allows for the encryption of rows (tuples) and columns (attributes) of a database. This is an alternate to the encryption of the entire database where all of the database contents are exposed when unencrypted.
Transparent encryption involves having the encryption engine within the database. The keys remain external and allow access to those with a need to know while applying the appropriate protection for sensitive data.
Public-Key Infrastructure (PKI)
A PKI is a set of system, software, and communication protocols required to use, manage, and control public-key cryptography. It has three primary purposes:
- Publish public keys/certificates
- Certify that a key is tied to an individual or entity
- Provide verification of the validity of a public key
Certificate Authority (CA)
The certificate authority (CA) “signs” an entity’s digital certificate to certify that the certificate content accurately represents the certificate owner. There can be different levels of assurance implied by the CA signing the certificate, similar to how forms of an individual’s physical identification can imply differing levels of trust.
The functions of a CA may be distributed among several specialized servers in a PKI. For example, registration authority (RA) servers may be used to provide scalability and reliability of the PKI. RA servers provide the facility for entities to submit requests for certificate generation. The RA service is also responsible for ensuring the accuracy of certificate request content. The CA can revoke certificates and provide an update service to the other members of the PKI via a certificate revocation list (CRL), which is a list of nonvalid certificates that should not be accepted by any member of the PKI.
The use of public-key (asymmetric) cryptography has enabled more effective use of symmetric cryptography as well as several other important features, such as greater access control, nonrepudiation, and digital signatures.
Public Keys
Public keys are by their very nature public. Many people include them on signature lines in emails, or organizations have them on their web servers so that customers can establish confidential communications with the employees of the organization, whom they may never even meet. How does one know an imposter or attacker has not set up a rogue web server and is attracting communications that should have been confidential to their site instead of the real account, as in a phishing attack?
Setting up a trusted public directory of keys is one option. Each user registers with the directory service, and a secure manner of communications between the user and the directory is set up. This allows the user to change keys—or the directory to force the change of keys. The directory would publish and maintain the list of all active keys and also delete or revoke keys that are no longer trusted. This may happen if someone believes that their private key has been compromised, or they leave the employ of the organization. Any person wanting to communicate with a registered user of the directory could request the public key of the registered user from the directory.
X.509 Certificate
A digital certificate is a digital communication device used to convey ownership of a PKI public key owner (distinguished name). It binds the owner to the key through a hierarchical system of certificate authorities.
X.509 is an ITU-T (International Telecommunication Union Telecommunication Standardization Sector). The certificate contains the name of the certificate holder, a serial number, expiration dates, a copy of the certificate holder’s public key (used for encrypting messages and digital signatures), and the digital signature of the certificate authority (CA) so that a recipient can verify that the certificate is real.
A certificate signing request (CSR) is used to request a digital certificate. The CSR is digitally signed using the requester’s private key and contains a description of the applicant as well as their public key.
To validate the authenticity of the digital certificate, it is digitally signed by the certificate authority that issued it. Certificates may become corrupted, expire, or otherwise be invalidated. In such cases, the certificate authority lists the inactive certificate in a certificate revocation list (CRL). This list may be accessed by the recipient of a certificate to validate that it is genuine.
Key Distribution
Symmetric encryption requires that both parties have the identical key. This creates a key distribution problem. Keys may be distributed in several ways. Normally a key is not included with the encrypted message, which is referred to as in-band key distribution. Sending a key to the other party by any other method is referred to as out-of-band key distribution.
Diffie–Hellman Key Exchange
Diffie–Hellmann is a key exchange algorithm. It is used to enable two users to exchange or negotiate a secret symmetric key that will be used subsequently for message encryption. The Diffie–Hellmann algorithm does not provide for message confidentiality but is extremely useful for applications such as public-key infrastructure (PKI). Diffie–Hellmann is based on a set of calculations that each party makes and results in each party deriving the same number. This number becomes the shared secret key.
Digital Signatures
The purpose of a digital signature is to provide the same level of accountability for electronic transactions where a handwritten signature is not possible. It will provide assurance that the message does indeed come from the person who claims to have sent it, it has not been altered, both parties have a copy of the same document, and the person sending the document cannot claim that they did not send it (nonrepudiation). A digital signature will usually include a date and time of the signature as well as a method for a third party to verify the signature.
Note that a digital signature only provides message integrity and nonrepudiation of the sender. It does not encrypt the original message. Therefore, there is no message confidentiality.
Encryption Implementation
Encryption can be implemented within different phases of the cloud secure data lifecycle:
- Data in motion (DIM): Technologies for encrypting data in motion are mature and well defined, including IPSEC or VPN, TLS/SSL, and other “wire level” protocols.
- Data at rest (DAR): When the data is archived or stored, different encryption techniques should be used. The encryption mechanism itself may well vary in the manner in which it is deployed, dependent on the time frame for which the data will be stored. Examples of this may include extended retention versus short-term storage, data located in a database versus file system, etc. This module will discuss mostly data at rest encryption scenarios.
- Data in use (DIU): Data that is being shared, processed, or viewed. This stage of the data lifecycle is less mature than other data encryption techniques and typically focuses on DRM solutions.
Sample Use Cases for Encryption
The following are some use cases for encryption:
- When data moves in and out of the cloud—for processing, archiving, or sharing—we will use encryption for data in motion techniques such as SSL/TLS or VPN in order to avoid information exposure or data leakage while in motion.
- Protecting data at rest such as file storage, database information, application components, archiving, and backup applications.
- Files or objects that must be protected when stored, used, or shared in the cloud.
- When complying with regulations such as HIPAA and PCI DSS, which in turn requires relevant protection of data traversing “untrusted networks,” along with the protection of certain data types.
- Protection from third-party access via subpoena or lawful interception.
- Creating enhanced or increased mechanisms for logical separation between different customers’ data in the cloud.
- Logical destruction of data when physical destruction is not feasible or technically possible.
Related article – Cloud Encryption Challenges