PKI – Let’s make it Secure

Post three of what currently stands at a 4 part introduction to Public Key Infrastructure from my colleague Jason Wallace. Jason is laying the foundations to cover some ConfigMgr related certificatary (I know that's not really a word, but it's the end of a very long hot day and I need to amuse myself somehow)  

Over to you Jason.

Thanks for bearing with me on this.

So, to recap, we know that there are two major forms of encryption - symmetric and asymmetric and we said that there are three goals of using encryption -

• Confidentiality
• Integrity
• Authenticity

We have not really touched Integrity, so, before we look at how this all stitches together let's briefly look at hashing.

Hashing

Hashing is unlike encryption as hashing does not alter the source data at all.  What it in fact does is to generate something brand new which can sit alongside the data being hashed.  The hash will be generated through a hashing algorithm which will always return a result of a known length but that would return a hash which is completely different if even only a single bit in the data being hashed is different.  For example, if I were to hash a single byte file with MD5 then I would see a 128 bit result.  If I were to hash 1 terabyte of data I would see a different 128 bit result.  If either of the files were to change by the slightest bit then we'd see a totally different hash.  With hashing, we can guarantee that what we have received is what was sent, thereby giving us integrity.

For example, if we hash the alphabet using the MD5 algorithm the output is:

8eb7ab130d2ebf1e0bff12606ccaabd3

If we hash the same string but capitalised, this time the hash string is totally different

9c4511bd25cb573b3994ea4f80f5652a

Here we can see that even if the data is fundamentally the same but has changed in the most minute of ways, we still see a different hash!

Stitching it all together

• Confidentiality

This one should be easy by now.  There are a number of options

• I could create an encryption key and deliver it to you out of band. We could use that key to symmetrically encrypt the data both ways
• Slightly more secure would be that I create a key which I give to you. You create one which you give to me. We use one of those keys for each direction of communications
• You could create a public/private key pair and give me your public key. I could then encrypt the data using your public key
• I could create a session key and then encrypt the session key with your public key. You could then decrypt the session key and then use that to encrypt the communications. When it comes to re-keying then we could revert to the public keys again.
• Integrity
• So this will be done by using hashes
• Authenticity
• If you encrypt something using your private key then this will prove that you encrypted it

Pretty much all we do with PKI is done using a combination of these technologies.  It can become difficult to track whose keys are who's when we are, for example looking at embedding a hash, which was encrypted with your private key and then re-encrypted using my public key but it does pan out in the end.  Remember that pretty much any solution that would involve a private key crossing the network is likely to be the wrong answer!

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

This post was contributed by Jason Wallace, a Premier Field Engineer with Microsoft Premier Field Engineering, UK