However it’s important to also understand that when we integrate a secret based protocol in our system, we will get another, more serious problem – how to securely hide the secret that is used in the protocol for authentication?

For example, suppose you have two components which are establishing an SSL protocol. As SSL is based on public key cryptography they both need to possess private keys (if the authentication is mutual). So how are they going to protect their private keys locally in their systems?

Of course the problem of hiding cryptographic keys or other secret information doesn’t only apply to systems which are implementing security protocols. Encryption is the most popular and convenient way to protect the confidentiality of information. However when the system encrypts something there should be a way to protect the encryption key (or the decryption key) and this, believe me, is a much, much harder problem.

In this article we will discuss the ways how one can hide secret information in:

• Windows environment
• Inside a software
• Inside a hardware

I have been doing research on this topic more than a year now and would like to share my knowledge and experience with you.

All the mentioned topics are heavy and one cannot describe all of them in a single article. I’m planning to have several articles describing different aspects of these themes (such as obfuscation and tamper-proofing in software, tamper resistance in hardware, etc).

So in this article we will discuss the “theoretical” part of the topic and then will go through an example and try to apply this knowledge in real life.

The Problem

The problem of hiding a cryptographic key in a system is a widespread problem and lot of research is going on over it worldwide. In general we can state that this problem is not solved. Whatever technique you are going to use to protect your information, be sure that it will be hacked over time. So engineers, instead of looking for an ideal solution, should look for protection techniques which will increase the time required for breaking their systems and thus gain business benefits.

Nowadays obfuscation is the only technique to protect secret information in an un-trusted environment. People often say (or assume by default) that putting a key in a hardware component is much more secure than implementing protection schemes in software itself however I don’t always agree with that opinion. If you think about it – putting a key in a hardware device is just another way of obfuscation… Yes, sometimes breaking hardware is more difficult than software, but it really depends on the protection schemes that have been used on both sides. I think people usually have this default opinion as most of them don’t have electrical/hardware engineering education/experience and that’s why they consider hardware related attacks to be much more difficult.

That is not true.

There are well known and easy attacks on hardware protections and most of the devices are prone to these attacks. I’m planning to discuss these kinds of attacks in one of my upcoming articles.

In my opinion there is only one big difference between these two systems which really makes sense. The difference is in fact that in case of hardware the system is able to physically remove the cryptographic key stored internally once it detected an active attack. For software systems this is not possible as you always can copy the software before starting attack on it. You can always put it under emulator while conducting an attack and in this case there is just no way for it to be able to delete the key. So you will be able to conduct the attack as many times as you want and if during one of these experiments one of your actions brings to deletion of the key – you can use the copy of software and continue experiments. In case of a hardware device – it’s little harder as you can’t physically copy the device and once the key is deleted there may be no way to restore the data back.

So, in general, hardware protection schemes are more reliable, but only if they are properly implemented. Software obfuscation and tamper proofing schemes have been significantly evolved in the past years and breaking these techniques is also considered to be a big challenge. For example the well known Skype software has been broken only after one year of its production which gave the developer company enough time to penetrate the market without letting the competitors to steal Skype protocol algorithm and make an illegal copy.

From other point of view there is no example of an unbroken software system while such examples exist for hardware. IBM 4758 device is a good example.

So let’s see what kind of software and hardware protection schemes exists currently in the industry. We will start discussing Windows, then go to general obfuscation and tamper proofing techniques in software and end with hardware based protection schemes.

Hiding cryptographic key in Windows

We will focus on Windows environment as I’m more handy with this operating system when it comes to security.

There is a strong opinion among the engineering community who are not experts in security that Windows operating system provides solid mechanism for protecting secret information in the system. That is not quite true. Windows does a great job by providing different mechanisms but it only does it in the scope of the resources it has access to. An ordinary laptop or a PC doesn’t possess a special device or a special hardware component for protecting your information… in fact what is has is just a hard disc and a RAM. So if Windows, by its definition, just cannot have a solid way for securely protecting your secret data.

However, as I said, it provides interesting opportunities, which, if properly used, can give a significant improvement for your application.

Account based protection

Windows provides API to encrypt data using Windows user account credentials under which the current application is running. CryptProtectData API receives a buffer as an input argument and returns the encrypted buffer as a result of successful operation. CryptUnprotectData API, in its turn, decrypts the encrypted data and returns it to the caller. Only applications which run under the same windows account are able to decrypt data.

From first point of view this is a very limited offering. However if your application is installed under administrator account then only limited applications would be able to access the data that you have encrypted.

Process based protection

I you want to protect your data in the context of a running process memory you can use CryptoProtectMemory and CryptoUnprotectMemory APIs. The first will encrypt the given buffer and return it and the second – decrypt and return.

Note that the buffer will be encrypted only in the context of the current process. If you run the same application again – the new process cannot decrypt it. These API are useful when you don’t want your in-memory data to be swapped to the hard disc.

Another technique for disallowing swapping is to mark the appropriate page as not swappable via VirtualLock API.

This is basically all that I’m aware of the mechanisms that Windows provides for protecting application specific data.

Hiding a cryptographic key inside software

If you don’t have a hardware component in your system – you are doomed to protect the secret information through obfuscation and tamper proofing.

Although there is a well formed opinion that whatever is obfuscated – is not secure, I wouldn’t completely agree with it. Currently there is no alternative to obfuscation. People who are saying that obfuscation should not be used need to invent better protection mechanisms before making such statements.

You can achieve a solid protection by properly using different techniques of obfuscation and tamper proofing but you also need to realize that it will have an impact on overall development, testing and deployment of the application. If the information you are going to protect is very valuable – I wouldn’t recommend using homegrown solutions. It’s better to integrate solutions form companies such as Arxan, Cloakware, Syncrosoft and put the security responsibility on them. Believe me these guys have a very good story for their secure technology and your customers will be definitely satisfied. However, most probably, you won’t be satisfied with their pricing…

Anyway, if you decide to design and implement a homegrown solution for obfuscation and tamper proofing there are many already known techniques that will help you to get to the approach which is the best for you.

Let’s outline what kind of techniques exists currently. We will just go over high-level descriptions of these techniques. I’m planning to dedicate a standalone article to these topics so there is no need to provide exhaustive explanation at this point.

Obfuscation

• Semantics-preserving transformations
• Complicating control flow
• Opaque predicates
• Data encodings
• Breaking abstractions
• Moving code around
• Encrypting code

Tamper-proofing techniques

• Checker Network
• Hiding hash values
• Response mechanisms
• Overlapping instructions

Hiding a cryptographic key inside hardware

If you are really targeting high-end security market you have to consider hardware level protection for your secret information. By saying hardware I mean a hardware device with non-volatile memory (such as OTP, ROM, EPROM, EEPROM, Flash, etc). However, as I said earlier, you will need to implement different complicated security measures in order to protect the data stored on this memory.

Remember, there are many attacks which are much easier to conduct for a medium trained electrical engineer on a bad designed hardware device rather than an expert software engineer on well obfuscated software.

Another problem related to hardware based protection is the deployment and adoption through users.

You can also achieve the goal of having an encryption key in hardware token without using internal memory in the device itself. You can have a hardware device which generates a unique, secure key on each boot so there is no need for a non-volatile memory. There are currently IPs available for this purpose with their proprietary technologies.

Many times during my experience I have heard statements like “well, we can utilize TPM to protect our cryptographic keys”. There are people, who are making such statements without really knowing what TPM is, and how and where you can use it. TPM won’t help you in protecting secret information. It’s only useful when used within the scope of a trusted stack. It can store your key securely however only if your application is a part of trusted booting chain. If it’s not – forget about TPM.

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.

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.

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

Think about the most recent security vulnerability you’ve read about. Maybe it’s a killer packet, which allows an attacker to crash some server by sending it a particular packet.

Maybe it’s one of the gazillions of buffer overflows, which allow an attacker to take control of a computer by sending it a particular malformed message. Maybe it’s an encryption vulnerability, which allows an attacker to read an encrypted message, or fool an authentication system. These are all software issues.

Testing the software from security standpoint is a key requirement especially for software products with security focus. Even if the product has been architected with the best security protocols and security designing best practices in mind, it doesn’t make much sense as the attacker will prefer focusing on the application layer and eventually will find a vulnerability there and exploit it…. Remember, on application layer…

When I was very new in security engineering I remember me asking people whether there are really real attackers who are trying to break the product’s security by attacking its cryptographic features, algorithms, protocols, etc (the architectural layer). Analyzing the architecture, trying to find problems in cryptography related parts of it and exploiting them? Say, you are using Diffie-Helman protocol to exchange a session key however the implementation you are using has to have a small modulus because of the computational restrictions. The attacker analyses the program, finds this problem out and conducts a brute-force attack on the algorithm trying to obtain the session key. Wow… do you believe in such attack? Why the attacker would do that if there are much simpler ways to attack the software? It’s much simpler to just find a vulnerability in application layer and exploit it.

Of course the architectural layer of product’s security is very important and of course my conclusion in the previous statement was too naive… however what I’m trying to say here is that I have an impression that all the cryptographic primitives that we are including in our solutions are more interesting to marketing and sales people rather than the real attackers (at least for products which are not used in government or military related projects)… and this needs to make people think that something is definitely wrong in the security engineering process…

The goal of this article is to discuss what means testing the security of product from application standpoint; which points need to be taken into account while developing test cases and what kind of attacks exist on software application level.

Recently I was planning the strategy of security testing of the product I’m working on. After some research and thinking I have divided the possible application layer attacks in to the following groups:

• Data Structure Attacks
• Input Data Modification Attacks
• Data Leakage Attacks
• Attacks based on Abuse of Functionality
• Attacks on the Implementation of Architecture Features

Let’s go over them quickly and discuss how we should test the system against such attacks.

This article doesn’t reflect all the possible attacks and weak points that are possible at the application layer however I think it’s a good start and a good experience sharing. I will probably cover topics like proper using of ACL, potentially exploitable code patterns, penetration testing, etc in a separate article.

Data Structure Attacks

I’m sure you heard about buffer overflow, string format, and integer overflow attacks. These are well known attacks which use the vulnerabilities that the bad coding may produce and inject code in the running program. I’m not going to explain how these attacks are conducted or what the reason behind them is in this article. You can find all questions to such answers in the following links:

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

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

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

Instead we will focus more on how to test the source code against such vulnerabilities and how to find them in the code.

Code review, code review and code review. Code review is an excellent way to find architectural mistakes, logical and coding bugs in the program. It’s also very useful while looking for an overflow bug in the source code. The teams where code review process is well established as a rule are having lesser number of bugs and much more secure code. So code review is always good to conduct.

However there is one bad thing with code review. It’s manual and thus very slow…

It’s not always necessary to conduct the code review process manually. There are actually tools which can automate this process and save lot of time for developers. These tools are called static code analysis tools. They run over static source code and find potential bugs. The type of problems that they are able to find is big and one of these types is the problem of overflow. I have utilized two static code analysis tools during my experience – preFast (from Microsoft) and coverity (from Coverity). Both they are very useful and do great job. I will probably dedicate another article to static code analysis tools and will cover lot of details there. But for now – remember, integrating and using static code analysis tools is a MUST step in building a mature software development process and building secure code. They  may significantly reduce the number of potential bugs in software if properly configured and continuously used.

There is one more thing that I find useful for prevention of overflow vulnerabilities in the code. Different compilers provide security checks, protections during compilation or generate a code which automatically prevents overflow attacks.

Let me list several recommendations on regarding this:

• Turn on the highest possible warning level of compiler while compiling the code (/W4 for Visual C++ compiler, -Wall for GCC)
• Use the /GS flag of Visual C++ compiler or StackGuard for GCC. With this flag the compiler injects code into compiling application to help detect buffer overflows at run time.
• /SAFESEH – after compiling with this flag the complier will add extra exception-handler information which will be verified by the operating system to make sure that the real exception handler hasn’t been overwritten. (This is not related to overflow problem however it’s still a useful thing to know ;))
• Don’t use banned functions.
  The latest compilers usually deprecate a set of old functions (mostly string based functions) and the programmers should never use those functions. They all have potential overflow vulnerability. Note that such functions can be easily found by static code analysis tools.

The following article is a good reference describing these recommendations in more details.

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

Input Data Modification Attacks

It’s important to understand that usually the only way the attacker can influence your program is through an external interface (we assume that he doesn’t have access to program’s internal memory). The main external interface of an application is the modules which process input data. During its execution any program receives input data from a file, registry, network, GUI, system, etc. If the program doesn’t verify this information carefully before using it – the attacker may be able to find and exploit a vulnerability because of that.

The exploit, that such vulnerability will eventually bring to, is based on overflow attack that is discussed in the previous section. However I have decided to separate these two vulnerability schemes because of the way we will fight against them. Finding a potential overflow and verifying that all input data is verified against its format are different operations and need to be handled differently.

The best way to avoid such problems in your program is to go over all input data that the program can receive during its execution lifecycle and make sure that each and every of these data has a predefined format and is checked against this format before being further used.

It’s also very useful to use fuzzers to test the program against bad input. The following Wikipedia article talks about fuzz testing and its applicableness:

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

Data Leakage Attacks

Often attackers, while playing with the victim program, are analyzing the output that the program produces and try to find a sensitive information leakage in this output. I call this type of attack Data Leakage Attack.

During its execution a program may produce different types of outputs:

• Trace
• Temporary (or persistent!) data stored in registry, hard disc
• Data exchanging in a protocol
• etc

All these outputs have a potential to contain sensitive information (confidential, important, etc) and if the program leaks such information – the attack will be very happy to eavesdrop them.

Unfortunately I don’t know any effective way to prevent programmers of leaking sensitive information. Of course the programmer doesn’t leak this data intentionally (I hope they don’t!). It can be a debug message, which was useful during debugging or just an unintentional mistake. No matter how this data leaked there must be a way to detect it…

The only way I’m aware of is to develop QA process (test cases) where QA engineers will go over all test cases and make sure that none of the outputs contains a leaked data. This is of course a poor approach and I would be glad to hear a better technique from you…

Attacks based on Abuse of Functionality

Many security oriented products have user interface – graphical or command line. This interface provides an opportunity to users to perform different operations and an opportunity to attackers to find a vulnerability in the program. In general the user interface can be considered another form of “external input” to the program and the attacks that are applicable here will be also covered by “Input Data Modification Attacks”. However again the approach to prevent such attacks is different here and I would like to briefly focus on that.

Suppose the program has 3 different buttons (1, 2, 3) on its GUI and the right combination of the usage of these buttons is – 2, 1, 3. The attacker will try to use other combinations (123, 321, etc) and see what happens with the program. If it’s crashes or misbehaves – bingo!

Automatic GUI testing tools must be used or just well covering test cases must be developed to check all the possible combinations of GUI control usage. In practice this is not always possible and the consequence is that such attacks are pretty much popular now.

Attacks on the Implementation of Architecture Features

The last type of attacks I’m going to discuss here is implementation level attacks on security architecture. Suppose on architectural layer you have decided to use AES128 algorithm to encrypt data. However your implementation (source code) has a bug and upon receiving some type of input data – doesn’t encrypt the data or does partially…. this is bad. Another example… Suppose in your architecture it is said that some confidential data needs to be stored on the hard disc and be deleted after 5 seconds. However your implementation has a mistake and the data is never deleted…

These examples show a simple thing – the implementation doesn’t not always correspond to the architecture (I would say in most cases it doesn’t) and careful test cases need to be created to cover all the logical statements that are present in the architecture.

In general testing that the actual implementation corresponds to its original security design is a tough process. It requires test case developers to carefully understand the security architecture and test each step that is defined there.

Let’s see a “simple” scenario… suppose the architecture defines that step A can be performed only when the system is in specific state B. Now, there should be a test case which not only tests that this requirement is met (step A can be performed in state B) but it also tests that step A cannot be performed in other state than state B. This of course complicates the life of test case developers…

Hope after reading this article you will come up with better understanding of why it’s important to write secure code and why it’s important to test the security software from application standpoint.

Useful Information

http://cwe.mitre.org/

http://cve.mitre.org/

http://capec.mitre.org/

http://www.exploitingsoftware.com/

http://www.webappsec.org/projects/threat/

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

During last several decades people have created a completely new discipline, a new world, something that even the most genius fiction writers didn’t come up with – computers and software.  Today it’s in our life everyday, everywhere, almost each second… I think that’s a wonderful progress…

Software and hardware are used everywhere, at home, when we drive a car, when we flight on airplane, when we talk by phone, when we watch TV, when we send a mail or wait in a queue in a restaurant…

However in parallel to this big progress there is one thing that I think is not improving very well over time. That is the quality of software. Although people realize and give a very high priority to the technologies, processes, methodologies, which will raise the opportunity to improve the quality of developing software, however there is no big progress in this area.

What you think is the reason behind this? How can we solve this problem and finally how is software security connected to its quality?

I will try to briefly discuss these questions in this article.

What you think is the reason behind this?

Today, medium size software is a very big, complex system which consists of a huge number of small elements and which is so huge that cannot be completely fit in the imagination of dozen of people. Hundred thousand lines of source code written in a language which, though is semantically correct, but sometimes is able to confuse any expert programmer… Infinite number of “if” and “branch” statements – a huge graph with million of edges and nodes… And you are asking why it is hard to test this monster?

If we also take into account the fact that this monster graph must be integrated to another, thousand times bigger, super monster graph (OS, internet, external devices with their software, etc) then it becomes clear that the testing of this huge system presents an extraordinary difficult engineering problem which is definitely not easier than the creation of this software.

There is an opinion that the profession of “test engineer” requires less knowledge and experience than the profession of software engineer. I find this opinion wrong. The testing of software is one of the most challenging problems that need to be addressed in the near future and every, even simple, progress in this area will be appreciated by the industry very much.

How can we address this problem?

Today’s giant companies are spending big efforts in order to improve the quality of their software. Microsoft, HP, Dell, IBM, etc spend huge money on increasing the quality of software development processes. The companies, which are able to produce qualitative, simple software, are having big success in the industry (google)…

It seems that the main focus, today,  is in creating effective software development processes and addressing the problem of testing in the process itself. The processes are developed in a way that development and testing teams are separated from each other as much as possible in order to not affect on each other. There are even methodologies where test cases are developed before development of the software itself (extreme programming).

However all this doesn’t change the situation. Software fails and crashes everywhere.

Let us discuss several activities and methods which might improve the overall testing process if properly applied.

More time , more money, more people

Time to market has the highest priority for many products and it’s obvious that project/product managers have to schedule projects in the way to complete the product as soon as possible. This brings to situation where in most cases the lion part of product development time is dedicated to software development and only a small portion – to testing. The consequence is what we have now – a market filled with lot of products but with poor quality.

The industry shows that companies who spend more resources (money, time, people, etc) to test their products and create qualitative software – have big success in the market. The industry and people need software with high quality.

The quality of software will never become as important as the “time to market” requirement; however software companies need to realize that over time people will just refuse using bad written software and will prefer to pay more for a qualitative product.

Optimizing the testing process

It’s obvious that for today’s software the number of surrounding environments is so large (different platforms, different operating systems, etc) and the environments are so complex that it requires lot of time from Verification and Validation teams to complete a single cycle of test cases validation (and of course all test cases are not covered). This, in its turn, has a significant affect on project’s schedule which is not allowed from business perspective. If it were possible to speed up the test execution process and particularly speed up the prelease->test->fix->prelease->test cycle – it would have a great impact on overall project schedule, budget and quality.

Imagine if there were tools which allow the test team to perform specific steps once, record them and playback whenever they want. The test team would record test cases on different platforms once and would run them overnight, automatically.

I’m sure such tools already exist in the industry but they are not yet mature enough and need to cover more environments and support more business cases.

A globally admitted testing language

Many companies have internally developed special purpose languages – designed for testing the internal products. This makes sense. However as a rule such languages are very poor designed and are very specific to the target product. They are not object oriented and the best practices that are applicable to development languages are not applicable for those languages (very difficult to reuse code, difficult to maintain, not generic enough, etc).

It’s time to think about developing libraries for testing and facilitate the life of test engineers. Of course this is not a trivial task – however I believe the industry needs it and there is a big niche in the market for such tools and libraries.

Automation Tools

If it were possible to detect bugs earlier in the process of software development using automation tools – it would significantly speed up the overall testing process.

There is a notable tendency today to use static and dynamic analysis tools during software development process, which allow finding coding and runtime errors that might become bugs in the future – if not fixed. In ideal case such tools would run over source code or emulate the software programs and find all the issues which can bring to crashes and vulnerabilities. Of course they cannot find logical errors but still their impact will be very big – they allow decreasing the number of potential issues significantly.

Application Verifier, Valgrind, preFast, Coverity, Fortify… These and similar tools will be a very important part of software development process in the near future and I think it’s time for everyone to integrate and use them.

How is security connected to quality?

In today’s world an essential thing becomes the testing of software from security standpoint. How one can achieve this goal and what are the best practices – I will cover in another article. However I would like to briefly discuss this topic here as I find it to be very important and directly connected to software testing.

Many software engineers and technical leads have no idea what means software security and either don’t pay attention to it at all or give very low priority to security aspects of coding. Of course this is a bad tradition. This tradition has been started a long ago when there were no computer viruses and no one cared about computer security.

Respectful consulting companies report that around 70% of all attacks are being conducted on application level rather than architectural layer. This means that even if a security application has very well designed architecture from security point of view – the attackers will focus on bugs and vulnerabilities that are result of bad coding (buffer overflow, SQL injection, XSS, etc) and will successfully exploit them. Even if your application doesn’t have any security requirement – it may (will!) become a target of attackers and once exploit – will be used to attack the environment where it is running (internet browser, operating system, web server, embedded device, etc).

Security of software (secure coding) explicitly affects the quality of software. And while no appropriate attention is paid to the testing of software from security perspective this will remain one of the weakest points of software QA process.

Afterword

And as an afterword I would like to mention that software engineers, and in the first place, software companies need to change their opinion and approach about the profession of QA engineer. This profession will play one of the most important roles in the software development process in the near future and it’s time to treat it more seriously.

The time when a small group of software engineers created breathtaking programs in a month and immediately made them available for millions of people without testing the product well – is gone. And we all need to admit it. Otherwise we will need to continue pressing Ctrl+S each 5 seconds while working with programs like MS Word.