Transcript slides [pdf]

Property based and Semantic Remote Attestation
2007-03-09 T-110.7200 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: 67-77
2. 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. 03-20, School of Information and Computer Science,
University of California, Irvine; October 2003)
•
1
Partly using excellent slides from Haldar’s presentation of the paper (e.g. the slides within the PDF
document):
2007-03-09 T-110.7200 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 Pi is compatible to another property Pj if Pi has the same security-related
behaviour as Pj”, 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.
2
2007-03-09 T-110.7200 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.
2.
3.
4.
5.
3
Integrity based attestation says nothing about program behavior
It is static, inexpressive and inflexible
How to cope with upgrades and patches (e.g. version control)?
How to manage with the heterogeneity of devices/platforms?
Revocation of the TPM?
2007-03-09 T-110.7200 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
4
2007-03-09 T-110.7200 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
5
2007-03-09 T-110.7200 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.
6
2007-03-09 T-110.7200 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?
7
2007-03-09 T-110.7200 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)
b)
c)
Demanded property: P
A public key of TTP that is trusted by the challenger: PKTTP.
Property certificate: cert(SKTTP, P’, S’)
•
d)
2.
3.
•
•
Then TPM verifies the property certificate and whether P’ == P, respectively whether S’ == S0
If positive TPM generates and returns a property based attestation certificate: certTPM := cert(SKTPM; P, r)
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 SKTPM.
Certificate revocation becomes an issue (e.g. requirement 3, revocability)
Group signatures for fulfilling more requirements…
•
•
•
8
Nonce r
Issues:
•
•
properties P’ are provided/present with configuration S’
“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)
2007-03-09 T-110.7200 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
• …
9
2007-03-09 T-110.7200 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 S0?
• 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].”
10
2007-03-09 T-110.7200 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…
11
2007-03-09 T-110.7200 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
12
2007-03-09 T-110.7200 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 S0). 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.”
13
2007-03-09 T-110.7200 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 S0 that provides P
certified by certTTP := cert (SKTTP; S0; P). Further, the TAS uses a secret key SK that is
bound to the configuration S0. The update function allows the user of the attestor to
bind SK to another configuration Si if the user can provide a certificate that states that
Si provides the same properties as S0.”
14
2007-03-09 T-110.7200 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 …
15
2007-03-09 T-110.7200 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?
16
2007-03-09 T-110.7200 Special Course in OS Security (Dan Forsberg) – Two possible steps from integrity-based remote attestation to the next level