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 different certificate profile types have their own setup requirements and different workflows.
In this article series “Intune PKI Made Easy With Joy“, I will be giving a walkthrough of the workflows for each certificate deployment scenario with Intune in detail.
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.
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.
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.
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.
SIGNATURE as below
Hashof the message is generated cryptographically
Hashas generated is then encrypted with the senders
private keyto produce 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
SIGNATUREusing the sender public key, which if successful, will give back the
Original Hashthe value that was computed when the sender signed the message.
- Computes a
Hashof the message received using the same algorithm used by the sender to produce
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.
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.)
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
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.
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.
A simple representation of the same for easy understanding is given below
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