Note: ACSAC2014 attendees looking for more information on the ICE work, may feel more at home at this location

Internet-connected devices are under constant attack. While research projects attempting to harden applications and the kernel are important, their sheer size makes it unlikely that they can ever be made secure enough to prevent infection. We take an alternative approach. We allow security sensitive parts of an application to be placed in self-protected modules (SPMs). Using a simple program counter based access control mechanism (PCBAC), SPMs execute in complete isolation from the rest of the system. Moreover, the code placed in an SPM has complete control over its own secrets. This enables the creation of SPMs with strong security guarantees, even in the event of kernel-level malware. An SPM protecting a cryptographic key, for example, can easily provide an encrypt/decrypt service while guaranteeing that the key itself is never leaked.

Protected-module architectures, provide an interesting alternative by isolating the execution of software modules. To minimize the amount of code that provides support for the protected-module architecture, persistent storage of (confidentiality and integrity protected) states of modules can be delegated to the untrusted operating system. But precautions should be taken to ensure state continuity: an attacker should not be able to cause a module to use stale states (a so-called rollback attack}), and while the system is not under attack, a module should always be able to make progress, even when the system could crash or lose power at unexpected, random points in time (i.e., the system should be crash resilient). Such considerations can be provided using orthogonal systems/algorithms. The interested reader is referred to the state-continuous execution page.

In order to provide an secure and easy to use system, we focus on three aspects:

Complete isolation of modules from the possibly infected kernel and application code is only useful if the module itself is implemented correctly. At KU Leuven, Bart Jacobs et al. developed a source code verification tool called Verifast. The application is available for download here

While verification of source code is an important property, it does not guarantee that the compiled version is also secure. An attacker with low-level access is more powerful than an attacker that can only interact with the module at source code level. Consider as an example a module storing a cryptographic key. It may be easy to verify that this key never leaks to an attacker that is interacting with the module at source code level (e.g. the getKey() function is marked as private). At assembly level however, such access restrictions do not exist and an attacker may directly access the memory locations that store the key.

This work present a secure (fully abstract) compilation scheme to compile a high-level language to low-level machine code. Roughly speaking, fully abstract compilation guarantees that when there are no attacks against the module at a high-level language, then there also does not exist a low-level attack against the system. To provide such strong guarantees, we apply a program counter based access control mechanism

Agten et al. were the first to show that fully abstract compilation of a safe high-level programming language to untyped machine code is possible. One limitation of their is that it only considers a simple high-level language. In subsequent work, Patrignani et al. show how essential programming language features can be securely compiled to the same low-level machine model of Agten et al.

Secure Compilation to Modern Processors Pieter Agten, Raoul Strackx, Bart Jacobs and Frank Piessens IEEE 25th Computer Security Foundations Symposium (CSF 2012)
We present a secure (fully abstract) compilation scheme to compile a high-level language to low-level machine code. Full abstraction is achieved by relying on the virtualization support provided by modern processors: a small hypervisor efficiently implements fine-grained memory access control, and this gives the low-level language sufficient protection features to serve as a target for the fully abstract compilation of a simple Java-like language. We formalize high-level and low-level languages and prove full abstraction for our compilation algorithm. We also show by means of an implementation that our low-level language with fine-grained memory access-control can be realized efficiently on modern commodity platforms.
@inproceedings{agten2012fullabstraction, author = {Pieter Agten and Raoul Strackx and Bart Jacobs and Frank Piessens}, title = {Secure Compilation to Modern Processors}, journal = {Computer Security Foundations Symposium, IEEE}, booktitle = {2012 IEEE 25th Computer Security Foundations Symposium (CSF 2012)}, isbn = {978-1-4673-1918-8}, issn = {1940-1434}, ar = {2012}, pages = {171-185}, doi = {http://doi.ieeecomputersociety.org/10.1109/CSF.2012.12}, publisher = {IEEE Computer Society}, address = {Los Alamitos, CA, USA}, url = {https://lirias.kuleuven.be/handle/123456789/358154}, }
Secure Compilation of Object-Oriented Components to Protected Module Architectures Marco Patrignani, Dave Clarke and Frank Piessens Asian Symposium on Programming Languages and Systems (APLAS'13)
A fully abstract compilation scheme prevents the security features of the high-level language from being bypassed by an attacker operating at a particular lower level. This paper presents a fully abstract compilation scheme from a realistic object-oriented language with dynamic memory allocation, cross-package inheritance, exceptions and inner classes to untyped machine code. Full abstraction of the compilation scheme relies on enhancing the low-level machine model with a fine-grained, program counter-based memory access control mechanism. This paper contains the outline of a formal proof of full abstraction of the compilation scheme. Measurements of the overhead introduced by the compilation scheme indicate that it is negligible.
@inproceedings{patrignani2013scoo, author = {Patrignani, Marco and Clarke, Dave and Piessens, Frank}, title = {{Secure Compilation of Object-Oriented Components to Protected Module Architectures}}, year={2013}, pages={176-191}, booktitle={Proceedings of the 11th Asian Symposium on Programming Languages and Systems (APLAS'13)}, location={Melbourne, Australia}, series={LNCS}, volume={8301}, }

To support secure, local communication between SPMs, we enforce a specific access control model. Every SPM is devided in a Public and Protected Data section. The Public section contains information that is non-confidential and should only be integrity-protected. This includes all the module's code as well as certain constant values used such as strings. Once the module is protected, the contents of this section can no longer be modified, it can only be read and/or executed. Read access to the Public section is allowed, from other modules as well as from unprotected code.

Each SPM comes with a list of entry points as metadata. The entries in this list contain memory locations in the Public section that are valid entry points into the SPM. The platform (e.g. a hypervisor or a hardware implementation) will guarantee that execution can enter an SPM only by jumping to an entry point. This protects against attacks that try to skip security-checks in the SPM, or against attacks that try to extract information from the SPM by selectively executing code snippets in the SPM.

The following table summarizes enforced the access control rules. It shows for instance that only code in the Public section of an SPM can read or write memory in the Protected Data section of the same SPM, and that code in unprotected memory or other SPM's can read the Public section of an SPM, or can execute an address that is an entry point of the SPM (this execution of the instruction at the entry point will then lead to a change in privileges, as from this point on, the program counter is within the SPM).

from / to Entry point Public Prot. Data unprot.
Entry pnt. --- --x --- ---
Public rx r-x rw- rwx
Prot. Data --- --- --- ---
Unprot/other SPM rx r-- --- rwx

The access matrix also shows that only the Public section contains executable machine code. As this section is readable from other modules (and from unprotected code), the authenticity of a module can be verified easily: if we identify a module by the hash of its Public section, the authenticated identity of a module can be computed by reading and hashing the Public section of the module.

Fides - A Hypervisor-Based Implementation

Implementing the program counter based access control mechanism completely in software would result in a huge performance cost as it would require checking the access rights for every memory access. Instead, we developed a hypervisor-based implementation using standard memory management units. This enables the creation of isolated modules on commodity systems with similar security guarantees against software-based attackers as Intel SGX. We also address issues like how SPMs can be updated and how their correct execution can be attested to a remote third party. Given the similarities between Fides (or PCBAC in general) and SGX, we plan to port our toolchain to SGX once SGX-enabled platforms are freely available.

The Fides Suite can be downloaded here

Fides: Selectively hardening software application components against kernel-level or process-level malware Raoul Strackx and Frank Piessens ACM conference on Computer and Communications Security (CCS 2012)
Protecting commodity operating systems against software exploits is known to be challenging, because of their sheer size. The same goes for key software applications such as web browsers or mail clients. As a consequence, a significant fraction of internet-connected computers is infected with malware. To mitigate this threat, we propose a combined approach of (1) a run-time security architecture that can efficiently protect fine-grained software modules executing on a standard operating system, and (2) a compiler that compiles standard C source code modules to such protected binary modules. The offered security guarantees are significant: relying on a TCB of only a few thousand lines of code, we show that the power of arbitrary kernel-level or process-level malware is reduced to interacting with the module through the module's public API. With a proper API design and implementation, modules are fully protected. The run-time architecture can be loaded on demand and only incurs performance overhead when it is loaded. Benchmarks show that, once loaded, it incurs a 3.22% system-wide performance cost. For applications that make intensive use of protected modules, and hence benefit most of the security guarantees provided, the performance cost is up to 14%.
@inproceedings{strackx2012fides, author = {Strackx, Raoul and Piessens, Frank}, title = {Fides: Selectively hardening software application components against kernel-level or process-level malware}, booktitle = {Proceedings of the 19th ACM conference on Computer and Communications Security (CCS 2012)}, year = {2012}, month = {October}, keywords = {SPM, Fides, full abstraction}, url = {https://lirias.kuleuven.be/handle/123456789/354603}, localfile = {2012/Strackx - Fides: Selectively hardening software application components against kernel-level or process-level malware.pdf} }

Sancus - A Hardware Implementation

While a hypervisor-based implementation provides obvious advantages on commodity systems with already hardware support for virtualization, adding such support to low-end, resource-constrained devices is infeasible. In this work we show that a hardware implementation of PCBAC enables strong security guarantees without any software in the TCB on the device, and with only minimal hardware extensions. Our attacker model assumes that an attacker has complete control over the software state of a device, and even for such attackers our security architecture ensures that any results a party receives from one of its modules can be validated to be genuine.

The Sancus project page can be found here

Sancus: Low-cost trustworthy extensible networked devices with a zero-software Trusted Computing Base Job Noorman, Pieter Agten, Wilfried Daniels, Raoul Strackx, Anthony Van Herrewege, Christophe Huygens, Bart Preneel, Ingrid Verbauwhede, Frank Piessens Proceedings of the 22nd USENIX conference on Security symposium (Usenix'13)
In this paper we propose Sancus, a security architecture for networked embedded devices. Sancus supports extensibility in the form of remote (even third-party) software installation on devices while maintaining strong security guarantees. More specifically, Sancus can remotely attest to a software provider that a specific software module is running uncompromised, and can authenticate messages from software modules to software providers. Software modules can securely maintain local state, and can securely interact with other software modules that they choose to trust. The most distinguishing feature of Sancus is that it achieves these security guarantees without trusting any infrastructural software on the device. The Trusted Computing Base (TCB) on the device is only the hardware. Moreover, the hardware cost of Sancus is low. We describe the design of Sancus, and develop and evaluate a prototype FPGA implementation of a Sancus-enabled device. The prototype extends an MSP430 processor with hardware support for the memory access control and cryptographic functionality required to run Sancus. We also develop a C compiler that targets our device and that can compile standard C modules to Sancus protected software modules.
@inproceedings{noorman2013sancus, title = "Sancus: {L}ow-cost trustworthy extensible networked devices with a zero-software trusted computing base", author = {Job Noorman and Pieter Agten and Wilfried Daniels and Raoul Strackx and Anthony Van Herrewege and Christophe Huygens and Bart Preneel and Ingrid Verbauwhede and Frank Piessens}, booktitle = "22nd USENIX Security Symposium, ", publisher = "USENIX Association", month = Aug, year = "2013", url = "https://lirias.kuleuven.be/handle/123456789/402673" }

Salus - A Kernel-Based Implementation

Protected module architectures isolate security-sensitive parts of applications into protected modules, each of which can only be accessed through a predefined public interface. But most parts of an application can be considered security-sensitive at some level, and an attacker that is able to gain in-application level access may be able to abuse services from protected modules. In this work we propose Salus, a Linux kernel modification that provides a novel approach for partitioning processes into isolated compartments. By enabling compartments to restrict the system calls they are allowed to perform and to authenticate their callers and callees, the impact of unsafe interfaces and vulnerable compartments is significantly reduced.

Salus: Non-hierarchical memory access rights to enforce the principle of least privilege Niels Avonds, Raoul Strackx, Pieter Agten, and Frank Piessens Security and Privacy in Communication Networks (SecureComm'13)
Consumer devices are increasingly being used to perform security and privacy critical tasks. The software used to perform these tasks is often vulnerable to attacks, due to bugs in the application itself or in included software libraries. Recent work proposes the isolation of security-sensitive parts of applications into protected modules, each of which can only be accessed through a predefined public interface. But most parts of an application can be considered security-sensitive at some level, and an attacker that is able to gain in-application level access may be able to abuse services from protected modules. We propose Salus, a Linux kernel modification that provides a novel approach for partitioning processes into isolated compartments. By enabling compartments to restrict the system calls they are allowed to perform and to authenticate their callers and callees, the impact of unsafe interfaces and vulnerable compartments is significantly reduced. We describe the design of Salus, report on a prototype implementation and evaluate it in terms of security and performance. We show that Salus provides a significant security improvement with a low performance overhead, without relying on any non-standard hardware support.
@inproceedings{avonds2013salus, title = {Salus: Non-Hierarchical Memory Access Rights to Enforce the Principle of Least Privilege}, author = {Niels Avonds and Raoul Strackx and Pieter Agten and Frank Piessens}, booktitle = {Security and Privacy in Communication Networks (SecureComm'13)}, year = 2013 }