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 we will go through the key concepts in information security and will try to explain them by bringing real life examples. Throughout the article I will also call the key concepts “security properties” of information.

So the security properties we will discuss here are:

• Confidentiality
• Integrity
• Authenticity
• Availability
• Non-Repudiation
• Accessibility

Why is it so important to always remember about these properties? Sometimes engineers just forget about the real security properties they need to protect and create systems which have lots of overheads and implement unnecessary security controls in it by complicating the overall system and introducing security holes. This can be avoided if we think about security properties from the very beginning and don’t forget about them until the system architecture is ready.

In information security what you need to protect is a block of information. Nothing more… If you are going to protect, for example, your car – that’s not a problem of information security. It’s a problem of physical security or another similar discipline. So let’s remember: in information security whatever we design we need to focus on the information and its security properties. The rest is not important.

Any information block may have 6 different security properties:

• Confidentiality – a security property which allows hiding the content of information from eavesdroppers. Even if eavesdroppers have the digital information in hand, they cannot see the real content if its confidentiality is protected.
• Integrity – a security property which allows making sure that the block of information is not modified/corrupted.
• Authenticity – a security property which allows authenticating the sender of information.
• Availability – a security property which allows making sure that the block of information is available to everyone whoever needs it.
• Non-Repudiation – a legal property which allows making sure that the person (or a company) who performed some operation on a block of information cannot refuse his participation in this operation in the future.
• Accessibility – a security property which describes the access rights (like read-only, read-write, etc) of all components in the system for a block of information.

A block of information may have zero or multiple security properties. Its security properties may be completely disappeared during its lifetime or be transformed from one type of property to another.

While designing a security system the architect needs to design security controls which will make sure that the security properties of all the information blocks cannot be damaged during their lifetime. Once this is done – the architect can be sure that the system security architecture is complete.

So the main task of a security architect is to:

1. identify the blocks of information which have got security properties
2. identify exactly what security property each of these information block has
3. design security controls to protect the security properties of all information blocks that have been identified during the step #1

Note that the complete algorithm of how to design secure systems is described in my previous article – How to design secure systems? Security Analysis.

Let’s bring a simple example and discuss each of these properties using real life terms. Note that as we need to cover all the security properties in it – the example may be somewhat artificial.

Suppose we need to design a social network similar to facebook.com. Let’s call it soshial.net. The users register with that web service and communicate with each other through it. The users are also able to keep sensitive information, such as personal files on the server.

Let us list the original requirements of the system:

1. Each user must have access only to his/her account.
2. User can submit his/her personal information in his/her account.
3. User’s private files should not be accessible even to the web service administrator.
4. After a user A sends a message to user B, user A must not be able to refuse this operation in the future.

Now let us try to identify the information assets and security properties associated with them.

Now let us design security controls to protect these properties.

First of all in order to protect the authenticity of user’s personal data we need to have a way to control the user authentication. We will use username/password approach to do that. So each user will create a username/password during registration and present this pair before getting access to his/her account.

After introducing username/password we have got new information blocks which also have security properties:

• Password
  • Confidentiality – only accessible to owner (even not to administrator)
• Let’s assume that username doesn’t have any security property in this example

Confidentiality, Integrity and Accessiblity

In order to protect the confidentiality of password, the server will store the hash (say SHA1) of password in its database. However we will also need to protect the confidentiality when the password is sent from user’s machine to the server. Here we will use HTTPS as a security control. HTTPS is based on SSL and it protects the confidentiality and integrity of data being sent over HTTP.

So, all the information that belongs to a user will be accessible only to that particular user. However user’s personal information will be accessible also to other users but only in read-only format.

After the user inputs his/her personal information during registration, this information becomes available to everyone in read-only mode. This goal will be achieved simply by having a script on the server which controls the accessibility of data and allows modifying data only to authorized people (in this example it’s the authenticated user).

In order to protect the confidentiality and integrity of user’s private files we will associate a symmetric key (say AES) with each user. This symmetric key will be used to encrypt all the files that belong to that user. Thus, these files will be stored on the server in encrypted form. In this case even the administrator cannot access them. The symmetric key, itself, will be created and immediately encrypted with user’s password when the user registers with the web service. So the key will be available only during the session when the user is logged in. Once user logs out – the key will be removed from server’s RAM. This mechanism allows protecting confidentiality of user’s private files.

However though confidentiality is protected, the integrity of data is still not there. If any file is modified – the user won’t see that modification unless he decrypts the file and looks inside. Even worse, if, for example, the last 16 bytes of an AES encrypted file is corrupted, the user might not notice that until he explicitly needs those 16 bytes, and if he needs them during a critical mission operation – this would be a huge problem.

So in order to protect the integrity of these files we can calculate a simple checksum (CRC32) or cryptographic hash (SHA1) and attached to the end of each file. Before loading the file we will verify the checksum and if the verification fails – will report to the user.

However still the authenticity of files is not there… What if someone modifies the entire file by purpose and attaches a valid checksum to the end of this file? User will decrypt the file and get some corrupted data but he won’t be able to verify the authenticity of data (to verify that he is the creator of that file). In order to solve this problem we will need to use message authentication code (MAC). In this particular example we will use HMAC-SHA1. So each time a user downloads a new file or modifies an existing one – the server will calculate a new HMAC-SHA1 based on the encryption key and file content and will attach it to the end of the file. When the user loads a file, the server script will verify the HMAC of data and make sure that this data has been created by this user and hasn’t been modified. Thus the authenticity and integrity properties are protected.

Authenticity and Non-Repudiation

Now the security properties of user’s personal information and user’s private files are protected.

The only security properties that are not protected yet are the authenticity and non-repudiation of messages. In order to protect the authenticity the server script just needs to allow sending messages only after the user logs in to his account and disallow to change the username field of the message.

However it’s little bit difficult with non-repudiation. Let me describe the problem. In case of non-repudiation the receiver of message must be able to verify that the sender is user A and user A cannot refuse that he created that message. In the same time no one but user A must be able to create that particular message otherwise user A would claim that someone else created that message and not him.

We can use PKI to solve the problem of non-repudiation. It will complicate the existing system significantly but the requirement itself is difficult. Each user will have a public and private keys assigned to them and the public part will be signed by a certification authority. When user A sends a message he will sign the message data with his private key. User B can verify the signature of message using user A’s certificate. With this approach nobody can create a valid message but user A and in the meantime after having a message created by user A, user B can always claim that user A has sent him that message and nobody else.

Availability

In our case social.net is a web service with millions of users and if this service stops working – it may have a huge business impact. There can be many technical reasons why this service might stop – technical problems, improper administration, DOS or other types of attacks…

In order to maintain the availability of social.net different security controls need to be designed, such as anti-DOS defense, database backup, etc.

This was just a demonstrative example which showed how engineers should think about security properties of the data they are trying to protect.