Skip to content

What is the difference between Encryption and Signing? Why should you use digital signatures?

Introduction

Threats loom ever present in our digital world, which is why methods of securing data are constantly advancing. Tactics like encryption are used every day on sensitive data-at-rest or in-motion. Encryption is the process of putting data in the form of plaintext into an encryption algorithm, and producing a ciphertext. Ciphertext is a form of data where all the patterns of letters that create words in the plaintext are scrambled into a new text that cannot be read without decrypting the data. Encryption uses a key to ensure the ciphertext cannot be deciphered by anyone but the authorized recipient.

Signing of data works to authenticate the sender of the data and tends to implement a form of encryption in its process. The process of signing emails, sensitive data, and other information has become necessary, as it verifies the identity of the sender and ensures the data has not been altered in transit. If a Man in the Middle attack occurred and the data was altered or compromised by the attacker, the recipient of the information would know that this has occurred. The attacker could alter the data, but as they do not have the key used by the sender to sign the data, the recipient of the data will know not to trust the sent data when analyzing the key and data.

How does digital signing work?

The process of digital signing works similarly to encryption. Encryption comes in two types, asymmetric and symmetric encryption. The process of asymmetric encryption works by creating a key pair with a public and private key. The private key is kept secret from everyone but the creator of the key, while the public key is available to everyone. The data is encrypted with the private key, and decrypted when needed with the public key. Symmetric encryption only uses one key for both encryption and decryption. As asymmetric encryption is more secure than symmetric encryption, it tends to be used more often. When sending data to a recipient, the correct method of encryption is to encrypt the data with the recipient’s public key, as this means only the owner of the key pair can decrypt that data.

Digital signing works oppositely. The data is signed by hashing the message with a hashing algorithm and the sender’s private key. This produces a hash digest, which can only be recreated through use of one of the keys in the key pair created by the sender. The recipient then receives the message, the hash digest, and the public key, if they did not already have it. The recipient then uses the sender’s public key to hash the message they have received. If the resulting hash digest matches the hash digest that has been sent along with the message, then the identity of the sender has been confirmed. This also confirms that the data has not been changed in transit. However, signing alone does not ensure the data has not been intercepted and read.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

Encryption and Signing

To protect data from compromise and authenticate the sender at the same time, encryption and digital signing are used together. They are also both used in tandem to fulfill compliance standards for companies. Standards, like the Federal Information Processing Standards (FIPS) or the General Data Protection Regulation (GDPR), require companies to protect data as securely as possible along with authenticating data received from others. Encryption and digital signing ensures these standards are reached, and that users can be secure in the knowledge that data that is sent to and from them will not be compromised.

Confidential or sensitive data should always be encrypted and signed for its own safety. The use of encryption and signing together ensures that the main goals of cryptography, Confidentiality, Integrity, Authenticity, and Non-Repudiation are all met. Confidentiality and integrity are reached when data is encrypted asymmetrically, as only the intended recipient can decrypt the message. Non-repudiation and authenticity occur due to digital signing. Non-repudiation means that using the technique of digital signing, the sender of any information cannot, in the future, say they did not send the data, as the use of their private key confirms that they sent the data.

Common Encryption and Signing Algorithms

Symmetric Encryption Algorithms:

Asymmetric Encryption Algorithms:

Signing Algorithms:

  • RSA
  • ElGamal Encryption System
  • Digital Signing Algorithm (DSA)
  • ECDSA

Why should you use digital signatures

Digital signatures offer several advantages in the realm of information security and authentication. Here are some key reasons why you should use digital signatures:

  • Authentication

    • Identity Verification

      Digital signatures provide a way to verify the identity of the sender or creator of a digital document or message. This is crucial for ensuring that the information has not been tampered with and comes from a trusted source.

    • Non-repudiation

      Digital signatures make it difficult for the signer to deny their involvement in creating or sending a document. This is important in legal and business transactions where proof of origin or consent is needed.

  • Integrity

    Digital signatures ensure the integrity of the signed data. If any changes are made to the document after it has been signed, the signature becomes invalid. This helps to detect and prevent unauthorized alterations to the content.

  • Data Integrity

    Digital signatures not only protect the integrity of the document but also ensure the integrity of the entire data transmission. Any tampering during transmission can be detected through signature verification.

  • Non-repudiation

    Non-repudiation is a key concept in digital signatures. Once a document is signed, the signer cannot deny their involvement or claim that they didn’t sign it. This is crucial in legal and contractual contexts.

  • Efficiency and Convenience

    Digital signatures streamline processes by eliminating the need for physical signatures and paperwork. This leads to faster and more efficient transactions, especially in the digital business environment.

  • Security

    Digital signatures use cryptographic algorithms to secure the signing process. As a result, they are highly resistant to forgery and tampering. The use of private and public key pairs adds an extra layer of security

  • Compliance

    In many industries and regions, the use of digital signatures is mandated by laws and regulations for specific types of transactions. Adhering to these standards ensures compliance with legal requirements.

Conclusion

Encryption and digital signatures are robust security measures and complicated to manage. CodeSign Secure from Encryption Consulting simplifies signing individual files, whole applications, or codes in batches. It also manages digital certificates, timestamps the code for immutability, and guarantees broad platform compatibility for signed code.

CodeSign Secure goes beyond basic code signing by providing enhanced security features and robust audit trails. It is CA/Browser Forum standard-compliant following to assure the credibility of the code signing certificates. It also supports the automation of the code signing process by allowing integration with the software development and deployment pipelines. CodeSign Secure offers diverse access controls and provides a safer environment with enhanced transparency to perform code signing efficiently.

What is the difference between Encryption and Tokenization? Which is better for data security?

Introduction

Encryption is the process of using an algorithm to transform plaintext information into a non-readable form called ciphertext. In simpler terms, encryption takes readable data and alters it so that it appears random. Encryption helps protect the confidentiality of digital data either stored on computer systems or transmitted through a network such as the Internet. When the intended recipient accesses the message, the information is translated back to its original form, in a process called decryption. To unlock the message, both the sender and the recipient must use a secret encryption key — a collection of algorithms that scramble and unscramble data back to a readable format.

What is Tokenization?

Tokenization is the process of replacing sensitive data elements (such as a bank account number/credit card number) with a non-sensitive substitute, known as a token. The token is a randomized data string which has no essential value or meaning. Unlike encrypted data, tokenized data is undecipherable and irreversible because there is no mathematical relationship between the token and its original number. There is no key or algorithm, that can be used to derive the original data for a token. Instead, tokenization uses a database, called a token vault, which stores the relationship between the sensitive value and the token. The real data in the vault is then secured, often via encryption.

Tokenization aims to safeguard sensitive information while maintaining its usefulness for business purposes. Although tokens are distinct values, they retain key characteristics of the original data, such as its length or format, allowing for seamless integration into ongoing business processes. Meanwhile, the original confidential data is securely stored in an external location, separate from the organization’s internal systems.

Furthermore, in machine learning, tokenization is crucial for feature extraction, transforming textual data into a numerical format suitable for model training. Beyond NLP, tokenization finds application in data security and blockchain, where it involves converting sensitive information into tokens to enhance privacy and reduce the risk of exposing confidential data during transactions or storage.

How data Tokenization works

Tokenization is one of the most popular security measures that merchants, payment processors, and banks use to protect sensitive financial and personal information from criminals.

For example, tokenization in banking protects cardholder data. While processing payment using the token stored in the systems, only the original credit card tokenization system can swap the token with the corresponding primary account number (PAN) and send it to the payment processor for authorization. The systems never record, transmit, or store the PAN—only the token. For tokenization to be effective, organizations must use a payment gateway to safely store sensitive data.

A payment gateway is a merchant service offered by an e-commerce application service provider that permits direct payments or credit card processing. This gateway stores credit card numbers securely and generates the random token.

Encryption vs Tokenization

While both tokenization and encryption enhance data security, their approaches differ. Tokenization focuses on replacing data with unrelated tokens, minimizing the exposure of sensitive information, and simplifying compliance with data protection regulations. Encryption, on the other hand, secures data by converting it into an unreadable format, necessitating a decryption key for access.

CriteriaEncryptionTokenization
Working processTransforms plaintext into ciphertext using an encryption algorithm and keyReplaces sensitive data with a randomly generated token value
Kinds of Supported DataStructured data such as payment cards, and unstructured data, such as entire files and emailsStructured data such as payment card, social security numbers, etc
Use Cases
  • In-person transactions
  • Payments over the phone
  • One of the main use cases is to ensure the confidentiality of data-at-rest (even if the storage media is compromised or lost, attackers are not able to see the actual data as they don’t have the keys)
  • Card-on-file payment
  • Recurring Payments
  • E-commerce transactions
  • Storing customer data across multiple locations
  • One of the main use cases is to reduce PCI scope by passing tokens to downstream applications.
Exchanging DataData can be exchanged with a third-party or recipient who has the encryption keyExchanging data is difficult since it requires direct access to a token vault mapping token value
Security StrengthOriginal sensitive data leaves the organization, but in encrypted formOriginal sensitive data never leaves the organization
OutputOutput is not generally format or length preserving (e.g. AES, RSA); exception FPE- Format preserving EncryptionOutput is format and length preserving
MappingMay or may not use encryption as a mapping function, could use a hash function or static mapping tableEncryption does not have any use of tokenization internally

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

What should your business use: Tokenization or Encryption?

The choice between encryption and tokenization is not always straightforward. Whether your organization should opt for tokenization or encryption will depend on your own unique requirements. If you want to stay compliant while reducing your obligations under PCI DSS, you can opt to use tokenization. If you want scalability, and must encrypt large volumes of data, then encryption is ideal since you only need an encryption key. But regardless of which one you choose for protecting private information, both tokenization and encryption can help satisfy regulatory requirements imposed by PCI DSS, HIPAA-HITECH, GLBA, ITAR and the upcoming EU Data Protection Regulation.

When to consider Encryption

Data encryption can efficiently apply a protective layer to large volumes of data without encumbering data transmission, or access by the recipient. In fact, for many general data protections use cases, data encryption offers the best mix of convenience, practicality, and security. Consider encryption for:

  • Unstructured data, large volumes of data: Where your enterprise transmits large amounts of data such as images or video footage, data encryption can provide effective protection without incurring large costs. Likewise, where data lacks the type of structure (ID numbers, credit card details, etc.) that is required for token association, encryption is a suitable alternative.
  • Lower compliance requirements. Some data requires Fort Knox-like protection, and regulation such as PCI compliance and HIPAA demands matching protective measures. Other data sets require merely adequate protection, with an associated reduced motive for data theft. In these cases, encryption is the most cost-effective protective measure.

Encryption Advisory Services

Encryption Consulting assist organizations to identify the key risks for their organization by conducting data encryption assessment. This also helps in understanding the capability maturity and any gaps that may exist in your organization. Based on this assessment, a data encryption strategy is developed, along with a roadmap that defines the components and capabilities of the data protection program and implementing an encryption plan end-to-end.

To learn more about Encryption Consulting’s advisory services, go to the following link: Encryption Advisory Services

What is the difference between Encryption and Compression? What order should they be done in?

Introduction

The Digital Age we live in requires more and more data to be sent at one time, but this can quickly become an issue for the hardware sending the data. If too much data is sent across a connection, it could take hours or days to transfer, when the recipient needs it in minutes. This is where compression comes in. Compression uses patterns in data to shorten the size of the data, saving bandwidth and storage space in the process. This works well, but what if the compressed data is stolen in transit? Compression is not complicated to reverse so retrieving the original would be easy. This is why many people use encryption and compression together when sending messages.

What is Compression and how it works

Compression is a process that reduces the size of a file or data, typically to save storage space, speed up data transmission, or improve efficiency in various applications. There are two main types of compression: lossless and lossy. In compression algorithm any phrase that is repeated gets stored once. This means that if a certain string of characters is repeated somewhere in the text, it is only stored the first time. The second time it occurs as a reference to the first occurrence, therefore when a text occurs multiple times it is very efficiently compressed so the size is smaller. This characteristic can be used in a compression side channel attack. Here’s how it works:

  • Redundancy Removal

    Compression algorithms identify and eliminate redundancy in the data. Redundancy can occur in the form of repeated patterns, duplicate information, or unnecessary details. By removing redundancy, the compressed data representation becomes more efficient.

  • Dictionary-based Compression

    Some compression algorithms, such as Lempel-Ziv-Welch (LZW), use a dictionary-based approach. They build a dictionary of frequently occurring patterns and replace them with shorter codes. This is particularly effective for compressing text or data with recurring sequences.

  • Entropy Coding

    Entropy coding techniques, like Huffman coding, assign shorter codes to more frequently occurring symbols and longer codes to less frequent ones. This exploits the statistical distribution of symbols in the data to achieve .

  • Quantization (Lossy Compression)

    In lossy compression, quantization is applied to reduce the precision of certain data, sacrificing some details. For example, in image compression, color values may be rounded, leading to a loss of color accuracy but a reduction in file size.

  • Transform Coding (e.g., Discrete Cosine Transform)

    Transform coding involves converting the data into a different domain where the information is more concentrated. In image and video compression, the Discrete Cosine Transform (DCT) is commonly used for this purpose.

Encryption and Compression

Encryption can be either symmetric or asymmetric. Symmetric encryption is the less complicated of the two, using one key to encrypt and decrypt data. Symmetric encryption is much faster than asymmetric encryption, but is not as secure. Only one key needs to be compromised to compromise the original data. Asymmetric encryption uses a public and private key pair to encrypt plaintext data. The plaintext is run through the encryption algorithm along with a private key, which only the sender knows. The data is then sent to the recipient, who uses the public key to decrypt the data. This ensures the identity of the sender of the data, as the public key only decrypts data encrypted with the private key in that pair.

Using encryption and compression, larger portions of data can be sent across the Internet securely. If only compression is used, the security of the data is at risk. A Man in the Middle attack could retrieve the data, decompress it, and read the original message. On the other hand, if only encryption were used, there is a limit to how big a message that is encrypted can be. This is why the majority of messages are both encrypted and compressed. The next question to answer is do you compress the data and then encrypt the data, or vice versa?

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

Encryption or Compression first?

The choice of encrypting or compressing data first depends on the types of attacks you need to circumnavigate. Initially, it was thought that the only way to combine encryption and compression was to compress the data before encryption. This is due to the fact that compression relies on patterns in data to function, while encryption attempts to destroy these patterns in data. The method of compression then encryption has been found to be weak to side channel attacks. These types of attacks use JavaScript code to perform a brute force attack on the victim’s browser, allowing the attacker to infer what the transmitted data is based on the size of that compressed data.

Though this issue was found with the method of compression then encryption, encryption then compression has many more issues comparatively. This method is more difficult than the previous method, because compression needs patterns in data to work correctly. This means the value of compressing data will not exist, as there should be no patterns in encrypted data. Due to this, differential cryptanalysis can be used against this method to determine the sensitive data’s value. Compression then encryption is much more resilient to differential cryptanalysis.

Common Encryption and Compression Algorithms

Symmetric Encryption Algorithms:

Asymmetric Encryption Algorithms:

Hashing Algorithms:

  • Deflate
  • Huffman Coding
  • LZ77

What is the difference between Encryption and Hashing? Is Hashing more secure than Encryption?

Introduction

In the data security field, encryption and hashing are commonly compared, but why is this the case. Encryption is a two-way function where data is passed in as plaintext and comes out as ciphertext. Plaintext is what you are reading in this article, whereas ciphertext is text made unreadable via encryption. Since encryption is two-way, the data can be decrypted so it is readable again. Hashing, on the other hand, is one-way, meaning the plaintext is scrambled into a unique digest , through the use of a salt, that cannot be decrypted. Technically, hashing can be reversed, but the computational power needed to decrypt the hash digestit makes decryption infeasible. You can make decryption even more complex by salting a hash as well. A salt is random data that is used in the hashing algorithm to further complicate the hash digest. The salt is then stored with the hash value in a database. You would usually use a salt in hashing if you want to increase the complexity of the hash digest, without making it more complicated for password users, if you are hashing passwords.

The way hashing works is with that the plaintext is passed into a hashing algorithm which then generates the hash digest. The hashing algorithm itself does different mathematical calculations on the plaintext data to generate that hash digest. This algorithm is most effective when it is collision resistant. Collision resistance means that all the digests are unique and do not overlap with each other. This means that the hashing algorithm must be complex enough to not have overlapping hashes, but not so complex as to take too long to compute hashes. Encryption comes in two different types, and both encryption and hashing have several common types of algorithms.

Common Encryption and Hashing Algorithms

Encryption comes in two types: Asymmetric and Symmetric. Asymmetric encryption uses two different keys, a public and private key, for encryption and decryption. The private key is used to encrypt data, and is kept a secret from everyone but the person encrypting the data. The public key is available for anyone, and is used for decryption. Using asymmetric encryption, the authenticity of the data can be verified, because if the data was modified in transit, it would not be able to be re-encrypted with the private key. Symmetric encryption uses the same key for both encryption and decryption. This type of encryption uses less processing power and is faster, but is less secure as only one key is used.

Symmetric Encryption Algorithms:

Asymmetric Encryption Algorithms:

Hashing Algorithms:

  • Message Digest Algorithm (MD5)
  • Secure Hashing Algorithm (SHA-1 [Deprecated], SHA-2, SHA-3)
  • WHIRLPOOL
  • TIGER
  • Cyclical Reduction Check (CRC32)

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

Hashing and Encryption Use Cases

Though they are similar, encryption and hashing are utilized for different purposes. One of the uses for hashing is to compare large amounts of data. Hash values are much easier to compare than large chunks of data, as they are more concise. Hashing is also used for mapping data, as finding values using hashes is quick, and good hashes do not overlap. Hashes are used in digital signatures and to create random strings to avoid duplication of data in databases too. As hashing is extremely infeasible to reverse, hashing algorithms are used on passwords. This makes the password shorter and undiscoverable by attackers.

Encryption, on the other hand, tends to be used for encrypting data that is in transit. Data being transmitted is data that needs to be read by the recipient only, thus it must be sent so that an attacker cannot read it. Encryption hides the data from anyone taking it in the middle of transit and allows only the decryption key owner to read the data. Other times encryption would be used over hashing is for storing and retrieving data in databases, authentication methods, and other cases where data must be hidden at rest but retrieved later.

When to use hashing

In general, hashing is valuable in situations where you need a fixed-size representation of data, want to verify data integrity efficiently, or require a quick and uniform distribution of data in various applications such as security, data retrieval, and distributed systems. Hash functions are commonly used in various computer science and information security applications. Here are some scenarios when hashing is particularly useful:

  1. Data Integrity Verification

    Hashing is commonly used to verify the integrity of data. By generating a hash value (checksum) of a piece of data and comparing it to a previously computed hash value, one can quickly determine if the data has been altered. This is crucial in ensuring the integrity of files during data transmission or storage.

  2. Password Storage

    Hashing is essential for securely storing passwords. Instead of storing actual passwords, systems store the hash values of passwords. During login attempts, the entered password is hashed and compared to the stored hash. This way, even if the hashed values are compromised, the original passwords are not easily recoverable.

  3. Digital Signatures

    Hash functions are a fundamental component of digital signatures. In digital signature schemes, a hash of the message is signed by a private key. Recipients can verify the signature using the sender’s public key and comparing the computed hash with the received hash value.

  4. Cryptographic Applications

    Hash functions are widely used in cryptographic protocols and algorithms. They play a role in message authentication codes (MACs), key derivation functions (KDFs), and various other security mechanisms to ensure data integrity and authenticity.

  5. Hash Tables and Data Retrieval

    Hash functions are used in hash tables, a data structure that allows for efficient data retrieval. By mapping keys to indices in an array using a hash function, hash tables enable quick lookup operations.

When to encrypt data

Encrypting data is crucial in scenarios where confidentiality and privacy are paramount. Here are several situations in which encrypting data is highly recommended:

  1. Data Transmission

    When transmitting sensitive information over networks, such as during online banking transactions, accessing email accounts, or making online purchases, encrypting the data ensures that even if intercepted, it cannot be easily understood by unauthorized parties. Secure protocols like HTTPS use encryption to protect data during transmission.

  2. Stored Personal Information

    Personal information, including financial records, medical records, and identification details, should be encrypted when stored on devices or servers. This helps safeguard the data from unauthorized access, particularly in case of device theft or data breaches.

  3. Database Security

    Databases containing sensitive information, such as user credentials, credit card details, or proprietary business data, should use encryption to protect against unauthorized access. Encryption mechanisms like Transparent Data Encryption (TDE) can be employed to encrypt entire databases or specific columns.

  4. Backup and Storage

    Data backups and storage, whether on physical devices or in the cloud, should be encrypted. This safeguards the information in case of data loss or theft of storage media.

  5. Laptops and Mobile Devices

    Encrypting data on laptops, mobile phones, and other portable devices is essential. If these devices are lost or stolen, encryption prevents unauthorized individuals from easily accessing the stored data.

Comparisons

EncryptionHashing
DefinitionA two-way function that takes in plaintext data, and turns it into undecipherable ciphertext.A one-way method of hiding sensitive data. Using a hashing algorithm, hashing turns a plaintext into a unique hash digest that cannot be reverted to the original plaintext, without considerable effort.
Reversible or Irreversible?ReversibleIrreversible
Variable or Fixed Length Output?Variable LengthFixed Length
TypesAsymmetric and SymmetricHashing
Common AlgorithmsAES, RC4, DES, RSA, ECDSASHA-1, SHA-2, MD5, CRC32, WHIRLPOOL

AWS S3 – Client and Server Side Encryption

Encryption is one of the most basic requirements for ensuring data privacy, especially for end-to-end protection of data transmitted across networks. Plain text is encrypted using an encryption algorithm and an encryption key. Encryption converts the readable text to an unreadable text which is called ciphertext (encrypted data).

In today’s blog, we will discuss various encryption options of the AWS Simple Storage Service known as S3. S3 is highly reliable, secure, and inexpensive compared to on-premises (On-prem) data storage for storage-intensive applications e.g. Hadoop EMR. S3 stores the data as objects called “Buckets” and each object can be up to 5 TB in size.

Encryption Methodologies

AWS S3 offers both encryption methodologies, Encryption in Transit and Encryption at Rest.

Encryption in Transit

Encryption in Transit for Amazon S3 can be facilitated with the help of SSL/TLS at the client end as well as with the below similar bucket policy at the bucket level:

{
  "Id": "Policy1600282742195",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1600282739517",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:s3:::mysecures3buket",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      },
      "Principal": "*"
    }
  ]
}

Encryption at Rest

Encryption at Rest can further be classified into Client-side encryption and Server-side encryption as well. For both server-side and client-side encryption, AWS utilizes AES-256 with Galois Counter Mode (GCM) for any symmetric key encryption operations. GCM provides authenticated encryption by adding a unique tag to the ciphertext which verifies that the encrypted data has not been tampered with in any way.

Client-side Encryption

In Client-side encryption, the data is encrypted before sending it to the S3 bucket. To implement Client-side encryption in S3, we have the following two options:

  • Use a CMK (customer master key) stored in AWS KMS (Key Management Service)
  • Use a Customer provided master key stored in the customer’s proprietary application

Note: Your client-side master keys and your unencrypted data are never sent to AWS. It’s really important that you manage your encryption keys with the utmost care. If you lose them, you can’t decrypt your data.

Server-side Encryption

In Server-side encryption, the data is encrypted after being sent to the S3 bucket and before storing it in the S3 bucket.

Server-side encryption has the following three options:

  1. Use Amazon S3-managed keys (SSE-S3)In this, the key material and the key will be provided by AWS itself to encrypt the objects in the S3 bucket.
  2. Use CMK (Customer Master key) in AWS KMS (SSE-KMS)In this, key material and the key will be generated in AWS KMS service to encrypt the objects in S3 bucket.
  3. Use a Customer provided encryption key (SSE-C)In this, the key will be provided by the customer and Amazon S3 manages the encryption and decryption process while uploading/downloading the objects into the S3 bucket.

With SSE-S3, Amazon S3 managed Server-side encryption uses one of the most secure block Ciphers, AES -256 (Advanced Encryption Standard) bit, to encrypt each object with a unique key which means no overlapping keys are used for encrypting the objects. Also, these unique keys are encrypted with a Master key which is rotated regularly to yield additional data security.

With SSE-KMS, Amazon S3 uses the AWS KMS functionality to encrypt the data in the S3 bucket. Combining Amazon S3 with the AWS KMS provides a perfect blend of security and availability.

Tailored Cloud Key Management Services

Get flexible and customizable consultation services that align with your cloud requirements.

Learn More

Diagrammatic illustration of how SSE-KMS works

  1. CMK, using the encryption algorithm (AES-256), creates two keys, one is a plaintext data key and the other is an encrypted data key.

  2. While uploading the object to the S3 bucket, S3 encrypts the object with the plaintext data key. The encrypted object (Ciphertext) along with the encrypted data key is then stored in S3.

  3. While downloading the object from the S3 bucket, S3 sends the encrypted data key to KMS. KMS matches the correct CMK, then it decrypts the encrypted data key and sends the plaintext data key to S3. S3 then downloads the object by decrypting the object with this plaintext data key.

While using SSE-KMS, you can have the following combinations:

  1. Customer Managed CMK (Customer Master Key)This is a use case where you want to have complete control over the CMK i.e. you may create, rotate, disable, audit, and have complete access control who can use it. If you want to use Customer Managed CMKs, you can create it under the AWS KMS console before using it at the S3 level.
  2. AWS Managed CMK (Customer Master Key)This is a use case where you do not specify a Customer Managed CMK. To facilitate the process for users, Amazon S3 automatically creates an AWS managed CMK in the AWS account the first time that you add an object encrypted with SSE-KMS to a bucket. By default, Amazon S3 uses this CMK for SSE-KMS.

Note: All requests (GET and PUT) for an object encrypted by SSE-KMS will give an error if they are not made via https or using SigV4. Amazon SigV4 is an authentication mechanism supported by Amazon S3 for signing the API requests. This enables Amazon S3 to perform the sender/source identification and protects your requests from bad actors.

  • Server-side encryption encrypts only the object data, not the object metadata.

With SSE-C, Amazon S3 performs Server-side encryption with customer-provided encryption keys. With the encryption key provided by the user, Amazon S3 manages the encryption and decryption process while writing and accessing the data on disks consecutively. Since the management of encryption and decryption is taken care of by Amazon S3, there is no requirement to manage the code at the user level. The only requirement from a user perspective is to manage the encryption keys.Amazon S3 uses AES-256 bit encryption to encrypt the data with the customer provided key and removes the key from its memory post completion of the encryption process whereas, in the decryption process, it first verifies and matches if the same key is provided (which was provided during the encryption) and then decrypts the data and make it available to the user.

Note: Amazon S3 does not store the encryption key, rather, it stores a randomly salted HMAC (hash-based message authentication code) value of the encryption key to validate future requests. The salted HMAC value cannot be used to derive the actual encryption key or to decrypt the contents of the encrypted data which means if you lose the encryption key, you lose the data.

Comparison of S3 encryption options

S3 offers multiple options to encrypt the data in the S3 bucket. The following table summarizes all the available options to encrypt the data at rest and data in transit:

 Encryption at RestEncryption in TransitSymmetric Key EncryptionAsymmetric Key EncryptionResponsible party for Data encryption/decryptionResponsible party for Secret Storage
AWS:SecureTransportNYYYAWSAWS
SSE-S3YNYNAWSAWS
SSE-KMS (AWS managed CMK)YNYNAWSAWS
SSE-KMS (customer managed CMK)YNYNAWSAWS
SSE-CYNYNAWSCustomer
AWS SDK + KMS (AWS managed CMK)YNYNCustomerAWS
AWS SDK + KMS (customer managed CMK)YNYNCustomerAWS
AWS SDK + self-managed secretYNYYCustomerCustomer

Conclusion

Amazon S3 is very well suited if you have an environment with various applications generating a large amount of data. The very reason to choose S3 is not only the fact that it can store the mammoth volume of data at cheaper rates, but it’s durable, scalable, and highly available as well. Data privacy and compliance are vital when it comes to data security, which can be achieved using various encryption methods that Amazon S3 offers. With the use of multiple S3 encryption options, you can relax without worrying about any data being compromised.

Certificate Authority – Hierarchy and Usage

Security and safety on the internet are essential, and individuals and organizations often have a legitimate need to encrypt and verify the identity of the individuals they are communicating with.

A certificate authority is a trusted entity that issues digital certificates. A certificate authority performs three major tasks:

  • Issues certificates
  • Certifies the identity of the certificate owner
  • Proves the validity of the certificate

Digital Certificates

A certificate, or a digital certificate, is a set of data to verify an entity’s identity. Certificates are issued by CAs and follow a specific format (X.509 certificate standard).

The information contained in a certificate is:

  • Subject

    Provides the name of the computer, user, network device, or service that the CA issues the certificate to.

  • Serial Number

    Provides a unique identifier for each certificate that a CA issues.

  • Issuer

    Provides a distinguished name for the CA that issued the certificate.

  • Valid From

    Provides the date and time when the certificate becomes valid.

  • Valid To

    Provides the date and time when the certificate is no longer considered valid.

  • Public Key

    Contains the public key of the key pair that is associated with the certificate.

  • Signature Algorithm

    The algorithm used to sign the certificate.

  • Signature Value

    Bit string containing the digital signature.

learn more about digital certificate – Digital Certificate and Windows Certificate Stores | Encryption Consulting

How Does a Certificate Authority Work?

The process for getting a certificate authority to issue a signed certificate is explained below:

  1. The requestor or client creates a key pair (public and private key) and submits a request known as a certificate signing request (CSR) to a trusted certificate authority. The CSR contains the public key of the client and all the information about the requestor.
  2. The CA validates whether the information on the CSR is true. If so, it issues and signs a certificate using the CA’s private key and then gives it to the requestor to use.
  3. The requester can use the signed certificate for the appropriate security protocol:

Uses of a Certificate Authority

Certificate authorities issues various types of certificates, one of which is an SSL certificate. SSL certificates are used on servers and are the most common certificate that an everyday user would come in contact with. The three levels of an SSL certificate are

  • Extended Validation (EV)
  • Organization Validation (OV)
  • Domain Validation (DV)

Certificates with higher levels of trust usually cost more as they require more work on the part of the certificate authority.

  1. Extended Validation (EV)

    These Certificates provide the highest level of assurance from the certificate authority that it has validated the entity requesting the certificate.During verification of an EV SSL Certificate, the owner of the website passes a thorough and globally standardized identity verification process (a set of vetting principles and policies ratified by the CA/Browser forum) to prove exclusive rights to use a domain, confirm its legal, operational and physical existence, and prove the entity has been authorized the issuance of the certificate. This verified identity information is included within the certificate.

    For example: An individual requesting an EV certificate must be validated through face-to-face interaction with the applicant as well as review of a personal statement, one primary form of identification, such as a passport or driver’s license, as well as two secondary forms of identification.

  2. Organization Validation (OV)

    OV certificates take security assurance and require human verification of the organization’s identity.OV SSL certificates assures visitors that they’re on a website run by an authentic business. Before an OV certificate is granted, a member of the security team must contact the business to confirm that the owners actually requested the SSL certificate.

  3. Domain Validation (DV)

    Domain Validation certificates are the easiest to get among all the other certificates, since no manual identity check takes place.DV SSL Certificates require only that the applicant demonstrate ownership of the domain for which the certificate is being requested.DV certificates can be acquired almost instantly and at low to no cost. For example: ACM Cert Manager’s DNS or Email validation.

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Learn More

Certificate authorities also issue other types of digital certificates:

  1. Code Signing Certificates

    Code signing certificates are used by software publishers and developers to sign their software distributions. End-users use these to authenticate and validate software downloads from the vendor or developer.

  2. Email certificates

    Enable entities to sign, encrypt, and authenticate email using the S/MIME (Secure Multipurpose Internet Mail Extension) protocol for secure email attachments.

  3. Device certificates

    Issued to internet of things (IOT) devices to enable secure administration and authentication of software or firmware updates.

  4. Object certificates

    Used to sign and authenticate any type of software object.

  5. User or client certificates

    Used by individuals for various authentication purposes.

Client-Server Authentication via Certificate Authority (CA)

The CA establish a digital certificate also known as an SSL/TLS certificate that binds a public key to some information related to the entity that owns that public key. This enables any system to verify the entity-key binding of any presented certificate.

  1. The first step is finding out if the CA is a trusted CA. The CA name is taken from the certificate and compared to a list of trusted CA’s provided by the web browser. If the CA name is found to be a trusted CA, the client will then get the CA’s corresponding public key to use in the next validation step.
  2. In this step, the digital signature on the server’s certificate will be validated. It is basically the hash of the CA’s Public key.
  3. To validate the digital signature, the client hashes the CA’s public key with the same hash algorithm used by the CA to get the digital signature.
  4. If the two hashes match then the digital signature is valid and the certificate is authenticated. If the hashes do not match then the certificate is invalid and cannot be authenticated.
  5. Certificate expiration dates also need to be checked to validate the certificate.
  6. Once a certificate is authenticated, the identity of the owner of the certificate will be authenticated as well.

CA Hierarchy options

CAs are hierarchical in structure, and there are generally three types of hierarchies: one-tier, two-tier, and three-tier.

Single/One-Tier Hierarchy

In this type of hierarchy, the single CA is both an Issuing CA and a Root CA. The Root CA is installed as an Enterprise CA, leaving the Root CA in the network as a member of a specific domain. In short, the Root CA is always available to issue certificates to requesting users, computers, network devices etc.

This single-tier hierarchy is not recommended for any production scenario because with this hierarchy, a compromise of this single CA equates to a compromise of the entire PKI.

Two-Tier Hierarchy

A two-tier hierarchy meets most company’s needs. This design comprises an offline Root CA and an online Subordinate issuing CA. In this model, the level of security is increased because the Root CA is detached from the network, so the private key of the Root CA is better protected from any compromises. The two-tier hierarchy also increases scalability and flexibility, since there can be multiple Issuing CAs subordinate to the Root CA. This allows CAs to exist in different geographical locations, as well as at different security levels.

Three-Tier Hierarchy

In a three-tier CA hierarchy, an offline Root CA is installed as a standalone Root CA, and one or more offline Intermediate/Policy CAs and one or more issuing CAs are installed as Enterprise Subordinate CAs. The Policy CA is configured to issue certificates to the Issuing CA which is restricted in what type of certificates it issues. One of the reasons the second layer is added in this hierarchy is that if you need to revoke a number of CAs due to a key compromise, you can perform it at the Second level, leaving other “branches from the root” available. It should be noted that Second Tier CAs in this hierarchy can, like the Root, be kept offline.

Conclusion

A certificate authority plays the key role of facilitating secure communication and building trust between a user and a resource by verifying that the organization and client in question are authentic or valid.

For a complete list of the recommendations for planning a CA hierarchy, along with the level of business impact at which you should consider implementing them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.

AWS Certificate Manager Private CA

E-commerce businesses are going to be ever more dependent on digital economy and electronic information which enables them to have exacting data privacy compliance and data security framework.

Public Key Infrastructure (PKI) is becoming quintessential to build and map the secure relation between users, devices, services and Organizations to their digital identities in the form of digital signatures and certificates.

To all the crypto engineers out there, have you ever thought of a PKI implementation with minimalistic configuration and a fully scalable feature set comprising of all the benefits which Cloud implementation has to offer?

Welcome to AWS Certificate Manager Private Certificate Authority (ACM PCA). ACM PCA offers almost all the same features provided by On-prem PKI providers.

Let’s understand the PKI offerings from AWS

AWS offers two services in the Cloud PKI space

  1. AWS Certificate Manager Is an AWS managed service known as ACM which provisions SSL/TLS based X.509 public certificates used for various purposes (e.g Web Server Authentication etc.). This service is targeted at customers who need a secure web existence using TLS certificates.ACM deploys certificates using AWS integrated services –
    • Amazon
    • CloudFront
    • Elastic Load Balancing
    • Amazon API Gateway
    • and other integrated services.

    Enterprises with a secure public website with significant web traffic will prefer this certificate management service which offers auto renewal, multi domain support and a hassle-free certificate management experience.

    Note: Kindly note that you can’t export the SSL/TLS public Certificate from the ACM, as the ACM doesn’t allow users to export the private keys of certificates.

  2. AWS Certificate Manager Private Certificate Authority Is an AWS managed private CA service, also known as ACM PCA, which provisions X.509 certificates. The ACM PCA is most suited for small and medium enterprise customers who desire to build their own Public Key Infrastructure (PKI) within AWS Cloud and distributed for private use within the organization. Within a private CA, users can create their own CA hierarchy and issue certificates for authenticating internal users, applications, services, IOT devices etc.

Now, let’s discuss the various Two-tier Cloud PKI Models offered by AWS for ACM PCA:

  1. Private Cloud: In this environment, both the Root CA and Subordinate CA exist in the AWS Cloud.
    Private Cloud
  2. Hybrid Cloud: In this environment, the Root CA exists in an On-prem data center, whereas the Subordinate CA is in the AWS Cloud. This requires you to have the Root CA (On-prem) sign the CSR for the Subordinate CA in the AWS Cloud.
    hybrid cloud

In the Private Cloud architecture, you can host the Root CA or Subordinate CA in the AWS Cloud and use it for all your certificate needs, On-prem as well as Cloud infrastructure. In the Hybrid Cloud architecture, however, you can host the Root CA On-prem and the Subordinate CA in the AWS Cloud for all the certificate requirements of the enterprise.Both these models have their pros and cons. The “Private Cloud Model” provides you all the cloud benefits (high availability, ease of management, access control etc.), but, as a security best practice approach, you might want to have full control over your Root CA with all the cryptographic keys being managed in the On-prem HSM which you don’t have in this approach.On the other hand, the “Hybrid Cloud Model” provides you with complete control over your On-prem Root CA, however, this adds some complexity to the overall architecture by hosting two CAs (Root and Subordinate CA) at different places (On-prem and AWS Cloud).Note: There are various combinations possible for placing the CAs (Root/Policy/Subordinate/Issuing) either in On-prem or Cloud environment/s depending upon the architectural needs of the Organization (like Management of CA lifecycle, DR planning etc.)

Tailored Cloud Key Management Services

Get flexible and customizable consultation services that align with your cloud requirements.

Learn More

Let’s deep dive more on the ACM PCA Service

With ACM Private CA, you can create a hierarchy of certificate authorities with up to five levels i.e. the root CA, at the top of a hierarchy tree can have as many as four levels of subordinate CAs. You may create multiple hierarchies, each with its own root as well.

The ACM PCA can issue X.509 end-entity certificates for creating encrypted channels, authenticating users, computers, API endpoints, and IoT devices, code signing scenarios and also implementing Online Certificate Status Protocol (OCSP) for obtaining certificate revocation status.

As mentioned, ACM PCA provides X.509 certificates to the end-entity; if AWS Certificate Manager issues a private certificate, the certificate can be associated with any service that is integrated with ACM (e.g. Amazon CloudFront, Elastic Load Balancing, Amazon API Gateway etc.). This is applicable in both scenarios, like the Root CA can be in the AWS Cloud or not, but, the Subordinate CA can only be in the AWS Cloud. Also, if you use the ACM Private CA API or AWS CLI to issue/export a private certificate from ACM, you can install the certificate anywhere depending upon your use-case.

After provisioning the ACM private CA, you can directly issue certificates without having any validation requirement from any third-party CA and as per the customization for your enterprise internal needs. A few of the standard use-cases are:

  • Provision certificates with any subject name/ expiration timeline.
  • Improving the uptime through the automated workflows for certificate management
  • Restraint certificate issuance using templates.

ACM PCA offers the shared responsibility model for AWS Cloud Security in which “Security of the Cloud” belongs to AWS and “Security in the Cloud” belongs to the “Customer”. This shared security model could be implemented with the help of AWS Data Protection services (e.g. Macie, IAM, Cross Account Access, Logging, Monitoring, Audit Report etc.).

As a final note, I would like to draw your attention to some of the best practices to effectively use ACM PCA:

  1. Logical explanation of your PKI Infrastructure (placement of CAs)
  2. Document policy procedures for validity periods/ path length
  3. Keep your private key secure and avoid any form of compromise
  4. Keep your PKI certificate management updated. Revoke certificates when necessary, clear out old/unused certificates, and formulate a documented procedure for certificate renewals and expirations.

Quick Note on Pricing
The AWS account is being charged a monthly fee of $400 for each private CA starting from the time that you create it. There is a charge associated with each certificate you issue/export (with its private key) with the model “the more you generate/issue the less you pay”.For the latest ACM Private CA pricing information, see the ACM Pricing page
aws.amazon.com/certificate-manager/pricing/ on the AWS website as prices may vary from time to time.

Summary

If you want to secure your data end-to-end with the assurance of legitimate sender source then usage of Public Key Infrastructure (PKI) is must. There are multiple PKI implementations doing the rounds with various complexity levels, however, AWS Certificate Manager Private CA provides this with maximum ease and robust infrastructure providing all the benefits of cloud i.e. pruning maintenance cost, scalability, business continuity, efficiency, flexibility and sec-ops automation.

Format Preserving Encryption (FPE) – Usage on GCP

Online data security has always been important, but never more so than now. With more and more of our data being stored on the cloud, users need to look for the best security solutions to ensure their confidential information is secure. While all parts of online data security are necessary to secure data, arguably the most important portion is data encryption.

This is why more and more cloud services are using a type of encryption called Format-Preserving Encryption.

What is Format-Preserving Encryption?

If your company has multiple 16-digit credit card numbers stored in a database, but the encrypted ciphertext needs to be 16-digits as well after encryption, this is where Format-Preserving Encryption [FPE] comes in.FPE encrypts plaintext that is a certain length and produces a ciphertext that is the same length as the plaintext and uses the same set of values as the plaintext. Using the previous example of a 16-digit credit card number with a plaintext of 1483920193402918, the ciphertext created with FPE could produce an output of 1483666666662918.

By using FPE, you can see that the ciphertext and plaintext are the same length and only use numerical values for encryption. One cloud provider that lets users implement FPE in their encryption is Google Cloud.

Tailored Cloud Key Management Services

Get flexible and customizable consultation services that align with your cloud requirements.

Learn More

Format-Preserving Encryption in Google Cloud

Google Cloud gives users access to a de-identification technique called pseudonymization. Pseudonymization is a technique that replaces sensitive data with cryptographically generated tokens. Google Cloud supports three different pseudonymization techniques:

  1. Deterministic encryption using AES-SIV
  2. Format-Preserving Encryption
  3. Cryptographic hashing

All three techniques use cryptographic keys for data transformation, but we will focus on the Format-Preserving Encryption.
Google Cloud uses a type of FPE called FPE-FFX. FFX focuses on two different FPE methods,FF1 and FF3, to encrypt data.At the time of writing this, FF1 is the only method currently supported for encryption. FF2 did not make it to publication at the time of FFX’s creation. FF2 and FF3 derivations are being resubmitted, but after a cryptanalytic attack in 2017, FF3 was considered to be too insecure.

FFX uses multiple rounds of a Feistel function on the plaintext, along with the use of a key, to create the ciphertext. A Feistel function splits the plaintext into two parts and does a permutation each round on each half of the plaintext, and then swaps the left half of text to the right and vice versa. The FF1 method uses 10 rounds of the Feistel function, and FF3 uses 8 rounds of the Feistel function. FPE-FFX has several steps necessary to encrypt data.To begin encryption, the alphabet being used to de-identify the data must be specified in one of three ways:

  1. Using one of four values that represent the most common character sets/alphabets
  2. Using a radix value specifying the size of the alphabet. Specifying 2 gives an alphabet consisting of the numbers 0 and 1, while specifying 95 gives an alphabet with all numeric, upper-case alpha, lower-case alpha, and symbol characters
  3. By building an alphabet containing the exact characters to be used

When using FPE-FFX in Google Cloud, the data is encrypted as previously described, but can also be prepended with a surrogate annotation, resulting in a final token. The token takes the following form when a surrogate annotation is included: surrogate_infotype(surrogate_length): surrogate_value. The surrogate annotation is surrogate_infotype(surrogate_length). The infotype is defined by the user and the surrogate value is the resulting ciphertext. If no surrogate annotation is specified, then the final token is just the surrogate value. To re-identify unstructured data, the full token, including a surrogate annotation, is necessary, while structured data only needs the surrogate value.

Conclusion

Format preserving encryption is extremely important for users who wish to keep the ciphertext after encryption as the same length as the plaintext. Of the several different FPE-FFX methods used on Google Cloud, FF1 is the best practice method to use, due to the extra rounds of the Feistel function it goes through.

Structured data requires a surrogate annotation be prepended on the ciphertext to allow for re-identification of data. Google Cloud has a strong implementation of FPE in place for customer use. For those in need of same length plaintext and ciphertext, Google Cloud’s FPE-FFX is their best choice.

Digital Certificates – Windows Certificate Stores

We often come across an abstract concept called “Security on the internet” and then the Unavoidable query comes “why do we need security on the internet?”

We spend loads of time on the internet be it social media, personal communication and business transactions. The Internet security is important to communicate securely over the Internet. Thus, with the use of internet security the computers, files/data from the computer, IT systems etc. are protected from any kind of intrusion by any malicious user/system over the Internet

What does security provide?

  1. Confidentiality: The information within the message or transaction is kept confidential. It may only be read and understood by the intended sender and receiver.
  2. Integrity: The information within the message or transaction is not tampered accidentally or deliberately.
  3. Authentication/Identification: The persons / entities with whom we are communicating are really who they say they are.
  4. Non-Repudiation: The sender cannot deny sending the message or transaction, and the receiver cannot deny receiving it.
  5. Access Control: Access to the protected information is only realized by the intended person or entity.

All the above security properties can be achieved and implemented with the help of Digital Certificate through the use of Public Key Infrastructure (PKI) mechanism.

About Digital Certificate

The digital certificate is basically a digital form of identification by which consumers, businesses and organizations can exchange the data securely over the internet using the public key infrastructure (PKI). Digital Certificate is also known as a public key certificate or identity certificate.

Public Key Cryptography or Asymmetric Cryptography uses two different cryptographic key pairs: A.) Private key and B.) Public key. One key from the key pair is used to Encrypt and the other key is used to decrypt the data and vice-versa.

To understand what certificates are, it is important to note that a digital certificate establishes the owner’s identity, and it makes the owner’s public key available. Digital certificates are issued by trusted Certificate Authorities (CAs), which are recognized as reliable digital certificate providers. These certificates are issued only for a limited time; after the expiration of the certificate a new certificate is issued. 

A digital certificate alone can only verify the identity of the digital certificate’s owner by providing the public key that is required to verify the owner’s digital signature. Therefore, the owner of the digital certificate must protect the private key that belongs to the public key of the digital certificate.

How digital certificates are verified?

  1. The issuer of a digital certificate is called a Certificate/Certification Authority. Verifying the certificates is the process of validating the entity’s identity. Validation process is a way to be sure about the person’s identity.
  2. The certificate contains information about the CA name and digital signature, these two fields will be used to authenticate the certificate. The CA name of the certificate has to be from a trusted CA and the digital signature must be valid.
  3. Now, the process is to validate the digital signature of the certificate, the verification of a digital signature is performed as per the below steps:
    • Calculate the hash-value: The first step is to calculate the hash-value of the message (often called a message digest) by applying a cryptographic
      hashing algorithm (For example: MD5, SHA1, SHA2). The hash value of the message is a unique value.
    • Calculate the digital signature: In this step the hash value of the message or the message digest is encrypted with the private key of the signer, the encrypted hash value is also called as digital signature.
    • Calculate the current message digest: In this step the hashed value of the signed message is calculated by the same algorithm which was used during the signing process.
    • Calculate the original Hash-value: Now, the digital signature is decrypted by the public key that corresponds to the private key of the signer. As a result, we will obtain the original hash value that was calculated from the original message during the first step of the signing process.
    • Compare the current and original hash value: In this step we will compare the hash values of the current message digest and the original hash value. If two values are identical then the verification is successful. This proves that the message has been signed with the private key that corresponds to the public key used in the verification process. If the two values differ, this means that the digital signature is invalid and the verification is unsuccessful.

To manage user certificates, individuals and organizations can use certificate lifecycle management tools, which facilitates the issuance, renewal and revocation of digital certificates. The tool can be essential for maintaining the integrity and security of digital communications. 

Now, worried about false impersonation of your identity? – If you send your digital certificate containing your public key to someone else, the person cannot misuse the digital certificate without having access to your private key. If the private key is compromised, then malicious users may act as the legitimate owner of the digital certificate.

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Learn More

Use of digital certificate in the internet applications

There are numerous internet applications using public key cryptography standards for key exchange, digital signature and digital certificates need to be used to obtain the desired public key.

Following are brief descriptions of a few of the commonly used Internet applications that use public-key cryptography:

  1. SSL (Secure Socket Layer) – This is an encryption-based internet security protocol. This protocol is used to provide security between the client and a server. SSL uses digital certificates, called SSL Digital, for key exchange, encryption, server authentication, and client authentication for secure communication over the internet. Overall, it provides a private communication path for a user and a trusted authority. 
  2. Client Authentication –Client authentication is an option which requires a server to authenticate a client’s digital certificate before allowing the client to access certain resources. The server requests and authenticates the client’s digital certificate during the SSL handshake and the server can also determine whether it trusts the CA that issued the digital certificate to the client.
  3. Secure Electronic Mail – To secure email messages, it uses standards such as Privacy Enhanced Mail (PEM) or Secure/Multipurpose Internet Mail Extensions (S/MIME). digital certificates are used for digital signatures and for the exchange of keys to encrypt and decrypt messages.
  4. Virtual Private networks (VPNs) – Virtual private networks, also called secure tunnels, can be set up between firewalls/secure gateways to enable protected connections between secure networks over insecure communication links. All traffic destined to these networks is encrypted between the firewalls/secure gateways.

Windows Certificate stores

Certificate stores are a combination of logical grouping and physical storage locations. Certificate store contains certificates issued from a number of different certification authorities (CAs). Windows Certification List is a collection of certificates which are part of Windows Certificate Store, these include Root Certificates, Intermediate Certificates, End Entity Certificates, SSL/TLS certificates, Client Authentication certificates etc. 

System certificate stores has the following types:

  1. Local machine certificate store: This certificate store is local to computer and global to all users on the computer. The certificate store is located in the registry under HKEY_LOCAL_MACHINE root.
  2. Current user certificate store: This certificate store is local to a user account on the computer. This certificate store is located in the registry under the HKEY_CURRENT_USER root.

Let’s start with the certificate MMC console, easily launched by certmgr.msc.
This gives us the hint of physical certificate stores, as shown in fig 1.

As shown in figure1 below, there are several stores: smart card store, Enterprise store, the Third-Party store etc.

If we go to MMC and add the certificate snap-in, we have some more choices for the accounts: user account, service account and the computer account, all the stores listed in the fig1 have their corresponding location for each account.

Microsoft certificate stores storage locations include:

  1. HKEY_LOCAL_MACHINESOFTWAREMicrosoftSystemCertificates – contain the info for the computer account
  2. HKEY_LOCAL_MACHINESOFTWAREMicrosoftEnterpriseCertificates – contains info about the AD published certificates
  3. HKEY_Local_MachineSoftwarePoliciesMicrosoftSystemCertificates- contains info for the computer account, but for Group policy distributed certificates for the computer account
  4. User: HKEY_CURRENT_USERSoftwareMicrosoftSystemCertificates – contains registry settings for the current user. Those can include the BLOB (Binary Large object) and various settings for the certificate, as well as settings related to the CA certificates that support the user certificates.
  5. HKEY_Current_UserSoftwarePoliciesMicrosoftSystemCertificates – contains registry settings for the current user, but for certificates distributed via Group Policy.
  6. HKEY_UsersUser SIDSoftwareMicrosoftSystemCertificates – contains this info for the corresponding user

If your organization is looking for implementation of encryption technologies in cloud environment, please consult [email protected] for further information.

AWS Certificate Manager (ACM) – Best Practices

What is AWS Certificate Manager (ACM)?

ACM is Amazon’s Certificate Manager offered as a service for its cloud customers. ACM provides its users with options to create, manage and deploy certificates (both public and private). AWS Certificate Manager Private Certificate Authority service enables small and medium enterprises to build and own Public Key Infrastructure (PKI) with in AWS cloud platform. AWS services such as Elastic Load Balancers, Amazon CloudFront distributions, Elastic Beanstalk, and AWS API Gateway are equipped to use AWS Certificate Manager Service.

For more detailed information on AWS Certificate Manager (ACM), please read our blog article

AWS ACM Best Practices

Following best practices for ACM services help organizations in conforming to audit processes and also ensure compliance with several security laws, standards and regulations such as Payment Card Industry Data Security Standard (PCI DSS), National Institute of Standards and Technology (NIST), Australian Prudential Regulatory Authority (APRA) etc.

Tailored Cloud Key Management Services

Get flexible and customizable consultation services that align with your cloud requirements.

Learn More

Here are top 10 best practices we identified for AWS Certificate Manager (ACM)

  1. ACM Certificate expiry check: One of the best practices to be followed in order to adhere to security standards is to ensure removal of expired SSL/TLS certificates managed by ACM. This eliminates the risk of deploying an invalid SSL/TLS certificate in resources which trigger error in front end. This might cause loss of credibility for business as well.
  2. ACM Certificate validity check: Ensure requests arrived during SSL/TLS certificate issue or renewal process are validated regularly. ACM certificate requests become invalid when not validated within 72 hours of request initiation. Application services might be interrupted during the process of new certificate requesting process.
  3. Root Certificate Authority (CA) usage: As per Amazon recommendation, it is always a best practice to minimize the use of root CA. Instead an intermediate CA can be created to perform daily activities of issuing certificates to endpoints and in turn root CA can issue certificates to intermediate CAs. This way root CA can be protected from direct exposure during any attacks. Also, providing a separate accounts for root CA and intermediate CAs is a recommended best practice.
  4. Use of SSL vs TLS:Transport layer protection is very important to ensure security. Use only TLS version 1.1 or above and do not use SSL as it is not considered secure anymore.
  5. Private keys (SSL/TLS) protection: Whenever you import certificates instead of ACM issued certificates, ensure keys used to generate SSL/TLS certificate private keys has high key strength to avoid data breach.
  6. Avoid using SSL wildcard domain certificates: Avoid using wildcard domain certificates instead try to issue ACM single domain certificate for each domain and subdomain with its own private key. Whenever there is a breach or hack performed on wildcard certificates, all the domains and sub domains linked are compromised causing greater security concern.
  7. Usage of imported certificates: Allow usage of imported certificates only from authenticated and trusted partners of your organization in ACM. When wildcard certificates are imported into AWS Certificate Manager (ACM), security threat risk is high as the user might hold an unencrypted copy of certificate’s private key.
  8. Fully qualified domain name: :One of the common mistakes organizations commit is using alias in certificates. Recommended best practice is to always use a Fully Qualified Domain Name (FQDN) in SSL/TLS ACM certificates.
  9. Perform audit of SSL/TLS certificates: To avoid misuse of generated certificates, perform frequent audits of AWS environment for trusted certificates and validate audit report.
  10. Turn on AWS CloudTrail and CloudWatch alarms: CloudTrail logging helps in tracking history of AWS API calls and monitoring AWS deployments. CloudTrail can be integrated with applications for performing automated logging and monitoring activities. Enabling CloudWatch alarm feature helps in alerting through notifications when configured metrics breach.

If your organization is looking for implementation of AWS Certificate Authority, please consult [email protected] for further information. BYOK allows organizations to encrypt data inside cloud services with their own keys — and maintained within the cloud providers’ vaults — while still continuing to leverage the cloud provider’s native encryption services to protect their data. Win win.