Learn The Basic Concepts of PKI – Intune PKI Made Easy With Joy Part-1

In the UEM marketspace, Microsoft Intune is a true cloud-based SaaS service for

  • managing your workforce devices
  • managing applications on the workforce devices
  • protecting data being accessed from the managed applications

However, when it comes to Certificate deployment – it is one of the two occasions (yes am pointing to Hybrid Azure AD join) where Intune leverages the on-premise infrastructure to deliver the required results.

Intune supports the deployment of SCEP, PKCS, and Imported PFX certificates to the managed endpoints. However, all three certificate profile types have their own setup requirements and workflows.

In this article series, “Intune PKI Made Easy With Joy“, I will give a detailed walkthrough of the workflows for each certificate deployment scenario with Intune.

Patch My PC

On a personal note, I believe that you can sustain only when you have the basics right. As such, before we get into the details of how Intune utilizes PKI, it is important to understand the basic concepts of PKI.

So today, we will be learning the basics of Public Key Infrastructure. Let’s get started!

Encryption/Decryption – Learn the basics of PKI

Encryption is the process to protect (encode) the content (data) of a file/message, in such a way that only the intended entity will be able to retrieve the content from the file/message. Decryption is the process of retrieving (decode) the content from an encrypted file/message.

Encryption is the process of converting plaintext to ciphertext. Decryption is reverse.

Adaptiva
Intune PKI Made Easy With Joy - Learning the basics - What is encryption?
Intune PKI Made Easy With Joy – Learning the basics – What is encryption?

There are different cryptographic algorithms that makes encryption possible, but discussing about those is not a focus of this article!

For the purpose of encryption, the encrypting entity needs to generate a cryptographic key with which the content will be encrypted. This cryptographic information needs to be known to the decrypting entity (shared out-of-band) to be able to decrypt the content.

What is a cryptographic key?

It is a random string generated by the cryptographic algorithm used to alter plaintext data and convert it to ciphertext. The usage of the key is determined by the Key Usage parameter that the algorithm used to generate the key – either Digital Signature or Key Encipherment or Both. There can be two types of encryption based on the key type

Symmetric Key Encryption

The same key is used for both encryption and decryption. Though this type of encryption usually benefits from faster convergence time when working with a large amount of content (data), however, it lacks in terms of security.

If the party encrypting the file is not the one who will be decrypting it, the key needs to be shared over a medium between the encrypting and decrypting party – thus very much prone to man-in-middle attacks.

Also, say you want to share content privately with 10 recipients in such a way that only the intended recipient will be able to decrypt and have access to the content. In such a scenario, you have to generate 10 symmetric keys and encrypt the content 10 times for each unique key and then send the content along with the unique key to the intended recipient – not secure as well as adds overhead.

Intune PKI Made Easy With Joy - Learning the baisc - Symmetric Key Encryption uses same key for encryption and decryption. Not secure if the encrypting and decrypting entities are not same.
Intune PKI Made Easy With Joy – Learning the baisc – Symmetric Key Encryption uses same key for encryption and decryption. Not secure if the encrypting and decrypting entities are not same.

As such, in most cases, symmetric key encryption is used when the encrypting/decrypting party is the same and does not involve sharing of encrypted content within different entities.

Mostly you will see symmetric key encryption is used in conjunction with asymmetric key encryption where the former is used for actual encryption/decryption of content while the latter is used to protect the encryption key.

Asymmetric Key Encryption

Encryption and decryption operations are performed with different keys cryptographically correlated to each other. It is also known as Public Key Encryption and is the base for Public Key Infrastructure (PKI).

One key is kept private to the entity, while the other one is made publicly available – thus the name private/public key pair. The content is encrypted with either one of the keys, only the corresponding correlated key would be able to decrypt it.

The public key is used for encryption so that the Private key can be used for decryption.

Every entity participating in the communication which involves asymmetric key encryption, at first, exchanges their public keys with each other so that every entity will have the public keys of all other participating entities before the actual communication starts.

This ensures that if the sender entity wants to send an encrypted message to the recipient entity, the sender would encrypt the message content using the public key of the recipient (already received as part of a key exchange that happens during communication initialization) so that the recipient will be able to decrypt the content with its own private key.

Since the private key is private to an entity and is not expected to be available to other entities, asymmetric key encryption ensures privacy without compromising security.

Intune PKI Made Easy With Joy - Learn the basics - Asymmetric Key Encryption uses seperate keys for encryption and decryption.
Intune PKI Made Easy With Joy – Learn the basics – Asymmetric Key Encryption uses seperate keys for encryption and decryption.

This not only solves the security issue which plagues symmetric key encryption (man-in-middle attack) but also reduces the overhead of creating multiple keys to send messages privately to different entities.

All these were about protecting the content (data). But how to prove

  • the authenticity of message origin to prevent impersonation?
  • the message was not tampered with during the transmission?

Digital Signature – Learn the basics of PKI

Digital Signature is used to prove the authenticity of origin. The sender entity uses its private key to sign the message. Since the private key is private to the sender and is not available publicly, thereby proves the authenticity of origin.

Sender generates SIGNATURE as below

  • Hash of the message is generated cryptographically
  • The Hash as generated is then encrypted with the senders private key to produce the SIGNATURE

The SIGNATURE is attached to the message and then sent.

The receiver verifies the signed data to check Sender authenticity as below

  • Tries to decrypt the SIGNATURE using the sender public key, which if successful, will give back the Original Hash the value that was computed when the sender signed the message.
  • Computes a Hash of the message received using the same algorithm used by the sender to produce Current Hash value.

If the Original Hash matches the Current Hash value means the signature is valid – the message has come from the sender and not from an impersonator and also the hash value match signifies the message has not been tampered with during the transmit.

Intune PKI Made Easy With Joy - Learn the basics - Digital Signature proves sender authenticity
Intune PKI Made Easy With Joy – Learn the basics – Digital Signature proves sender authenticity.
Digital Signature combined with PKI encryption
 
The data is first encrypted using the recipient's public key and then the
HASH value of the encrypted message is computed, which is again encrypted
with the sender's private key to generate the sender Signature which is 
attached to the encrypted message. When the recipient gets the encrypted 
and signed message, it will decrypt the Signature with the sender's public 
key to get the original HASH value. It will also compute hash of the encrypted
message to get the current HASH value to match it with the original HASH value
retrieved by decrypting the signature.
 
This way, both the message privacy as well as authenticity is satisfied.

Digital Certificate – Learn the basics of PKI

A digital certificate (in PKI terms) is a PKI object which contains the public key along with other information like

  • Issuer – Entity who issued the certificate
  • Subject Name/Subject Alternate Name – Entity to whom the certificate is issued to
  • Certificate Usage – The intended purpose of the certificate (determined by EKU)
  • Issuer Signature – The issuer signs the Certificate with its private key

and other metadata information. (like Thumbprint, etc.)

Intune PKI Made Easy With Joy - Learn the basics - Understanding Digital Certificates
Intune PKI Made Easy With Joy – Learn the basics – Understanding Digital Certificates

When we say that in PKI, the public key of an entity is made available publicly, it’s actually the public key certificate we are referring to which is shared with others.

The private key corresponding to the public key remains securely stored within the entity (or can be taken out and stored securely on a USB key if it is exportable). The private key is never made available to the public. If the private key gets compromised, the whole security breaks.

The most used purpose of a digital certificate is to facilitate Authentication.

Digital Certificates can again be of two types

Self-Signed

An entity can generate its own public/private key pair (PKCS#12) which results in a self-signed certificate (x.509) for the public key which can be presented or distributed publicly.

A self-signed certificate is way of saying I-AM-WHO-I-SAY-I-AM

In an enterprise scenario, a self-signed certificate does not serves the purpose of security. If a self-signed cert is allowed in an enterprise scenario to get authenticated, anyone (who is not a member of the organization) can gain access to the resources. Certainly not desired!

3rd Party generated

Thus an enterprise requires an entity that is authorized with the task of creating public/private key pairs and issuing digital certificates for the corresponding pubic key created,  to the enterprise members (end entities) requesting certificates.

Such an entity to which all other entities will reach out to request for a certificate is known as a Certificate Authority (CA), the core of PKI infrastructure.

A 3rd party generated certificate is a way of saying I-AM-WHO-THE-ISSUER-SAYS-I-AM

Thus when an entity (requestor) requires a certificate, it reaches out to the CA to request one. The CA validates the request – to see if the requestor is permitted to gain a certificate as requested. If true, it generates a public/private key pair for the requestor, issues a digital certificate for the public key signed with its own private key (CA private key) and sends the certificate along with the key pair as generated back to the requesting entity. The requesting entity then stores the private key securely and uses the certificate to prove its identity.

CA can again be of two types – Standalone and Enterprise (domain joined)

Active Directory Certificate Services is a huge topic in itself! Certainly not in the scope of this article series…

Establishing Trust – Learn the basics of PKI

When working with a CA generated certificate, the important topic that comes is Trust.

For an entity to make a certificate request to the CA, the CA first needs to be trusted by the entity. The trust is established via the exchange of public keys initiated by an actor who the entity trusts by default.

In the case of Enterprise CA, the PKI trust is established by default when the device becomes a domain member and automatically receives the enterprise CA public key cert for trust establishment. For devices that cannot become domain members – mobile devices like iOS/Android or Workgroup Windows devices, the trust needs to be established by an out-of-band method – the admin exports the public certificate of the CA and installs it on the device as a Trusted Certificate to explicitly establish the trust.

Now consider the Requestor (the end entity) has established trust with the CA and has received a certificate that it can use for authentication. When it presents the certificate to the authenticating party (Challenger) to request access, the Challenger also must trust the CA in order to trust the Requestor. Let us understand with a simple example below.

Consider three entities as A, B and C.
 
A is the certificate issuer who issued the certificate to B, who goes to entity C
to access some resource. When C asks B to provide a certificate to prove identity
and validate the access request, B provides to C the certificate it received from A.

How will C validate B? 

C will be able to validate the access request made by B only if it trusts A. So if
A trusts B and C trusts A, means C will trust B also. 

This is how 3rd party trust is established in PKI.
Intune PKI Made Easy With Joy - Learn the basics - 3rd party Trust establishment - A trust B and C trust A so C trust B
Intune PKI Made Easy With Joy – Learn the basics – 3rd party Trust establishment – A trust B and C trust A so C trust B

Once the PKI trust is established, C will check the certificate validity against the CRL that the CA publishes.

Certificate Revocation List (CRL) is information that the CA publishes at regular interval which contains the information of the certificates that has been revoked.

Once CA publishes a certificate, it remains valid from the time it is issued (Not Before) till it reaches the expiry date (Not After). However, in between the validity period, a certificate may get invalidated due to various reasons. In such circumstances, the CA operator can revoke a certificate that the CA issued making the certificate useless.

So when C receives a request from B to grant access to resources, C will also check the CRL if the certificate as provided is still valid or has been revoked.

Chain Building – Learn the basics of PKI

The above is considering there is only an Enterprise Root CA, which itself is the Issuing CA. In the real world, most organizations who have invested in on-premise PKI infrastructure will have a  multi-tier PKI infrastructure – one Enterprise Root CA per AD forest and multiple levels of  Sub CA, and any one of those Sub CA is configured as the Issuing CA.

In such a scenario, when the Requestor reaches out to Challenger to get access, the Challenger will verify the complete chain of trust to the Root.

This is commonly referred to as “PKI Chain Building” where the Challenger verifies the digital signature of each CA public certificate until forming the chain of hierarchy to the Root.

Intune PKI Made Easy With Joy - Learn the basics - PKI Chain Building is a process to verify all the trusted CA which forms the chain of hierarchy to Root in a multi-tier PKI infrastructure.
Intune PKI Made Easy With Joy – Learn the basics – PKI Chain Building is a process to verify all the trusted CA which forms the chain of hierarchy to Root in a multi-tier PKI infrastructure.

A simple representation of the same for easy understanding is given below

Intune PKI Made Easy With Joy - Learn the basics - PKI Chain Building simple illustration - Each certificate refers to the Issuer and is signed by the Issuer for verification purpose.
Intune PKI Made Easy With Joy – Learn the basics – PKI Chain Building simple illustration – Each certificate refers to the Issuer and is signed by the Issuer for verification purpose.

To be contd. (Part 2 coming soon!)

This article is the foundation for the series “Intune PKI Made Easy with Joy“.

In the next part of this series (Part 2), I will be taking you through the process of how an end entity makes a certificate request to the CA.

Does it involve a standard process? If yes, what protocol(s) is/are used? Will be covered in Part 2. So stay tuned!

I recently completed the LearnWIPwithJoy series (4 articles on WIP!) so if you have not read those, you can have a look at them here from my profile.

As I say at the end, keep reading, keep learning, and last but not least – Stay Safe

3 thoughts on “Learn The Basic Concepts of PKI – Intune PKI Made Easy With Joy Part-1”

  1. Great series Joymalya, One question is why not just have one Root CA only? what benefit is there to have a multi tier PKI infrastructure especially if there is only one forest/domain in the enviroment?

    Reply
    • Hey Jack,

      You can definitely use the Root CA as your Issuing CA to bypass a multi-tier architecture, however, most organizations do like to have their Root CA secured by taking it offline and instead use Issuing CAs to handle client cert requests. It all depends on what your infrastructure is and what your requirement is and how your requirement can be made to best fit with your current environment without doing many major changes unless absolutely required.

      Hope I was able to answer your query.

      Reply
  2. Nice article. You have mentioned that CA creates public/private key pair for the end device. But the end device creates the pair and sends only public key to CA (in CSR) for signing.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.