BACKGROUND

Remote Attestation is a technique defined by the Trusted Computing Group (TCG) consortium (http://www.trustedcomputinggroup.org/) to verify a platform's integrity (i.e. whether or not that platform is behaving as expected).

Main use cases are:

  • an user remotely attests a server which is expected to perform critical functions, before sending to it any sensitive data;
  • an administrator wants to periodically monitor the integrity of their servers and be notified when someone tries to attack them.

Differently from policy enforcement, Remote Attestation (and Trusted Boot) do not prevent an action undermining the system's security from being performed, but they can ensure that this event is reliably reported to who is assessing the platform's integrity.

Remote Attestation consists of three main phases:

1) collecting evidence of the platform's integrity (e.g. collecting fingerprints of binaries, shared libraries and configuration files) 2) delivering fingerprints (digests) collected through a protocol which protect that data against tampering 3) evaluating digests (e.g. comparing them with a database of reference values)

PROBLEM

One big issue for verifying the integrity of platform is the necessity to maintain the database of reference values, i.e. the values of files digests known to be good (shipped by the Linux distribution vendor). Although by using NoSQL databases it is possible to keep track of all updates released for a reasonable number of Linux distributions (with 4GB, it is possible to store the SHA1 of files belonging to four distributions), offering a service for querying a database introduces considerable costs in terms of storage and network bandwidth.

SOLUTION

Since the RPM header contains the list of files included in the package and the corresponding MD5 (the RPM format has been extended to support different hash algorithms), instead of querying a central database, the entity in charge of assessing a platform's integrity can fetch reference digest values by downloading the headers of the RPMs installed in the remote platform. The clear advantage of this solution is that the necessary infrastructure is already in place (mirrors of the distribution RPM repository); thus no additional costs are required for querying digests values.

IMPLEMENTATION

The main requirement for verifying a platform integrity is that the digests query is done reasonably fast. Thus, the downloading of requested RPM headers must be done in parallel and with a fast network connection.

The implementation will consist in developing a script that takes in input a list of packages (it can be obtained for example by executing 'rpm -qa' on the remote platform) and build a temporary database locally from fetched RPM headers.

An extension of this work could be to develop a second script that takes in input the digests of files accessed by the platform to be verified (obtained with Integrity Measurement Architecture or IMA, see http://sourceforge.net/p/linux-ima/wiki/Home/) and returns the digests (with the path name of the file accessed) not found in the database built with the first script. This script can be used for example to detect malware running in the platform to be evaluated.

Looking for mad skills in:

Nothing? Add some keywords!

This project is part of:

Hack Week 12

Activity

  • about 4 years ago: rsassu originated Remote Attestation of SLE 12
  • Show History

    Comments

    • rsassu
      about 4 years ago by rsassu | Reply

      Created SUSE Hack Week 12 repository on GitHub.

      Checkout the code at: https://github.com/rsassu/suse-hackweek-12

    Similar Projects

    This project is one of its kind!