Thomas Locher

Johannes Schneider, Thomas Locher

Protecting source code against reverse engineering and theft is an important problem. The goal is to carry out computations using confidential algorithms on an untrusted party while ensuring confidentiality of algorithms. This problem has been addressed for Boolean circuits known as `circuit privacy'. Circuits corresponding to real-world programs are impractical. Well-known obfuscation techniques are highly practicable, but provide only limited security, e.g., no piracy protection. In this work, we modify source code yielding programs with adjustable performance and security guarantees ranging from indistinguishability obfuscators to (non-secure) ordinary obfuscation. The idea is to artificially generate `misleading' statements. Their results are combined with the outcome of a confidential statement using encrypted \emph{selector variables}. Thus, an attacker must `guess' the encrypted selector variables to disguise the confidential source code. We evaluated our method using more than ten programmers as well as pattern mining across open source code repositories to gain insights of (micro-)coding patterns that are relevant for generating misleading statements. The evaluation reveals that our approach is effective in that it successfully preserves source code confidentiality.

Thomas Locher, Sebastian Obermeier, Yvonne-Anne Pignolet

The functionality that distributed ledger technology provides, i.e., an immutable and fraud-resistant registry with validation and verification mechanisms, has traditionally been implemented with a trusted third party. Due to the distributed nature of ledger technology, there is a strong recent trend towards using ledgers to implement novel decentralized applications for a wide range of use cases, e.g., in the financial sector and sharing economy. While there can be several arguments for the use of a ledger, the key question is whether it can fully replace any single trusted party in the system as otherwise a (potentially simpler) solution can be built around the trusted party. In this paper, we introduce an abstract view on ledger use cases and present two fundamental criteria that must be met for any use case to be implemented using a ledger-based approach without having to rely on any particular party in the system. Moreover, we evaluate several ledger use cases that have recently received considerable attention according to these criteria, revealing that often participants need to trust each other despite using a distributed ledger. Consequently, the potential of using a ledger as a replacement for a trusted party is limited for these use cases.