Definition of a safe initialization module

We describe here the steps between the power on of the system till the launch of the operating system. By safe, we mean that each component that is started is sure, and is the one that is supposed to be.

Linux startup description

The following description is quoting some parts of the (recommended) following article “Inside the Linux boot process” by Tim Jones (url : http://www-128.ibm.com/developerworks/linux/library/l-linuxboot/?ca=dgr-lnxw16LinuxBoot ).

The steps of the start-up are the following :

• power on, the electronic startup of the system starts,
• a first program stored in a flash or rom (the “bios part”) is read and executed by the processor,
• on a complex system (typically a pc), a boot loader is searched. It may be searched on hard disk, a cdrom, on a network or on an usb key,
• most of the time the boot loader will read its own configuration at a specific place (harddisk, cdrom, flash, network).
• Eventually, some kind of user interface will present a choice of boot option. Then an operating system (or a new bootloader) is called.
• In the case of linux, the kernel is loaded (explain the initrd stuff) and starts.

When a system is booted, the processor executes code at a fixed memory place. In a personal computer (PC), this location is in the on board flash rom (the BIOS). In PC the part of the bios run must then determine from which device (hard disk, network, cdrom, usb key, ...) the boot process will continue.

When a boot device is found, the first-stage boot loader is loaded into RAM and executed. This boot loader is less than 512 bytes in length (a single sector), and its job is to load the second-stage boot loader.

When the second-stage boot loader is in RAM and executing, Linux and an optional initial RAM disk (temporary root file system) are loaded into memory. When the images are loaded, the second-stage boot loader passes control to the kernel image and the kernel is decompressed and initialized. At this stage, the second-stage boot loader checks the system hardware, enumerates the attached hardware devices, mounts the root device, and then loads the necessary kernel modules. When complete, the first user-space program (init) starts, and high-level system initialization is performed.

In order to secure the computer, at each step, each code part and configuration file must be checked. The only solution for that is to have a secure place where signature informations are stored. This place may be directly on the main-board (TPM technology) or may be on an external media (such as a smart card or with a normal usb key).

Using TPM chip

Introduction to TPM

The following informations are a summary of what may be found either on the Trusted Computing Group web site https://www.trustedcomputinggroup.org/ or on wikipedia. “Trusted Computing Group members develop and promote open, vendor-neutral, industry standard specifications for trusted computing building blocks and software interfaces across multiple platforms.” The organisation members are providing specifications for all type of computing devices (printers, desktop, mobile phones, ...).

The main concept consists in assigning a digital signature to each elements (software, document) and to delegate to a third party device the task of verifying that the manipulated element is allowed to be used on the local computer system. All elements that are not signed or the signature of which is not listed by the signing device will be rejected.

Directly from wikipedia : “A Trusted Platform Module offers facilities for secure generation of cryptographic keys, the ability to limit the use of keys (to either signing / verification or encryption / decryption), as well as a Hardware Random Number Generator. It also includes capabilities such as remote attestation, binding, and sealed storage. Remote attestation creates an unforgeable summary of the hardware, boot, and host O/S configuration of a computer, allowing a third party (such as a digital music store) to verify that the software has not been changed. Sealing encrypts data in such a way that it may be decrypted only in the exact same state (that is, it may be decrypted only on the computer it was encrypted running the same software). Binding encrypts data using the TPM's endorsement key (a unique RSA key put in the chip during its production) or another trusted key.

A Trusted Platform Module can be used to authenticate a hardware device. Since each TPM chip is unique to a particular device, it is capable of performing platform authentication. For example, it can be used to verify that the system seeking the access is the expected system.”

The main pc vendors are part of the Trusted Computing Group (IBM, HP, Dell, Lenovo, ...) and are providing computers with these functions.

TPM and boot

The sequence of boot is the following :

• bios start (pre-boot process),
• bootloader start (boot process),
• kernel start (boot process).

TPM provides ways to ensure the security of each stage.

With TPM the first BIOS operation is to verify the BIOS integrity (signature worked out and compared with on board signature stored in TPM chip), then the BIOS is run. Before starting the bootloader, a signature of the bootloader is calculated and compared with the real bootloader.

These steps ensures that the bios and Grub are what they should be.

Then, grub starts. It is interesting to use Trusted Grub which integrates specific TCG extensions (project Trusted GRUB http://trousers.sourceforge.net/grub.html).

The details of the checks performed by grub are the following :

• Stage 1 verifies the signature of the first sector of the stage 1.5 (or stage 2).
• During the stage 1.5 of grub the first sector of stage 2 is checked as well as the remaining sectors of stage 1.5 and stage 2.
• Just after grub started, it checks its own configuration file (grub.conf). The files that are checked are to the choice of the administrator. They just need to be given in the grub.conf configuration file with the following syntax : measure (hd0,0)/root/a_file

grub will also check all the files given to the commands “kernel”, “initrd”, “chainloader” and “module”.

All the checks are made before the loading and the start of the kernel itself. If all checks are successful, then we consider that we are in the “Initial Platform’s Trustworthy State”. It becomes then possible to load and start the kernel. A mechanism within the cryptographic device must be found.

It may be decryption key of the kernel itself. However, it forces to decrypt the kernel which is not what is necessary. The kernel just requires to have its integrity checked, it is not a confidential information by itself. Then, its encryption is useless. Then, what may be decrypted is the user data. So the cryptographic key for accessing the user data needs to be released only if the Initial Platform's Trustworthy State is reached.

One of the possible attack to TPM is to have a PCI board with an autonomous behaviour that will try to dump all the available memory. It is then interesting to have a file with the listing of the PCI devices, and having the stage2 regenerating the file and checking its integrity. It will guarantee that no unauthorized device was plugged in. A special grub command must be added for creating this function (this does not exist today within Trusted Grub). This method does not protect from a hidden special device just listening on the bus, but at least it forbids any active hardware, that could for example access all the memory using DMA.

Another potential attack is the use of many memory banks either for the RAM, the bios or another component (Sata or SCSI controller for example). An additional component plugged on the address bus would choose to switch between the “normal” memory bank and a “bad” one while some address access pattern is reached. This would for example allow to switch from an access to the checked “bios” to another access to an unchecked one. A protection against this possibility would be to write random patterns provided by the TPM chip in the memory and to check regularly these patterns with the cryptographic chip. A particular command may be added to the bootloader and these checking made at various place in the boot loader process. So consider that the bootloader has started the kernel which then loads the initrd file system. With the TPM, we have reasonably ensured that all files and programs used are the one they should be. This is done only by signatures. Till now, there was no necessity to have some data decrypted. This was also true for the kernel and the initrd. We will examine the process in order to mount the partitions in a next paragraph as this part is globally common to the TPM and external hardware case.

Using an external secured key with physical pin code

We consider the use of an external device for storing part or all data : * bootloader, * kernel and initrd, * partitions of data and applications.

A boot is done through the bios on an external key. We consider that no confidence may be made to the bios. In this case, the single solution is to put confidence features at the level of the external storage (usb key, usb hard disk, cdrom). As in the TPM case, the different steps of the boot are the following :

• bios start,
• bootloader start,
• kernel start.

So first the bios starts. The bios may have been modified. The first sector of the key is used to load the first stage bootloader. Is there a way to have some confidence in the pre-boot process ? Normally, either the bios is mapped in the memory or the bios is copied from the flash to the DRAM. So it becomes possible to put in place the following mechanism :

• as soon as possible the memory is filled with 0,
• the bios is in memory,
• some different stages of the bootloader are executed,
• a full signature of the memory is worked out, ideally in using a random seed given by a cryptographic processor on the usb key,
• the signature is sent to the cryptographic processor that unlock portions of the key that are necessary for continuing the boot,
• a password or a passphrase may be asked in one way or another to further secure this procedure. Ideally, the first unlocking of the usb key should be done with an external system,
• a checking of the firmware of the different components that have one should be done. It should be possible to ask for the firmware and check a signature of it. This means special commands to add in the bootloader for the bootloader to be able to get the firmware from the device.

It is crucial that the working of the bootloader (for example the bios calls) is fully done in the RAM of the computer. As at one stage the RAM was checked, operations may reliably be based on it. Even if the usb channel is corrupted, the working of the computer stays secure.

So even without TPM, it becomes possible to guarantee the integrity of the BIOS and of the bios parts that are used by the bootloader. This function should be built in the grub on the key.

The same steps that were described in the case of the TPM boot needs also to be done in the case of an external usb key. However, it is the cryptographic processor included in the usb key that will store the signatures of the different code parts. The ideal would be to have a cryptographic processor that would unlock the different signatures one after the other, checking after checking. In order to avoid a simple reproductions of the signatures, a seed provided by the cryptographic processor should be used.

There are 2 use cases. Either we require the external device for operating, or the external device is just used on start. From a security point of view, it is much more interesting to have the “security chain” initiated on start and that is transitively transmitted from execution stage to execution stage, than a fixed material system. In this last case, a physical access will allow to take the element and deny the working of the system.

The goal of security system is to minimize the impact of a physical access to the device. This is not the case with a fixed hardware system. So we consider that the physical device should only be used on start of the system. The biggest interest in these 2 last cases, is that even with a physically compromised pc which bios would have been changed, the pc would not start without the key.

So the secured storage is partly unlocked, the bootloader is started. Then the kernel may be on the key or not. If the kernel is on the device, there is no further verification to do. The kernel should start. If the kernel is not on the device, then before starting the kernel, the system must check the integrity of the kernel. The best way would be to have a challenge proposed by the device, a workout of grub on this challenge with the kernel, a sending of the answer to the physical device and an unlocking of a new storage zone on the device with the elements either to decrypt the kernel or to use encrypted partitions via one or the other encrypted file systems.

Mounting the partitions

All steps that were taken till now, where only done in order to ensure that it was only possible to the user to read its own encrypted data in a secure way. The scenario that we try to avoid, is a user working on his secret data and having his computer stolen, and then its data read.

To access his secret data, a user must use a password (or passphrase). If somebody succeeds to stole the passphrase (and the login) all efforts that were taken till now are useless. Without further measure, a simple keylogger would be enough. It just has to store the 100 first characters that are typed and it is finished. 2 solutions exist : either use a one time password solution or include a special way to give the passphrase defeating a keylogger (graphical grid, random ordered list of letters, ...).

Classical secured solutions for user data should be used (encrypted file systems either block level such as dmcrypt or cryptoloop or file level such as with ecrypt-fs). In this case, a careful analysis must be made to choose the one that will allow to store the keys in the cryptographic chip (TPM, or usb key) with a secure passphrase. In fact, things are very opened at this stage. The kernel is booted, the root filesystem was mounted, we may consider that a first set of programs are available and are considered to be sure. We then may use either a text interface (for example providing a list of letters in a random order and asking people to enter the password only the arrow keys and the “Enter” key) or directly with a graphical interface in gdm, kdm or xdm. In this case a graphical interface (the classical grid with randomly placed numbers or letters) may be used to login and access the encrypted data.