This document is a high-level overview of The Cyber Resilient Platforms Program (CyReP) – a Microsoft-led industry initiative to improve the security and resiliency of computers, with particular emphasis on cloud-managed IoT devices. The CyReP Program includes hardware and protocol specifications, as well as open-source software that enables the security features. One of the primary goals of CyReP is to enable a rich ecosystem of hardware and software components that can be used to build systems and devices that meet the requirements of NIST SP-800-193 (DRAFT) “Platform Firmware Resiliency Guidelines.”

This is a draft specification describing processor and/or platform technologies that provide a foundation for device vendors to build cyber-resilient systems. The technologies are general purpose and can be implemented by any platform, processor, or SoC, but a priority is to define technologies that are suitable for IoT devices. The mechanisms in this specification are well suited for constructing systems that meet the requirements of NIST SP-800-193 (DRAFT) “Platform Firmware Resiliency Guidelines.”

Commodity CPU architectures, such as ARM and Intel CPUs, have started to offer trusted computing features in their CPUs aimed at displacing dedicated trusted hardware. Unfortunately, these CPU architectures raise serious challenges to building trusted systems because they omit providing secure resources outside the CPU perimeter.This paper shows how to overcome these challenges to build software systems with security guarantees similar to those of dedicated trusted hardware. We present the design and implementation of a firmware-based TPM 2.0 (fTPM) leveraging ARM TrustZone. Our fTPM is the reference implementation of a TPM 2.0 used in millions of mobile devices. We also describe a set of mechanisms needed for the fTPM that can be useful for building more sophisticated trusted applications beyond just a TPM.

This paper presents the design and implementation of a firmware-based TPM 2.0 (fTPM) leveraging ARM TrustZone. The fTPM is the reference implementation used in millions of mobile devices, and was the first hardware or software implementation to support the newly released TPM 2.0 specification. This paper describes the shortcomings of ARM’s TrustZone for implementing secure service (such as our implementation), and presents three different approaches to overcome them. Additionally, the paper analyzes the fTPM’s security guarantees and demonstrates that many of the ARM TrustZone’s shortcomings remain present in future trusted hardware, such as Intel’s Software Guard Extensions (SGX).

Traditional network authentication systems like Windows’ Active Directory or MIT’s Kerberos only provide for mutual authentication of communicating entities, e.g. a user’s email client interacting with an IMAP server, while the user’s machine is inherently assumed to be trusted. While there have been first attempts to explicitly establish this trust relationship by leveraging the Trusted Platform Module, these provide no means to directly react to potentially relevant changes in the client’s system state. We expand previous designs by binding keys to the current platform state and involving these in the network authentication process, thereby guaranteeing the continued validity of the attestee.

Communication in microkernel-based systems is much more frequent than system calls known from monolithic kernels. This can be attributed to the placement of system services into their own protection domains. Communication has to be fast to avoid unnecessary overhead. Also, communication channels in microkernel-based systems are used for more than just remote procedure calls. In distributed systems, which also have a componentized design, it is state of the art to use tools to generate stubs for the communication between components. The communication interfaces of components are described in an interface definition language (IDL). In contrast to distributed systems, components of a microkernel-based system run on the same architecture and message delivery is guaranteed. In this Thesis, I explore the different kinds of communication, which can be used in microkernel-based systems, as well as their possible representation in IDL. Specifically, I introduce the syntax to describe kernel objects in IDL. I discuss the complexity of IDL compilers and its relation to the complexity of the IDL. Furthermore, I evaluate the performance of the communication stubs generated by different IDL compilers and discuss techniques to minimize performance overhead in generated stubs. I validated these techniques by implementing the Drops IDL Compiler – Dice. Finally, this Thesis presents a mechanism to measure the frequency and performance of invocations of generated communication code. I used this technique to conduct measurements in highly complex systems and introducing the least possible overhead.

We present enforceable component-based realtime contracts, the first extension of component-based software engineering technology that comprehensively supports adaptive realtime systems from specification all the way to the running system.To provide this support, we have extended component-based interface definition languages (IDLs) and component representations in repositories to express realtime requirements for components. The final software, which is assembled from the components, is then executed on a realtime operating system (RTOS) with the help of a component runtime system. RTOS resource managers and the IDL-extensions are based on the same mathematical foundation. Thus, the component runtime system can use information expressed in a component-oriented manner in the extended IDL to derive parameters for the task-based admission and scheduling in the RTOS. Once basic realtime properties can thus be guaranteed, runtime support can be extended to more elaborate schemes that also support adaptive applications (container-managed quality assurance).We claim that this study convincingly demonstrates how component-based software engineering can be extended to build systems with non-functional requirements.

We presentenforceable component-based realtime contracts, the first extension of component-based software engineering technology that comprehensively supports adaptive realtime systems from specification all the way to the running system. To provide this support, we have extended component-based interface definition languages (IDLs) and component representations in repositories to express realtime requirements for components. The final software, which is assembled from the components, is then executed on a realtime operating system (RTOS) with the help of a component runtime system. RTOS resource managers and the IDL-extensions are based on the same mathematical foundation. Thus, the component runtime system can use information expressed in a component-oriented manner in the extended IDL to derive parameters for the task-based admission and scheduling in the RTOS. Once basic realtime properties can thus be guaranteed, runtime support can be extended to more elaborate schemes that also support adaptive applications ( container-managed quality assurance). We claim that this study convincingly demonstrates how component-based software engineering can be extended to build systems with non-functional requirements.

In this paper we describe a solution to the problem of communication between real-time and non-real-time components in a split container architecture. The split architecture carries forward an experience we gained in the The Dresden Real-Time Operating System Project (DROPS) [8]: Often, only small parts of applications need to be real-time capable. Furthermore, often these parts require only a small fraction of the complex services, which the remainder of the application needs. Therefore, we proposed the splitting of applications in these two parts, whereas the small real-time part runs directly on our fast real-time capable L4 microkernel and the remainder runs on a off-the-shelf operating system [14]. Consequently, using this approach for a component-container architecture, we can support real-time components and standard components in one system. In this paper we focus on the connections between both component types. We draft a buffer component which represents a non-real-time component in the real-time container. This component allows using non-real-time component’s complex services from real-time components, without giving up the real-time.

Component-based applications require runtime support to be able to guarantee non-functional properties. This report proposes an architecture for a real-time-capable, component-based runtime environment, which allows to separate non-functional and functional concerns in component-based software development. The architecture is presented with particular focus on three key issues: the conceptual architecture, an approach including implementation issues for splitting the runtime environment into a real-time-capable and a real-time-incapable part, and details of contract negotiation. The latter includes selecting component implementations for instantiantion based on their non-functional properties. A shorter version of this technical report appears in the proceedings of the WICSA-4 [10]

Component-based applications require runtime support to be able to guarantee non-functional properties. This paper proposes an architecture for a real-time-capable, component-based runtime environment, which allows to separate non-functional and functional concerns in component-based software development. The architecture is presented with particular focus on the real-time-non-real-time split of the runtime environment and the communication issues of respective component types and container parts.

Eine Komponente bietet einerseits quantitative Eigenschaften anderen Komponenten an, andererseits kann sie quantitative Eigenschaften anderer Komponenten nutzen. Zur Laufzeit müssen sich zwei Komponenten auf konkrete Eigenschaften dieser Beziehung festlegen und darüber einen Vertrag schließen. Dieser Vertrag beinhaltet, dass die nutzende Komponente sich auf Zusagen der anbietenden Komponente verlassen kann und diese ihre Leistungen mit den garantierten quantitativen Eigenschaften erfüllt. Dies gilt unter der Voraussetzung, dass wiederum Verträge, welche sie mit von ihr genutzten Komponenten geschlossen hat, eingehalten werden.Kann zu irgendeinem Zeitpunkt die anbietende Komponente den Vertrag nicht mehr erfüllen, besteht eine mögliche Reaktion auf die Vertragsverletzung in der Adaption des Vertrages. Dazu müssen beide Komponenten mit den neuen Bedingungen …