Wednesday, 17 July 2019

Security Protocols & Authentication

Well, it seems that this word protocol has once again raised its ugly head. Well, that may be a bit too harsh to refer to protocol as having an ugly head, but the thing is that this seems to be coming back again and again as we move through these topics. However, in this instance the word security comes before the word protocol, so I guess what we are looking at is that when we access something, such as Facebook, we can prove to Facebook that we are who say we are, and just as importantly, Facebook can prove to us that it is who it says it is.

As we go through this we may realise that these protocols occur when we log into a website. For instance, when we log into Google, we enter our user name, it sends the user name to the server, and then requests our password. Others might simply request both our username and password at the same time. However, a lot of this also goes on behind the scenes when we first access the site. Sometimes it seems as if it is taking quite a long time for the site to load, however it isn't just the site loading, but the security protocols going back and forth. For instance your browser might be confirming that the site that you are trying to access is who it says it is. In fact, occasionally the browser might even refuse access due to a problem with the digital certificate - that is a security protocol at work.

So, we have two concepts here - Authentication and Authorisation. Basically authentication comes down to you proving who you say you are, and authorisation comes after authentication, and that namely comes down to determining what you are allowed to do. For instance are you a guest, a vendor, or even a systems operator. In many cases sites will take a layered approach, namely if one layer fails to prevent an attack, then another layer is there to attempt to foil the said attack. However, intrusion detection is something that we will cover in the next post. Yet, this image probably says a lot:


Authentication can be based on something that you know, such as a password, something you have, such as a key card, or even something that you are, such as your fingerprint, or even your retina pattern. The thing is that each of these have benefits and flaws. For instance, passwords have the strength in that they can be changed if they are compromised, or forgotten, however they are actually one of the weakest forms of protocol.

The thing is, many people are really, really bad when it comes to passwords. If the only symbols used in passwords are letters, and the password is 8 characters long, then that is 268, or 208,827,064,576 possible combinations. Say we use a mix of upper and lower case letters, then that is doubled to 5.35×10¹³ possible combinations. Throw in numbers, and then you get 1.92×10¹⁴ possible combinations. However, if you have a brute force attack which basically tries every single combination of the password, and it is able to attempt 100 passwords a second, then it will take 60 thousand years to crack that password.

Well, that seems like it will take a pretty long time to be able to go through all those different combinations of passwords, except that things aren't as simple as that. Say, for instance, we have a password file which contains 210 passwords, and the attacker has a dictionary that contains 220 passwords, then there is a 1 in 4 chance that one of the passwords will be in the dictionary. This is the problem with passwords, because people aren't always smart when it comes to selecting a password. A brute force attack might take quite a long time, but if the head on your IT department is lazy, and has simply used 'password' for his (or her) password, then that is going to be cracked pretty quickly (and you can be assured that that is probably the first password that any attacker is going to try).

The other form of attack is a social engineering attack - for instance, how visible is your Facebook profile, and how much information is on your Facebook profile. Do you get a bazillion birthday wishes from friends everytime it is your birthday, and you are almost forced to respond with the standard 'thankyou for your birthday wishes, I had a wonderful day?". Hah, it looks as if a potential attacker has got a key part of your identity. Are you friend's with your Mum, Dad, brother, sister? Well, there is another one. How about all those pictures of your dog, or cat, and those pictures where you are cuddling your partner, and both of you have been tagged in the photo. Well, it seems as if a potential attacker probably has everything they need. Oh, I also forgot, you might even have your place of birth listed, or even have photos of your primary school. There you go - that is enough information that an attacker needs to be able to engineer a way into your accounts.

Well, we can also have what are known as items that we need, such as your Visa Card. Sure, you need to be in possession of that card to access your account, but the thing is banks these days are making it easier to access your account without it - all you need is a mobile phone. How about that access card for your office. Well, the problem with these is that they can be lost. In fact, I suspect people still do not treat mobile phones as the serious security risks that they actually are. Does a random person come up to you, give you a sob story and asks if they can use your phone to make a call? Will you let them use it. Me, I'd point them to the nearest phone box, and maybe give them 50c to make the call.

So, the final thing we have is biometric protocols, that is something physical about who you are. The most common one happens to be finger prints. Okay, there are a lot of others as well, such as facial recognition, retina scanning, or even hand prints, but let us have a look at how fingerprinting works:


A lot of these systems work similarly. Basically an image is taken of the fingerprint, it is then enhanced, and certain parts of the finger print are then recorded. Once this is done, the sections are then stored on file. So, when you then place your fingerprint on the scanner, it will match your fingerprint with that which is stored on file. The problem is that finger prints aren't necessarily all that different, and can change, especially if you suffer an injury. This is the same with facial recognition because your face in one sense changes as you grow older, but in other cases it stays the same, or at least the bone structure, which is what is recorded, stays the same. As for the iris, well that is incredibly chaotic, no two are the same, and they do not change throughout a lifetime. Well, apparently it is possible to fake an iris, but that seems to be in the realm of science fiction.

Protocols on the Computer

Well, we all have protocols, such as asking a question in class - we raise our hand and wait for the teacher to point to us. There are networking protocols, such as FTP and HTTP, as well security protocols such as SSL, IPSec, and Kerebos. However there are flaws, and some of these flaws can be particularly subtle. For instance, there may be implementation flaws, or simply flaws in the actual way the protocol works. However, a security protocol needs to be efficient, robust, easy to use and flexible. For instance, it needs to require minimal computational requirement and use minimal bandwidth, yet needs to be able to resist an attacker, or still work when the environment changes. Basically, trying to balance these factors out is the key.

So, we have Moss, who is attempting to access the Benhom industries server, and there are a number of ways that the protocol can operate. Now, Moss needs to prove to Benhom that he is Moss, but since Moss isn't stupid, he should also require Benhom to prove to him that it is actually Benhom. In order to do this a session key needs to be established. However, there are other keys as well, such as public/private keys, hash functions, and symmetric keys. Yet sometimes there is also a requirement for anonymity and plausible deniability, such as when you, well, want to visit that website.


Now, authentication on a stand alone computer is relatively simple, namely you just need a password. However, authentication over a network does get somewhat more complicated. Sure, attacks on authentication software, such as keyboard logging, are an issue with standalone computers, but honestly, the only way somebody is going to be able to access your desktop is to break into your house (though laptops are a completely different story). With a network this is vastly different since attackers can passively listen, and also use what are known as replay attacks.

So, we have the following simple protocol:


This is okay for your laptop, or your desktop, but not so much for accessing a site like Facebook. For instance, Bob needs to know Alice's password, and Trudy (who is the attacker) could be sitting there passively listening to what is going on. For instance, Alice has a keyboard logger on her computer, so when Alice enters her password, Trudy captures it, and can then use her password to access Bob.

Well, this can be prevented by having Alice enter her username and password as soon as she requests access. Yeah, that might work, except remember, Alice has a keylogger on her computer, so Trudy is basically listening into what is going on, and can then use Alice's details to access her account.

You could Hash Alice's password, so that neither Trudy, nor Bob, actually know the password, except the problem is that it is still subject to a replay attack. Further, If Alice has a key logger on her computer, then Trudy can easily hash the password, or she can simply send the hashed password directly to Bob to allow access. So, there is a problem.

So, what we have is the challenge-response scenario. Basically when Alice requests access, Bob replies with what is known as a Nounce, or number used only once. So, when Alice replies with her password, the password is hashed, with the nounce. This will actually defeat the replay attack since the hash will pretty much change every time that Alice requests access. However, there is still the problem with the keyboard logger, namely because if Trudy knows Alice's password, then it doesn't matter what the nounce is, Trudy can always gain access (unless Alice removes the keyboard logger and changes the password). The other thing is that Bob must know Alice's password to be able to reply.

However, there is a better way than a hashed password, and that works with encryption. The thing with a hashed password is that if Trudy intercepts the password, then she can use the hash to gain access to Bob on behalf of Alice. What needs to be done is that the password is hashed once it reaches Bob so that Trudy does not actually know what the hash is. This is done through generating a key, whether symmetric or asymmetric. Basically the password is encrypted, and then sent to Bob, who then decrypts the password and then hashes it.

Yet there is still a problem. Sure, Bob is able to Authenticate Alice, but what if Alice wants to authenticate Bob. Surely Alice needs to know that she is actually sending her password to where she actually wants to send it as opposed to some imposter that has basically copied the bank's homepage and created a replica?

So, we have here Alice requesting a reply from Bob, Bob replying with an encrypted reply, and a key, and then Alice responding. Well, that seems to work, but the thing is that Bob isn't actually authenticating Alice. Sure, Alice knows that Bob is Bob, but the problem is that Bob doesn't know whether Alice is who she says she is - she could be Trudy.

While we have a secure one way authentication protocol, we don't have them authenticating each other. So, could the solution be to have a two way authentication protocol where both parties are authenticating each other?


So, Alice requests authentication from Bob. Bob responds with an encrypted authentication reply, with a key, and a request for authentication from Alice. Alice then sends the authenticated reply back to Bob. Well, that looks like it could work, except there is one major flaw - Trudy could open two sessions.

Basically, Trudy sends an authentication request and receives the encrypted reply, with Bob's authentication request. Now, remember, these keys are symmetric, meaning that they are the same on both sides. Now, Trudy has Bob's authentication request, so in a second session, Trudy sends the same request to Bob, who responds with an encrypted reply. Suddenly, Trudy now has the encrypted reply (she doesn't know the key), and she can then send it back to Bob, and thus gain access.


So, while our one way authentication may be secure, it isn't secure when we are using it for mutual authentication. This is the problem with protocols - they can be incredibly subtle, and while they may work in one scenario, they won't necessarily work in another. The other thing is that attackers are very, very resourceful. In fact they may even have the resources of entire governments behind them, so we need to be wary. Another problem is when environments change - what may work on a desktop in an office does not necessarily work when you are logging onto the office network from a remote location.

However, what about this:


Well, we have now included the identity within the nounce. So, Bob replies with his identity, and Alice responds with hers. This seems like it will defeat the above attack, since Trudy should not be able to replicate Alice's identity.

Another way is to use the public/private key encryption. Basically everybody knows Alice's public key, but only Alice knows her private key. We can also use digital signatures as well. That this for example (where M is the passphrase):

[{M}Alice]Alice

here, Alice encrypts the password {} and the signs it. Or:

{[M]Alice}Alice

Here, instead, Alice signs the password, and then encrypts it.

While this looks okay, once again we are back to the problem of mutual authentication. Basically, Bob is authenticating Alice, but not vice versa. In this situation Trudy can basically get Alice to decrypt anything.

In this situation, Trudy has previously intercepted a message signed with Alice's public key. As such, she can then use the public key to get Alice to decrypt something and then send it back to her. This is another flaw with the public/private key algorithm - you should never use the same public/private key pairs for both encryption and signing.

The same is the case where Bob requests Alice to sign something, Trudy can basically get Alice to sign anything. What we want is mutual authentication - if Alice is unable to authenticate Bob, then the problem arises that Trudy could impersonate Bob and then get Alice to basically provide anything that she wants off of Alice.

One way to do this is to use a session key, namely a symmetric key that is only active for that particular session. Basically there is authentication, and once that authentication is complete, then a session key is shared. Without the session key, Trudy does not have access.

Well, this looks secure, where Alice sends a Nounce to Bob, Bob replies with an encrypted key using Alice's public key, and Alice responds with a with Bob's public key. Yet there is a problem - Alice's nounce R does nothing to authenticate Bob. Sure, Alice is using Bob's public key, but there is no response from Bob - the nounce is in fact useless.

Well, Bob could instead respond by signing the reply, expect there is a further problem - the signature does not actually encrypt the session key, so it is exposed for an attacker to be able to see it. So, let us try this:

Well, it looks like we have solved it here, except that this is subject to a Man in the Middle attack:


In this situation, Trudy can get [R,K] from Bob, while Alice believes that she is actually communicating with Bob. However, what if instead on signing and encrypting, we encrypt and sign? Such as this

[{R,K}Bob]Alice

Well, the problem here is that anybody can see {R,K}Bob so unfortunately that isn't going to work all that well.

We can solve that by using a time stamp, which also works as a nounce. They can prevent replay attacks, and reduce the number of messages being sent back and forth. However, the problem arises in that not all times are synchronised. Thus we need to take into account what is called 'clock skew' yet by taking that into account we can suddenly open ourselves up to replay attacks.

As mentioned, they can be subtle, for instance signing and encrypting with a nounce is insecure, but encrypting and signing with a nounce is secure. However, if we use a time stamp, suddenly the opposite becomes true - protocols can be very subtle, and it really does depend on what we are using.

What we need is perfect forward security, namely a situation where if a message is intercepted, it cannot be used later - basically the attacker needs to act within a certain time, or else the information is useless. In many cases it really depends on the situation - access to an office desktop is going to require different protocols than, say, accessing Facebook. Also, the complexity really needs to depend on the type of data that is being stored - access to your bank is probably going to require different protocols than, say, access to a news site, or Netflix. It really does depend on the situation.


Creative Commons License

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. This license only applies to the text and any image that is within the public domain. Any images or videos that are the subject of copyright are not covered by this license. Use of these images are for illustrative purposes only are are not intended to assert ownership. If you wish to use this work commercially please feel free to contact me

No comments:

Post a Comment