Software diversification

Challenges and Best Practices with Software Diversification

In our last blog we shared what software diversification is and why it’s important. Just to recap, software diversification is a method of altering an executable binary so that various instances of the same software, while providing identical functionality, to an attacker appear different and operate differently on the binary level. It confounds an attacker’s attempts to exploit information gained from one deployment to compromise other deployments. 

While software diversification throws up barriers to adversaries in open environments, it also adds complexity to software development and maintenance:

  • It is expensive and technologically difficult to develop and implement a software diversification scheme.
  • It is a complex task to maintain a large deployed base of diversified application instances.

Suppose thousands of diversified software instances are to be upgraded to a new version. The code base must be replaced with a compatible upgrade, and the persistent data of each application must be transformed to the new protection version without revealing any secrets. The planning and development requirements are significant. Therefore, the design and costs of installing, upgrading, and maintaining diversified applications must be carefully evaluated when planning a diversification scheme.

If your system contains sensitive data, such as licenses, personal information, passwords, or cryptographic keys, and runs in an untrusted environment, such as consumer devices, you need some form of software diversification as part of your tamper-resistance solution. This will greatly improve the security of your applications and enhance protection against class breaks and piracy.

In our last blog we noted that data diversification is a simple and effective means for enhancing software security. It ensures that data processed by different instances of the same software are not compatible and cannot be transferred from one instance to the other. Because this method is quite easy to implement, it should be a standard component in the security design of your applications. And code diversification, also discussed in our last post, is a more complex solution but it provides the best protection against class breaks, making them extremely expensive and time-consuming for software attackers.

Regular renewal of diversified code

Software diversification can be effectively used to proactively prevent attacks by regularly updating the security software on installed hardware, thus frustrating hacker attempts to crack the system. By occasionally replacing security software with new diversified instances, an attacker is forced to abandon his existing analysis. In the end, the effort of breaking code exceeds the value gained.

Upgrading diversified applications

Upgrading a large number of diversified software instances is challenging, since the new binary implementations and embedded data may be incompatible with the old.

The following techniques can make the upgrading of diversified applications a manageable task:

  • Confine the diversified parts of your application to isolated modules that can easily be replaced.
  • The diversified code modules should export and import their internal state in encrypted form. If the exported state is retained between upgrades, the software can be safely replaced with new code patterns. The state can be protected by a key that is unique to each software instance. This is a form of data diversification.
  • Develop a mechanism to test if two application instances use the same or compatible diversified data instances (for example, the same state export/import key). For instance, an application could return a data diversification identifier, a number that would be identical for applications whose data is compatible.
  • If an older module uses a state that is compatible with the state of the newer version (as described in the previous point), the new module can simply be substituted for the old module, with no need to transform the module state.

At the end of the day, you should consider the following questions when evaluating code diversification:

  • What will be the cost and effort required to develop a code diversification scheme?
  • How complex and costly will it be to maintain an installed base of diversified applications?
  • How much of the software code should be diversified?
  • Should code diversification be applied to individual application instances or rather sets of application instances?