PKI - Let's Keep it Secret
Over here in Thames Valley Park, myself and a few colleagues attended a brilliant session on Intel vPRO, in particular, playing about with AMT (Active Management Technology) which integrates with Configuration Manager under the Out Of Band Management banner.
One of the upshots of this session was my colleague, Jason, putting together some details on Public Key Infrastructure. Over the next week or so Jason will be providing a series of articles on PKI which will eventually lead in to blogs covering Native Mode and Out of Band Management. These blogs won’t specifically be ConfigMgr or even strictly speaking be manageability related. But stick with it, Jason is laying the groundwork for some future blogs.
Over to Jason, who is a colleague of mine in the Configuration Manager team, but he does also dabble in the security and PKI space
Let’s imagine that you want to send some information to a friend. What are the things that you might be interested in within this communication? This section is going off on a rather long tangent, but please bare with me. If you know all of this then please skip to the next blog post.
· Confidentiality
You might want to be certain that only you and your co-respondent can see the message contents. If there is someone looking to learn your innermost secrets then you’d want to have a degree of certainty that the information is secure.
· Integrity
You might want to be able to guarantee that the information which was received was verifiably the same information that was sent. Imagine how bad it could be if someone received some information which was even a single character different. Imagine what impact to your business there could be if the quotation you sent to a potential client charging $10,000 is actually received as £10,000. Ok, so this might not be a bad thing for you, unless someone else has quoted $12,000!
· Authenticity
When I receive some information I want to have some assurance that the person who the message claims to be from actually IS the sender of the information. If I receive a message from Barack Obama then I’d like to have certainty that it was The President who sent me the message. So, you need to prove your identity.
Right, now that we have the introduction let’s spend just a few moments considering some of the ideas involved in this whole cryptography world.
Confidentiality
If you have a message to send to someone and you want to keep it secret then you are going to need to do something with that message. Essentially there are three things that you can do with the data at this stage
· Obfuscate the message
OK, this is a geek’s way of saying that you want to make something difficult to read. Programmers will obfuscate code, we will obfuscate passwords – if you look into your ConfigMgr client’s computer policy then you will see that the Network Access Account username is human-readable. The password isn’t.
· Hide the message
You might want to place the message in some form of container which carries the message, while making it look innocuous. Imagine, for example, that I decided to take up photography as a hobby and uploaded several hundred photos to my Facebook profile. Now, imagine if for each of the pixels I changed the colour definition by just one bit. Will you notice? Probably not! If I now use that one bit as a carrier for each bit of my message then even in a simple RGB colour scheme I have 3 bits to play with for each pixel in my image. Suddenly I have a lot of information embedded within the source image. This process is called Steganography.
These two are somewhat outside the scope of where we are going so if anything were on a tangent within a tangent. They do show however that we can do things to data which are not . . .
· Encryption
So now we are looking not at hiding our message but changing it in such a way as it becomes unreadable for a casual observer but can easily be read by the legitimate receiver of the message. A lot has been said about the merits or otherwise on the different methods of encryption. Specifically; which is the BEST, but I want to introduce the opposite idea – is it GOOD ENOUGH? If I want to send you a message that says “Let’s meet at 8” and it takes an attacker 13 hours to decrypt the message then it’s safe to say that the encryption was GOOD ENOUGH.
Now we have a new element in our communication – the possible ATTACKER. What do we know about the attacker? Well, the answer is, not a whole lot! We don’t even know whether they exist, so we make some assumptions about them:
o They exist, but we don’t know how many of them there are. We don’t know whether they are co-ordinated or not.
o They have lots of time, but we don’t know how much
o They have lots of computer time, but again we don’t know how much
o They are clever. In fact they may even be cleverer than us.
Given this ethereal attacker then perhaps we should err on the side of caution. The 13 hours to decrypt our “Let’s meet at 8” message was a pure guess, so let’s guess caution and choose some form of encryption that will protect for, say 13 years instead. That should do it.
To encrypt something therefore, we need to have three things
1. An encryption protocol.
We need some method of making our message secure. That’s going to be our encryption protocol. We could for example agree on a protocol:
“We will transpose all characters by x”
That was easy. We also need to give this protocol a name – usually named after the inventor of the protocol; this one is called the Caesar Cypher. This, by the way, is what is known as a symmetric encryption algorithm – the same key is used to decrypt as was used to encrypt the message.
2. A Key
You and I need to agree upon a key – let’s say x=5 and then come up with our transposition. So:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
VWXYZABCDEFGHIJKLMNOPQRSTU
3. A Message
I’ll leave you to work that out for yourself and you know both the protocol and the key
PKBMVYZ OJ XJIADBHBM ORZIOT ORZGQZ
OK, I know this IS supposed to be a System Center related blog, so that’s my excuse. It does, however demonstrate a few things – As an attacker, just looking at the string there are some patterns. You’re assuming that the language is English and therefore there are some patterns which you can make out. Here starts your new career as a cryptographer.
So, how long is it going to be before the attacker (who does not know our key) will crack the code? Not long I guess. So, what can you and I do about that?
· We could have a more complicated protocol or key
That’s a great idea. A more complicated protocol however will add to the length of time that it takes to encrypt or decrypt the message. In computing terms that means CPU cycles.
· We could re-key more often
Another great idea, as a general principle a simple encryption algorithm can be secure as long as the key changes often or a more complicated operation needs to have a shorter key in order to remain secure.
If we are going to re-key often, how are we going to do this? In the case of our simple example, is there a point in re-keying by encrypting the new key with the old key (in band)? Probably not!
If in-band re-keying is not a good plan then how about out of band? Well, this is either going to involve you and I meeting up on such a regular basis that we might as well just exchange our messages at that time or you and I having some form of book of codes stretching into the future (a code book) where we can just cycle through the codes. Both of these present some severe logistical problems.
With that bombshell, we’ll close off this blog post, but the story continues in PKI – Let’s make it public
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