Blurry Box Technology
Software is contributing an ever greater share to the value created in our economy. This makes software protection an increasingly important part of IT security: Software protection stops the illicit copying and reverse engineering of products containing software and is therefore an important safeguard against industrial espionage.
Kerckhoffs’ Principle
Kerckhoffs’ principle states: “The key is the secret and not the method.”
All software protection solutions currently in use violate Kerckhoffs’ principle, since they rely essentially on guarding the secrecy of the protection method itself. An attacker who knows these methods is already half-way through the fence. In theory, the methods that can protect software in compliance with Kerckhoffs’ principle are already known. However, these are not used in practice for resource and performance reasons. CodeMoving, essentially the execution of the protected program in a secure special hardware key (dongle), is equally too slow for regular operations in complex applications.
The Blurry Box Approach
Blurry Box makes Kerckhoffs-compliant software protection a reality. Blurry Box® technology was developed in partnership with the FZI research center, the Karlsruhe Institute for Technology and Wibu-Systems. It is scheduled for release to software developers in mid-2015.
Blurry Box technology assumes would-be attackers know the Blurry Box method, and the protected software product is not a black box for them. They can use the software and access the executed code in cleartext form. But Blurry Box technology makes static code analysis impossible and adds more solid layers of protection against dynamic code analysis.
Blurry Box technology and its proof of concept come in response to empirical observations and experiences from software development and the world of hackers and IT criminals over the last 20 years.
- Typical software is so complex that nobody could run the entire code simply by operating the application. A typical user uses around 10 to 20%, a power user 30 to 50%, and internal quality inspectors 80 to 90% of the code.
- A hacker will usually have considerable knowledge about the act of hacking itself. He or she might find hidden code, change return values, combine code fragments, or read and reenter code in the computer’s memory banks.
- A hacker does not know the actual purpose of the software or its internal workings.
These insights, specifically the lack of specialized subject-matter expertise, help establish software protection that works without having to outsource substantial amounts of the executed code to a dongle.
How the Blurry Box Works
Blurry Box technology combines multiple methods which will be showcased here.
Multiplying function blocks as variants
Any application can be broken down into a group of function blocks. A function block f[i] can have the entry parameter pIn[i] and output parameter pOut[i]. Depending on the pIn[i], the function block will return pOut[i]. In the Blurry Box process, the individual function blocks are multiplied into several variants: A function block f[i] is turned into blocks f[i,1] to f[i,m]. The function blocks f[i,j] are accessed with a wrapper function fw[i] depending on the access parameter pIn[i]. The output of variant f[i,j] is returned as value pOut[i], which means that the code executed during each cycle is minimized, governed by the chosen wrapper parameters.
Modifying the Variants
One trivial means of bypassing the variants would be to tamper with the wrapper function fw[i], so that only a single variant is executed in every case. To close this door against attacks, Blurry Box technology modifies the variants for a function block to only work with the correct range of parameters. An attacker without inside knowledge will not be able to recover other unknown variants or the original function block simply from single (or even several) variants.
By modifying the code, the variants would deliver incorrect output for parameters not within their range. Without a specialist’s insights, the attacker would have no means for correcting this intentional mistake. The unknown variant could therefore not be replaced with a known substitute.
Encrypting all Variants
Every single variant is fully encrypted, with the encryption key stored securely on the dongle, which also holds an API function to load the encrypted data and decrypt it inside the dongle. The decrypted code is returned by the dongle API and executed as a code variant. Without the dongle with the correct key, no variant can be decrypted. The encryption uses the Advanced Encryption Standard (AES) and includes a random value in the computation to represent blocks with similar contents in different cipher texts.
Built-in Traps
To prevent attackers from decrypting all variants by the dongle without the application being executed concurrently, several trapdoors are built into the system. These trapdoors are encrypted variants that would flag the license in question as invalid when they are encrypted by the dongle. For the trapdoors to work not only for statistical attacks, but also for attackers who try to analyze the source code in question, the source code includes links leading directly to the booby-trapped blocks. These would never be accessed during regular operations, since they would only be accessed in variants that are not expected to be executed when the application is run normally.
Computing the Choice of Variants on the Dongle
Code moving (executing the program code on the dongle) is usually not a feasible option, as it slows down the protected application too much. Selecting only a sensible portion of code to be executed on the dongle is, in turn, too complex to be implemented meaningfully. The code for computing the selection of variants, however, is a very good choice for code moving. It is a short, but essential piece of the puzzle. The selection and implementation works without involvement of the software’s original developer and is fully automated. For this purpose, the index of the wrapper function (i) and the relevant parameter pIn[i] are moved to the dongle, where the index of the variants to be accessed is computed and returned (j). This makes it impossible for attackers to predict which variants (or trapdoors) are chosen or not chosen, even if they know the valid parameter range, unless the code is run with the right parameters.
Using the Dongle as State Engine
The sequence in which blocks are decrypted during regular operations is not random. A block can only be followed by a very specific selection of other blocks. The memory of the dongle allows the Blurry Box to distinguish between valid and incorrect sequences and to lock down the operations in the latter case.
Security of the Blurry Box Technology
Hackers are experts for different attack methods, but they often lack insight into the inner workings of the applications they are trying to crack. This lack of knowledge can be formalized, which is the backbone of the formal proof of security of the novel process developed by the FZI research center and the Karlsruhe Institute for Technology. It has been shown that all successful attacks are equivalent to attacks that are by their nature not preventable. The proof covers all attacks, including those by attackers who know the method. It complies with Kerckhoffs’ principle, which means that the method can be tested and validated independently. This is not possible for protection methods kept secret, making it a great advantage in the fight against industrial espionage and sabotage.
Availability
Blurry Box technology is being integrated in CodeMeter and AxProtector. As software developers, you will have access to a framework that enables you to integrate the Blurry Box concept in your software starting mid-2015.
KEYnote 29 – Edition Spring 2015