A Basic Set-Up of Cryptography and Azure on How to Implement PKI within the Azure Environment

People and services in your organization share massive confidential information over the public internet. Cryptography in Azure environment offers enhanced network security, including authenticating users. A public key infrastructure (PKI) provides a framework of encryption to protect communication between end-users and the Azure environment.

Admins can use PKI, or asymmetric encryption, to create a public-private key pair for users. In this setup, the system stores the public keys in digital certificates for secure exchange. On the other hand, the private keys are securely stored in the software. The two-key encryption system secures sensitive information as it passes through the network. Each communicating party receives a key to encrypt and decrypt the digital data.

A Basic Setup of Cryptography in Azure

This set up used digital certificates to associate a PKI system's public key with the owner's identity. To authenticate the identity disclosed in the digital certificate, the owner needs to respond to a query using the private key belonging to the key-pair that only he has access to.

The certificate authority in the setup, the certificate authority (CA) provides a foundation of trust by authenticating identities of users, services, and other entities in the Azure environment. The PKI system saves all certificate requests in a certificate database.

A user sends a request to the Azure environment using a CA certificate. The sender uses a private key to create a unique signature for the message being sent. The signature is forwarded to the verification authority for user authentication and authorization before granting access on the cloud.

Figure 1 - Basic Setup of Cryptography

Factors to Consider When Implementing PKI in Azure

A PKI infrastructure includes a system that enables users and services to issue, distribute, store, use, verify, and revoke cryptography keys and certificates. Setting up a PKI system is essential to consider the available resources to manage the solution. Some of the considerations include:

·       Integration – the PKI service should integrate with other services for seamless information exchange

·       Automation – the service should automate the deployment of keys/certificates to users and systems. Besides, the key deployment should be transparent to end-users

·       Manageability – the service requires proper management processes to issue and revoke keys and certificates

·       Security – determine the level of protection required for the PKI system and the encryption algorithm used

·       Flexibility – determine if the system will need to support different technology, varying security levels, and global presence

Public Key Infrastructure

This section provides an overview of Public Key Infrastructure (PKI) and details the PKI requirements and solutions as they relate to Switching. It explains the digital certificate requirements for Parties and the interaction between the PKI components and processes, enabling Parties to register, request, install and manage the certificates necessary to secure the Switching ecosystem.

Overview

Implementing the mechanisms required to secure the flow of messages with TLS and digital signatures requires digital certificates. The digital certificates are used to secure communications using public key cryptography schemes.

A Public Key Infrastructure (PKI) is a collection of policies, procedures and technology needed to manage digital certificates in a public key cryptography scheme.

Digital Certificates

The objective of a public key cryptography scheme is trust. A digital certificate is an electronic signature from a trusted third parties that guarantees the validity and authenticity of a public key.

The digital certificate binds an entity, being an institution, a person, a computer program, a web address etc., to its public key.

The most common type of certificate is the one compliant with the X.509 standard, which allows the encoding of a party’s identifying details in its structure.

Figure 2 - Digital Certificate

The most common trust model used to validate the validity and authenticity of a public key is a Certificate Authority.

What is meant by a Public Key?

Authentication and message integrity are important concepts in secure communications and are vital security services for Switching.

Authentication requires that entities who exchange messages are assured of the identity that created a specific message. For a message to have “integrity”, it should not have been modified during transmission (or at least if it has, you should have a way to find out).

For example, you will want to be sure you’re communicating with a real third party (such as a bank) rather than an impersonator. Or if you have received a message from a bank system you will want to be sure that it hasn’t been tampered with by anyone else during transmission.

Traditional authentication mechanisms rely on digital signature schemes that, as the name suggests, allow a party to digitally sign its messages. Digital signatures also provide guarantees as to the integrity of the digitally signed message.

Technically speaking, digital signature schemes require the Source and each third party to hold two cryptographically connected keys: a public key that is made widely available and acts as authentication anchor, and a private key that is used to produce digital signatures on messages. Recipients of digitally signed messages can verify the origin and integrity of a received message by verifying that the attached signature is valid using the public key of the assumed sender.

The unique mathematical relationship between the keys (which is called a trapdoor one-way function) is such that the private key can be used to produce a signature on a message that only the corresponding public key can verify.

It is the public key that is embedded in a digital certificate, and the security of public key cryptography relies on ensuring that private keys are kept secure.

Figure 3- Public Key Authentication

Certificate Authority

The Certificate Authority (or CA - synonymous with an Issuing Authority – or IA) is a trusted third party specialised in issuing and managing digital certificates such as DigiCert and Verisign.

The CA will issue digital certificates to authorised Users. These certificates are digitally signed by the CA and bind Service Users with their public keys. As a result, if you trust the CA (and know its public key), you can trust that the specific party’s public key included in the certificate is genuine.

Certificates are publicly available as they do not include either the Service User or the CA’s private keys. As such they can be used as anchors of trust for authenticating messages originating from different parties.

CAs also have a certificate, which they make widely available. This allows the consumers of identities issued by a given CA to verify them by checking that the certificate could only have been generated by the holder of the corresponding private key (the CA).

Figure 4 - Certificate Authority (CA)

Source: hyperledger.org

1.5        Determining Trust and Validity

To verify whether a digital certificate for an end-entity can be trusted and is valid requires the party doing the validation (or Relying Party) to validate as follows:

Chain of Trust

The standard trust model used holds that if the digital certificate is digitally signed by the CA, then it can be trusted by the relying party. To do this the relying party needs to verify the CAs digital signature and that certain contents of the digital certificate are also correct (for example that the certificate has not expired and that the key usage is for digital signatures).

To verify the CAs digital signature, the relying party must have access to the CAs public key, which itself will be contained in another certificate signed by a higher-level (Intermediate) or top-level (Root) CA. All certificates that comprise the ‘certificate chain’ will be required to complete the validation process (also known as ‘walking the chain’).

Figure 5 - Chain of Trust

Certificate Revocation Lists

A Certificate Revocation List (CRL) is a list of references to certificates that a CA knows to be revoked for one reason or another (much like a list of stolen credit cards).

When a relying party wants to verify another party’s identity, it first checks the issuing CA’s CRL to make sure that the certificate has not been revoked. A relying party doesn’t have to check the CRL, but if they don’t, they run the risk of accepting a compromised identity.

Figure 6 - Certificate Revocation Lists

A Basic Setup of Cryptography in Azure

This set up used digital certificates to associate a PKI system's public key with the owner's identity. To authenticate the identity disclosed in the digital certificate, the owner needs to respond to a query using the private key belonging to the key-pair that only he has access to.

The certificate authority in the setup, the certificate authority (CA) provides a foundation of trust by authenticating identities of users, services, and other entities in the Azure environment. The PKI system saves all certificate requests in a certificate database.

A user sends a request to the Azure environment using a CA certificate. The sender uses a private key to create a unique signature for the message being sent. The signature is forwarded to the verification authority for user authentication and authorization before granting access on the cloud.

Benefits of using PKI within the Azure Environment

What are the benefits of implementing PKI within your Azure environment?

1.     Security: Implementing PKI within the Azure environment eliminates the possibility of information theft. The security measure renders attacks like the man-in-the-middle (MITM) useless since hackers cannot decrypt stolen data.

2.     Trust: cryptography provides a foundation for building trust by verifying and ensuring data is exchanged between authorized users and services

3.     Compliance: a PKI system in Azure environment provide privacy of information by mitigating cyber risks while on transit. This capability enhances an organization's compliance efforts with regulations like the General Data Protection Regulation (GDPR)

4.     Integrity: with PKI solution, external parties cannot alter or tamper with information shared in an Azure environment. The system assures the integrity of electronic communication

5.     Non-Repudiation: implementing a PKI system in Azure provides transaction non-repudiation. Users cannot deny their activities in a valid electronic transaction

Authorize: PKI within an Azure environment enables applications approval and authorization with code signing

Azure Key Vault helps solve the following problems:

• Secrets Management - Azure Key Vault can be used to Securely store and tightly control access to tokens, passwords, certificates, API keys, and other secrets
• Key Management - Azure Key Vault can also be used as a Key Management solution. Azure Key Vault makes it easy to create and control the encryption keys used to encrypt your data.
• Certificate Management - Azure Key Vault is also a service that lets you easily provision, manage, and deploy public and private Transport Layer Security/Secure Sockets Layer (TLS/SSL) certificates for use with Azure and your internal connected resources.

Figure 7 - PKI within the Azure Environment

Why use Azure Key Vault?

Centralize application secrets

Centralizing storage of application secrets in Azure Key Vault allows you to control their distribution. Key Vault greatly reduces the chances that secrets may be accidentally leaked. When using Key Vault, application developers no longer need to store security information in their application. Not having to store security information in applications eliminates the need to make this information part of the code. For example, an application may need to connect to a database. Instead of storing the connection string in the app's code, you can store it securely in Key Vault.

Your applications can securely access the information they need by using URIs. These URIs allow the applications to retrieve specific versions of a secret. There is no need to write custom code to protect any of the secret information stored in Key Vault.

Securely store secrets and keys

Access to a key vault requires proper authentication and authorization before a caller (user or application) can get access. Authentication establishes the identity of the caller, while authorization determines the operations that they are allowed to perform.

Authentication is done via Azure Active Directory. Authorization may be done via Azure role-based access control (Azure RBAC) or Key Vault access policy. Azure RBAC is used when dealing with the management of the vaults and key vault access policy is used when attempting to access data stored in a vault.

Azure Key Vaults may be either software-protected or, with the Azure Key Vault Premium tier, hardware-protected by hardware security modules (HSMs). Software-protected keys, secrets, and certificates are safeguarded by Azure, using industry-standard algorithms and key lengths. For situations where you require added assurance, you can import or generate keys in HSMs that never leave the HSM boundary. Azure Key Vault uses nCipher HSMs, which are Federal Information Processing Standards (FIPS) 140-2 Level 2 validated. You can use nCipher tools to move a key from your HSM to Azure Key Vault.

Finally, Azure Key Vault is designed so that Microsoft does not see or extract your data.

Monitor access and use

Once you have created a couple of Key Vaults, you will want to monitor how and when your keys and secrets are being accessed. You can monitor activity by enabling logging for your vaults. You can configure Azure Key Vault to:

• Archive to a storage account.
• Stream to an event hub.
• Send the logs to Azure Monitor logs.

You have control over your logs and you may secure them by restricting access and you may also delete logs that you no longer need.

Simplified administration of application secrets

When storing valuable data, you must take several steps. Security information must be secured, it must follow a life cycle, and it must be highly available. Azure Key Vault simplifies the process of meeting these requirements by:

• Removing the need for in-house knowledge of Hardware Security Modules.
• Scaling up on short notice to meet your organization's usage spikes.
• Replicating the contents of your Key Vault within a region and to a secondary region. Data replication ensures high availability and takes away the need of any action from the administrator to trigger the failover.
• Providing standard Azure administration options via the portal, Azure CLI and PowerShell.
• Automating certain tasks on certificates that you purchase from Public CAs, such as enrollment and renewal.

In addition, Azure Key Vaults allow you to segregate application secrets. Applications may access only the vault that they are allowed to access, and they can be limited to only perform specific operations. You can create an Azure Key Vault per application and restrict the secrets stored in a Key Vault to a specific application and team of developers.

Integrate with other Azure services

As a secure store in Azure, Key Vault has been used to simplify scenarios like:

• Azure Disk Encryption
• The always encrypted and Transparent Data Encryption functionality in SQL server and Azure SQL Database
• Azure App Service.

Key Vault itself can integrate with storage accounts, event hubs, and log analytics.