Software attestation

1
Software attestation

• Overview of the TCG-based Integrity Measurement
  Architecture

2
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

3
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 -gt Trusted environment
• should be necessary for critical tasks, ex.
  Remote banking application

4
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?

5
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

6
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!)

7
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?

8
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

9
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 SHA1 hash over its contents
• protect the result by using the TPM
  functionalities
• This procedure is applied recursively until the
  OS has been bootstrapped

10
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?

11
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

12
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

13
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

14
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

15
Design of an Integrity Measurement Architecture
(2)

• An Integrity Validation Mechanism
• For validating that the measurement list is
  complete, non-tampered and fresh

16
TPM-based Integrity Measurement
17
Results (1)

• Experiments rootkit attack detection
• using the lrk5 (a popular Linux rootkit)
• the rootkit substitutes the syslogd
• the syslogd signature before and after the
  rootkit attack are different

18
Results (2)

• Performances
• tested with a set of micro-benchmarks
• latencies of some system call
• the bottleneck is the TPM

19
Considerations (1)

• Architecture is non-intrusive and doesnt 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)

20
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 cant measure
  some applications

21
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...

22
References

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