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

This article is the first part of a series of articles dedicated to principles and best practices of designing secure systems. It will discuss the following topics:

• The wrong approach of designing security systems
• The right approach
• Assets, threats, security controls, vulnerabilities, attack vectors and risks

The wrong approach

Security design, as a standalone discipline, has been significantly evolved in the recent years. People have designed tools and techniques for thinking about security and design it more effectively. However this discipline and the knowledge associated with it hasn’t yet fully integrated into system engineering processes and in many cases security systems are designed with a big lack of professionalism. As a result such systems often implement unnecessary and inappropriate security controls, don’t protect the security properties of real assets and leave security holes in the system.

A classical mistake is when engineers start designing security features without first understanding the real assets they are going to protect, their security properties and the real threats that are going to affect the system.

As an example they might decide to encrypt confidential data with a strong cryptographic encryption algorithm but also decide to store the cryptographic key on the hard disc in clear text or use a global key and put it in an executable without understanding that it doesn’t make sense at all.

The usual flow of the wrong approach is demonstrated in the following diagram:

1. Engineers start designing security controls by analyzing inputs which are mainly based on intuition. Although intuition is sometimes very good source but is not an institutional way of engineering.
2. After creating the initial security design, it is being analyzed against different attacks, again based on intuition.

This is a wrong approach as it doesn’t use standardized techniques and doesn’t take into account best practices.

Let’s see what the right approach is in my opinion for doing such analysis.

The right approach

The reasons behind mistakes that engineers are facing while designing security systems are well known. They are also present in other engineering areas such as software engineering. In order to develop the required software, first engineers need to understand the requirements. In many cases software engineers start to design (even implement!) software without properly clarifying the requirements and at the end of the day they are coming with a product which doesn’t correspond to customer requirements.

In order to avoid such problems people invented different software development methodologies and best practices, which will help guide the engineer to take the appropriate steps while developing software.

Similar methodologies exist also for security system engineering although I would say they are not as popular and distinguished as it is for software engineering.

Assets, threats, security controls, vulnerabilities, attack vectors and risks

Let’s take a look at the diagram below:

There are several new “keywords” used in this diagram. Let’s define them carefully:

• Informational Asset
  • Asset is an information piece that needs to be protected. It may have four types of security properties – confidentiality, integrity, authenticity and availability.
  • Examples – user credentials, high-definition video, private information, etc
• Threat
  • Threat is anything that has the potential to cause harm to the security properties of an Asset.
  • Examples – stealing of user credentials, piracy of high-definition video, breach of privacy, etc
• Security Control
  • Security controls are safeguards or countermeasures to avoid, counteract or minimize security risks.
  • Examples – Authentication systems, DRM systems, encryption of private information, etc
• Vulnerability
  • Vulnerability is a weakness that could be used to causes harm the security properties of an Asset.
  • Examples – Weak passwords, global key in a DRM system, weak encryption function, etc
• Attack Vector
  • A set of steps which exploits vulnerability of a system to result in a successful threat execution.
  • Examples  – Using brute force to break weak password, Reverse engineer DRM system and obtain the global key, Crypt-analyze the weak encryption function and obtain the encryption key, etc
• Risk
  • Risk is the likelihood that something bad will happen that causes harm to the security properties of an Asset.
  • Examples – the potential of having broken authentication system because of weak passwords is a risk, the potential of having broken DRM system because of global key is a risk, the potential of having broken privacy because of weak encryption function is a risk for the entire system

So after defining the terms used in the diagram let’s go through the steps of the flow and understand what each step means:

1. Identify and understand your Information Assets:
   1. What is the valuable information of your system and what security properties does it have.
   2. Where will your assets be stored and where they need to be traveled.
   3. What security properties of your asset need to be maintained at each point of the system’s lifecycle
2. Identify Threats:
   1. Understand what the applicable threats are to your information assets and the future entire system.
   2. Research for known threats in the internet.
3. Start designing security controls:
   1. Consider using cryptography
   2. Consider using physical security
   3. Plan protection mechanism for software and hardware (if needed)
   4. Implement other security features
   5. etc
   6. Note that during design of security controls you will introduce new information assets and thus will need to go to step #1
4. Construct the attack vectors (also known as attack trees) of your system:
   1. Consider you in the place of the attacker and think different attack scenarios
   2. Research the internet and find applicable attacks
   3. Etc
5. Identify vulnerabilities of the system
   1. Attack vectors will result in finding vulnerabilities in your designed system
6. Understand the risks of the vulnerabilities:
   1. Evaluate the risk of having vulnerabilities in the system
   2. If the risk is high you might decide to implement new security controls or change existing ones
   3. goto step #3

This algorithm allows designing security systems which are measureable by the means of risks. Of course the main problem in security engineering is that during “Construct Attack Vectors” step there is no way to construct and understand all the possible attacks and thus you cannot identify all the vulnerabilities of your system, so you cannot completely measure your design. However the algorithm at least gives you a better understanding of what you are doing, gives the ability to better measure the risks you have in your system and finally – it allows using institutional approach for future analysis.

References

http://www.sse-cmm.org

http://msdn.microsoft.com/en-us/security/cc448177.aspx

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

http://iac.dtic.mil/iatac/download/security.pdf

It has always been a mystery for me how crackers try to break software. What techniques they are starting with when they have the executable in hand, or what tools they are using for doing the crack.

In general the motivation of crackers is obvious and is the same as what the abovementioned applications want to prevent from:

• They are trying to use software without paying money (break)
• They are trying to steal intellectual property of applications to create a copy of it
• They are trying to steal confidential information (such as cryptographic keys) from applications to have access to other valuable information, such as user credentials, high-definition video content, etc, which is accessible in this application

In this article we will try to outline the techniques and tools that crackers are using while trying to break protections that exist in applications.

Typical “cracking lifecycle” consists of the following steps:

1. Static and dynamic analysis of binary executable file
2. Preparation for an attack
3. Automation (optional)

Usually the first two steps are mandatory but the third is optional and depends on the crackers motivation. If the goal is reverse engineering of IP based algorithms – there is no need to automate the attack. However, for removing license checks – the automation phase is essential.

The diagram above shows details of these steps and how they actually interact with each other. The adversary usually starts with conducting static and dynamic analyze of the executable. After some protection mechanisms are discovered, the next step will be to remove it, rebuild the executable and test. This process will continue until all protections primitives are removed.

During analysis the adversary can use very different techniques and of course there is no way to cover all possible approaches in one article as they are being improved over time and new, smarter, more complex approaches are being invented. It’s important to note that the cracker has full control over the environment where he runs the target executable. He can run debuggers, run the executable under virtual machine, hook system DLLs, write a kernel rootkit, etc.

Let’s go over each technique mentioned in the diagram above and see how they are performed.

Learning the Executable structure (Static analysis)

The first thing that the cracker would do (though it highly depends on his/her taste) is probably learning the structure of executable. Though this step is not very difficult (comparing to others) the information she can gather from it is essential for the next steps.

The following information can be comparably easily obtained from an executable:

• What libraries is it dynamically linked to? (if any)
• Symbol Table (if any)
• The starting address of executable
• The starting and ending addresses of text and data segments

Tools which can help you to dump this information are usually available by default in the operating system or are included in the package of integrated development environments. For Linux type systems it will be GNU Binutils (http://en.wikipedia.org/wiki/GNU_Binary_Utilities), for Windows – set of Dumpbin tools. In addition of course IDA Tool, PE explorer can also be used for this purpose.

The following link provides comprehensive listing of available tools:

http://en.wikibooks.org/wiki/X86_Disassembly/Analysis_Tools

Searching for known strings (Static analysis)

The next obvious thing the adversary will try to do is searching for string characters which the program outputs as an indication for error. For example, a license checking or registration based program must have a way to inform the user that registration code is wrong or that the license has been expired. Obviously the adversary can search for these strings in the binary file and try to locate the place of license check.

Constant data is usually embedded in data segment so the basic algorithm for disabling the license check or registration code check would be:

1. Search for the error indication string (smth like “incorrect registration code”) in data segment
2. Retrieve the address of this string in data segment
3. Search for the reference of this address in code segment. The code will be something like this:
   1. cmp readRegCode, realRegCode
   2. je regCodeValid
   3. …
4. Replace the “je” command with ‘always’ jump command (“jmp”)

Note that for some architectures the address gathered from data segment will not be referred directly in code but will be constructed as a “base + offset”. It may make harder finding the appropriate code in code segment.

De-compilation (Static analysis)

Another helpful technique is to try to decompile the binary code into higher level language, such as C. After decompilation is done obviously the code will still be hard to analyze but it may give a better understanding of high-level structure of modules and functions in binary file.

The following resource discusses more about decompilation process and what can be achieved with it:

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

Searching for algorithm patterns (Static analysis)

If the target program has cryptographic features implemented inside, such as encryption/decryption functions, it may be an interesting option to try to search the binary file for patterns of “encryption instructions”.

Usually encryption functions have lot of XOR and SHIFT commands inside and that makes them different from usual code. Every standard encryption algorithm (AES, DES, TEA, etc) has its pattern of implementation (a sequence of assembly instructions similar to mov, shl, shl, shl, xor, shr, etc) and if the adversary searches with this pattern, he may be lucky by finding the encryption/decryption functions. After these functions are found if can be easy to locate where exactly the data is being encrypted or decrypted.

Listening for library calls (Dynamic analysis)

The first dynamic analysis technique we will discuss here is the “listening for library calls”. The idea behind this technique is to set a breakpoint on a library function call which is definitely going to be called while checking the license expiration or registration code.

Let’s see an example. Suppose the target program checks for registration code and prints “incorrect code” on command prompt if the input code is wrong. Most probably the program will call printf function to do the print. If the adversary sets a breakpoint in printf function and gives a wrong registration code to the program, the breakpoint will be hit. The cracker can navigate up by the call stack and find the appropriate code fragment which is comparing the real registration code with wrong one.

It’s possible that the target program, instead of dynamic linking, used static linking with C libraries. So it won’t be possible to set a break point on printf function as it won’t be called. For these cases there are two options:

• Search for the pattern of printf function in target binary and set a breakpoint there.
• Set a breakpoint on an underlying system call which will be called when printf is called and navigate back by call stack. For printf it will probably be the “write” system call.

Monitoring memory (Dynamic analysis)

Sometimes replacing the “je” command with “jmp” won’t be enough for cracking the software. The software developers could implement complicated protections schemes against cracking which assume crashing of software at random places if the registration code was incorrect – e.g. instead of having just an “if” statement for checking the validness of input registration code the software may also have a logic which overwrites some important data in RAM and after the software executes – it crashes at different points. So even if the adversary was able to crack the checking of “reg code” she won’t be able to use the program properly.

In order to understand where exactly the program crashes the following technique could be used:

1. The program is usually crashing when an inaccessible memory is read or write
2. The cracker will run the program until it’s crashed
3. The cracker will review the crash dump information and locate the memory address which was being read
4. The cracker will set a breakpoint on this memory address and wait until it’s hit
5. In simplest scenario this memory will be is just set to zero
6. After identifying the code fragment the cracker replaces the “mov” command with appropriate number of “nops” so that the size of binary file is not modified.

Dumping the internal data (Dynamic analysis)

Sometime the adversary’s goal is to obtain data which is being available in the program at some point of execution. This data could be user credentials, high definition video content, etc.

Let’s assume that after playing with binary file for some period the attacker found the place where the data is getting available. Now he needs to output it to an external disc. The first option that will come to mind is to add a code to the executable that dumps this data. However, this is not trivial. Adding a new code to a binary executable is not easy as it will break the offsets of different data in the binary file and its integrity will be broken.

So a better approach will be to use the debugger for this purpose. The adversary will run the debugger and set a breakpoint on the place where the data is available. Then he may use the features of debugger to output the content of a variable to external disc (the debuggers usually have a feature of executing set of commands when a breakpoint is hit).

Hooking the library calls (Dynamic analysis)

I’m sure everyone reading this article has heard about DLL hooking. This technique provides a way to intercept the program data that is being passed to different functions that are called from DLLs.

“Hooking library calls” technique can be used for two purposes:

• The one that we mentioned above – intercept the program data
• Replace standard functions with yours and make the program to use them

We will focus on the second technique.

Sometimes it’s much easier for the adversary to change the environment settings that surround the target program to turn off protection schemes implemented in the program. For example if a program is calling time() function to get the current time, the adversary might provide his own implementation of this function, which will always return a previous time and the license checking code will always succeed.