Software attestation Overview of the TCGbased Integrity Measurement

Software attestation Overview of the TCG-based Integrity Measurement Architecture 1

Software • Objective: software should behave in specific way, as it was designed • We should protect software from Tampering: – modify, add or remove software functionalities – Ex: • the attacker wants to change software funtionalities to execute specific operations • the attacker wants to add software functionality to extract some data 2

Approaches • To protect software from tampering we consider two different approaches: – software should provide protection by itself • reasonable for non-critical tasks, ex. A player for watching a DVD on my laptop – a set of mechanisms (hw and sw) able to guarantee software integrity -> Trusted environment • should be necessary for critical tasks, ex. Remote banking application 3

Trusted environment (1) • Every software in the system should behave as it was designed • How verify this condition? • software code measurements? • when? • Who should verify this condition? • the software by itself? 4

Trusted environment (2) • Every software in the system should behave as it was designed • How verify this condition? • software code measurements? OK, how do that? • when? At boot? At run-time? • Who should verify this condition? • the software by itself? KO, the software could be tampered 5

Trusted environment (3) • We should measure application software… • …but for doing that we should firstly measure: – the BIOS (at system startup) – the operating system (at system startup) – … everything has been loaded! (at run-time!) 6

Trusted environment (4) • We should measure application software… • …but for doing that we should measure: – the BIOS (at system startup) could be tampered! – the operating system (at system startup) could be tampered! – … everything has been loaded! (at run-time!) could be tampered! • What can we do? 7

What can we do at system startup? • The Trusted Computing Group (TCG) has defined a set of standards (trusted boot): – to take integrity measures – to store measures in separate coprocessor Trusted Platform Module (TPM) whose state cannot be compromised – the TPM is the root of trust 8

Trusted boot: how it works? • At system power on the control is transfered to an immutable base (root of trust) • The immutable base measures the next part of BIOS: – compute SHA 1 hash over its contents – protect the result by using the TPM functionalities • This procedure is applied recursively until the OS has been bootstrapped 9

Trusted boot: results • The trusted boot is composed by sequential steps • mantains trust chain up to bootstrap loader • after that? What can we do to mantain trust chain? 10

Trusted chain continuum • An OS handles a large variety of executable content: kernel, kernel modules, binaries, shared libraries, etc. • We should measure all…? • Sailer, Zhang, …, propose an Integrity Measurement Architecture to address this problem 11

The Integrity Measurement Architecture – Ideas (1) • Modify GNU/Linux kernel to: – take integrity measurements as soon as executable content is loaded into the system, but before it is executed – keep the ordered list of measurements inside the kernel • Change the TPM role to protect integrity of the in-kernel list 12

The Integrity Measurement Architecture – Ideas (2) • Remote attestation: – to prove to a remote party what software stack is loaded, the system needs to present the TPM state using the TCG attestation mechanisms and the kernel inside list – the remote party can determine whether the list has been tampered 13

Design of an Integrity Measurement Architecture (1) • The Measurement Mechanism (on the attested system): – What parts of the run-time environment should measure, when and how securely maintain the measurements • An Integrity Challenge Mechanism: – Allows authorised challangers to retrieve measurement list, verify freshness and completeness 14

Design of an Integrity Measurement Architecture (2) • An Integrity Validation Mechanism: – For validating that the measurement list is complete, non-tampered and fresh 15

TPM-based Integrity Measurement 16

Results (1) • Experiments: rootkit attack detection – using the lrk 5 (a popular Linux rootkit) – the rootkit substitutes the syslogd – the syslogd signature before and after the rootkit attack are different 17

Results (2) • Performances: – tested with a set of micro-benchmarks – latencies of some system call – the bottleneck is the TPM 18

Considerations (1) • Architecture is non-intrusive and doesn’t prevent system from running malicious programs (only detection!): – some code lines of the GNU/Linux kernel are different • The measurement architecture can be extended to measure structured input data (for ex. configuration files) 19

Considerations (2) • Size of kernel measurements list: – about 250 for web server tasks – about 500 for workstation tasks (writing doc, compiling, web browsing) • Inducing frequent changes in loaded executables files can cause denial of service (due to size of kernel list): – reducing the size of the list : we can’t measure some applications 20

Other approaches • Measurements: – At startup only or at runt-time? • Services/Applications isolation: – using virtualisation technology to isolate different system components/services/applications – virtual machines measurements. . . – If one application of a virtual machine has been tampered we can perform substitution as a reaction. . . 21

References • R. Sailer, X. Zhang, T. Jaeger, and L. Van. Doorn, "Design and Implementation of a TCG-based Integrity Measurement Architecture" Proc. of 13 th USENIX Security Symposium, 2004, pp. 223 -238. 22