Reading time: 3 minutes, 27 seconds

LDAPS is one of the most crucial functionalities to properly protect and secure credentials in your PKI environment. By default, LDAP communications between client and server applications are not encrypted. This means that it would be possible to use a network monitoring device or software and view the communications traveling between LDAP client and server computers. This is especially problematic when an LDAP simple bind is used because credentials (username and password) are passed over the network unencrypted. This could quickly lead to the compromise of credentials.

Prerequisites

A functional Microsoft PKI should be available and configured. While viewing PKIView.msc, no errors should appear

If you need help in deploying your own PKI, you can refer to this article to build your own Two Tier PKI

Installing AD LDS

This step should be carried out on LDAP Server or on Domain Controllers which would be responsible for hosting LDAPS service.

  • Open Server Manager
  • From manage, open Add Roles and Features
  • On Before you Begin, click Next
  • On Installation type, ensure Role based or feature based installation, and click Next
  • On Server Selection, click Next.
  • On Server Roles, click Active Directory Lightweight Directory Services, and click Add Features, and then click Next
  • On Features, click Next
  • On AD LDS, click Next
  • On Confirmation, click Install
  • Post Installation, AD LDS needs to be configured

Configuring AD LDS

  • Run AD LDS setup wizard. Click Next on first page.
  • Ensure unique instance is selected, and click Next
  • Provide Instance name and Description, and click Next
  • Leave default ports and click Next

If AD LDS is installed on domain controller, then LDAP port would be 50000 and SSL port would be 50001

  • On Application Directory Partition, click Next
  • On File locations, click Next
  • On Service Account Selection, you may leave it on the Network service account, or choose a preferred account that can control LDAPS service
  • On AD LDS administrators, leave the current admin, or choose another account from the domain
  • Choose all LDF Files to be imported, and click Next
  • On Ready to Install, click Next
  • After Installation, click Finish

Publishing a certificate that supports Server Authentication

  • Login to the Issuing CA as enterprise admin
  • Ensure you are in Server Manager
  • From the Tools menu, open Certificate Authority

Expand the console tree, and right click on Certificate Templates

  • Select Kerberos Authentication (as it provides Server Authentication). Right click and select Duplicate Template. We can now customize the template.
  • Change Template Display Name and Template Name on General tab. Check Publish Certificate in Active Directory. This will ensure that the certificate appears when we enrol domain controllers using that template
  • On Request Handling, check Allow private key to be exported.
  • On the Security tab, provide Enroll permissions to appropriate users
  • Click Apply

Issue the Certificate on Issuing CA

  • Login to the Issuing CA as enterprise admin
  • Ensure you are in Server Manager
  • From the Tools menu, open Certificate Authority

Expand the console tree, and click on Certificate Templates

On the menu bar, click Action > New > Certificate Template to Issue

  • Choose the LDAPS certificate
  • Click OK and it should now appear in Certificate Templates

Requesting a certificate for Server Authentication

  • Log into LDAP server or domain controller.
  • Type win+R and run mmc
  • Click File and click Add/Remove Snap-in
  • Choose Certificates and click Add
  • Choose Computer account
  • If the steps are followed on LDAPServer where AD LDS is installed, click Local computer, or choose Another computer and choose where it would need to be installed
  • Expand the console tree, and inside Personal, click Certificates
  • Right click on Certificates and click All Tasks and select Request New Certificate
  • Follow the instructions, choose LDAPS template that we issued earlier and Install.}
  • Once Installed click Finish
  • Open the certificate, and in Details tab, navigate to Enhanced Key Usage to ensure Server Authentication is present.

Validating LDAPS connection

  • Login to LDAP Server as Enterprise admin
  • Type win+R and run ldp.exe
  • On the top menu, click on Connections, and then click Connect
  • In server, provide domain name, ensure SSL is checked and proper port is provided and click OK
  • No errors should appear. If connection was unsuccessful, the following output may appear

Conclusion

This should enable LDAPS which can be used to properly protect credentials used in your PKI environment as well as enable other applications to use LDAPS.

If you need help with your PKI environment, feel free to email us at info@encryptionconsulting.com.

About the Author

Anish Bhattacharya is a Consultant at Encryption Consulting, working with PKIs, HSMs, creating Google Cloud applications, and working as a consultant with high-profile clients.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Read Time: 10 min

Let’s define NIST Cyber Security Framework in brief. 

The NIST Cyber Security Framework known as NIST CSF is a cybersecurity assessment-type framework developed by the NIST (National Institute of Standards and Technology). The core purpose of the NIST CSF is to protect the nation’s critical infrastructure using a set of cybersecurity best practices and recommendations. It’s a voluntary, risk-based, and outcome-oriented cybersecurity framework to help your organization to categorize its security activities around five key functions 1) Identify 2) Protect, 3) Detect, 4) Respond, and 5) Recover.

 Let’s look at each function briefly:

Identify – The Identify function assist you to evolve an overall cybersecurity risk management approach to systems, people, assets, data, and capabilities in the organization. It helps you to identify the critical assets, overall business environment, governance model, and supply chain. 

Protect – The protect function helps you to set up defensive controls based on the inputs from identify function such as critical assets, risk tolerance/acceptance levels. It also emphasizes the importance of access control & identity management, protecting data, and training & awareness to users. 

Detect – The detection functions help you to detect anomalies, malicious activities, and other events effectively by continuous security monitoring and with the help of other detection processes & procedures. 

Respond – To complete the detection function, respond helps you to take the right action immediately through incident response planning, mitigation actions for events, accurate analysis, communication to the designated stakeholders, and continuous improvement with each event.

Recover – Recover function assists you to get back to the pre-attack condition with the help of recovery planning, continuous improvement, and communication to the designated stakeholders.

NIST Cyber Security Framework Overview: Core, Tiers, and Profile

The NIST CSF consists of three sections:

The core section represents cybersecurity practices, technical, operational, process security controls, and outcomes that support the five risk management functions such as Identify, Protect, Detect, Respond, and Recover.

The tiers section emphasizes the organization’s processes of managing risks while remaining aligned with NIST CSF.

The profiles characterize how effectively an organization’s cybersecurity program is managing its risk. It also expresses the state of an organization’s “as is” and ‘’to be’’ cybersecurity postures.


NIST Cyber Security Framework and AWS Cloud

Earlier AWS team published a guide on how to implement the NIST CSF in an AWS cloud environment. AWS recommends using NIST CSF as a mechanism to have baseline security in place that can improve the cloud security objectives of an organization. NIST CSF contains a comprehensive controls catalogue derived from the ISO/IEC 27001 (1), NIST SP 800-53 (2), COBIT (3), ANSI/ISA-62443 (4), and the Top 20 Critical Security Controls (CSC) (5).

There is a listing on the AWS portal that specifies the alignment of NIST CSF to various AWS services that are known as “AWS Services and Customer Responsibility matrix for Alignment to the CSF” (6). This is a comprehensive list that customers can use to align their needs with the CSF in the AWS cloud for their security requirements. Also, this enables the customer to design their baseline security requirements to meet their security goals.

AWS Cloud Adoption Framework

Before setting up a baseline, it is important for a customer to have a clear understanding of their business use cases and the customer-owned responsibilities for “security in the AWS cloud”. The customer should review the “AWS Cloud Adoption Framework” (7) to evaluate the governance model that will be required while implementing the NIST CSF into the AWS cloud services. The AWS CAF (Cloud Adoption Framework) lists pointers known as “CAF Perspectives” to identify gaps in security skills, capabilities, and cybersecurity processes.

NIST CSF Functions and Responsibilities (Customer-owned & AWS-owned)

AWS team has come up with the concept of NIST CSF Functions categories & sub-categories into 108-outcome based security activities. Every function depicts the Customer-owned and AWS-owned responsibilities that mean security of the cloud owned by AWS and security in the cloud owned by the Customer. Business owners/stakeholders can use the AWS link of “AWS Services and Customer Responsibility matrix for Alignment to the CSF” to tailor their needs as per the organization’s tiers and profile level in the CSF.

The below figure represents the CSF core functions (Identify, Protect, Detect, Respond, and Recover) with categories defined and those that have been converted to 108-outcome based security activities (8) by AWS.

Till now we have discussed the NIST CSF alignment with the AWS Cloud Services and how the customer can use CAF (Cloud Adoption Framework) to evaluate the skill gap, capability, and cybersecurity processes using the CAF Perspectives.    

Let’s discuss how appropriate AWS services can be leveraged to set up effective Security Architecture using NIST Cyber Security Framework.

The table below provides a summarized view of AWS Cloud Services categorized into the NIST CSF Core Functions based on the nature of the service:

#IdentifyProtectDetectRespondRecover
1OrganizationsShieldGuardDutyCloudWatchOpsWorks
2Security HubCertificate ManagerMacieLambdaCloudFormation
3ConfigKMSInspectorDetectiveS3 Glacier
4Trusted AdvisorNetwork FirewallSecurity HubCloudTrailSnapshot
5Systems ManagerWAF Systems ManagerArchive
6Control TowerFirewall Manager Step FunctionsCloudEndure Disaster Recovery
7 CloudHSM   
8 IAM   
9 Direct Connect   
10VPC    
11 Single-Sign-On   

Conclusion:

Having the AWS Cloud Services aligned with the NIST CSF enables the customer to improve their cloud security posture with appropriate risk management and industry-compliant cloud services. Encryption Consulting, a leading cyber-security firm, offers various AWS and NIST related cybersecurity consulting Services catering to its customers a risk and security control maturity assessment based on the outlined standards. Encryption Consulting helps customers to get them familiarized with NIST CSF and AWS security tools & documentation and assist them in conducting a meaningful and quantifiable cybersecurity assessment while keeping the organization’s business goals intact.

Resources:
  1. ISO/IEC 27001:2013, Information Technology – Security techniques – Information Security management systems – Requirements. ISO. Retrieved February 18, 2021, from: https://www.iso.org/standard/54534.html
  2. NIST Special Publication (SP) 800-53, Rev. 5, Security and Privacy Controls for Information Systems and Organizations. National Institute for Standards and Technology. Retrieved February 18, 2021, from: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
  3. Control Objectives for Information and Related Technology (COBIT), an ISACA Framework. Information Systems Audit and Control Association (ISACA). Retrieved February 18, 2021 from: https://www.isaca.org/resources/cobit
  4. ANSI/ISA-62443-2-4-2018 / IEC 62443-2-4:2015+AMD1:2017 CSV, Security for industrial automation and control systems. International Society of Automation (ISACA).
  5. The 20 CIS Controls & Resources. Center for Internet Security (CIS). Retrieved February 18, 2021, from: https://www.cisecurity.org/controls/cis-controls-list/
  6. AWS Services and Customer Responsibility Matrix for Alignment to the CSF can be downloaded from here: https://aws.amazon.com/compliance/nist/
  7. An overview of the AWS Cloud Adoption Framework (CAF), Ver. 2. Amazon Web Services, Inc.
  8. An overview of AWS capabilities that can be leveraged with NIST CSF: https://d1.awsstatic.com/whitepapers/compliance/NIST_Cybersecurity_Framework_CSF.pdf

About the Author

Dipanshu Bhatnagar is a Principal Consultant Cloud Security Specialty at Encryption Consulting working with PKIs, AWS Cloud Cryptographic services and tools, Google Cloud Cryptographic Services, and helping high profile clients towards their cloud journey with complete data privacy assurance.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Read Time: 15 minutes

AWS provides many services, including database, storage, networking, and many more. AWS Key Management Service (KMS) is one of the most popular services offered by AWS. It is a beneficial service that helps in dealing with sensitive data and managing cryptographic keys.

What is AWS Key Management Service (KMS)?

AWS KMS is a service that can be integrated with various other AWS services. It can be used to create, store, and control cryptographic keys to encrypt data in your application. With the help of the AWS KMS service, a user can control access to the encrypted data. AWS KMS provides almost 100 percent of the durability of cryptographic keys.

Keys are stored in multiple Availability Zones (AZ’s) that ensure the high availability of keys. AWS KMS is integrated with CloudTrail, which allows users to audit the purpose for which the key is used, when it was used, and by whom the key was used.

Some Important Points about AWS KMS

  • The keys generated in a region cannot be sent outside of that region.
  • KMS uses an AWS Hardware Security Module (HSM), which is FIPS 140-2 compliant, to store keys.
  • AWS KMS allows controlling access to master keys.
  • Users can encrypt data stored in Amazon EBS, Amazon S3, and Amazon Redshift as AWS KMS is integrated with these services.

How does AWS KMS work?

To learn the inner workings of AWS KMS, we must first learn the terms and concepts used in AWS KMS.

There are two types of keys in AWS KMS:

  1. Customer Master Keys
  2. Data Keys

Customer Master Keys (CMKs)

A CMK is a logical representation of the master key. The CMK contains metadata like key ID, Creation Date, key state, and description of the key and the key material used for encryption and decryption.

By default, Key material is created by AWS KMS. No one can modify, manage, view, or extract the key material. Key material cannot be deleted as well. If a user wants to delete key material, then the user has to delete the CMK. Users can import their key material into a CMK or create key material for CMKs in an AWS CloudHSM Cluster.

AWS CMK provides both Symmetric and Asymmetric CMKs. Symmetric CMKs use a 256-bit key for encryption and decryption. In contrast, asymmetric CMKs use RSA key pairs for encryption and decryption or Signing and verification. An asymmetrically created key, called an ECC key, can only be used for signing and verification. CMKs are created in AWS KMS. CMKs can be managed by the AWS Management Console or the AWS KMS API. All symmetric keys and private asymmetric keys never leave the AWS KMS unencrypted. To perform any cryptographic operation using CMKs, the user must use the AWS KMS API.

There are three types of CMKs supported by AWS KMS:

  1. Customer Managed CMK: Customer Managed CMKs are those CMKs in the user account that the user can create, own, and manage. Users have complete control over Customer Managed Keys, allowing them to establish and manage their key policies, IAM policies, grants, rotation of cryptographic material, etc.
  2. AWS Managed CMK: The CMKs in the user account created and managed by AWS on behalf of the user is known as AWS Managed CMKs. AWS managed CMKs cannot be directly used in cryptographic operations. Users cannot manage, rotate or change the key policies of AWS managed CMKs. However, users can view the key policies and audit their use in AWS CloudTrail (integrated with AWS KMS) in their AWS account.
  3. AWS Owned CMK: The Collection of CMKs owned and managed by AWS for use in multiple clouds is known as an AWS Owned CMK. AWS owned CMKs protect the resources in the user account. These CMKs are not found in the user’s account. With AWS owned CMKs, users do not need to create or manage CMKs. Users cannot view, use, track, or audit them.

Data Keys

The keys used to encrypt data and other data encryption keys are Data Keys. Data keys are used to encrypt a large amount of data as customer master keys (CMKs) cannot encrypt data larger than 4KB. Data keys are used and managed outside of AWS KMS. Data keys are not stored, managed, or tracked by AWS KMS. AWS KMS does not perform any cryptographic operation with data keys, however, users can generate, encrypt, and decrypt data keys with the help of AWS KMS customer master keys (CMKs). Data keys can encrypt and decrypt data in other AWS services like Amazon S3, EBS, EC2, etc.

  • Create data key
    AWS KMS uses user-specified CMKs to generate a data key. A data key can be generated by calling the GenerateDataKey operation. This operation returns two copies of the data key, one in plaintext and the other one encrypted under the CMK. Another operation, GenerateDataKeyWithoutPlaintext, can also be used, which returns a single copy of the data key that is encrypted under CMK.
    Before using an encrypted data key, ask AWS KMS to decrypt it.
  • Encrypting data with a data key
    As mentioned earlier, AWS KMS does not use data keys to perform any cryptographic operation. To encrypt data with a data key, use a plaintext data key, encrypt data outside of AWS KMS, and delete it from memory, then, store the encrypted data key.
  • Decrypting data with a data key
    To decrypt data outside of AWS KMS with a data key, the Decrypt operation is used to decrypt the encrypted data key, which returns a plaintext copy of the data key.
    Now, Data outside of AWS KMS can be decrypted using a plaintext data key. The user must remove the plaintext data key from memory after using it.
    The following diagram show how the Decrypt operation decrypt the Encrypted Data Key:
  • Data Key Pair
    Users can create an asymmetric data key pair consisting of mathematically related private and public keys. Generally, these key pairs are used for client-side encryption and decryption or the signing and verification process outside of AWS KMS.
    The private key of each data key is protected by AWS KMS using user-specified symmetric CMKs, but users have to manage and use the data key pair outside the AWS KMS as it does not track, manage or use data key pairs to perform any cryptographic operations.
    Users can generate the following data key pairs in AWS KMS:  
    • RSA key pair of 2048 bit, 3076 bit, and 4096 bits. Generally used for encryption and decryption.
    • Elliptical Curve key pair: ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P512, and ECC_SECG_P256K1. Generally used for Signing and verification.
  • Creating a Data key Pair
    To generate a data key pair, the user needs to call the GenerateDataKeyPair or GenerateDataKeyPairWithoutPlaintext operation according to the requirement and specify a symmetric CMK that will encrypt the private key.
    GenerateDataKeyPair operations generate three keys: a plaintext public key, a plaintext private key, and an encrypted private key. In contrast, GenerateDataKeyPairWithoutPlaintext generates two keys: a plaintext public key and an encrypted private key.
  • Encrypting data with a data key pair
    The public key of a data key pair is used to encrypt the data, and the private key of the same data key pair is used to decrypt the data.
  • Decrypting data with a data key pair
    The plaintext private key of the same data key pair whose public key was used for encryption is used to decrypt the data. The Decrypt operation is used to decrypt the encrypted private key of a data key pair, and remove the plaintext private key from memory after using it.
  • Signing messages with a data key pair
    The plaintext private key of a data key pair is used to generate a cryptographic signature for a message, and anyone with the public key of the same data key pair can use it to verify the signature.
    If the private key is encrypted with the AWS CMK, the Decrypt operation is used, which returns the private key in plaintext format used for signing purposes. As always, the user should remove the plaintext private key from memory after use.
  • Verifying a message with a data key pair
    The public key of the data key pair is used for verification. The public key should belong to the same data key pair whose private key was used for Signing. Verification of the signature confirms that an authorized user signed the message and it has not been altered.
  • Aliases
    Users can give a friendly name to a CMK known as an Alias. For example, the CMK name is 9897aswd-34dw-1234-89hg-asdkal212012, the user can give it an alias of key-01. With the help of an alias, users can easily identify a CMK in AWS KMS operations.
  • Cryptographic Operations
    The AWS SDK, AWS Tools for PowerShell, or AWS Command Line Interface (AWS CLI) is required to perform any cryptographic operations with CMKs because CMKs remain within AWS KMS. Users cannot perform any cryptographic operation with CMKs in the AWS KMS console.

Below is a table which summarizes the AWS KMS cryptographic operations:

OperationCMK Key TypeCMK Key Usage
DecryptSymmetric/AsymmetricENCRYPT_DECRYPT
EncryptSymmetric/AsymmetricENCRYPT_DECRYPT
GenerateDataKeySymmetricENCRYPT_DECRYPT
GenerateDataKeyWithoutPlaintextSymmetricENCRYPT_DECRYPT
GenerateDataKeyPairAsymmetricENCRYPT_DECRYPT
GenerateDataKeyPairWithoutPlaintextAsymmetricENCRYPT_DECRYPT
ReEncryptSymmetric/AsymmetricENCRYPT_DECRYPT
SignAsymmetricSIGN_VERIFY
VerifyAsymmetricSIGN_VERIFY

Note:  GenerateDataKeyPair and GenerateDataKeyPairWithoutPlaintext operations generate asymmetric data key pair which symmetric CMKs protect it.

  • Envelope Encryption
    Users can protect their plaintext data by encrypting it with a key, but how do they protect the encryption key? This brings in the concept of Envelope encryption, where the plaintext data is encrypted with the data keys, and the data keys are encrypted with master key. AWS KMS is responsible for the security of the master key. Master keys are stored and managed by AWS KMS and never leave the HSM unencrypted.
    Benefits of Envelope Encryption:  
    • Protecting data keys: The data keys are inherently protected by encrypting them with CMKs. So, the encrypted data keys can be safely stored with encrypted data.
    • Encrypting the data key with master key: Encrypting large data with data keys, again and again, can be a time-consuming process. So, instead of encrypting data repeatedly, the encryption key can be encrypted with a master key.
    • Combining the strength of multiple algorithms: Envelope Encryption enables you to use the strength of both Symmetric and Asymmetric algorithms.
  • Key Policy
    Users can define the permissions for CMK in a document called a key policy. Users can add, remove or change permissions at any time for Customer Managed Keys, but cannot edit the AWS Managed CMK as AWS manages it on behalf of the user.
  • Grant
    Grants are temporary permissions that users can create, use, and delete without changing key or IAM policies. Grants are also considered with IAM policies and key policies when users access a CMK.
  • Auditing CMK Usage
    AWK KMS is integrated with CloudTrail, which can be used to audit key usage. CloudTrail creates log files for AWS API calls and related events in the account. These log files contain all AWS API requests from AWS SDK, AWS Management Console, or AWS command-line tools. These log files can be used to find important information like when the CMK was used, which operation was requested, requester identity, and the source IP address.

Creating Customer Managed Symmetric CMKs

A user should follow the following steps to create Customer Managed Symmetric CMK using AWS Management Console:

  1. Sign in to the AWS management console and open the AWS KMS console.
  2. You can change the AWS region from the upper-right corner of the page.
  3. Choose customer manages keys from the navigation pane.
  4. Choose create key.
  5. In Key type, select the type of CMK, i.e., Symmetric.
  6. Click on Next.
  7. Create an alias for the CMK.
  8. Type the description for the CMK. (Optional)
  9. Click on Next.
  10. Type a tag key and tag value. (Optional)
  11. Click on Next.
  12. Select IAM users and roles that can administer the CMK.
  13. Clear Allow key administrators to delete this key check box if you do not want to allow IAM users and roles to delete this key. (Optional)
  14. Click on Next.
  15. Select IAM users and roles that can use the CMK to perform cryptographic operations.
  16. In the Other AWS accounts section, click on Add another AWS account and type AWS account identification number to allow them to use this CMK for cryptographic operations. (Optional)
  17. Click on Next.
  18. Review the key configuration that you have done.
  19. Click on Finish to create the CMK.

Creating Customer Managed Asymmetric CMKs

A user should follow the following steps to create Customer Managed Symmetric CMK using AWS Management Console:

  1. Sign in to the AWS management console and open the AWS KMS console.
  2. You can change the AWS region from the upper-right corner of the page.
  3. Choose customer manages keys from the navigation pane.
  4. Choose create key.
  5. In Key type, select the type of CMK, i.e., Asymmetric.
  6. In Key usage, select the purpose for which key is created, i.e., Encrypt and decrypt or Sign and verify.
  7. Select the specification of your asymmetric CMK.
  8. Click on Next.
  9. Create an alias for the CMK.
  10. Type the description for the CMK. (Optional)
  11. Type a tag key and tag value. (Optional)
  12. Click on Next.
  13. Select IAM users and roles that can administer the CMK.
  14. Clear Allow key administrators to delete this key check box if you do not want to allow IAM users and roles to delete this key. (Optional)
  15. Click on Next.
  16. Select IAM users and roles that can use the CMK to perform cryptographic operations.
  17. In the Other AWS accounts section, click on Add another AWS account and type AWS account identification number to allow them to use this CMK for cryptographic operations. (Optional)
  18. Click on Next.
  19. Review the key configuration that you have done.
  20. Click on Finish to create the CMK.

Benefits of AWS KMS

  1. Fully managed: AWS KMS provides full control access to encrypted data by enforcing the permissions defined by the user to use keys.
  2. Centralized key management: AWS KMS provides a single control point to manage and define key policies. Users can create, import, manage, delete, or rotate keys from the AWS key management console, or use AWS CLI or SDK.
  3. Digitally Sign data: The user can generate an asymmetric key in AWS KMS and can perform digital signing operations to maintain the integrity of the data.
  4. Secure: In AWS KMS, keys are generated and protected in Hardware security modules (HSMs) validated under FIPS 140-2. For security, keys are only used inside HSMs and can never be shared outside the AWS region in which they were created.
  5. Built-in auditing: AWS KMS is integrated with CloudTrail to help in monitoring key usage to meet regulatory and compliance needs.

Below is the table which summarizes the AWS Key Management Service Crypto Properties:

AWS Key Management Service Crypto Properties
 
Tenant Multi-Tenant
Standard FIPS 140-2 Level 2
Master Keys
  • Customer Owned Master key
  • AWS Managed Master Key
  • AWS owned Master key
Crypto Keys
  • Symmetric
  • Asymmetric
    AES in XTS mode only
Crypto API AWS SDK/API for KMS
Access Authentication/Policy AWS IAM Policy
Key Accessibility Accessible in multiple regions (Keys outside the region in which created cant be used)
High Availability AWS Managed Service
Audit Capability
  • CloudTrail
  • Cloud Watch
TenantMulti-TenantStandardFIPS 140-2 Level 2Master Keys
  • Customer Owned Master key
  • AWS Managed Master Key
  • AWS owned Master key
Crypto Keys
  • Symmetric
  • Asymmetric
    AES in XTS mode only
Crypto APIAWS SDK/API for KMSAccess Authentication/PolicyAWS IAM PolicyKey AccessibilityAccessible in multiple regions (Keys outside the region in which created cant be used)High AvailabilityAWS Managed ServiceAudit Capability
  • CloudTrail
  • Cloud Watch
 
TenantMulti-Tenant
StandardFIPS 140-2 Level 2
Master Keys
  • Customer Owned Master key
  • AWS Managed Master Key
  • AWS owned Master key
Crypto Keys
  • Symmetric
  • Asymmetric
    AES in XTS mode only
Crypto APIAWS SDK/API for KMS
Access Authentication/PolicyAWS IAM Policy
Key AccessibilityAccessible in multiple regions (Keys outside the region in which created cant be used)
High AvailabilityAWS Managed Service
Audit Capability
  • CloudTrail
  • Cloud Watch
Move your IT infrastructure to Cloud.

AWS CloudHSM

AWS CloudHSM is an AWS hardware security module that is customer-owned and managed. AWS CloudHSM acts as a single-tenant on hardware, restricting it from being shared with other customers and applications. Organizations can utilize AWS CloudHSM for those wanting to use HSMs to administer and manage encryption keys, but not have to worry about managing HSM Hardware in a datacenter.
AWS CloudHSM allows FIPS 140-2 Level 3 overall validated single-tenant HSM clusters in your Amazon Virtual Private Cloud (VPC) to store and use your keys. Complete control is given to users whose keys are used through an authentication mechanism separate from AWS.

AWS CloudHSM supports multiple use cases, including the following: management of Public/Private key pairs for Public Key Infrastructure (PKI), Code & Document Signing, or storing private keys for various services such as database, storage, and web applications, storing keys for DRM solution. AWS CloudHSM will allow your organization to meet compliances of key management requirements with the use of Hardware Security Modules supervised by AWS with the ability to incorporate multiple platforms to store keys.

Below is the table which summarizes the AWS Cloud HSM Crypto Properties

AWS CloudHSM Crypto Properties
 
Tenant Single-Tenant
Standard FIPS 140-2 Level 3
Common Criteria EAL4+( supported by cloudHSM classic older model)
Master Keys Master Key HSM
Crypto Key types
  • Symmetric – AES (Modes supported CBC, GCM and ECB)
  • Asymmetric – RSA, ECC
  • Hashing – SHA-256, SHA-512, RSA, ECDSA
API Support
  • PKCS11
  • OpenSSL
  • JCE
  • Crypto next generation (CNG)
Access Authentication/Policy Quorum based K of N principle
Key Accessibility Can be accessed and shared across multiple VPC
High Availability ADD HSM in Different Availability Zones
Audit Capability
  • CloudTrail
  • Cloud Watch
  • MFA support
TenantSingle-TenantStandardFIPS 140-2 Level 3
Common Criteria EAL4+( supported by cloudHSM classic older model)
Master KeysMaster Key HSMCrypto Key types
  • Symmetric – AES (Modes supported CBC, GCM and ECB)
  • Asymmetric – RSA, ECC
  • Hashing – SHA-256, SHA-512, RSA, ECDSA
API Support
  • PKCS11
  • OpenSSL
  • JCE
  • Crypto next generation (CNG)
Access Authentication/PolicyQuorum based K of N principleKey AccessibilityCan be accessed and shared across multiple VPCHigh AvailabilityADD HSM in Different Availability ZonesAudit Capability
  • CloudTrail
  • Cloud Watch
  • MFA support
 
TenantSingle-Tenant
StandardFIPS 140-2 Level 3
Common Criteria EAL4+( supported by cloudHSM classic older model)
Master KeysMaster Key HSM
Crypto Key types
  • Symmetric – AES (Modes supported CBC, GCM and ECB)
  • Asymmetric – RSA, ECC
  • Hashing – SHA-256, SHA-512, RSA, ECDSA
API Support
  • PKCS11
  • OpenSSL
  • JCE
  • Crypto next generation (CNG)
Access Authentication/PolicyQuorum based K of N principle
Key AccessibilityCan be accessed and shared across multiple VPC
High AvailabilityADD HSM in Different Availability Zones
Audit Capability
  • CloudTrail
  • Cloud Watch
  • MFA support

Custom Key Store

The Custom Key store feature of AWS KMS provides a way of integrating AWS CloudHSM clusters easily with AWS KMS.

Users can configure their CloudHSM cluster to store keys rather than the default KMS key store.

Users can also generate key material within the CloudHSM cluster. The master keys generated in the customer key store never leave the AWS Hardware Security Module in the CloudHSM Cluster in plaintext form, and all the cryptographic operations required by KMS are performed within the HSMs.

Conclusion:

AWS CloudHSM provides single-tenant key storage giving organizations FIPS 140-2 Level 3 compliance. CloudHSM allows full control of your keys, including Symmetric (AES), Asymmetric (RSA), SHA-256, SHA 512, Hash-Based, or Digital Signatures (RSA). On the other hand, AWS Key Management Service is multi-tenant key storage owned and managed by AWS. AWS KMS allows Customer Master Keys for symmetric key encryption (AES-256-XTS) and asymmetric keys (RSA or elliptic curve (ECC)). Suppose your organization’s key management strategy for encryption will be running a singular cloud service provider for now and for the foreseeable future. In that case, AWS KMS will provide the simplest environment to maintain the keys. However, suppose you are planning to take advantage of multiple cloud providers but do not wish to maintain the HSMs. In that case, AWS CloudHSM may be the solution for your organization that allows separating encryption keys from the data of the other platforms that are being utilized.

About the Author

Shorya Goel is a Consultant at Encryption Consulting, working with PKIs, HSMs, and working as a consultant with high-profile clients.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Read Time: 7 min

In today’s world, protecting your data is the most critical job at hand for any security expert. Once the data is protected with the help of some data protection tool and passphrases or passwords, then the next challenge is how to protect the passphrases or passwords or secrets itself. That’s when you need a software or hardware tool which can help you manage the secrets effectively and efficiently. AWS Secrets Manager is one such tool that can manage, retrieve, and rotate the passwords, database credentials, API keys, and other secrets throughout their lifecycle. It provides the central credential management with security at its best, resulting in avoidance of hard coding of credentials in the code.

Today, we will discuss the AWS Secrets Manager and its role in credential management facilitating some of the critical security use cases.

Characteristics of AWS Secrets Manager

AWS Secrets Manager provides various characteristics with respect to credentials management, such as:

  1. Integration with AWS KMS: AWS Secrets Manager is fully integrated with AWS KMS service and encrypts secrets as data-at-rest encryption with the Customer managed KMS keys. While retrieving the secrets, it decrypts the secrets using the same CMK KMS keys used earlier for encryption and transmits the secrets to your local environment securely.
  2. Secret Rotation: AWS Secrets Manager enables you to meet security and compliance requirements as per your organization’s goal. It provides you the secret rotation functionality on-demand or on a scheduled basis through the AWS management console, AWS SDK, or AWS CLI.
  3. Integrating with AWS Database services: AWS Secrets Manager supports native AWS database services such as Amazon RDS, Amazon DocumentDB, and Amazon Redshift. It also provides you the capability to rotate other types of secrets such as API Keys, OAuth tokens, and other credentials with the help of customized lambda functions.
  4. Contains multiple versions of secrets: AWS Secrets Manager can contain multiple versions of secrets with the help of staging labels attached with the version while rotating the secrets. Each secrets’ version contains a copy of the encrypted secret value.
  5. Manage access with fine-grained policies:  AWS Secrets Manager provides you flexible access management using IAM policies and resource-based policies. For e.g., you can retrieve secrets from your custom application running on EC2 to connect to a specific database instance (on-prem or cloud).
  6. Secure and audit secrets centrally: AWS Secrets Manager is fully integrated with AWS CloudTrail service for logging and audit purposes. For e.g., AWS CloudTrail will show the API calls related to creating the secret, retrieving the secret, deleting the secret, etc.

We have discussed some of the characteristics of the Secrets Manager. Now, below are the key points to be kept in mind while working with Secrets Manager:

  1. You can manage secrets for databases, resources in On-prem & AWS cloud, SaaS applications, third-party API keys, and SSH keys, etc.
  2. AWS Secrets Manager provides compliance with all the major industry standards such as HIPAAPCI-DSS, ISO, FedRAMP, SOC, etc.
  3. Secrets Manager doesn’t store the secrets in plaintext in persistent storage.
  4. Since the Secrets Manager provides the secrets over the secure channel, it doesn’t allow any request from any host in an unsecure fashion.
  5. Secrets Manager supports the AWS tags feature, so you can implement tag-based access control on secrets managed by the secrets manager.
  6. To keep the traffic secured and without passing through the open internet, you can configure a private endpoint within your VPC to allow communication between your VPC and Secrets Manager.
  7. Secrets Manager doesn’t delete the secrets immediately; rather, it schedules the deletion for a minimum period of 7 days. Within those 7 days, you may recover the secrets depending upon your requirements and post the scheduled period; the secrets are deleted permanently. However, through the AWS CLI, you may delete any secrets on an immediate basis.
  8. The AWS Secrets Manager offers a cost-effective pricing model where it charges $0.40 per secret per month or $0.05 per 10K API calls.

Use cases for AWS Secrets Manager

  1.  Secrets Manager avoids the need for hard-coding the credentials or sensitive information in your application code. It serves the purpose of having an API call to the secrets manager to retrieve the secret programmatically. Having this mechanism in place restricts anyone from compromising sensitive information or credentials as secret information doesn’t exist in the plaintext in the code.
  2. Secrets Manager provides centralized credential management, which reduces the operational burden resulting in the active rotation of credentials at regular intervals to improve the security posture of the organization.

Resources: https://aws.amazon.com/secrets-manager/pricing/

Conclusion:

Secret management plays a critical role in data protection for any organization in any environment (On-prem or Cloud). AWS Secrets Manager provides a rich feature set when it comes to secret management solutions. It supports a wide variety of secrets such as database credentials, credentials for On-prem resources, SaaS application credentials, API keys, and SSH keys, etc. In today’s security world, there are a number of secret management solutions available; however, considering the fact that AWS Secrets Manager works seamlessly in the AWS environment, it also provides great compatibility with other environments (On-prem) as well.

About the Author

Dipanshu Bhatnagar is a Principal Consultant Cloud Security Specialty at Encryption Consulting working with PKIs, AWS Cloud Cryptographic services and tools, Google Cloud Cryptographic Services, and helping high profile clients towards their cloud journey with complete data privacy assurance.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Public Key Infrastructure (PKI) is mostly about managing secure digital identities that enable ways to protect data and know the subject’s (a subject could be anything such as a computer, a person, a router or a service) identity when sharing information over untrusted networks. PKI is essential to most businesses and their applications today.

As the adoption of various forms of cloud models (i.e., public, private, and hybrid) across multiple industry is increasing, the cloud buzzword is on a new high. However, customers still have concerns about security areas and raise a common question:
“How can I trust the cloud?” The most straightforward answer to this question will be to “build trust around the cloud,” but how? Well, we will discuss a few wonderful concepts of PKI, which, if planned and implemented correctly, can be a good solution
to building customers’ trust in a cloud.Before discussing in detail about cloud-based PKI architecture models, let’s refresh some basics.

What is Public Key Infrastructure (PKI)?

Public Key Infrastructure combines different technological components for authenticating users and devices within a digital ecosystem. A PKI’s primary goals are for confidentiality and authentication i.e. allow for very private conversations over any
platform while keeping individual identities available for authentication. Cryptosystems use mathematical functions or programs/protocols to encrypt and decrypt messages.Each security process, layer, or software must implement and cover the CIA triad.

  • ConfidentialityIt refers to the process to ensure that information sent between two parties is confidential between them only and not viewed or disclosed by/to anyone else.
  • IntegrityIt refers to the process to ensure that the message in transit must maintain its integrity, i.e., the message’s content must not be changed. The Integration of data is secured by hashing.
  • AvailabilityAvailability is the final component of the CIA Triad and refers to the actual availability of your data. Authentication mechanisms, access channels, and systems all have to work correctly for the information they protect and ensure it’s available when it is needed.

Along with these, there are some important parameters which are described below:

  • AuthenticationThe process of confirming someone’s identity with the supplied parameters like username and password. PKI offers this through digital certificates.
  • AuthorizationThe process of granting access to a resource to the confirmed identity based on their permissions.
  • Non-RepudiationA process to make sure that only the intended endpoint has sent the message and later cannot deny it. PKI offers non-repudiation through digital signature.

Challenges when adopting a cloud-based PKI model

There are various challenges in PKI as per industry and business trends. Here we will discuss some of the most common challenges.

  • Lack of understanding of PKI concepts and design aspects. Also, meeting compliance requirement such as NIST-800-57 (provides recommendation for cryptographic key management) post-deployment is important.
  • Ignoring the importance of HSMs . When the use of HSMs is ignored, know that your PKI will not be FIPS-140 Level 3 compliant.
  • Knowing and understanding cloud providers (AWS, Azure, GCP etc.) which cloud provider can fulfil all the requirements, as per your business needs, is something that needs to be taken care of.
  • Integration with your existing PKI infrastructure. Choosing the right model for your organization is a must.
  • Choosing the right tools and processes for your certificate lifecycle management.

Considering Cloud-based PKI

Unlike on-premises counterpart, cloud-based PKIs are externally hosted PKI services, supplying PKI capabilities on demand. The cloud-based approach drastically reduces the burden on individual organizations – financially, resource-wise, and timewise,
by eliminating organizations’ need to set up any infrastructure in-house. The service provider handles all the ongoing maintenance of PKI while ensuring scalability and availability – providing a hassle-free, efficient service.Scalability to match the growing needs of the organization is another advantage. The service provider handles all additional requirements – installing software, hardware, backup, disaster recovery, and other infrastructure – that would otherwise become
a burden for owners of on-premises PKI solutions.

Options for Cloud-based PKI models

PKI or Public Key Infrastructure can be leveraged in several ways to benefit the organization. In each cloud-based PKI options, data security is utmost important, a properly functioning PKI is a must. Here are the following options of cloud-based PKI.

  • Simple Model
  • Two Tier hybrid Model
  • Three Tier Model
  • Three Tier Hybrid Model

Simple Model

This is the simplest model for cloud-based PKI to deploy and can be useful for small scale business models. In this approach Root CA is placed on-prem and offline the same way it is done for the traditional PKI. Issuing CA is kept on the cloud and acts
as a primary enterprise CA which issues certificates to the end-entities. Here, we leverage the cloud providers to provide management and availability for the virtual machines and certificate authorities.

For example: If your issuing CA is on AWS Certificate management private CA (ACM PCA) then to store the private keys, AWS cloud HSMs will be used.

NOTE: In the above model, the security of the private keys for the issuing CA relies entirely on the cloud providers, as you are using cloud HSMs.

Two Tier hybrid Model

In this architectural model, we are expanding the simple model for more security. The Root CA is kept on-prem and offline. Here, we have two issuing CAs, one is kept on-prem, and another one is kept on the cloud, and both are online.If you see the previous model, there will be trouble addressing the devices of the On- premise. However, in this model we are achieving the hybrid option as we are addressing both the resources (on-premises and cloud).The cloud Issuing CA will focus on the things which need issuance and availability outside the On-premises, whereas the on-prem Issuing CA will be focusing on the security of non-cloud resources e.g., Workstation authentication, Domain Certificates etc.
Also, the other PKI components such as CDP, AIA and OCSP can be placed on the cloud in a highly available state. By doing this, the cloud providers can be leveraged for revocation information.For this model, the signing keys are protected by both on-prem and cloud HSMs.

Three Tier Model

In this model, The Root CA is on-prem and offline and a Policy CA or Intermediate CA is added in the hierarchy (kept offline and secure) where you can explicitly define issuance and application policies. The Policy CA will decide which policies are going
to be issued and how it is going to be issued in an issuing CA.If you want to have tight control over the issuance of your certificates, while leveraging cloud providers at the same time, then putting the Policy CA on-prem and the Issuing CA on the cloud is the right use of this model.


However, in this model the issuing CA will not be able to issue certificates for any other purpose except the ones explicitly mentioned in the Policy CA.

Three Tier Hybrid Model

This model is almost like the previous three-tier option. The Root CA and Policy CA are kept on-prem and offline. There are two issuing CAs, one on-prem and another one on the Cloud to address different use cases. The explicit policies will be mentioned
in the Policy CA and Issuing CAs will issue certificates according to that.In this model, HSMs are used both on-prem (for the On-prem Issuing CA) and in the cloud (for the cloud Issuing CA) to store the signing keys. However, if you wish to use an on-prem HSM for your cloud issuing CA to store keys, you can do this by putting your Microsoft CA on the AWS EC2 instance.

The cost of a cloud-based PKI

Cloud-based PKI imposes a reduced financial burden on the organisation compared to
on-premises PKI. While on-premises PKI incur both hidden and traditional costs, cloud-based PKI services only incur a single monthly fee – ensuring all outgoing PKI costs
are fixed. On-premises PKI cost organisations approximately $305,000 more than the cloud-based Managed PKI service.

Conclusion

Cloud-based PKI services allow organisations to reduce some of the expensive costs associated with PKI deployment, which includes infrastructure and personnel training. Cloud-based PKI services are a cost-effective solution for all critical business transactions,
which means organisations do not have to choose between expensive security or a costly breach any longer.

About the Author

Parnashree Saha is a data protection senior consultant at Encryption Consulting LLC working with PKI, AWS cryptographic services, GCP cryptographic services, and other data protection solutions such as Vormetric, Voltage etc.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Read time: 15 mins

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:

  • SubjectProvides the name of the computer, user, network device, or service that the CA issues the certificate to.
  • Serial NumberProvides a unique identifier for each certificate that a CA issues.
  • IssuerProvides a distinguished name for the CA that issued the certificate.
  • Valid FromProvides the date and time when the certificate becomes valid.
  • Valid ToProvides the date and time when the certificate is no longer considered valid.
  • Public KeyContains the public key of the key pair that is associated with the certificate.
  • Signature AlgorithmThe algorithm used to sign the certificate.
  • Signature ValueBit 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.

Certificate authorities also issue other types of digital certificates:

  1. Code Signing CertificatesCode 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 certificatesEnable entities to sign, encrypt, and authenticate email using the S/MIME (Secure Multipurpose Internet Mail Extension) protocol for secure email attachments.
  3. Device certificatesIssued to internet of things (IOT) devices to enable secure administration and authentication of software or firmware updates.
  4. Object certificatesUsed to sign and authenticate any type of software object.
  5. User or client certificatesUsed 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.

Step 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.
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.
Step 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.
Step 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.
Step 5
Certificate expiration dates also need to be checked to validate the certificate.
Step 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.

About the Author

Parnashree Saha is a data protection senior consultant at Encryption Consulting LLC working with PKI, AWS cryptographic services, GCP cryptographic services, and other data protection solutions such as Vormetric, Voltage etc.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Read Time: 10 min

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 ManagerIs 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 AuthorityIs 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.)

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.

About the Author

Dipanshu Bhatnagar is a Principal Consultant Cloud Security Specialty at Encryption Consulting working with PKIs, AWS Cloud Cryptographic services and tools, Google Cloud Cryptographic Services, and helping high profile clients towards their cloud journey with complete data privacy assurance.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

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.

A digital Certificate establishes the owner’s identity and it makes the owners public key available. A digital certificate is issued by a trusted Certificate Authority and it is issued only for a limited time, after the expiration of the certificate a new certificate would be 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.

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.

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 for key exchange, server authentication, and client authentication.
  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).

System Certificate Stores:

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 info@encryptionconsulting.com for further information.

About the Author

Parnashree Saha is a data protection senior consultant at Encryption Consulting LLC working with PKI, AWS cryptographic services, GCP cryptographic services, and other data protection solutions such as Vormetric, Voltage etc.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

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 www.encryptionconsulting.com/2020/08/08/pki-in-aws-cloud

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.

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 info@encryptionconsulting.com 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.

About the Author

President at Encryption Consulting LLC focusing on providing consulting to customers in the Applied Cryptography space.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Global Public Cloud market size is expected to reach $488.5 billion by 2026 as per a research study conducted by www.businesswire.com and there will be a predicted 16% CAGR market growth during the forecasted time period. This triggers the immediate need to shift our focus on “Cloud Security”. Let’s deep dive into the Public Key Infrastructure (PKI) in Amazon Web Services (AWS) Cloud.

Let us understand PKI in AWS:

ACM stands for AWS Certificate Manager. Just like any Certificate Manager, ACM provides convenient options for cloud service users to create, manage and deploy public and private SSL/TLS X.509 certificates and keys. These certificates provide authentication of identity of websites as well as private resources and protection for sensitive data hosted on Amazon Web Services platform. AWS services supported certificates can be provided either by directly issuing with ACM or by importing third party certificates to ACM management system.

Services offered through ACM in AWS:

Amazon provides two options for customers to deploy SSL/TLS X.509 certificates. Depending on the business requirement customers can choose from the below options.

  • ACM Certificate Manager (ACM) : This service is targeted for customers who need secure web existence using TLS certificates. ACM deploys certificates using AWS services – Amazon CloudFront, Elastic Load Balancing, Amazon API Gateway, and other integrated services. Enterprises with secure public website with significant web traffic can prefer this certificate management service
  • ACM Private CA – This service is most suited for small and medium enterprise customers who desire to build their own Public Key Infrastructure (PKI) with in AWS Cloud and projected for private use within the organization. Within private CA users can create their own CA hierarchy and issue certificates for authenticating internal users, applications, services, devices etc.Note : Certificates issued using Private CA cannot be used on internet

ACM Certificate Characteristics:

Public certificates provided by ACM have the characteristics described in this section. These characteristics only apply to certificates provided by ACM and might not apply to certificates imported to ACM:

Serial No. Characteristics
1Domain Validation (DV)ACM Certificates are domain validated. Subject field of an ACM Certificate identifies a domain name. Ownership can be validated using email or DNS
2Validity Period for Certificates13 months
3Managed Renewal and DeploymentAutomatic renewal and provisioning of certificates by ACM
4Browser and Application TrustACM certificates are trusted by all major browsers including Google Chrome, Microsoft Internet Explorer and Microsoft Edge, Mozilla Firefox, and Apple Safari. ACM Certificates are also trusted by Java
5Multiple Domain NamesEach ACM certificate must include one Fully Qualified Domain Name (FQDN) and additional names can be added further
6Wildcard NamesACM allows to use an (*) asterisk in domain name to create an ACM certificate that can protect several sites in the same domain
7AlgorithmsPublic key algorithms supported by ACM:

 

  • 2048-bit RSA (RSA_2048)
  • 4096-bit RSA (RSA_4096)
  • Elliptic Prime Curve 256 bit (EC_prime256v1)
  • Elliptic Prime Curve 384 bit (EC_secp384r1)

AWS Certificate Manager Pricing:

  1. Public SSL/TLS certificates provisioned through AWS Certificate Manager are free of cost. Customer needs to pay only for AWS resources created to run application/services.
  2. ACM Private CA is priced along two stages
    1. Monthly fee of $400 for each ACM private CA until it is deleted
    2. Customer pays a one-time fee when certificates are issued from ACM Private CA

Please visit Amazon Web Services portal for more details: www.aws.amazon.com

If your organization is looking for implementation of AWS Certificate Authority, please consult info@encryptionconsulting.com for further information.

About the Author

President at Encryption Consulting LLC focusing on providing consulting to customers in the Applied Cryptography space.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Let's talk