Creating secure protocols is not an easy task and this article is not intended to help you to create new protocols from the scratch. There already exist many well designed protocols which will give you all the necessary features to meet your requirements. There are many books and articles about how different secure protocols work and how they are designed. This article is not trying to describe details of these protocols rather it tries to recommend the “ideal” protocol for you, which of course doesn’t exist. The question that this article will try to answer is how you should choose the right secure protocol for your particular application.

Choosing the right protocol is also not a trivial task however I believe there are patterns which will help you to solve this task for your particular application. I’m able to recognize these patterns and I’m sure you will also be able to do it once you get the proper knowledge and experience.

We will go over the following topics:

• Data confidentiality and integrity in protocols
• Two types of security protocols
• Attacks you should worry about while thinking about protocols
• Protocol Choosing Patterns
• A demonstrative example
• Recommended references

So let’s start.

Data confidentiality and integrity in protocols

Before going deep into different security protocols and their problems let’s understand why they exist and what they are protecting from.

In my last article (How to design secure systems? Key concept in Information Security) I was talking about security properties of information. I expressed an idea in that article that the whole problem that information security area is trying to solve is “how to make sure that security properties of an information block are properly maintained during its lifetime and that there is no way to damage them?”. Security protocols are tools which allow us designing systems where the information can be transferred from point A to point B over insecure/un-trusted networks without loosing its security properties. I have highlighted six properties in that article – confidentiality, integrity, authenticity, accessibility, availability, non-repudiation. Although in particular applications other properties also can be damaged while transferring data over un-trusted networks – in most cases only confidentiality, integrity and authenticity are of the major concern of security architects. In this article we will mostly focus on these three security properties.

Let’s see what mean confidentiality, integrity and authenticity of data when it comes to transferring information. We transfer sensitive (confidential, private, important) data everyday in our life – when browsing over web, when chating over Skype or other messengers, when talking over phone, transferring files to other locations in network or internet, sending and receiving emails, watching HD TV at home, when locating our location with GPS, etc.

When we transfer this information we want to be sure that nobody else can get it except the addressee. We also want to be sure that the addressee will receive the information exactly in the form we sent it to her. And finally, when the addressee receives our information she wants to be able to make sure that information really came from us and nobody else who is claiming to be us. So our first requirement is about confidentiality, the second is about integrity and the third – authenticity.

Two types of security protocols

Although there may be many criteria which can be used to define different categories for security protocols – I have decided to divide them into two types:

• Authentication based
• Zero knowledge

Authentication is a key part in a security protocol. Remember, if you want to maintain confidentiality of data – you need to have an authentication part in your protocol. Otherwise how you would know who you are sending your data to?

However it’s not always possible to have authentication primitives in the systems. This is especially true for embedded systems with restricted capabilities. Sometimes you have to restrict yourself with protocols which don’t require authentication and thus are prone to man in the middle attacks.

Let’s see what kinds of attacks are possible on security protocols.

Attacks you should worry about while thinking about protocols

There are three important attacks you should worry about while designing a security protocol for your system:

• Eavesdropping
  
  • The attacker has access to the communication channel over which your data is going to be transferred
  • The attacker can read everything on this channel

• Replay
  
  • This attack is applicable only to authentication based security protocols
  • When two legitimate users create a secure session – attacker records the authentication part of the protocol.
  • After this the attacker replays recorded messages to one of the users and tries to impersonate as the previous legitimate user.
  • If the protocol doesn’t have means to protect against replay attack – the attack will be successful.

• Man in the Middle
  
  • Any protocol which doesn’t have authentication part is prone to this attack.
  • The main idea is that the attacker is acting as a malware which stays between two legitimate users – A and B.
  • When user A sends a message to user B, the attacker is able to receive this message, change it and send the modified message to user B and vice versa.

If you designed/chose a protocol which is protected against these three attacks – you can be sure that your protocol is good enough. There can be cases when your system will have specific requirements and those three attacks won’t cover all possibilities. I’m afraid these cases must be addressed uniquely. However I can assure you that in most cases protecting against eavesdropping, replay and MitM attacks is enough.

Protocol Choosing Patterns

There are lots of security protocols available in different cryptography books and publications – Challenge-Response, OTP, EKE family (EKE, SPEKE, J-PAKE, Augmented-EKE, etc), Kerberos, SSL, Diffie-Hellman, and more. How should you choose the right protocol for you?

Choosing the right protocol highly depends on your requirements. I will try to describe an algorithm here aimed to help you in making the right decision but you should understand that it’s not always going to solve the exact problem you have. There will always be cases specific to your requirements and for these cases the described algorithm will serve you just as a direction and not as a solution.

Suppose you have two components in your system – C1 and C2. These components are connected via an un-trusted network. Your general requirement is to be able to send data from C1 to C2 (and vice versa) and yet maintain the security properties of the sending data.

1. If (C1 and C2 don’t share a secret)
   1. If (you are not using PKI) then
      1. Implement Diffie-Hellman protocol between them
      2. You will be protected against Replay and Eavesdropping attacks
      3. However, note that you are not protected against Man in the Middle attacks.
   2. Else
   3. If (you want one way authentication – C1 authenticates C2 and C2 doesn’t authenticate C1) then
      1. Implement one way SSL between them. C1 authenticates C2 with certificates (this is how web sites are usually authenticated by the browsers).
      2. You will be protected against Replay, Eavesdropping and Man in the Middle attacks
      3. Note that you need to address the problem of CLR (certificate revocation list) on C1. For embedded devices it’s not always possible.
   4. Else
   5. If (you are able to use PKI) then
      1. Implement SSL between them
      2. You will be protected against Replay, Eavesdropping and Man in the Middle attacks
      3. Note that you need to address the problem of CLR (certificate revocation list). For embedded devices it’s not always possible

1. If (C1 and C2 share a secret) then
   1. If (there is no trusted Root server) then
      1. If (you want one way authentication – C1 authenticates C2 and C2 doesn’t authenticate C1) then
         1. Use Challenge-Response or OTP based protocols
         2. Authentication will be protected against Replay and Eavesdropping attacks
         3. However, note that authentication process is not protected against Man in the Middle attacks.
      2. Else
      3. If (You want mutual authentication between C1 and C2) then
         1. Use SPEKE (or other EKE based strong algorithm)
         2. You will be protected against Replay, Eavesdropping and Man in the Middle attacks
      4. Else
      5. If (You want mutual authentication between C1 and C2 but don’t want to have exponentiation block in your protocol) then
         1. v. Use SSL which is not based on PKI. Instead of encrypting the pre-master secret with a private key, encrypt it with the shared symmetric key and transfer to C2.
         2. This is quite effective.
         3. You will be protected against Replay, Eavesdropping and Man in the Middle attacks
   2. Else
   3. If (there is a trusted Root server) then
      1. i. Use Kerberos
      2. ii. You will be protected against Replay, Eavesdropping and Man in the Middle attacks

A demonstrative example

Let’s assume we have a USB based biometric sensor. After it is attached to a USB port of a PC, user’s biometrics can be scanned and transferred to the PC where it will be processed.

Now, user’s biometric information is used for authentication purpose and it usually opens privacy problems if not protected well… That’s why it is required to protect the confidentiality, integrity and authenticity of biometric data when it is being sent from the sensor to PC.

Biometric sensor usually doesn’t have enough computation power and internal persistent memory and that’s why we are not always free to choose the “ideal” protocol for our system. We will go over several possible cases and discuss how to choose the right protocol.

No shared secret

Biometric sensors are now very popular and there are companies which produce such sensors by dozens million of units per year. It’s not always easy to share a secret between these sensors and PC. One of the problems is “where exactly the shared secret will be stored on PC?”. It’s not very secure to store it on hard disc. So this is a real problem. Another problem is how the secret will be provisioned in the sensor? This may impact the manufacturing process and make it more expensive. That’s why it’s quite practical to assume that there is no secret shared between the sensor and PC.

So what should we do here to protect the confidentiality of biometric data?

Let’s see what happens if we decide to send biometric data without protecting it:

Hopa, the malware can just read the data by installing a USB Kernel driver and eavesdropping the traffic. That’s not good.

Ok, let’s refer to the algorithm described above and see what it suggests. We are not sharing a secret between Biometric Sensor and PC and we are not using PKI – so we fell in 1.a. After implementing Diffie-Hellman only the man in the middle attack will be possible on our system. Note that because we don’t have authentication – we cannot have a better protocol here. So Diffie-Hellman is the best choice.

Shared secret

Let’s assume we designed a system where each sensor possesses a symmetric key and there is a way to securely install this key on PC when we first time attach the sensor to the PC.

The first idea that will come to mind is to encrypt biometric data with the shared secret when the user provides it and send it to PC.

Data confidentiality is protected here – the eavesdropper cannot decrypt data being send. But, hey, what if the malware records the traffic when a legitimate user provides biometrics and replays this traffic next time? The malware will impersonate a legitimate user in this case and gain access to the system without even having the shared secret. That’s bad and that is called a replay attack.

Ok, let’s go further. Usually replay attacks can be protected by using a random challenge in the protocol. If PC sends a random challenge each time before receiving the biometric data and verifies that random challenge exists in the received package – we might be protected against replays.

This is already not bad. First we protect the confidentiality of biometric data by encrypting it and second, we protect authenticity and integrity by verifying the hashed MAC and making sure that it contains the random challenge. In this case we will also be protected against man in the middle attacks as we are doing one way authentication.

Sometimes it’s also required to authenticate the PC in order for the attacker to not be possible to impersonate PC. In this case above mentioned algorithm will direct us to the cases 2.iii or 2.v.

Recommended references

http://en.wikipedia.org/wiki/Man-in-the-middle_attack

http://en.wikipedia.org/wiki/Eavesdropping

http://en.wikipedia.org/wiki/Replay_attack

http://en.wikipedia.org/wiki/Transport_Layer_Security

http://en.wikipedia.org/wiki/SPEKE

http://en.wikipedia.org/wiki/Encrypted_key_exchange

http://en.wikipedia.org/wiki/Kerberos_%28protocol%29

http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

In this article I will overview the following topics:

• Basic ideas behind OTP
• OTP Types
• Vulnerabilities
• Standards and Applications

To make the illustration of OTP more practical we will implement a web server with authentication from scratch by trying to integrate an OTP scheme.

Basic ideas behind OTP

Consider a web server which has a database of users and implements a basic user authentication scheme based on passwords. There are various ways to implement a password based authentication server and key decisions to make while designing it. For example, the following questions need to be addressed:

1. Are we going to keep the copies of passwords on server side?
2. Are we going to have a certificate for server website?
3. What is the authentication protocol we will implement?
4. Are we going to send the hash of password during authentication?
5. …

These questions are interconnected. Answer to one will definitely affect the rest of them.

Let’s consider the simplest scheme:

• The server keeps the hashes of passwords in the database (instead of real copies) and thus doesn’t take unnecessary security responsibility
• Once the server received the password, it calculates the hash of it and verifies with the hash stored in the database
• If the hashes are equal – user is authenticated

Everything looks fine with one exception. Replay attack. An adversary, recording a single authentication session would be able to repeat the steps and get authenticated with the server.

In order to prevent such attack servers usually implement PKI approach. They acquire a certificate from Certification Authorities (such as Verisign) and install it on server. When the user enters this website the browser automatically verifies the certificate of the web server via HTTPS (it’s based on SSL) and creates a one way secure connection. So after this is done the password will be transferred in SSL and will be encrypted with SSL session key. So no replay attack is possible.

This is the simplest and most famous approach for user authentication with web servers. However this approach has several problems which are discussed in my previous article – phishing/pharming attacks, password related problems and man in the browsers attacks…

Imagine that the password never transferred to the server. Imagine a scheme where web server could authenticate the user without receiving any confidential information… Let’s talk little bit about challenge response protocol.

• Both user and server share a shared secret (password)
• During authentication the server sends a random challenge to the user machine
• User’s machine calculates a response with the following formula – CR=HMAC(RC, SS) and sends it back
• After receiving CR, the sever calculates the same thing on server side and compares with CR
• If they are equal – the user is authenticated

If the server is able to generate secure random challenges each time then there is no way to conduct replay, phishing and pharming attacks – because the user never sends a clear password to the server. Instead it sends a one time usable token – based on random number, shared secret and a cryptographically secure hash function. This becomes interesting, right? And note, in ideal case, there is no need to implement PKI based authentication for this scheme (though it would be good to have as other sensitive information is also transferring over wire, such username).

However this scheme doesn’t give much advantage if we are still using passwords. Man in the browser, and social engineering attacks are still possible.

Now suppose that the secret, shared between the user and server, is not a text based password but is a cryptographic key with the length of, say, 128 bit. And suppose that the user possesses a hardware token which is provisioned with this secret and this hardware token is used for authentication purpose.
The hardware has a basic functionality – when it received a random challenge (RC) – it calculates HMAC(RC, SS) and gives back.

So whenever user needs to authenticate with a web server, he puts this device into laptop and authentication succeeds automatically. No replay, phishing, pharming, man in the browser and password related attacks are possible now. Everyone is happy.

This is the basic idea behind OTPs. We have discussed only one type of OTP – challenge response, but as you will see there other types too. However all types share the following concepts:

• User and server share a secret.
• During authentication the OTP device generates a value which is used only one time by the authenticator and which can be calculated on the server too.
• Server calculates it and compares with the one that user provided. If they are equal – authentication succeeds.

OTP Types

As far as I’m aware of there are five types of one-time password schemes:

• Challenge response (the one that we discussed earlier)
  • Note that this can be considered a real OTP only in case if there is a cryptographically secure random number generator installed on server.

• Counter based
• Time based
• Counter + challenge response
• Paper written OTPs

In case of counter based OTPs, beside the secret, OTP device and the server share also a counter. There is usually a trigger on the OTP device. When the user pushes this trigger, device generates a value, something similar to HMAC(counter, shared secret) and sends it to the server. Device increments the counter after the trigger is pushed and data is sent.

As server also shares all data contained in the HMAC it can calculate the same HMAC value and compare with the one that user sent. After authentication succeeds, the server increments the server side counter.

The concept of time based OTP is very similar to counter based one. The difference is that instead of sharing a counter the server and OTP device are calculating the OTP value based on time. In this case the OTP device must have a trusted clock and usually a time circuit is integrated in the hardware which is synchronized with the server time. So when the user pushes the trigger, the following value is calculated – HMAC(current time, shared secret). The server also calculates a vaue with the same formula and compares with the client’s one.

Counter and time based OTPs schemes share a common problem – the synchronization problem. When device’s counter or time gets out of synch with the server’s one there must be a way to synchronize them. These synchronization techniques usually cause lot of troubles to users and IT administrators and thus affect the overall price of installation.

There are also OTP schemes where a counter is combined with a challenge-response protocol. In this case prior to authentication, the server sends a random challenge (nonce) to the client and OTP device generates the OTP value based on the following formula – HMAC(nonce, counter, shared secret). The counter in this scheme makes sure that the OTP value will never repeat and the server nonce provides more security to the scheme.

There are financial institutions (mostly in Europe) which are using paper written OTPs. The concept is that the user receives a number of different OTP tokens (e.g. 100) and uses them one per one during authentication with a website. The server shares the same amount of OTPs and is able to compare them. These OTP tokens can be sent to the user via SMS or email.

Vulnerabilities

Though OTP is able to protect against phishing, pharming, replay, password related attacks however it’s still prone to the man in the middle type of attacks.

The following diagram illustrates the man in the middle attack on a challenge response OTP authentication.

1. A malware is installed in the browser
2. The user enters to a web site
3. Web sites sends a nonce (rand challenge) and requests for a valid response
4. OTP device generates the valid response and sends to the server
5. Malware records this response, generates a fake error message to the user (smth like “some error occurred, please try again”) and continues the session with web server by sending the valid response and getting authenticated.

These types of attacks cannot continuously succeed, especially in case of careful users. Usually users will contact with service providers and report about errors. Although the web site will cancel the OTP device after that but the attack already has been successful conducted.

Standards and Applications

There are several OTP standards and real life applications:

• Counter and challenge-response based OTP
  • HOTP
  • OCRA
  • Yubico
  • Vasco

• Time based OTP
  • TOPT
  • RSA Secure ID

Additional information can be found about these standards and their applications in the following resources:

http://en.wikipedia.org/wiki/One-time_password

http://www.openauthentication.org/specifications

http://www.rsa.com/node.aspx?id=1156

http://www.vasco.com/

http://www.yubico.com/home/index/

The following topics will be covered:

• Conventional user and website authentication model
• Weak points of password based authentication
• Weak points of website authentication
• Alternative ways for user authentication in websites

Note that by the term “conventional” we mean the most popularly used authentication scheme – username/password.

Conventional user authentication model

Conventional authentication scheme for websites and users is based on two steps:

• User’s internet browser authenticates the website with PKI (through SSL)
• Website authenticates the user with username and password

Currently most websites require only username and password for user authentication although it’s obvious that the data they are storing on web servers and their services require much stronger security than the passwords can provide.

Weak points of password based authentication

Passwords are prone to many attacks, such as:

• Weak passwords
  • Although there are many recommendations for constructing more secure pass phrases – these recommendations don’t provide the desired effect as the users usually give higher priority to the factor of remembering the password rather than making it secure

• Social Engineering based attacks
  • Passwords are usually designed around personal characteristics of the user (names, birthdays), their friends or relatives
  • This makes easy to retrieve a password by doing basic social engineering
  • Users tend to write their passwords on a paper and keep it somewhere close to the computer

• Phishing attacks
  • User’s credentials (username and password) can be obtained by conducting phishing attacks. Those will be discussed in details later in this article.

• Pharming attacks
  • The concept is very similar to phishing attack. The following link provides thorough explanation of this type of attack:
    http://en.wikipedia.org/wiki/Pharming

• Malware steals the password
  • Man in the browser malware can easily obtain user’s password after it is submitted to the HTML form
  • Keyloggers can easily obtain user’s password while it is being entered in a password field
  • Man in the middle malwares can easily obtain these passwords (this is true if SSL is not used for website authentication)

It’s also important to mention that passwords provide only “something you know” authentication factor and if this knowledge is stolen – the attacker can have access to any data and operation that the user has access to.

Having all these said it’s obvious that password based authentication cannot remain the primary scheme for websites which keep sensitive information about users or provide valuable services (like financial or privacy related).

Weak points of website authentication

Although PKI based SSL authentication provides a very strong trust, while visiting websites, there is still one issue which remains unresolved for internet users and websites. This is the problem of phishing. The user, who enters a website, doesn’t pay enough attention to the website’s name and thus can be prone to obvious attacks.

The browser developers didn’t yet invent a proper way to notify the user about website identity (identity can be the website name, something else describing it uniquely… can you think a better way to identify a website than the URL?) she is entering to. For example if you see a link with name “pEypal.com” you may probably not notice it, treat it as “paypal.com” ad just trust it. This is actually what phishing attacks are based on.

In my opinion this problem has two major points. The first is in the browser and the second – in website’s identity.

• Browser developers must convince the user to always pay attention to the website’s identity (currently URL) they are visiting to
• Websites (or Web) must invent a new approach for website identity

So the fact is that although website authentication is based on the strongest cryptographic algorithms and protocols – it is still not perfect. Let’s discuss here how phishing attacks work.

• Attacker creates a website with a similar name that the original one (like for paypal.com it would be smth like peypal.com)
• Attacker sends some message (email) to the user from Paypal’s name and asks the user to enter www.peypal.com for more information.
• Peypal.com has a very similar user interface as paypal.com and the user likely won’t notice that this is not the real paypal.com
• The user provides her username and password, peypal.com first stores this info internally and then redirects this information to the original paypal.com
• User is logged in paypal.com and has no doubt that his credentials have been stolen
• Refer to the following resource for more information about these popular attacks:
  http://en.wikipedia.org/wiki/Phishing

Alternative ways of user authentication by websites

In spite of the weaknesses we have mentioned for password based authentication it’s still the most popular authentication scheme used by everyone in the Web – financial institutions, social websites, emails, etc. Of course the reason behind this is not that website developers are not aware of these problems. The problem is that secure alternative approaches require a specialized hardware or software which the users are not willing to buy and install.

The security of user authentication model could be significantly strengthen by integrating specialized hardware such as OTP (One time password) tokens, PKCS#11 tokens, biometric devices (although these still have privacy related problems), corresponding software components. However these hardware tokens cost money and the users, as a rule, are not willing to pay for them – even if it doesn’t cost much. Users also don’t want to download and install software components (applications, browser plugins) for this purpose, because they don’t trust these applications. So how this problem can be solved?

I think the only way to solve it is to use the power that ODMs have. ODMs have a full control of the hardware and software that is being installed by default on laptops or PCs. If they decide to integrate a hardware token (and accompanying software) on laptops by default – the abovementioned problem would be solved automatically. Users would obtain a much higher level of security with such systems.

A good example of such hardware token is a fingerprint device which is already in its way to become a mainstream for laptop market.

Let’s summarize the list of alternative ways that hardware tokens or software components can provide for better user authentication:

• Hardware tokens with OTP support
  • RSA SecureID, Vasco, Yubico, etc

• Cryptographic tokens which support PKCS#11
  • The website could completely support PKI and provide each user with a certificate
  • The private key of user would be embedded in a PKCS#11 enabled hardware token
  • In this case two side SSL would be established between the user’s machine and website when the hardware token is connected to the system
  • Additional factor would be added to authentication scheme if this hardware token generated RSA signature only when, for example, the user provides pre-enrolled biometrics (such as swipes a valid finger)

• Special software could be installed on the user’s machine and provide a better authentication for users
  • As it was mentioned before the problem with this solution is that users usually don’t want to download and install unknown software from web