This is the 4th part on my CISSP Reloaded where I am revisiting the 10 CISSP domains I studied for many years ago to see what has changed and how much of it I have retained as well as adding in my own personal thoughts, experiences and rambles into the mix. Read domain 1, intro and risk management http://www.j4vv4d.com/?p=433 , domain 2, access controls at http://www.j4vv4d.com/?p=438 and domain 3, Telecomms and network security at http://www.j4vv4d.com/?p=454
Cryptography, the dark art of information security. The deus-ex-machina, the silver bullet, the be all and end all of all security measures. Widely misunderstood, often poorly implemented.
My first introduction to cryptography was when I was told of this man called Phillip Zimmerman who’d created a piece of software called Pretty Good Privacy or PGP. A bit of sorcery that could protect emails so well, that even the prying eyes of Big Brother could not get at it easily. It was so profound, that the U.S. Government initiated an investigation against Zimmerman. This was on the premise that strong cryptography was classed as munitions so it was in the same classification as real life weapons.
How amazing could that be? This software called cryptography, according to the U.S. Government could be as potent as an AK47? I had to find out more.
But this was a pre-Google era whilst I was still a student and long before I’d known that I’d end up with a career in information security. I relied on Alta-Vista, infoseek and Ask that was still called AskJeeves and dig out useful information on what this cryptography thing was all about. In between all the distractions such as websites that played awfully rendered music when you visited them, the 56k modem periodically disconnecting from the phone line and very creative ASCII art I found little information that I could make sense of. There were all sorts of mathematical formulas that looked so horrendously complicated, they were like algebra to the power of 3.
This was what a digital hand grenade looked like? A bunch of maths and who know’s how many geek-hours worth of coding?
I was disappointed as a teenager who goes to a concert to hear their favourite band play only to find they sound absolutely awful when playing live.
So I closed that chapter in my life and moved on. Cryptography would be another one of those things that I could never understand.
Or was it?
We know the story goes: <title sequence> Boy meets recruiting manager. Recruiting manager offers job in information security. Happy years of employment ensue. Boy does CISSP <dramatic music> and learns more about cryptography. Boy actually understands how cryptography works (to a degree)<triumphant and uplifting music>. Boy now a man. <end credits>
What is cryptography?
Cryptography is a relatively simple concept to understand. It’s the ‘how’ that can get slightly complex.
In essence, it’s taking some information and scrambling it up so no-one else knows what it is. Then having a way to unscramble it back to the original information again.
And really that’s all there is to it. Just like how when you were a child you were told that’s all there is to a Rubik cube and wasted many frustrated hours failing to get it right before resorting to peeling off the stickers and sticking them on wherever you darn well felt.
Everything else surrounding cryptography is about finding ways to make sure the scrambling of information is done in a quick and efficient manner that nobody else in the entire universe can unscramble unless they possess the McGuffin.
Think of it like a Witch who can cast a spell on a Prince and turn him into a frog. If she waves her wand and says “hocus pocus” the Prince turns into the frog and becomes completely unrecognisable. No-one would ever know that the frog was actually a Prince unless they had the Witches wand and waved it over the frog saying “hocus pocus”.
Bear this example in mind as I’ll be using this little bit of hocus pocus to carry on my explanations because it’s a lot more simpler than maths!
But before we jump into modern day cryptography that will be relevant to you and your day job, the CISSP course would like to take you on a trip down memory lane on the history of encryption and see how cryptography started out and how it’s evolved from a single-cell organism in a mud pool to a complex self-aware science, that puts rocket science and brain surgery to shame.
History
To be honest, in my opinion, knowing the history of cryptography is very interesting to read about. You can even apply some of the learnings to make games to play with your kids. But probably not much use to a security professional going about their day to day job. I mean, I certainly haven’t been in a scenario where I just had to know how cavemen encrypted their messages!
So, I’ll gloss over this shorthand.
Some say that the Egyptians were the first to employ cryptography with their hieroglyphics. Although, personally, it looks like a bunch of graffiti to me.
Substitution cipher was probably the first real attempt primitive man employed to send secret messages. The way it was implemented was that you took the alphabet and then substituted each letter for another. For example you could substitute each letter for the letter that came after it e.g. A becomes B and B becomes C and so forth. So the word “CISSP” encrypted using a substitution cipher would become “DJTTQ”.
It’s just dawned on me that actually it’s probably not such a waste of time knowing this because men could implement this knowledge amongst themselves to hide the true meaning of messages from their wives. So if one wanted to send a text message to his friend asking if he wanted to go to the cinema, it would read as djofnb and the wife would have no idea where they were planning on going.
The Spartans, when not prancing around in their small pants fighting an army 20 times larger than them had a system where they would wrap a piece of paper around a rod of a particular diameter and write their message. They would then unwrap the paper. The message could then only be read by someone when they wrapped it around a rod of the exact same diameter.
Over time though, the method to encrypt and decrypt information became more and more complex. More tools and techniques were adapted and nearly every military had their own cryptographic formula to exchange information amongst themselves. The most famous example would probably be that of the German Enigma machine which was used during World War 2 to transmit secure information. They must have been a bit disappointed when they learnt that a team of Polish cryptographers were able to crack their encryption method and share it with the British and French militaries (despite Hollywood trying to tell you that it was Bon Jovi and Matthew McConaughey who done this).
Things really changed with the advent of computers. More specifically when mathematics had a love affair with computers and they produced some of the most complex cryptographic techniques (algorithms) known to man, that no scroll of any diameter would be able to break.
By the way, did you know that the word cryptography comes from Greek, kryptos (hidden) and graphein (to write), I bet you just felt your life was completed with that piece of information.
Symmetric key cryptography
Symmetric key is something that is conceptually familiar as it is a simple flow. One key is used to transform the information from plaintext to ciphertext. Ciphertext is just the fancy way of saying that the plain or clear text has been converted into a format that makes no sense or doesn’t resemble the original text.
The same key is then used to reverse the process and convert the ciphertext into plaintext.
If we revisit the example of the Witch turning the Prince into the frog, the Prince is plaintext and the frog is ciphertext. The key that the Witch uses to convert the Prince into the frog and from a frog back into the Prince is the same, i.e. wave a wand and say ‘hocus pocus’.
Because the process is the same for both sides, one could say it’s symmetric. Hence the highly original definition of symmetric key cryptography.
Now may be a good time to touch upon the different types of encryption algorithms. First lets look at what an algorithm is. In most books, you’ll probably fry your brain trying to understand the mathematical methods that are employed. But it’s enough to understand that an algorithm is like a mathematical formula that gives the steps to convert the plaintext into ciphertext.
There are many different ways of doing this. For example, lets say your plaintext is the number 5 and the ciphertext is the number 10. Different algorithms will make this calculation in different ways. A simple algorithm may just say, 5+5=10. Another may break it down to 5+10+5-10=10 or an even more complex one may follow the calculation of (5+1+2)x3-14=10 On top of it some may include square roots and something to the power of something etc. But you understand that some methods will be more complex than others and speaking generally the more complex the method is, the more secure it will be
So you have different encryption algorithms which work in different ways in the attempt to achieve the same result, i.e. encrypt the data using a mathematical computation so complex that it becomes very difficult for someone to crack. Note that I avoided using the word impossible. Because let’s face it, nothing is impossible to break. Given enough time and computational power, you could crack any code.
You have symmetric encryption algorithms such as DES, Triple DES, AES and others. I recall studying this for my CISSP and suffering internal injuries trying to understand the formulas and mathematics behind these algorithms.
I don’t know if these are questions that come up in the CISSP exam, but my personal view is that unless you need to know how the maths behind the algorithms work, or you’re one of those geniuses who grew up writing mathematical fomulas on their windows with markers, don’t bother yourself trying to understand them.
The best way to look at algorithms are like cars. You buy a car of a known brand and make such as a Volvo and you will be able to look up that it has got a 5 star safety rating. This means, some very clever people in white jackets, goggles and clipboards examined all the safety features of the Volvo. They crashed the car into walls, drove it sideways, flipped them over and checked the state of their crash test dummies inside. After all of their rigorous testing they give the verdict that the car is safe.
Algorithms are no different. Well at least the ones that are reviewed by industry experts whose job it is to see how effective any form of encryption is. As computing power increases and it becomes easier to crack certain algorithms, or if weaknesses are discovered in existing algorithms, new, more complex algorithms are introduced. Just as if you looked at a car 30 years ago, it would have had little of the safety features found in modern-day cars. But for it’s time, it was deemed suitable.
So whereas Triple DES was considered one of the cool kids in it’s leather jacket and dark glasses, it’s now considered an old man who’s best kept away from schools and AES is more in favour with the cool kids. Tomorrow, father age with catch up with AES and retire it whilst another algorithm will takes it’s place. Life as an algorithm is tough, they really only do have 15 minutes of fame before they are relegated to insignificance.
But the important thing to bear in mind is that these algorithms go through industry review, people spend time and effort testing them for vulnerabilities and cracking them. They withstand a whole lot of torture before cracking. Which is why you should never trust a company that tells you that they’ve “developed their own encryption algorithm”. 9 times out of 10, they haven’t even got real encryption, it’s more a case of a program that’s simply encoded the data. Which is about the same as using a substitution cipher. But more importantly, it hasn’t been subjected to any analysis by industry experts. These private and in-house developed algorithms are like those awful auditions you see on programs such as X-Factor, <country’s> got talent, Pop Idol etc. They get up on stage because their best friend told them they can sing or dance and they make you cringe and feel embarrassed on their behalf. That’s what these algorithms are like most of the time, embarrassing and cringeworthy. Although you may find a diamond in the rough every now and then, but it’s a risk.
Asymmetric (public) Key Cryptography
Asymmetric or public key cryptography isn’t as difficult in concept to understand as most books, including the CISSP textbooks I used made it out to be.
In asymmetric key cryptography, you use a key (like in symmetric key) to encrypt some plaintext into ciphertext.
And again very much like symmetric encryption, you use a key to decrypt the cipher text back into plaintext.
The importance difference is that one key encrypts the data and a different key decrypts the data.
This sometimes confused people and I think this is because we’re so used to physical keys it’s difficult to rationalise how one key can only lock a door and not unlock it and vice versa. So, I’ll use a different analogy.
Remember I mentioned the Witch who waves her wand and says hocus pocus for the Prince to turn into a frog.
Now imagine, she didn’t have the ability to turn the frog back into the Prince. The wand only casts spells but can’t break the spells.
No, in order to break the spell, a certain Princess (only one of them) has to kiss the frog and it turns back into a Prince.
One key (the wand) was used to turn the Prince into the frog and another key (the kiss) was used to turn the frog back into the Prince.
This is how a key pair work in asymmetric encryption. One key encrypts and one key decrypts. Both the keys have a weird relationship to each other. It’s like they’re unidentical twins. They share the same parents but are totally different, yet connected to one another. Thats about as far as the mathematics of the key pair go. By all means, if you have an interest in understanding the mathematical way the key pairs are created, there are plenty of books that will explain it in great detail till your brain bleeds.
Now expanding on this example let’s say the princess is the one who created the magic wand and she went and put it in the market square. Anyone who wanted to send her a Prince could take the wand, say hocus pocus at a Prince and it would turn the frog, get delivered to the Princess and she could kiss the frog and turn it back into the Prince.
Bear with me… this is important.
Firstly, why would a Prince need to be changed to a frog to get to the Princess? Let’s assume that the guards didn’t let anyone into the palace, so a frog could easily get inside.
Secondly, because the wand was created by the Princess, only HER kiss would be able to change the frog back into the Prince so no other Princess would be able to claim the Prince as her own.
Are we following this?
We’ve established that there are two keys. One is the Wand which is placed in the market place (public key) where anyone can pick it up and use it to turn a Prince (plaintext) into the frog (ciphertext).
This frog (ciphertext) can then waltz into the palace and to the Princess undetected by the guards (unreadable by anyone else). If anyone does try to kiss the frog, it will remain a frog.
Only the Princess, using her own kiss (private key) can turn the frog (cipher text) back into a prince (plaintext).
If you’re a girl, or have daughters, this example will probably ruin all those stories for you forever.
At a simple level then we have described how asymmetric key encryption works. You have a key pair, one part is public and one part is private. if someone wants to send a secret message, they will use the recipients public key to encrypt the data and send it to them. That way they are assured that only the true recipient will be able to decrypt the data because only they have the private key needed to do so.
So if someone encrypts data using the public key, they can be sure that only the owner of the private key can decrypt it.
On the reverse side, if someone encrypts data with their private key and sends it out, then anyone can decrypt it using the senders public key. However, what it does guarantee is that the message indeed originated from the person owning that private key.
Just like symmetric encryption, you have specific algorithms for asymmetric key cryptography such as RSA, Diffie-Hellman, El Gamal, DSA etc.
Hash Functions
An important function within many aspects of cryptography is the hash function. The has function is one-way process. Data is passed through it and it produces a much smaller output called a hash value, or hash sum, checksums, or hash brownies. OK you don’t call them hash brownies, but you get the idea, a hash by any other name is still a hash.
Think of the hash value as your fingerprint. If your fingerprints are on a glass, then it leaves little doubt that you were holding that particular glass. Your fingerprint is unique to you and only you. If someone only had your fingerprint, they would not be able to draw any other conclusions, e.g. they can’t tell if you’re male or female, your age or hair colour etc. It only works one way.
This is what a hash does. Or a what a good has should do. There are various different hashing algorithms such as MD5 or the SHA family. Just like encryption algorithms, some are stronger and others have had flaws discovered in them over time. So depending on what year this is when you’re reading this, you should be aware of what the latest industry reviewed and accepted as secure hashing algorithms are.
Now that you’re an expert in understanding what hash functions are, we can look at what role they play in cryptography.
Continuing with the fingerprint analogy, lets say a criminal is transferred from one prison to another. Before the prisoner is transferred, his fingerprints are taken and those are emailed to the receiving prison. When the prisoner reaches the destination, the receiving prison can take his fingerprint and match it to those which were emailed to them separately by the sending prison. If they match, then they can be sure that this is the right prisoner and there hasn’t been an elaborate switch conducted en-route.
However, if the fingerprints don’t match then, there is a bit of a problem.
This is one of the primary functions of a hash, its a quick to reproduce a hash and compare it’s value to ensure the integrity of the item it’s validating. Which is why when you go to a website and download a package, they sometimes have the MD5 hash displayed. The purpose of that is so that when you download the file you can check the hash of the downloaded file and compare it against what it should be. If the values match you’re ok, otherwise it could be you’ve downloaded an altered file which could contain some malware. In which case it would be best to reinstall your operating system. I’m not serious about reinstalling your operating system, as long as you haven’t executed the file you should be generally ok. Well most of the time. But who knows? Which is why it’s a good idea to run a network sniffer like wireshark every now and then to see what network traffic is coming and going from your machine. You may be surprised by the results.
For the smarty pants out there, you’ve probably noticed one flaw with using hashes to validate the integrity of a sent file. If I were a bad guy and could intercept the file and change or replace it before it got to you. Then I could just as easily change or replace the hash so that everything looked ok.
Which is why before the hash is sent, it is encrypted with the private key of the sender. That way the receiver can decrypt it using the senders public key and be assured that it was indeed sent by the right person. A hash encrypted with a private key is usually referred to as a digital signature.
So to break it down we have 3 core components,
A public key
A private key
A digital signature
If you send an email to me using my public key, then that protects the confidentiality of the message because only I will be able to open it.
If you send an email to me using your private key, then I can be sure it came from you and only you. But anyone who can access your public key (everyone) will be able to read it.
A digital signature provides assurance that the message has not been altered in any way from the time it left you till I received it, i.e. it assures integrity.
Public Key Infrastructure
If we go back to our Princess and frog example, if you recall, the Princess leaves her Public key (magic wand) in the market place so that anyone who wanted to send her a prince in the form of a frog can do so.
However, what’s to stop anyone else putting their own wand in the marketplace and claiming it to be from the princess.
OK talking about a princess and her wand maybe isn’t such a good example.
What I’m trying to say is that if you share your public key, how does anyone know that it’s your public key? How does that public key get stored or distributed or used or even revoked?
To address these questions we found a crack commando unit who were sent to prison for a crime they didn’t commit. This came to be known as Public Key Infrastructure or PKI.
PKI is more like a setup whereby public keys are all handled by a Certificate Authority. This Certificate Authority issues and verifies the digital certificates which are used to guarantee that a public key is valid.
Imagine you’re introduced to someone called Bob. How do you know this person actually is Bob? If his friend told you that he is Bob, you may believe him, but you have no idea who his friend actually is. But if one of your friends told you that he is Bob, you would believe them because you trust them. A certificate authority is similar. I wouldn’t go as far as saying it’s your friend, but it’s a trusted body that your web browser likes and gets along with. If your browser sees a certificate that the CA hasn’t verified, it throws up one of those popups on your screen asking you if you’re sure you want to continue because the identity cannot be verified. Of course everyone ignores this and clicks OK anyway.
But is it really that simple? Recently, there have been a couple of cases where it’s come to light that Certificate Authorities have been compromised and that rogue certificates are out there. It’s a bit like forged currency, anyone with a forged certificate could claim their website is your bank’s website and there’s not much you can do about it. So it’s interesting to see how this develops over time. It kind of breaks the ‘web of trust’ model and as it spreads, so will paranoia. It’s like a bad teen horror movie where people start getting killed one by one in a remote location and people start to distrust each other and even turn on each other until the virginal heroine is the only survivor with her dog. Because we all know Hollywood never kills dogs. Unless it’s the dog in “I am Legend” with Will Smith. That was sad.
Key Management
Keys are a bit like the ring from Lord of the Rings and you are Frodo. OK maybe you’re not a short hobbit, but taking a ring from the Shire to be destroyed in the face of certain death can sometimes be an easier experience than having to manage keys.
The responsibility level is the same. It’s the key which can lock or unlock your data, and with that the secrets of the universe.
Key management is an issue that crops up in both symmetric and asymmetric cryptography. The key is the, well it’s the key. So all the security revolves around keeping your key safe.
Secondly, one key isn’t going to last forever. So you’ll have to come up with some method of tracking when you want a key to expire and generate a new key. This can introduce challenges in larger setups. So you’ll need to have a good understanding of the processes that rely on the keys and determine the best way to do the switchover. Think of it like tyres on your car. They will eventually need replacing and you sure won’t try replacing a tyre whilst you’re driving along the road, unless of course you’re Keanu Reeves on a bus which will blow up if the speed drops below 50mph.
So you need to establish a process to make the change. Just like some people have a driveway and the tools to change a tyre themselves, others will need to take it to a garage.
Another thing to bear in mind is to document a key revocation process. i.e. what do you do to your key if it gets compromised? You need a way to be able to cancel it so that it isn’t usable and the thief is foiled.
Simple enough? But I’ll just throw in one last monkey-wrench into the picture. Imagine your company processes high volumes of data that is encrypted on a daily basis, lets say its payment transactions. You encrypt it diligently before storing it on the server. Now imagine your encryption key gets compromised, so you revoke it. What happens to the backed up data that is sitting on the server that is protected by a key which is now revoked?
Getting key management designed correct from an early stage is probably the most valuable piece of input you can provide a project. Work out how the key will be stored, used, destroyed, retired, generated, or used. Everything else is more or less automated by software and doesn’t need a whole deal of hand-holding.
Attacking cryptography
Like any other security process or technology, there are some attacks that can be carried out against cryptography. Granted, if you’ve implemented cryptography in the right manner using a suitably strong algorithm, it becomes a harder channel to exploit so people after your information will probably revert to a social engineering attack.
However, that being said, one of the most common ways to attack encryption is to take several copies of ciphertext that have been encrypted using the same algorithm and compare them to try and work out the key. Commonly known as a Cipher-only attack as you only have the cipher to work with.
Other attacks such as known plaintext attacks work work more or less on the same principals. In some cases the attacker has a bit of plaintext to work with, in others they can generate the plaintext that is used so they can use it for comparison. All of these work on having some data and comparing them in the hope of finding out the information.
There are a bunch of other attacks. A good example of a common attack in web applications are replay attacks. This is where someone sniffs the network for an encrypted piece of information, captures it, and then sends the same ciphertext to the application in the hope that the application will assume that you are the same person and give you a meaningful response. Some of this spills into session management but you get the drift hopefully.
Business usage of Encryption
One thing that isn’t in my notes but I feel is important to cover is what the business expect of encryption and how it is best deployed.
A lot of people will rely on the assumption that encryption is the ultimate form of protection and won’t consider the various complexities that come with encryption such as choosing the right type of encryption, having a robust key management process in place or even the right deployment.
Which reminds me, that certain countries have import / export laws around what type of encryption can or can’t be used as Mr Zimmerman found when PGP was distributed internationally. So it’s an important consideration if you work for a global organisation. That’s not taking into account local data privacy laws and regulations which are another interesting challenge altogether.
If you’re involved in forensics, encryption throws up a lot of nice challenges. Especially if you have to move the hard-drive that you wish to examine back to your lab for detailed analysis. Who knows what information is on the hard drive, who knows what encryption has been used. So if your lab is across a state or National border, you’re better off hiring Jason Statham to Transport it for you.
Also consider, why is your organisation deploying encryption in the first place? What are they trying to protect and from whom? Let’s think of a piece of data that is transferred to an external 3rd party. Internally we don’t encrypt it because it’s on the internal network and hence protected <insert sarcastic laugh> you remember the part in telecoms and network security where we looked at the M&M model.
But that aside, we think if we want to transfer the data to a 3rd party, we need to encrypt it. Because clearly, the internet is a bad place and hence needs protection.
Now you’re left with two options. Do you simply encrypt the transport layer, i.e. the tunnel across the internet so that the data is protected from the time it leaves our servers and hits the 3rd party’s server? This is the common choice as it’s comparatively easier to implement.
But what if the data we’re sending is more sensitive than that. What if the contract with the 3rd party states that only authorised personnel within their company are allowed to view the data. Well by only encrypting the transport layer, you’ve got no assurance that will happen, because on the other side when the data lands on their internal server it will be unencrypted and will remain so wherever it travels in their organisation, free to be seen by whoever has access.
So the second option is to encrypt the data layer, where you encrypt the data itself and send it across. Then you know that the encrypted data will only be decrypted once it reaches the correct destination and only decrypted by the right person. But this is a more resource intensive process to implement.
I guess if you’re paranoid enough there is a 3rd option which is to encrypt both the data layer and the transport layer. But then you’re dealing with maintaining two sets of encryption keys and processes which then has a lot of businesses asking the question as to what their return on investment will be for all this cryptography!
Return on investment or ROI is one of those terms you will hear a lot of as a security professional. It will give you a nervous tick. Just mention ROI to a senior security leader in your organisation and see them get that 1000 yard gaze in their eyes. Go ahead, try it.
Javvad Malik 