The goal of this Dagstuhl Seminar is to establish a common understanding of principles and techniques that can facilitate composition and integration of hardware systems to achieve specified security guarantees. Theoretical foundations of secure composition have been laid out in the past, but they are limited to software systems. New and unique security challenges arise when a real system composed of a range of hardware components, including application-specific blocks, programmable microcontrollers, and reconfigurable fabrics, is put together. For example, these components may have different owners, different trust assumptions and may not even have a common language to describe their security properties to each other. Physical and side-channel attacks that take advantage of various physical properties to undermine a system’s security objectives add another level of complexity to the secure composition problem. Moreover, practical hardware systems include software of tremendous size and complexity, and hardware-software interaction can create new security challenges.

The seminar will consider secure composition both from a pure hardware perspective, where multiple hardware blocks are composed in, e.g., a system on chip (SoC), and from a hardware-software perspective where hardware is integrated within a system that includes software. Examples of relevant research questions are:

• What are relevant security properties for hardware-software systems and their parts? This inclu-des properties at different abstraction levels, from hardware to software, system, and application.
• What models and description languages are useful for the formalization of security properties?A central question is how to make interoperable formalisms for different abstraction levels.
• Which protocol-level secure composition methods are applicable in hardware domain? Can we apply the existing theory of “universally composable security” to hardware-software systems?
• Can trust start in software, or are hardware roots and anchors of trust indispensable? If extra hardware is used, does it suffice to have dedicated “root of trust” modules for, e.g., key storage, or do we need to re-design major parts of the system’s mission hardware with security in mind?
• Who owns the security of a system’s hardware (e.g., secret keys), and who drives security? How and why would component designers, hardware architects, software developers, etc. collaborate?
• Under what circumstances is security additive, and how can this be proven and validated? How can we know that different countermeasures strengthen, or at least do not contradict, each other?
• How can existing hardware fulfill expectations and idealistic assumptions of protocols? How can we verify that available hardware indeed fulfills protocol-level requirements (e.g., perfect random number generation) and does not compromise security by implementation weaknesses?
• How to counter possible loss of security due to the abstraction of hardware components? Can we develop the notion of “secure abstraction”, which enforces that no security vulnerability will be added during system design by implementation details invisible on more abstract level?

The seminar will bring together researchers and industry practitioners from fields that have to deal with secure composition: secure hardware architectures, hardware-oriented security, applied cryptography, test and verification of security properties. By involving industrial participants, we hope to get insights on real-world challenges, heuristics, and methodologies employed to address them and initiate a discussion towards new solutions.

Creative Commons BY 3.0 DE

Arora Divya, Ilia Polian, Francesco Regazzoni, and Patrick Schaumont

• Divya Arora (Intel - Santa Clara, US) [dblp]
• Georg T. Becker (ESMT - Berlin, DE) [dblp]
• Yaacov Belenky (Intel Israel - Haifa, IL) [dblp]
• Shivam Bhasin (Nanyang TU - Singapore, SG) [dblp]
• Ran Canetti (Tel Aviv University, IL) [dblp]
• Gaetan Cassiers (University of Louvain, BE) [dblp]
• Anupam Chattopadhyay (Nanyang TU - Singapore, SG) [dblp]
• Jean-Luc Danger (Telecom ParisTech, FR) [dblp]
• Lucas Davi (Universität Duisburg-Essen, DE) [dblp]
• Elke De Mulder (Rambus - Sunnyvale, US) [dblp]
• Elena Dubrova (KTH Royal Institute of Technology - Stockholm, SE) [dblp]
• Yunsi Fei (Northeastern University - Boston, US) [dblp]
• Fatemeh Ganji (University of Florida - Gainesville, US) [dblp]
• Tim Erhan Güneysu (Ruhr-Universität Bochum, DE) [dblp]
• Annelie Heuser (IRISA - Rennes, FR) [dblp]
• Johann Heyszl (Fraunhofer AISEC - München, DE) [dblp]
• Elif Bilge Kavun (University of Sheffield, GB) [dblp]
• Osnat Keren (Bar-Ilan University, IL) [dblp]
• Johann Knechtel (New York University - Abu Dhabi, AE) [dblp]
• Itamar Levi (University of Louvain, BE) [dblp]
• Michail Maniatakos (New York University - Abu Dhabi, AE) [dblp]
• Marcel Medwed (NXP Semiconductors - Gratkorn, AT) [dblp]
• Nele Mentens (KU Leuven, BE) [dblp]
• Johannes Mittmann (BSI - Bonn, DE) [dblp]
• Debdeep Mukhopadhyay (Indian Institute of Technology - Kharagpur, IN) [dblp]
• Paolo Palmieri (University College Cork, IE) [dblp]
• Ilia Polian (Universität Stuttgart, DE) [dblp]
• Milos Prvulovic (Georgia Institute of Technology - Atlanta, US) [dblp]
• Wenjing Rao (University of Illinois - Chicago, US) [dblp]
• Francesco Regazzoni (University of Lugano, CH) [dblp]
• Ahmad-Reza Sadeghi (TU Darmstadt, DE) [dblp]
• Kazuo Sakiyama (The University of Electro-Communications - Tokyo, JP) [dblp]
• Fareena Saqib (University of North Carolina - Charlotte, US) [dblp]
• Patrick Schaumont (Virginia Polytechnic Institute - Blacksburg, US) [dblp]
• Werner Schindler (BSI - Bonn, DE) [dblp]
• Georg Sigl (TU München, DE) [dblp]
• Dey Soumyajit (Indian Institute of Technology - Kharagpur, IN) [dblp]
• Marc Stöttinger (Continental AG - Frankfurt, DE) [dblp]
• Shahin Tajik (University of Florida - Gainesville, US) [dblp]
• Marten Van Dijk (University of Connecticut - Storrs, US) [dblp]
• Ingrid Verbauwhede (KU Leuven, BE) [dblp]