T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level Property based and Semantic Remote Attestation T Special Course in OS Security (Dan Forsberg) Two possible steps from integrity-based remote attestation to the next level: 1.Sadeghi, Ahmad-Reza and Christian Stüble (2005 ). “Property-based attestation for computing platforms: caring about properties, not mechanisms”, Proc. of the 2004 NSP, Nova Scotia, Canada ACM Press: Vivek Haldar, Deepak Chandra, and Michael Franz, “Semantic Remote attestation: A Virtual Machine Directed Approach to Trusted Computing”, USENIX Virtual Machine Research and Technology Symposium, May 2004; Winner of Best Paper Award (also Technical Report No , School of Information and Computer Science, University of California, Irvine; October 2003) Partly using excellent slides from Haldar’s presentation of the paper (e.g. the slides within the PDF document):

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level Terminology Integrity-based attestation The TCG approach.. Property-based Attestation “A property of a platform describes an aspect of the behaviour of that platform regarding certain requirements, such as security related requirements (e.g. that a platform has built-in measures in accordance to the privacy laws). Hence, different platforms with different components may have different configurations while they may all offer the same properties and consequently fulfill the same requirements”, Sadeghi and Stüble “We say that a configuration C provides the property P. Further, we say that a property P i is compatible to another property P j if P i has the same security-related behaviour as P j ”, Sadeghi and Stüble Semantic Remote Attestation (slides from Haldar et al.) “Using language based virtual machines enables the remote attestation of complex, dynamic, and high-level program properties – in a platform-independent way. We call this semantic remote attestation”, Haldar et al.

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level Problems with Integrity-based Attestation Sadeghi and Stüble (property-based attestation): 1.Platform discrimination (e.g. some platforms can be excluded from business models because of too many variants to check) – leads to enforcement or isolation 2.Existing proposals allow remote attestation parties to get complete information about the hardware and software configuration 3.Data sealing for a certain configuration may be lost when the configuration is updated (upgrades, patches) 4.System backups are not available to other platforms with similar hardware configurations Halder et al. (semantic attestation): 1.Integrity based attestation says nothing about program behavior 2.It is static, inexpressive and inflexible 3.How to cope with upgrades and patches (e.g. version control)? 4.How to manage with the heterogeneity of devices/platforms? 5.Revocation of the TPM?

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level Ideal Model of “Property-based Attestation” Sadeghi and Stüble

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level Ideal Property-based Attestation Mechanism Reqs. 1.“Security: The ideal TC only attests certified platform configurations.” 2.“Accountability: Although the TTP has to be trusted by all participants, it is desirable to be able to detect TTP's misbehavior.” 3.“Revokeability: The TTP should be able to selectively revoke TCG versions and TCG realizations under certain circumstances, e.g., if TPM has been broken.” 4.“Non-Discrimination: Challengers should neither be able to favor selected configurations nor should they get information about the configuration of the user platform.” 5.“Unlinkability: Challengers should not be able to link two different attestation sessions.” 6.“Availability: When modifying a platform configuration without changing the provided properties, access to sealed data should be possible.” 7.“Privacy: Users should be able to control which property their platforms attest.” 8.“Reduced Complexity: Security enhancements to U should not be costly. Thus, the complexity of potentially required TCG-extensions should be low.” TTP = Trusted Third Party

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level But…. In Practice Not Possible Proof-carrying code could be one starting point or possibility… “Today, not even content providers are able to formally specify the demanded properties, as it would be necessary to use proof carrying code or formal analysis” … also how to analyze the whole operating system etc.

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level  Real World Trusted Computing (TC) Component?

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level Property-based Attestation Using Certificates Procedure: 1.TPM receives: a)Demanded property: P b)A public key of TTP that is trusted by the challenger: PK TTP. c)Property certificate: cert(SK TTP, P’, S’) properties P’ are provided/present with configuration S’ d)Nonce r 2.Then TPM verifies the property certificate and whether P’ == P, respectively whether S’ == S 0 3.If positive TPM generates and returns a property based attestation certificate: cert TPM := cert(SK TPM ; P, r) Issues: Fulfills requirement 5 (unlinkability) if CA-based pseudonyms are used and if DAA protocol (Direct Anonymous Attestation) can be used to blind the signature key SK TPM. Certificate revocation becomes an issue (e.g. requirement 3, revocability) Group signatures for fulfilling more requirements… “A group signature scheme allows a group member to sign messages anonymously on behalf of the group” Public group signature key presents a property P, while appropriate private group signature keys generated by TTP represent configurations providing the same property P Fulfills requirements 4 (non-discriminatory) and 5 (unlinkability)

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level … different Sets of Property Profiles Are Possible “Privacy protecting Common Criteria” Created by end-users (?) E.g. fulfills privacy laws. Attested by government (TTP). “Content-protecting profile” Created by the content providers …

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level … advantages and disadvantages Advantages: “The trust model related to the trusted computing platform (TPM) does not change, since the TPM has to be fully trusted anyway. Thus, the requirement 1 (security), 2 (accountability), and 4 (non-discrimination) can be fulfilled.” “Since the realization of property-based attestation within a TPM does not depend on external components, changes to the platform configuration cannot lead to unavailability of sealed data (see requirement 6).” How does this relate to the configuration S 0 ? Disadvantages: “The disadvantage of this approach is the additional complexity of the TPM which makes the TPM more expensive. Nevertheless, the required complexity should be acceptable compared to the complexity of the DAA protocol [7].”

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level If TPM (e.g. hw) extension is not possible?  Extend the TCG Software using Trusted Attestation Service (TAS) Separate Trusted Third Party translates attestation requests into configurations online.. Both, TAS and the OS must be fully trusted…

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level But trusting the whole OS is not realistic…  change the OS

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level  TCB (Trusted Computing Base?) Requirements.. Assumed that TAS takes care of security policy enforcement, not the TCB.. 1.“Protected Domain: The TCB has to prevent that an attacker (e.g., the local user or a concurrent application) can access or manipulate the code or the data of the application (which is similar to overwriting S 0 ). This requirement ensures that the code and the data of the TAS are protected against attacks of concurrent processes.” 2.“Secure Path: The TCB has to provide a secure path between provider and application, e.g., it has to ensure that only the provider's application can access the unsealed content. This requirement ensures that the challenger and the TAS can communicate securely.”

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level Further the Property-based attestation paper discusses about… Solutions without a trusted service software module Based on by proving possession of valid property certificate Configuration blinding.. And TCB updates without loosing the sealing property (e.g. when platform configuration changes) “Update Example: Consider an operating system configuration S 0 that provides P certified by cert TTP := cert (SK TTP ; S 0 ; P). Further, the TAS uses a secret key SK that is bound to the configuration S 0. The update function allows the user of the attestor to bind SK to another configuration S i if the user can provide a certificate that states that S i provides the same properties as S 0.”

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level Semantic Remote Attestation based on trusted VM Let’s see Haldar’s slides instead …

T Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level Different approaches? Different goals?... Integrity attestation: provides proof of running system software configuration – “enforces” system configurations Semantic attestation: provides proof of the system functionality in some level – enforces security policies – also runtime and dynamic property attestation  attests program properties Haldar’s TrustedVM still depends on the integrity attestation of the underlying system Property attestation: provides a list of properties bound to the system by a Trusted Third Party – enforces system properties Integrity attestation of small part of the system, which is trusted to force security policies and configurations The way Microsoft’s NGSCB is heading?