Home

SAMSON

Secure Authentication ModuleS

This project is a set of modules designed to facilitate remote attestation. This work is base of the work done by General Dynamics C4S for the High Assurance Platform, and is based in part on work done by many other projects, including the Integrity Measurement Architecture (IMA) logic (now included in the mainline Linux kernel, since 2.6.30), the trousers library http://sf.net/projects/trousers, freeradius-server <http: freeradius.org="">, wpa_supplicant http://hostap.epitest.fi/wpa_supplicant, and the Trusted Computing Group specifications (http://www.trustedcomputinggroup.org) for IF-PTS, IF-IMC, IF_TNCCS, Reference_Manifest_Schema ), and IntegrityReport_Schema. The freeradius and wpa-supplicant code have extensive changes written by the Applied Physics Lab at Johns Hopkins University.

The problem that remote attestation is designed to solve is verifying that a computer system that is requesting access to a protected asset has not been compromised. Remote attestation will be most effective in an environment where the clients systems are tightly constrained to a fixed set of software, e.g. a corporate environment or government office, where the individual users cannot install their own versions of software, but must use the software provided by a central authority. The clients systems must contain a Trusted Platform Module (TPM) as this is required for the IMA functionality.

Given such an environment, this is done by generating a number of golden measurements for a system when it is in a trusted state (usually immediately following installation of the operating system and software from a trusted source) prior to its being deployed. When the system is bootloaded following installation, the PCRS 0-7 in the TPM will contain a number of values related to the bootload, including a hash of the Master Boot Record, and a HASH of the BIOS code it self. Also immediately following installation, two keys are generated in the TPM, one of them can only be used to sign a TPM Quote, and the other is used only to sign an Integrity Measurement Report (IMR), as well as to sign a verification block. The public portion of the keys as well as the current PCR values are transferred to the attestation server prior to the client system being deployed.

After the client system is deployed, when the client system requests access to the protected asset, a report is generated with the current integrity values and sent to the attestation server, which verifies those measurements against the previously stored values. If the current values do not match the "golden" values, the system is presumed to be compromised and access to the asset is denied. if they match, then access is granted. Most of the effort in remote attestation is to detect is a compromised system is attempting to "fake" a good report in order to gain access to the asset.

The current implementation utilizes the IMA changes to the Linux kernel to "measure" (perform a SHA1 hash) every file prior to its being placed into execution - both executable files and files that are memory mapped for execution. This measurement is stored in a kernel maintained Integrity Measurement List (IML), and the hash value is used to extend PCR10 in the TPM.

When the system requests access to the protected asset, a request is sent from the attestation server for an IMR. This request includes a 20 byte random NONCE (number once). When the client system receives this request, it generates an IMR by requesting a QUOTE from the TPM. This QUOTE will include all of the relevant PCRs, including PCR10, as well as the NONCE. It will be signed by the TPM key reserved for signing QUOTEs. The IMR will also include the entire IML. This IMR is signed by the other TPM key, and sent to the attestation server. When the attestation server receives the IMR, it will check the signature on the report, and verify that the report was not tampered with. It will then compare the public key used to sign the report with the public key for that client system. It will then validate the quote in the IMR by verifying that the quote was signed by the same public key as the one stored for this computer system, and verifying that the PCR values match those that are safe stored. Once the quote has been validated, then the IML is checked to verify that the cumulative hash of all of the individual IML entries matches the PCR10 value in the QUOTE, and that each of the IML entry hashes are in the table of golden values. Assuming all of these checks pass, the system is presumed to be uncompromised and access is granted.

This particular implementation utilizes a piece of hardware to enforce access to the greater network. In our case it is a CICSO 3750 programmable switch. This switch is configured such that prior to the client system attesting, the only port it can talk to is a specially configured port on the attestation server that is dedicated to the attestation process. When the client system is successfully verified, freeradius notified the switch that this port may be opened , and the system will be permitted access to the other ports on the switch, presumably to access the protected asset. If the system does not authenticate, then the switch is informed to keep the port closed, and the client system will not be able to access the other ports of the switch. Programming of the switch is not a part of the this project.

This implementation is broken into 15 separate modules. The modules are designed to be largely independent of each other, and it should be possible to replace a module with one that maintains the same interfaces. There are some dependencies however. For example, the logic in verifyIMR that verifies an IMR is dependent on the logic in PTS that generates the IMR. It is possible to replace both the generation code and the verification code by maintaining the same interfaces, should the presented code be not what is desired. There is a more detailed discussion of each of the 15 modules in separate pages.

[kernel2.6.18]
[trousers]
[wpa-supplicant]
[tboot]
[freeradius-server]
[fast_tncs]
[RIMM Tools]
[RIMM Library]
[Attestation Utilities]
[Client Registration]
[Platform Trust Services]
[Integrity Measurement Collector]
[Trusted Network Connect Client]
[hostimserver]
[TCG Interface Library]
[Verify IMR]
[Key Manager]

A set of steps for using all 15 of these modules in conjunction with the switch discussed above is defined [here].