1 Lecture Embedded System Security Prof. Dr.-Ing. Ahmad-Reza Sadeghi System Security Lab Technische Universität Darmstadt (CASED) Summer Term 2012
Roadmap: Trusted Computing Motivation Notion of trust Trusted Computing Group (TCG) approach Basic TCG concepts Chain of trust Integrity measurements Slide Nr. 2, Embedded System Security, SS 2012
The Big Picture Trustworthiness in distributed IT systems Different parties with potentially conflicting requirements involved Cryptographic methods are of limited help The challenges How to define trustworthiness? How to determine/verify trustworthiness? How could common computing platforms support such functionality? Even a secure OS cannot verify own integrity The role of Trusted Computing Enable the reasoning about trustworthiness of own and other s IT system Slide Nr. 3, Embedded System Security, SS 2012
Demand for Trusted Computing Improve security of existing IT Systems Malware, phishing, etc. Increasing threats for IT systems Inflexibility of traditional secure systems Reference monitors Improve existing IT infrastructures (e.g., VPN) Enable new applications with sophisticated (security) requirements Slide Nr. 4, Embedded System Security, SS 2012
Possible Use-Cases E-Services Government (e.g., e-voting integrity) Health (e.g., confidentiality of sensitive medical records) Commerce (e.g., enforceability of digital signatures) Online banking Digital/enterprise rights management and copyright protection Mobile computing Slide Nr. 5, Embedded System Security, SS 2012
Roadmap: Trusted Computing Motivation Notion of trust Trusted Computing Group (TCG) approach Basic TCG concepts Chain of trust Integrity measurements Slide Nr. 6, Embedded System Security, SS 2012
Vocabulary I Trust Complicated notion studied and debated in different areas (social sciences, philosophy, psychology, computer science, ) Notion relating to belief in honesty, truthfulness, competence, reliability, etc. of the trusted entity Social Trust: Belief in the safety or goodness of something because of reputation, association, recommendation, perceived benefit Slide Nr. 7, Embedded System Security, SS 2012
Vocabulary II Meanings (an attempt) Secure: System or component will not fail with respect to protection goals Trusted: System or component whose failure can break the (security) policy (Trusted Computing Base, TCB) Trustworthy: Degree to which the behavior of a component or system is demonstrably compliant with its stated functionality Trusted Computing Group (TCG) defines a system as trusted if it always behaves in the expected manner for the intended purpose. Slide Nr. 8, Embedded System Security, SS 2012
Basic Idea for Trusted Platform Trusted components in hardware and software Provides a variety of trusted functions In particular a set of cryptographic and security functions Ideally creates a foundation of trust for software Provides hardware protection for sensitive data e.g., keys, counters, etc. Desired goals in practice Trusted Computing Base (TCB) should be minimized Compatibility to commodity systems Application Application Application Application Operating System (OS) Hardware OS Hardware Trusted Component Trusted Component Conventional Platform Slide Nr. 9, Embedded System Security, SS 2012 Trusted Platform
General Objective: Multilateral Security Considers different and possibly conflicting security requirements of different parties and strives to balance these requirements Refers to (classical) security goals Confidentiality, integrity, availability, etc. Typical conflict occurs between the wish for privacy and the interest in cooperation Slide Nr. 10, Embedded System Security, SS 2012
Problems Insufficient protection in SW and HW of existing computing platforms Malicious code (viruses, Trojan horses, etc.) DMA (Direct Memory Access) No secure storage Main reasons High complexity and poor fault isolation of operating systems Lack of functional and protection mechanisms in hardware Security unawareness of users or security measures still not useable enough Slide Nr. 11, Embedded System Security, SS 2012
Primary Goals in Practice Improve security of computing platforms Reuse existing modules GUI, common OS, etc. Applicable for different OS No monopoly, space for innovation (small and mid-sized companies) Open architecture Use open standards and open source components Trustworthiness, costs, reliability, compatibility Efficient portability Allow realization of new applications/business models Providing security needed for underlying applications (based on various sets of assumptions and trust relations) Avoiding potential misuse of trusted computing functionalities Slide Nr. 12, Embedded System Security, SS 2012
Desired Primitives 1. Metric for code configuration/identity I/O behavior of a machine based on an initial state Example of a simple metric: Hash value of binary code Problematic when code functionality depends on other code not included in hash digest (e.g., shared or dynamically linked libraries) 2. Integrity verification (Attestation) Allows computing platform to export verifiable information about its properties (e.g., identity and initial state) Comes from the requirement of assuring the executing image and environment of an application located on a remote computing platform Slide Nr. 13, Embedded System Security, SS 2012
Desired Primitives (cntd.) 3. Secure storage Securely stores data on traditional untrusted storage (e.g. hard disks) Encrypts data and assures that no other entity can decrypt it 4. Strong process isolation Assures process (memory space) separation Prevents a process from reading or modifying another process memory 5. Secure I/O Allows applications to assure the endpoints of input and output operations Assures to the user that he securely interacts with the intended application Slide Nr. 14, Embedded System Security, SS 2012
Need for Secure Hardware and Software Hardware Even a secure operating system cannot verify its own integrity Another party is needed Secure storage DMA control Isolation of security-critical programs Hardware-based random numbers Fundamental to cryptography Software (operating systems) Hardening (e.g., SE Linux) Still too complex and too large TCB (Trusted Computing Base) Complete new design (e.g., EROS) Compatibility problem, less market acceptance Secure Virtual Machine Monitors Allow reuse of legacy software Slide Nr. 15, Embedded System Security, SS 2012
Roadmap: Trusted Computing Motivation Notion of trust Trusted Computing Group (TCG) approach Basic TCG concepts Chain of trust Integrity measurements Slide Nr. 16, Embedded System Security, SS 2012
Trusted Computing Group (TCG) Consortium of IT-Enterprises (since April 2003) Today more than 100 members www.trustedcomputinggroup.org Focus on development of hardware-enabled trusted computing and security technology across multiple platforms and devices Evolved from Trusted Computing Platform Alliance (TCPA) Formed by Hewlett-Packard (HP), Compaq (today part of HP), IBM, Intel and Microsoft in January 1999 Has published many specifications on Trusted Platforms and Infrastructures Slide Nr. 17, Embedded System Security, SS 2012
TCG Main Specifications Trusted Platform Module (TPM) Provides a set of immutable cryptographic and security functions Trusted Software Stack (TSS) Issues low-level TPM requests and receives low-level TPM responses on behalf of higher-level applications Slide Nr. 18, Embedded System Security, SS 2012
Chain of Trust Consider Entities E 0,, E n Goal is to gain trust in entity E n Operational standpoint: E 0 launches E 1, E 1 launches E 2, etc. To trust E n one must trust E n 1 The sequence E 0, E 1 to E n creates a chain of trust Transitive trust from E 0 to E 1 to E 2, etc. Trusting E 2 requires one to trust E 0 and E 1 However: Trusting E 0 does not imply that one must trust E 2 Entity E 0 Entity E 1 Entity E 2 Entity E n Slide Nr. 19, Embedded System Security, SS 2012
Chain Measurement What is needed to trust the chain The identity of each entity E i in the chain Identity = measurement (according to TCG definition) For instance the hash digest of the binary code of E i Generic flow: Each entity E i measures its successor E i+1 before passing control to it Who measures E 0? Root of Trust for Measurements (RTM) Must be trusted, no mechanism to measure E 0 To create a chain of trust the first entity E 0 must be the RTM RTM Entity E 0 Entity E 1 Entity E 2 Entity E n Slide Nr. 20, Embedded System Security, SS 2012
Performing Integrity Measurements RTM 3. SM (Security Module) Registers 2. 4. 1. Entity E SM Event Log One Event Structure per measurement Event Structure Extend Value (digest of E) Extend Data (information about E) Slide Nr. 21, Embedded System Security, SS 2012 1. RTM measures entity E 2. RTM creates Event Structure in SM Event Log SM Event Log contains the Event Structures for all measurements extended to the SM SM Event Log can be stored on any (untrusted) storage device (e.g. hard disk) 3. RTM extends measurement value into SM registers 4. RTM executes/passes control to entity E
Abstract Model of TCG Concept Trusted Platform P Provides integrity of host H Host H (untrusted) Firmware Operating system Applications D execute(c H ) Attestor A Trusted component (hard- and software) Securely stores C H RTM challenge response Attest(Hash(C H )) Bind(Hash(C H ), D) init(c H ) Challenger / Verifier Verifier V Local or remote Can decide whether C H violates its security requirements Can bind/seal data D to a specific (probably secure) configuration/state of H Attest: Verify system integrity Bind/Seal: Access control depending on system configuration C H - initial configuration/state of host H when platform P has been booted D - data to be revealed only if host H is in the (secure) configuration C H User / Adversary insecure channel secure channel
Concerns About TCG Approach Potential basis for Digital Rights Management (DRM) Less freedom Including freedom of choice and user control Privacy violation Disclosure of platform identity and configuration Confusing language Trust, control, opt-in, etc. Core specifications not really readable Leads to misunderstanding Potentially restricting competition Misuse of sealed storage capabilities, locking out alternative applications and inhibiting interoperation Much of the criticism related to Microsoft s NGSCB NGSCB = Next Generation Secure Computing Base Several name changes Palladium, NGSCB, Longhorn, Vista Bad publicity or legal challenges on rights to the names Slide Nr. 23, Embedded System Security, SS 2012
Some Legal Requirements on TC/TCG Prevent confusion and clarify terms Trust, trusted, trustworthy, thread model, etc. Privacy issues (user, platform, ) Application and design of new technologies should be privacy compliant by default Unrestricted user control e.g., over keys and IT technology Transparency of certification Option for transferring secrets between different machines Functional separation of TPM and CPU/chipsets Product discrimination TC/DRM should not adversely affect security of government-held information Slide Nr. 24, Embedded System Security, SS 2012