Introducing artificial diversity between versions of a piece of software has a number of applications. Firtly, multiple versions of the software may be distributed over time or to different users. The difference between these versions may consist of critial information that shouldn't be leaked. Consider the example of a user-specific key in DRM applications. Another example can be found in software updates: the difference between the patched and unpatched version may inform an attacker on how to exploit vulnerabilities in systems that haven't been patched yet. In these cases, we can introduce additional, artificial diversity to hide the true differences. Secondly, diversity may be used to mitigate class attacks, if every user has a different version, or different versions are distributed over time, an exploit against one version may not work against another version. We will also look at the other side of the spectrum: at techniques to match related fragments between different versions. These techniques are often the first step against artificial diversity.

Confidentiality and data authenticity are two basic concepts in security. The first guarantees secrecy of a message, while the latter protects its integrity. We propose a technique based on self-encrypting code to protect software against static analysis and tampering attacks. We will present the concept of code encryption, which offers confidentiality, and a method to create code dependencies that implicitly protects integrity of the code.

Defined during the '80s by Yao, Secure Multiparty Computation is the scenario where a set of users wants to compute a function of their inputs, without disclosing them. General solutions exist for the 2 or n participants case, and they will be introduced during this talk.

The remote trust problem aims to address the problem of verifying the execution of a program running on an untrusted host which communicates regularly with a trusted server. One proposed solution to this problem uses a centralized scheme using assertions and replication to withhold usable services from tampered client. We show how to extend such a scheme to a distributed trusted hardware such as tamper-resistant smartcards. We compared the performance and security of proposed distributed system to the original centralized scheme on a case study. Our results indicate that compared to a centralized scheme, our distributed trust scheme has dramatically lower network traffic, and smaller memory and computational requirements on the server.

We investigate "software hardening", for secure execution on an untrusted server, as required for many applications. The common approach to such problems is to use an obfuscator. We present White Box Remote Procedure Call (WBRPC), an alternative definition of hardening mechanism, and argue that it may provide a better fit for important applications, including grid computing, software agents, private databases and more. We define several security specifications for WBRPC, protecting client (sending request to the untrusted server) and server, and addressing both confidentiality (indistinguishability) and integrity (unforgeability). Barak et al. showed, that some programs cannot be obfuscated. We believe there is reason to hope that, in contrast, all programs can be white-boxed. Specifically, we present a "universal WBRPC"; namely, if there is an obfuscator (or WBRPC) for the universal WBRPC, then there is a WBRPC for all programs. Finally, we present a combiner, with input two candidate WBRPC implementations W1, W2, and output a third candidate W3 = W1 o W2. We show that this combier is robust for WBRPC, namely, W3 is secure as long as either W1 or W2 is secure.

White Box Cryptography is a technique for hiding a cryptographic key in the software implementation of a cryptographic algorithm. The presentation shows how White Box Cryptography can be used to create secure storage. Applications are for example secure smart card storage and protection of intellectual property in embedded devices.

A lot of progress has been made to secure network communication, e.g., through the use of cryptographic algorithms. However, this offers only a partial solution as long as the communicating end points still suffer from security problems. A number of applications require remote verification of software executing on an untrusted platform. Trusted computing solutions propose to solve this problem through software and hardware changes, typically a secure operating system and the addition of a secure coprocessor respectively. On the other hand, timed execution of code checksum calculations aims for a solution on legacy platforms, but can not provide strong security assurance. We present a mixed solution by using the trusted computing hardware, namely the time stamping functionality of the trusted platform module, in combination with a timing based remote code integrity verification mechanism. In this way, we do not require a secure operating system, but at the same time the overall security of the timed execution scheme can be improved.

We survey the topic of obfuscating programs from a cryptographic perspective. In a nutshell, obfuscating a program means transforming the program code such that it still provides the desired functionality, but in a way that hides the way how functionality is achieved. Besides the obvious practical application of protecting software know-how against reverse engineering, this concept has also important theoretic applications.
We start off with Barak et al.'s celebrated result that obfuscating programs is impossible for arbitrary classes of programs. We then give an overview over the program classes which are currently known to allow for an obfuscation. The mentioned results are achieved with respect to different definitions of obfuscation, so we will also go into technical difficulties and proposed solutions to defining obfuscation in the first place.