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.

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.