@ -18,8 +18,8 @@ The hardware itself is strongly defined by the standard and comes in the followi
The user can plug it into a compatible compute platform. This gives most control to the end user since it is easy to disable trusted computing or to switch to another TPM.
\item\emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard.
Therefore, removing or changing the TPM is imossible.
All recent Intel and AMD platforms supporting TPM2.0 are able to manage a TPM within the BIOS, even as mounted device.
\item\emph{Firmware TPM (fTPM).} This variant was introduced with the TPM2.0 Revision.
All recent Intel and AMD platforms supporting TPM~2.0 are able to manage a TPM within the BIOS, even as mounted device.
\item\emph{Firmware TPM (fTPM).} This variant was introduced with the TPM~2.0 Revision.
Instead of using a dedicated coprocessor for the TPM features, this variant lives as firmware extension within Intel's Management Engine or AMD's Platform Security Processor.
Both Intel and AMD provide this extension for their platforms for several years now.
When activating this feature on BIOS level, the user gets the same behavior as when using a mounted device.
@ -71,12 +71,12 @@ Unfortunately, the command line parameters changed several times during the majo
With the previously mentioned software layers the TCG achieved independence of the underlying hardware.
Hence, this design made the different flavors of TPMs possible.
With the TPM2.0 standard, TCG defined a highly constrained hardware with a small feature set.
With the TPM~2.0 standard, TCG defined a highly constrained hardware with a small feature set.
It is a passive device with some volatile and non-volatile memory, which provides hardware acceleration for a small number of crypto algorithms.
The standard allows to add some extra functionality to the device.
However, the TPMs used in this project provide just the minimal set of algorithms and also the minimal amount of memory.
Since TCG published its documents, several IT security teams investigated the concept and implementations of TPMs. \ToDo
Since TCG published its documents, several IT security teams investigated the concept and implementations of TPMs. \ToDo (With what outcome? references? AW Matthew Garrett references?)
\subsection{TPM Key Hierarchies}%
\label{sub:tpm_key_hierarchies}
@ -94,7 +94,7 @@ Arthur et al.~\cite{arthur15} provide a more detailed description on how the hie
\end{itemize}
Each of the persistent hiearchies represents its own tree of keys, beginning with a root key.
Since TPM2.0 was published, these root keys are not hard coded anymore and can be changed if necessary.
Since TPM~2.0 was published, these root keys are not hard coded anymore and can be changed if necessary.
The process of key generation described below is similar to all three persistent hierarchies.
\subsection{Endorsement Key}%
@ -141,8 +141,8 @@ The formula shows that a new PCR value holds the information of the preceeding v
This \emph{hash chain} enables the user to add an arbitrary number of hash computations.
One can clearly see that the resulting hash will also change when the order of computations changes.
Therefore, the BIOS/UEFI has to provide a deterministic way to compute the hash chain if there is more than one operation necessary.
The procedure of measurements is available since the first public standard TPM1.2.
For TPM2.0, the process was only extended to support the newer SHA256 algorithm.
The procedure of measurements is available since the first public standard TPM~1.2.
For TPM~2.0, the process was only extended to support the newer SHA256 algorithm.
A PCR is now useful for a sequence of measurements with similar purpose.
When, for example, a new bootloader is installed on the main disk, the user wants to detect this with a separate PCR value.
@ -209,7 +209,7 @@ This guarantees that the chain of trust keeps intact when the bootloader/OS take
The bootloader has to continue the chain of trust by measuring the kernel and the corresponding command line parameters into the next PCRs.
The support and the way how the measurements are done is not standardized.
GRUB, for example, measures all executed GRUB commands, the kernel command line and the module command line into PCR 8, whereas any file read by GRUB will be measured into PCR 9~\cite{grub19}. \ToDo
GRUB, for example, measures all executed GRUB commands, the kernel command line and the module command line into PCR 8, whereas any file read by GRUB will be measured into PCR 9~\cite{grub19}. \ToDo (Any example for a bootloader that does it differently)
The whole process from initialization over measuring all software parts until the OS is started, is called \emph{Trusted Boot}.
The user can check the resulting values in the written PCR registers against known values.
@ -231,11 +231,12 @@ The binary is signed with the official PK and uses itself a self signed CA to si
A detailed description how shim works on Ubuntu is shown on their corresponding Wiki page~\cite{ubuntuwiki20}.
Only this workflow enables secure boot when using Linux OSes.
Secure boot uses conventional non-volatile memory instead of the TPM to store private parts of its signing keys. Although there exists a signature chain for any software involved in Microsoft's boot process, using alternative OSes breaks the signature chain.
Secure boot uses conventional non-volatile memory instead of the TPM to store private parts of its signing keys. \ToDoAlthough there exists a signature chain for any software involved in Microsoft's boot process, using alternative OSes breaks the signature chain.
When using an own PK, you loose the benefit of having externally created and signed hash values for checking during booting.
Secure and trusted boot can, however, exist side by side on one system.
The benefit of using it seems to be very limited when not using a Microsoft OS.
Secure and trusted boot can, however, exist side by side on one system.\ToDo (Why? Due to not working with a TPM? If yes, that's also the case with Secure Boot for a Microsoft OS, right?)
The benefit of using it seems to be very limited when not using a Microsoft OS.\ToDo (Unless you cite such a statement it seems to be inappropriate for this part of your thesis)
\ToDo(In deinem Fall würde ich empfehlen, Intel TXT (sehr kurz, ein Absatz reicht) und TEE allgemeiner (konkrete ARM Trustzone) etwas ausführlicher (nicht mehr als eine halbe Seite, dafür vielleicht mit ein paar Referenzen wofür ARM TEEs schon heute verwendet werden, was als teilweise Ersatz von TPMs gesehen werden könnte) zu erwähnen. Aber noch weiter würde ich die Runde nicht ziehen.)
\section{Integrity Measurement Architecture}%
\label{sec:integrity_measurement_architecture}
@ -325,7 +326,7 @@ There exist three template policies which can be used concurrently:
corresponding public key must be provided by the system manufacturer within the provided firmware or as Machine Owner Key in shim.
\end{itemize}
In addition to these templates, the system owner can define custom policies.
Some example policies can be found in the Gentoo Wiki~\cite{gentoo19}.
Some example policies can be found in the Gentoo Wiki~\cite{gentoo19-2}.
It is, for example, useful to exclude constantly changing log files from being measured to reduce useless entries in the measurement log.
\subsection{Other System Integrity Approaches}%
@ -351,8 +352,8 @@ These signatures can be verified with a single public key when private keys are
The scientific community is researching on TPM-backed DAA since the first standard of TPM went public in 2004.
Since then many different approaches of DAA were discussed.
According to Camenisch et al.~\cite{camenisch16}\cite{camenisch17}, almost all schemes were proven insecure, since many of them had bugs in the protocol or allowed trivial public/secret key pairs.
This also includes the impementation of DAA in the TPM1.2 standard.
According to Camenisch et al.~\cite{camenisch17}~\cite{camenisch16}, almost all schemes were proven insecure, since many of them had bugs in the protocol or allowed trivial public/secret key pairs.
This also includes the impementation of DAA in the TPM~1.2 standard.
This section describes the concept by Camenisch et al.~\cite{camenisch16} including the cryptographic elements used for DAA.
Unlike the description in the original paper, we describe the practical approach, which will be used in the following concept.
@ -409,7 +410,7 @@ This scheme is extensible to prove knowledge of an arbitrary number of secrets a
\label{ssec:bilinear-maps}
Bilinear Maps define a special property for mathematical groups which form the basis for verifying the signatures in DAA.
Consider three mathematical groups $\mathbb{G}_1$, $\mathbb{G}_2$, with their corresponding base points $g_1$, $g_2$, and $\mathbb{G}_T$.
Let $e:\mathbb{G}_1\times\mathbb{G}_2\rightarrow\mathbb{G}_T$ that satisfies three properties~\cite{camenisch04,camenisch16}:
Let $e:\mathbb{G}_1\times\mathbb{G}_2\rightarrow\mathbb{G}_T$ that satisfies three properties~\cite{camenisch04}~\cite{camenisch16}:
\begin{itemize}
\item\emph{Bilinearity.} For all $P\in\mathbb{G}_1, Q\in\mathbb{G}_2$, for all $a,b \in\mathbb{Z}: e(P^a,Q^b)= e(P,Q)^{ab}$.
\item\emph{Non-degeneracy.} For all generators $g_1\in\mathbb{G}_1, g_2\in\mathbb{G}_2:
@ -438,7 +439,7 @@ According to Camenisch et al.~\cite{camenisch16}, the DAA protocol consists of t
\item\emph{Host}\host. The host creates a platform with the corresponding TPM \tpm{}.
Membership of groups are maintained by the TPM.
Only the key owner (TPM, passive) and the message author (Host, active) form a full group member.
\item\emph{Verifier}\verifier. A verifier can check, whether a host with its TPM is in a group or not. Besides the group membership, no additional information is provided.
\item\emph{Verifier}\verifier. A verifier can check whether a host with its TPM is in a group or not. Besides the group membership, no additional information is provided.
\end{itemize}
Please note that these entities are different to the Digidow roles although they have the same name.
When leaving the DAA context after this section, the DAA entities will clearly be qualified (e.g. \emph{DAA} verifier).
@ -550,6 +551,6 @@ The feature of linking messages together requires further security features with
The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standardizes online authentication algorithms.
When the first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the newer standard, TPM2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
When the newer standard, TPM~2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
This standard is still in development; a draft version from February 2018 is published on the FIDO website~\cite{fido18}.
It implements a close variant of the previously described concept.
The BS itself is defined as edge device within the Digidow network which will be placed in a public area (e.g. a checkpoint in an airport or as access control system at a building) to interact directly with the Digidow users.
There, the BS acts as interface to the to the Digidow network.
There, the BS acts as interface to the Digidow network.
By providing a biometric property, the user should be able to authenticate itself and the network may then trigger the desired action, like granting access or logging presence.
Depending on the biometric property, the sensor may not be active all the time, but activated when an authentication process is started.
@ -40,7 +40,7 @@ There exists no exact definition or list of metadata which makes it hard to prev
Metadata does not directly identify an individual.
However huge network providers are able to combine lots of metadata to traces of individuals.
Eventually an action of those traced individuals might unveil their identity.
Consequently, a central goal of Digidow is to minimize the amount to minimize the risk of traces.
Consequently, a central goal of Digidow is to minimize the amount of traces.
Privacy defines the ability of individuals to keep information about themselves private from others.
In the context of the BS, this is related to the recorded biometric data.
@ -74,10 +74,10 @@ Given this environment, there are a number of threats that need to be considered
Due to this error, a wrong identity and therefore false claims would be made out of that.
\end{itemize}
Although all of these attack vectors should be mitigated when usen in production, we will address only a subset for the prototype.
Although all of these attack vectors should be mitigated when used in production, we will address only a subset for the prototype.
First, we assume that only authorized personnel has access to the hardware itself.
Any other person should only interact with the hardware sensor.
Therefore any threat atacking communication between internal system components will not be addressed.
Therefore any threat attacking communication between internal system components will not be addressed.
Furthermore, we will assume an already established bidirectional channel between BS and PIA.
Any algorithms on how the BS finds the corresponding PIA exceed the focus of this work.
@ -102,15 +102,15 @@ A flavour of Linux supporting all features described in this chapter, will be us
The ARM platform seem to be capable of all these features as well.
However, the support for TPMs, the amount of available software and the ease of installation is better on the PC platform.
As described in \autoref{sec:trusted_platform_module_tpm_}, the TPM functions can be delivered in three different flavors: As dedicated or mounted device and as part of the platform firmware.
The fTPM is part of larger proprietary environments from AMD and Intel which introduces, besides implementation flaws, additional attack surfaces for the TPM.
As described in \autoref{sec:trusted_platform_module_tpm_}, the TPM functions can be delivered in three different flavors: As dedicated or mounted device, as part of the platform firmware, or as software simulator.
The firmware variant is part of larger proprietary environments from AMD and Intel which introduces, besides implementation flaws, additional attack surfaces for the TPM.
Hence, we will use plugged TPM chips on the platform.
Then we are able to deactivate the TPM for demonstration purposes by simply unplugging it.
Any recent PC platform supports TPMs and consequently trusted boot as mentioned in \autoref{sec:trusted_boot}.
The system will describe its hardware state in the PCRs 0\,--\,7 when the EFI/BIOS hands over to the bootloader.
We use these PCR values to detect any unauthorized modifications on hardware or firmware level.
It is important to also include \emph{epmty} PCRs to detect added hardware on the PCI bus with an Option ROM, for example.
It is important to also include \emph{empty} PCRs to detect added hardware on the PCI bus with an Option ROM, for example.
With these PCR values we can seal a passphrase in the TPM.
The disk, secured with Full Disk Encryption (FDE), can only be accessed when the hardware underneath is not tampered with.
@ -147,7 +147,7 @@ The system needs to check its integrity on the OS level and summarize that by pu
\autoref{fig:measuements} illustrates how above processes extend the trust on the system.
The TPM is the cryptographic root of trust, storing all measurement results and the target values for validation.
Since the RTM is the only piece of code which lives in the platform firmware and is executed \emph{before} it is measured, it is an important part in the trust architecture of the system.
An honest RTM will measure the binary representation of itself, which makes the code at least provable afterwards.
An honest RTM will measure the binary representation of itself, which makes the code at least provable afterwards.\ToDo (not really since you can still not distinguish this from an dishonest RTM)
Finally, the CPU is assumed to execute all the code according to its specification.
Proving correctness of the instruction set cannot be done during the boot process.
@ -162,14 +162,14 @@ According to \autoref{sec:integrity_measurement_architecture}, every file will b
By enforcing IMA, the kernel allows access to only those files having a valid hash.
Consequently, every file which is required for proper execution needs to be hashed beforehand, i.e. before IMA is enforced.
The IMA policy in place should be \texttt{appraise\_tcb}, to analyze kernel modules, executable memory mapped files, executables and all files opened by root for read.
This policy should also include drivers and kernel modules for external hardware like a camera for attached via USB.
This policy should also include drivers and kernel modules for external hardware like a camera attached via USB.
\subsection{Proving Trust with DAA}%
\label{sub:prove_trust_with_daa}
The features described above take care of building a trusted environment on the system level.
DAA will take care of showing the \emph{trust} to a third party which has no particular knowledge about the BS.
In the Digidow context, the PIA should get, together to the biometrical measurements, a proof that the BS is a trusted system acting honestly.
In the Digidow context, the PIA should get, together with the biometrical measurements, a proof that the BS is a trusted system acting honestly.
To reduce the complexity of this problem, we consider two assumptions:
\begin{enumerate}
@ -180,7 +180,7 @@ To reduce the complexity of this problem, we consider two assumptions:
For the scope of this thesis, the DAA protocol should be applied on a simple LAN, where all parties are connected locally.
The BS will eventually become a member of the group of sensors managed by the DAA issuer.
During signup, DAA issuer and BS (DAA member) negotiate the membership credentials over the network.
By being a member of the DAA group, the DAA issuer fully trusts that the BS is honest and acting according the specification.
By being a member of the DAA group, the DAA issuer fully trusts that the BS is honest and acting accordingly the specification.
The DAA issuer will not check any group members, since they can now act independently.
When the BS is then authenticating an individual, the process illustrated in \autoref{fig:daa-attestation} will be executed.
The concept decscribed in \autoref{cha:concept} will be implemented as a prototype to demonstrate a working implementation and to analyze the speed of those parts of a transaction.
The concept described in \autoref{cha:concept} will be implemented as a prototype to demonstrate a working implementation and to analyze the speed of those parts of a transaction.
Although the goal is to put all these features on a highly integrated system, we decided to start with widely available hardware based on Intel's x86 architecture.
\caption[Prototype schematic]{Prototype setup to show DAA features and the Dataflow from BS to PIA}
\caption[Prototype schematic]{Prototype setup to show DAA features and the dataflow from BS to PIA}
\label{fig:prototype}
\end{figure}
@ -41,12 +41,12 @@ All features used in this thesis were available on both platform types, so there
\end{tabular}
\end{table}
The used mainboards come with a dedicated TPM2.0 header which may differ from board to board.
The used mainboards come with a dedicated TPM~2.0 header which may differ from board to board.
A 19-pin header is available on the older platform of \emph{System 2}.
As long as TPM and mainboard have the same 19-pin connector they will be compatible to each other.
The newer Gigabyte mainboards come with a proprietary 11-pin connector which is only compatible with Gigabyte's TPM2.0\_S module.
All modules are however electrical compatible since only unused pins of the full size connector are removed.
With a wiring adapter any TPM board would work on any mainboard supporting TPM2.0 even when coming with a prorietary header.
With a wiring adapter any TPM board would work on any mainboard supporting TPM~2.0 even when coming with a prorietary header.
\section{Select the Operating System}
The OS needs to fulfill three requirements for this prototype.
@ -59,9 +59,9 @@ This feature is available in the mainline Linux kernel.
However, the corresponding kernel compile parameters must be set.
Ubuntu 20.04 LTS does fulfill above mentioned requirements by default.
Ubuntu is also supported by the Xaptum ECDAA project, although it was tested with an older version (18.04).
Ubuntu is also supported by the Xaptum ECDAA project, although compatibility was tested with an older OS version (18.04).
When installing Ubuntu on the prototype, we used \emph{Full Disk Encryption} (FDE) which leads to the disk allocation described in \autoref{tab:disklayout}.
Ubuntu installs Grub by default, and it is used as a fallback bootloader.
Ubuntu installs Grub by default, which we will use in the following as a fallback bootloader.
\begin{table}
\centering
@ -87,18 +87,18 @@ Ubuntu installs Grub by default, and it is used as a fallback bootloader.
\section{Trusted Boot}
By default, every mainboard with support for TPM2.0 must support trusted boot.
When a TPM becomes available, the UEFI/BIOS itself takes all required measures until the boot process is handed over to the OS bootloader (e.g. GRUB).
Since Ubuntu uses GRUB 2.04 as bootloader which has TPM support by default, trusted boot needs just to be enabled in the GRUB configuration.
In this case, GRUB will be measured from the BIOS to the PCRs 4 and 5, as shown in \autoref{tab:PCR}.
\section{Trusted Boot}\ToDo(Für das Master-Projekt: FDE mit TPM klingt im ersten Moment nach einem guten Teil, der als "Add-on" definiert werden könnte zum ursprünglichen Auftrag für die Masterarbeit (Attestation, Trusted Boot und IMA sind hier näher am eigentlichen Kern). Vielleicht sollten wir das als Projekt herausschneiden und mit einem eigenen kurzen Dokument bzw. einer Abgabe definieren? Das Dokument kann auch z.B. ein "HOWTO Setup" für FDE mit TPM für Standard-Debian/Ubuntu sein, das du vermutlich in anderer Form schon als Markdown-Doc hast, wenn es einfach nur mit einem Titel und Hinweis aus Master-Projekt versehen wird.)
By default, every mainboard with support for TPM~2.0 must support trusted boot.
When a TPM becomes available, the UEFI/BIOS itself takes all required measures until the boot process is handed over to the OS bootloader (e.g. Grub).
Since Ubuntu uses GRUB 2.04 as bootloader which has TPM support by default, trusted boot needs just to be enabled in the Grub configuration.
In this case, Grub will be measured from the BIOS to the PCRs 4 and 5, as shown in \autoref{tab:PCR}.
According to the documentation~\cite{grub19}, Grub itself uses PCR 8 for executed commands, the kernel command line and all commands forwarded to kernel modules.
PCR 9 is used to measure all files read by GRUB.
PCR 9 is used to measure all files read by Grub.
Embedded systems like a productive version of the BS do not need several boot options, making Grub unnecessary.
Embedded systems like a rolled out version of the BS do not need several boot options, making Grub unnecessary.
Therefore we can replace Grub's bootloader EFI file with a blob containing all required information to load the kernel directly.
This kernel decrypts the disk and boots the remaining system autonomously.
Pawit Pornkitprasam~\cite{pornkitprasan19-diskencryption}~\cite{pornkitprasan19-tpmtools} and the Tevora company~\cite{tevora-secureboot} introduced the concept of a \emph{Unified Kernel} for Ubuntu
Pornkitprasam~\cite{pornkitprasan19-diskencryption}\cite{pornkitprasan19-tpmtools} and the Tevora company~\cite{tevora-secureboot} introduced the concept of a \emph{Unified Kernel} for Ubuntu
and Arch respectively.
This large EFI file contains the initramfs, kernel command line and the kernel itself.
@ -127,15 +127,15 @@ Only the command line parameters need to be customized.
\subsection{Install and use Trusted Boot}
\label{ssec:install-and-use-trusted-boot}
The following shell scripts are available online\footnote{\url{https://git.ins.jku.at/proj/digidow/trustedboot}} and in the folder \texttt{trustedboot/}.
The following shell scripts are available online\footnote{\url{https://git.ins.jku.at/proj/digidow/trustedboot}}.
All are tested on a Ubuntu 20.04 server minimal installation on all three devices.
These packages need to be installed beforehand to make use of the scripts:
\begin{itemize}
\item\texttt{binutils} for objcopy, generating unified kernel, and
\item\texttt{binutils} for objcopy, generating the unified kernel, and
\item\texttt{tpm2-tools} to interact with the onboard TPM,
\end{itemize}
Installing trused boot is done in three steps, assuming being root at the target system:
Installing trused boot is done in three steps, assuming being root on the target system:
\begin{enumerate}
\item\emph{Execute \texttt{install.sh}}: It installs the shell scripts into \texttt{/usr/sbin} and adds a new random passphrase to LUKS. It furthermore adds TPM support to the initramfs and creates the unified kernel described above.
\item\emph{Reboot}: During reboot, the new PCR values are generated.
@ -160,8 +160,8 @@ Relevant for trusted boot is the parameter where the root filesystem is located.
This example works for the default Ubuntu LVM on LUKS configuration.
The parameters activate also IMA which will be discussed later in this chapter.
If FDE is installed, the boot process need to be aware of how to decrypt the disk.
Therefore, the initramfs needs the luks binaries as well as the TPM software stack to unseal the passhrase with the PCR registers.
If FDE is installed, the boot process needs to be aware of how to decrypt the disk.
Therefore, the initramfs needs the LUKS binaries as well as the TPM software stack to unseal the passhrase with the PCR registers.
The unseal operation itself is then done with \autoref{code:tbpassphrasesh}, which also needs to exist in the initramfs.
\lstinputlisting[float,language=bash, caption={\texttt{passphrase-from-tpm.sh}: Initramfs-script to ask the TPM for the LUKS key}, label={code:tbpassphrasesh}]{../../trustedboot/passphrase-from-tpm.sh}
We copy the script of \autoref{code:tbtpm2hooksh} to \texttt{/etc/initramfs-tools/hooks} to enable TPM access during boot after the next initramfs update.
@ -197,59 +197,46 @@ The result is a trusted boot chain which ensures, that the system only has acces
The result of trusted boot is a measured and therefore trusted kernel with its command line parameters and modules.
IMA extends this trust to the file system as described in \autoref{sec:integrity_measurement_architecture}.
All features of IMA are already implemented in the kernel sources and do not need additional packages.
The Gentoo wiki page about IMA~\cite{gentoo19} describe which kernel compiler flags are related to IMA:
\begin{itemize}
\item\texttt{CONFIG\_INTEGRITY=y}
\item\texttt{CONFIG\_IMA=y}
\item\texttt{CONFIG\_IMA\_MEASURE\_PCR\_IDX=10}
\item\texttt{CONFIG\_IMA\_LSM\_RULES=y}
\item\texttt{CONFIG\_INTEGRITY\_SIGNATURE=y}
\item\texttt{CONFIG\_IMA\_APPRAISE=y}
\item\texttt{IMA\_APPRAISE\_BOOTPARAM=y}
\end{itemize}
The Gentoo wiki page about IMA~\cite{gentoo19} describes which kernel compiler flags are required to enable IMA in a Gentoo kernel.
According to their blog, Redhat\footnote{\url{https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture}, last visited on 9.7.2021} supports IMA since Enterprise Linux 8 and so would the Redhat clones like CentOS, Rocky or Alma Linux.
According to their blog~\cite{RedHat2020}, Redhat supports IMA since Enterprise Linux 8 and so would the Redhat clones like CentOS, Rocky or Alma Linux.
Ubuntu enabled the required kernel compile flags by default on version 20.04 in the ubuntu kernel repository\footnote{\url{https://kernel.ubuntu.com/git/kernel-ppa/mirror/ubuntu-5.4-focal.git/tree/security/integrity/ima/Kconfig}, last visited on 9.7.2021}.
However, we found no official information on when IMA was introduced or whether IMA support will continue in future releases.
Every kernel supporting IMA creates a virtual file at:
Every kernel supporting IMA creates a virtual file at \texttt{/sys/kernel/security/ima/ ascii\_runtime\_measurements}.
When IMA is disabled, which is the default, this file has only one entry representing the boot aggregate.
By enabling IMA via kernel command line parameters, this virtual file gets filled according to the policies defined.
The first four parameters used in \autoref{code:tbcommandlinetxt} define the behavior of IMA and how the measurement log should look like.
The first four parameters used in the kernel command line as shown in \autoref{code:tbcommandlinetxt} define the behavior of IMA and how the measurement log should look like.
\begin{itemize}
\item\texttt{ima\_appraise=fix} appends the filehash as an extended file attribute for every accessed file.
\item\texttt{ima\_policy=appraise\_tcb, ima\_policy=tcb} analyzes resources owned by root and opened for execution.
\item\texttt{ima\_policy=appraise\_tcb} together with \texttt{ima\_policy=tcb} analyze files owned by root and opened for execution.
\item\texttt{ima\_hash=sha256} sets the hashing algorithm.
\item\texttt{rootflags=i\_version} must be enabled when mounting the filesystem since IMA is checking that number before re-hashing the resource.
\item\texttt{rootflags=i\_version} must be enabled when mounting the filesystem since IMA is checking that number before re-hashing the resource.\ToDo(what number)
\end{itemize}
Unfortunately, the resulting integrity log is between 2000 and 3000 lines long when the system is freshly booted.
The log can blow up to several 10000 lines when uptime exceeds several days.
IMA has therefore a policy language rules for hashing files can be customized.
Therefore, IMA has a policy language where rules for hashing files can be customized.
It might, for example, be useful to exclude log files from being hashed.
However, a thrid party can comprehend the state of the attesting system, when parsing the integrity log.
A third party can comprehend the state of the attesting system, when parsing the integrity log.
Together with the corresponding value of PCR 10, where the hashes of all entries are chained, the TPM can \texttt{certify} correctness of the log.
Besides the log entries, every hashed file gets an extended file attribute called \texttt{security.ima} holding current hash value in base64 encoding.
The apt package \texttt{attr} contains the binary \texttt{getfattr} which can show these additional attributes.
Now, the file attributes are shown with:
Besides the log entries, every hashed file gets an extended file attribute called \texttt{security.ima} which holds the current hash value in base64 encoding.
The apt package \texttt{attr} contains the binary \texttt{getfattr} which can show these additional attributes with the following command:
\begin{lstlisting}[numbers=none]
getfattr -m - -d trustedboot/install.sh
\end{lstlisting}
Having attributes for all relevant files allows IMA to enforce appraisal.
This means that the hash of every file is checked before it is accessed.
This means that the hash of every file is checked before accessing the file.
Before enforcing IMA, the root filesystem should be parsed to create attributes for every file.
Touching the file is not enough, the file must be openend for read, as shown in the following command:
Touching the file is not enough, the file must be opened for read.
The following command opens every file in an ext4 filesystem for read, causing the kernel to create/update the file attributes, but does not read any data:
\begin{lstlisting}[numbers=none]
time find / -fstype ext4 -type f -uid 0 -exec dd if='{}' of=/dev/null count=0 status=none \;
\end{lstlisting}
This command opens every file in an ext4 filesystem for read, causing the kernel to create/update the file attributes, but does not read any data.
It takes about fifteen minutes to parse the file system on a Ubuntu minimal server system given the hardware described above.
It takes about fifteen minutes to parse the filesystem on a Ubuntu minimal server system given the hardware described above.
The final step is to enforce IMA appraisal via kernel command line parameter.
By changing the parameter \texttt{ima\_appraise=enforce} in
@ -267,36 +254,40 @@ Two options are therefore available:
The host can directly check whether the file was tamepered with and act accordingly.
Linux kernels support this feature with the \emph{extended verification module} (EVM).
\end{itemize}
We use with DAA an attestation variant where the integrity log is part of the message.
We use the variant where the integrity log is part of the message.
Details about the message design will be discussed in \autoref{ssec:daa-network-protocol}.
This variant makes the BS prototype implementation easier, however, it increases complexity to completely verify the message.
It might be useful in the future to use EVM to prevent executing unsigned or modified code.
\section{Dynamic System Analysis}
\section{Runtime Analysis}
IMA is a comprehensive tool for checking the integrity of a file or executable or library before it gets executed.
When access is allowed, IMA's job is done.
When access is granted, IMA's job is done.
Hence, IMA is a tool for static system analysis.
An executable can however change its behaviour during runtime, either intended with remote procedure calls or unintended with a remote code execution vulnerability.
These attack vectors can be addressed with runtime analysis.
One approach for runtime analysis is to create a log of syscalls for a certain process.
Syscalls are the only interface from the program to the OS when managing resources needed by the program.
Hence logging the trace of syscalls show which resources it needs and which files areaccessed or modified.
Hence logging the trace of syscalls shows which resources it needs and which files areaccessed or modified.
Any unusual behavior could be detected immediately given a good knowledge of the used resources when executing a good version of the program.
The trace logs are created with \texttt{auditd} which requires the corresponding apt package to be installed.
\section{Prove TPM2 Certificate Chain}
\section{Prove TPM~2.0 Certificate Chain}
Every TPM has a corresponding certificate which is part of a certificate chain maintained by the TPM manufacturer.
In our case, Infineon certifies its TPM with a number of intermediate CAs which itself are certified with Infineon's root CA.
The TPM certificate is available for RSA and ECC cryptofamilies respectively.
Since the verification workflow is the same on all machines and for both cryptofamilies, we demonstrate on system 1 how the process works.
Note that this works for Infineon TPMs.
Other Vendors like STM, AMD or Intel may provide certificates via download on their website.
Other vendors like STM, AMD or Intel may provide certificates via download on their website.
\begin{enumerate}
\item Read the certificate from the TPM NVRAM.
The RSA certificate is located at address \texttt{0x1c00002}, that for ECC on address \texttt{0x1c0000a}:
\begin{lstlisting}[numbers=none]
root@amd1:~# tpm2_nvread -C o 0x1c0000a -o amd1_ecc.crt
\end{lstlisting}
\item Download the certificates from the intermediate and root CA from infineon's website:
\item Download the certificates from the intermediate and root CA from Infineon's website:
\begin{lstlisting}[numbers=none]
root@amd1:~# wget https://www.infineon.com/dgdl/Infineon-TPM_ECC_Root_CA-C-v01_00-EN.cer?fileId=5546d46253f65057015404843f751cdc -O infineon_ecc_root_ca.crt #Infineon root CA
root@amd1:~# wget https://www.infineon.com/dgdl/Infineon-OPTIGA-ECC-Manufacturing-CA_036-Issued_by_RootCA.crt-C-v01_00-EN.crt?fileId=5546d46262475fbe0162486417b73cbe -O infineon_ecc_intermediate_ca_036.crt #Infineon intermediate CA
@ -308,20 +299,20 @@ Other Vendors like STM, AMD or Intel may provide certificates via download on th
The option \texttt{-untrusted} is required since the provided root CA is not in the OS' trust store and hence of unknown trust.
The option \texttt{-untrusted} is required since the provided root CA is not in the OS trust store and hence of unknown trust.\ToDo(I'm a bit surprised thet openSSL checks against the system trust store even when providing a specific CA file. Have you checked that verification fails if you di not provide the CA file/if the CA file is incorrect/etc.)
When OpenSSL returns \texttt{OK}, the certificate chain is intact and the TPM is indeed one from Infineon.
To be correct: The website, probably hosted by Infineon, provides a certificate chain which matches and the links to the corresponding parent certificate is correct.
Unfortunately, Infineon do neither provide any website certification nor any checksums of the provided certificates.
To be exact: The website, probably hosted by Infineon, provides a certificate chain which matches and the links to the corresponding parent certificate are correct.
Unfortunately, Infineon does neither provide any website certification nor any checksums of the provided certificates.
So, if the above described check fails, no source of trust can ensure that the root certificate is correct.
We found, that both, ECC and RSA chains of all TPMs are intact.
We found that both, ECC and RSA chains of all TPMs are intact.
For documentation reasons, we provide the OpenSSL SHA256 checksums of all used certificates in \autoref{tab:certchksum}.
@ -350,7 +341,7 @@ These chaecksums were generated with:
\bottomrule
\end{tabular}
\end{table}
\ToDo (table into Appendix?)
\section{Using the DAA Protocol}
Direct anonymous attestation uses the TPM as cryptoprocessor and key store.
The feature of identifiable instances of sensors is not required when interacting with the Digidow network.
@ -366,8 +357,8 @@ We describe in the following which programs need to be installed and what config
\subsection{Provision Hosts of Test Setup}
The demonstration setup, shown in \autoref{fig:prototype}, consists of three independent hosts which are connected together via TCP/IP.
Every host represent one party in the DAA scheme, each requiring additional software to support the DAA protocol.
Xaptums ECDAA library need to be installed on all three hosts but only the sensor requires TPM support.
Every host represents one party in the DAA scheme, each requiring additional software to support the DAA protocol.
Xaptums ECDAA library needs to be installed on all three hosts but only the sensor requires TPM support.
Similar to that, the ECDAA network wrapper is required to support the network communication part.
The member needs, besides DAA protocol support, software to capture and process an image of the USB webcam.
@ -375,7 +366,7 @@ We developed a small Rust program called \texttt{bs-capture} for capturing a fac
For biometric processing, we transform the image into an embedding with the face recognition prototype of Digidow\footnote{\url{https://git.ins.jku.at/proj/digidow/prototype-facerecognition}}.
\subsection{Installing Xaptum ECDAA Library}
Xaptum's ECDAA Library provide the cryptographic functions and the protocol primitives for DAA.
Xaptum's ECDAA library provides the cryptographic functions and the protocol primitives for DAA.
A file based demonstration of the protocol is provided within the project.
We have to build the ECDAA library from source since the provided deb packages do not officially support Ubuntu 20.04.
Therefore we need the C build environment as follows:
@ -412,17 +403,17 @@ Now, all prerequisities are installed to build and install the ECDAA network wra
\subsection{DAA Network Protocol}
\label{ssec:daa-network-protocol}
The network protocol provided by \texttt{ecdaa-network-wrapper} adds to the cryptographic implementation of Xaptum's ecdaa project a network communication layer.
The network protocol provided by \texttt{ecdaa-network-wrapper} adds a network communication layer to the cryptographic implementation of Xaptum's ECDAA project.
It is designed to match the workflow of a Digidow transaction, affecting the decision which party is defined as listener and which as sender.
\begin{itemize}
\item\emph{Start DAA issuer listener}: During startup of the issuer server, the program loads the public/private key pair if present.
Otherwise, a new key pair will be created.
The DAA issuer listener is always active to manage group subscriptions and queries for the group publiic key.
The DAA issuer listener is always active to manage group subscriptions and queries for the group public key.
\item\emph{Broadcast DAA group public key}: The group public key created by the DAA issuer is necessary for group enrollment and for verification of any messages signed by a DAA group member.
Consequently, DAA verifier and (potential) DAA member must get this key first.
\autoref{fig:daa-network-publish} shows the two steps that are visible on the network.
Since this communication contains only public data, no additional privacy measurenments are required.
Since this communication contains only public data, no additional privacy measurements are required.
@ -433,7 +424,7 @@ It is designed to match the workflow of a Digidow transaction, affecting the dec
This protocol requires the group public key to be present at the DAA member.
If this is not the case, the member asks for it automatically.
The procedure is a four-way handshake, as shown in \autoref{fig:daa-network-join}.
We describe in \autoref{ssec:daa-protocol-on-lrsw-assumption} that the key exchange is cryptographically secure, meaning that no adversary can extract any private keys when getting access to these messages.
We describe in \autoref{ssec:daa-protocol-on-lrsw-assumption} that the key exchange is cryptographically secure, meaning that no adversary can extract any private keys when getting access to these messages.\ToDo(Please clarify that you completely skip any endorsement in the practical implementation)
@ -465,7 +456,7 @@ Furthermore, the the ECDAA library limits the message size for signing to 1024 B
Thus, we created a sha512 sum of the message and signed only this hash allowing us to send messages of arbitrary size and constant effort for signing.
\subsection{Installing the DAA Network Protocol}
The Network Wrapper is located at \texttt{ecdaa-network-wrapper/} or can be downloaded from the Git repo\footnote{\url{https://git.ins.jku.at/proj/digidow/ecdaa-network-wrapper}}.
The Network Wrapper can be downloaded from the Git repository\footnote{\url{https://git.ins.jku.at/proj/digidow/ecdaa-network-wrapper}}.
Copy the folder \texttt{ecdaa-network-wrapper} to the build directory and change to this directory:
@ -499,25 +490,25 @@ When all above steps are finished successfully, the host is capable of taking it
For demonstration purposes, we use an USB webcam to take a photo of the person being in front of the sensor.
This photo is then processed to generate a face embedding, which is small enough to be sent with the DAA attestation message.
The first part is done with a small Rust program called \texttt{bs-capture}, which is available in the folder \texttt{bs-capture/} as well as online\footnote{\url{https://git.ins.jku.at/preisach/bs-capture}}
It uses the libraries from the video4linux project to capture a still image and saving it to disk.
The first part is done with a small Rust program called \texttt{bs-capture}, which is available online\footnote{\url{https://git.ins.jku.at/proj/digidow/bs-capture}}.
It uses the libraries from the video4linux project to capture a still image and save it to disk.
Ubuntu 20.04 requires the following packages to be installed:
Cargo creates a binary in \texttt{target/debug/bs-capture} which can then be used for this prototype.
The program assumes that a webcam is available at \texttt{/dev/video0}.
It takes a still image which is saved as \texttt{frame.jpg} in the working directory, which is in this example \texttt{~/bs-capture}.
It takes a still image which is saved as \texttt{frame.jpg} in the working directory, in this example \texttt{\textasciitilde/bs-capture}.
This image needs then to be processed to generate the face embedding data.
This image needs to be processed to generate the face embedding data.
Therefore we use the project \emph{Prototype Facerecognition} which uses a trained tensorflow network to generate embeddings.
The branch \texttt{retinaface-tflite} of the Git repository\footnote{\url{https://git.ins.jku.at/proj/digidow/prototype-facerecognition}} contains an install script which cares about installing all dependencies for setup:
The branch \texttt{retinaface-tflite} of the Git repository\footnote{\url{https://git.ins.jku.at/proj/digidow/prototype-facerecognition}} contains an install script which takes care of installing all dependencies for setup:
@ -6,23 +6,25 @@ We show in the following how well each part of the setup work and which performa
Furthermore we analyze the footprint in memory as well as on the disk.
The tests are only applied to System 1 and 3 since System 2 has a comparable hardware configuration to System 3 but uses a CPU of an older generation.
Furthermore, only two TPMs support the cryptographic parts required for ECDAA.
The TPM in System 2 uses an older firmware version which does not support the used implementation of ECDAA.
We discuss this issue in further detail in \autoref{sec:limitations}.
Consequently, System 2 was used as DAA verifier since this host does not require a TPM.
\section{Trusted Boot}
The first part of the setup is trusted boot which is well integrated in recent releases of kernel and GRUB bootloader.
Furthermore, unlocking the optional disk encryption with the TPM works seamless with the kernel, even when using the manually generated unified kernel without GRUB.
Only when performing an update for GRUB, it will modify the entries in the EFI boot manager.
Furthermore, unlocking the optional disk encryption with the TPM works seamless with the kernel, even when using the manually generated unified kernel without Grub.
Only when performing an update for Grub, it will modify the entries in the EFI boot manager.
Consequently, we recommend a check of the boot entries after a system upgrade.
Having a backup boot option with GRUB is useful for maintenance tasks.
Having a backup boot option with Grub is useful for maintenance tasks during development.
Especially for modifying the IMA configuration via kernel command line, it may be necessary to boot with a backup kernel.
Hence, a backup boot process is strongly recommended for test setups.
This requires a backup password for the disk encryption since which allows to bypass the TPM during booting.
This requires a backup password for the disk encryption which allows to bypass the TPM during booting.
Otherwise there are no updates possible with the current setup since the affected PCRs are used by the EFI bootloader and cannot be precomputed.
However, a backup bootloader is not required when operating the BS in unattended environments.
GRUB already supports trusted boot and activation requires a line in the corresponding config file.
Unlike GRUB, the unified kernel does not perform any measurements.
Unlike Grub, the unified kernel does not perform any measurements.
Only when asking the TPM for the disk encryption key, the initramfs must have the TPM stack available.
These files use about 62\,KB of space in initramfs which is negligible compared with the complete image using about 80\,MB.
Furthermore, only in this case exists a measurable difference in the boot performace since asking the TPM takes around 4\,s.
@ -40,7 +42,7 @@ The number of files is determined with the following command
\begin{lstlisting}[numbers=none]
find / -fstype ext4 -type f -uid 0 | wc -l
\end{lstlisting}
For example, system 1 holds after setup as Biometric Sensor and several system updates 156947 files.
For example, system 1 holds 156,947 files after setup as Biometric Sensor and several system updates.
This results in estimated additional disk usage of 613\,MB when adding the \texttt{xattr} block for each file.
Further attributes, however, would not require more disk space on ext4 since every extended attribute must exist in this single block.
@ -48,14 +50,14 @@ IMA holds all runtime information as virtual files in memory, including the inte
In context of memory usage, it is clear that the size of the virtual files without the redundant information (like PCR number and log format) is a rough estimation for the memory usage within the kernel since we did not analyze the corresponding data structires within the kernel.
Both memory and disk usage do not change between IMA's fixing and enforcing mode since enforcing only adds file access control.
Saving the file to disk, uses about 2\,MB of size per 10000 lines in the log.
Saving the file to disk, uses about 2\,MB of size per 10,000 lines in the log.
This indicates a linear dependency to the number of accessed files for the log and the kernel's memory usage.
The log can easily get over 100000 entries when the system is running long enough.
System 1, for example, had a log file with 214561 lines after about 15 days of uptime, resulting in about 40\,MB of size.
The log can easily get over 100,000 entries when the system is running long enough.
System 1, for example, had a log file with 214,561 lines after about 15 days of uptime, resulting in about 40\,MB of size.
The log file showed that a major impact on the size was the performed system update.
Generating the iniramfs blob and compiling programs from source generates together several 10000 lines in the log.
Generating the iniramfs blob and compiling programs from source together generates several 10,000 lines in the log.
When looking into the performance of IMA, there is a huge drop when it is enable, especially when files are read the first time.
When looking into the performance of IMA, there is a huge drop when it is enabled, especially when files are read the first time.
We show in \autoref{tab:bootperformance} the reboot performance of the used test systems given a setup for a biometric sensor described in \autoref{cha:implementation} with TPM backed disk encryption enabled.
\begin{table}
\renewcommand{\arraystretch}{1.2}
@ -83,8 +85,8 @@ With boot disk and kernel available, the system starts all services until the lo
This ends the reboot procedure.
Although the number of runs is very small, the test clearly shows that enabling IMA doubles the time for rebooting.
Furthermore, asking the TPM for the decryption key and decrypting the disk takes around 4\,s in any case.
This may caused by the \texttt{tpm2\_unseal} operation which computes multiple relatively complex cryptographic instructions before the task is done.
Furthermore, asking the TPM for the decryption key and decrypting the disk takes around 4\,s.
This may be caused by the \texttt{tpm2\_unseal} operation which computes multiple relatively complex cryptographic instructions before the task is done.
\section{Processing and Sending Biometric Data}
@ -96,11 +98,11 @@ Analyzing the occupied resources is only meaningful for the DAA member.
The implemented protoype of the DAA issuer does only negotiate the membership key.
Revocation lists and group management are not implemented yet, although the ECDAA library provides datastrucutres and functions for that.
Similarly, the DAA verifier only checks the signature of the received message.
In a production setup, both entities must hold the revocation list and perform further checks to trust the DAA member and its messages.
In a production setup, both entities must hold the revocation list and perform further checks to trust the DAA member and its messages:
We split the tasks of a Digidow sensor in several parts to document the conrtibution of each.
We split the tasks of a Digidow sensor in several parts to document the conrtibution of each:
\begin{itemize}
\item\emph{DAA TPM key generation}: Clear the TPM, generate a new EK and DAA key pair and persist the DAA key in the TPM's NVRAM
\item\emph{DAA TPM key generation}: Clear the TPM, generate a new EK and DAA key pair and persist the DAA key in the TPM's NVRAM.
\item\emph{DAA TPM join w/o keygen}: Use the DAA key which is already in place and negotiate a group membership with the DAA issuer.
\item\emph{DAA TPM keygen \& join}: This combines the two steps above to give comparable time measurements to the join procedure without TPM.
\item\emph{DAA keygen \& join}: Generate the DAA keypair and save it to disk.
@ -116,16 +118,16 @@ We split the tasks of a Digidow sensor in several parts to document the conrtibu
\subsection{Disk Usage}
In this early stage of the prototype, any statistics about how much disk space is required to run this setup is not useful.
All programs besides the face embedding application are rather small, the binaries itself have a size ofless than 100\,kB.
All programs besides the face embedding application are rather small, the binaries itself have a size ofless than 100\,kB.
The installing process is still manual requiring a local build environment for C and Rust.
Furthermore the programs require a list of dependencies which need to be installed with the package manager.
Hence neither the size of the executables, nor the total disk occupation is informative for productive estimations.
Simlarly, the face embedding application should be seen as example of a biometric sensor, making a detailed discussion about time and space efficiency less meaningful.
\subsection{Memory Usage}
First, we look into the memory footprint of each part by executing them via\texttt{/usr/bin/time}.
It measures the the maximum resident size im memory during lifetime, which includes stack, heap and data section.
\autoref{tab:memoryusage} show the maximum usage of each task during 10000 runs in the different IMa configurations \texttt{off}, \texttt{fix}, and \texttt{enforcing}.
First, we look into the memory footprint of each part by using\texttt{/usr/bin/time}.
It measures the the maximum resident size in memory during lifetime, which includes stack, heap and data section.
\autoref{tab:memoryusage} shows the maximum usage of each task during 10,000 runs in the different IMA configurations \texttt{off}, \texttt{fix}, and \texttt{enforcing}.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
@ -147,11 +149,11 @@ It measures the the maximum resident size im memory during lifetime, which inclu
The memory allocation is constant for all parts in this table.
Besides calculating the face embedding of the captured image, the whole transaction can be executed using few Megabytes of heap memory.
This would fit on most embedded devices running a Linux kernel.
However, the face embedding algorithm uses over 800\,MB and requres the majority of the computation time as shown below.
However, the face embedding algorithm uses over 800\,MB and requires the majority of the computation time as shown below.
\subsection{Memory Safety}
\label{ssec:memory-safety}
During these memory tests, valgrind showed a large number of possible memory leaks in the python binary itself.
During these memory tests, valgrind showed a large number of possible memory leaks in the Python binary itself.
@ -179,12 +181,12 @@ Valgrind ends with the report as follows:
\end{lstlisting}
This report shows that the Python binary (here Python 3.8 from Ubuntu 20.04) is not memory safe, which is a significant drawback for the system and software integrity.
Any binary which is directly involved in the DAA protocol frees every allocated block.
Furthrmore any binary in the TPM2 software stack is memory safe according to valgrind.
Furthermore, any binary in the TPM~2.0 software stack is memory safe according to valgrind.
The used shell commands may not free every allocated block, however valgrind still finds no errors in these programs.
\subsection{Performance}
\autoref{tab:wholeperformance} shows the time consumption for each task with its minimum, average and maximum results over 10000 runs.
\autoref{tab:wholeperformance} shows the time consumption for each task with its minimum, average and maximum results over 10,000 runs.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
@ -238,8 +240,8 @@ Consequently, the difference between fixing and enforcing mode is to compare the
Since IMA measures every loaded resource, the corresponding log file will constantly increase during testing.
Unfortunately the integrity log is required to collect the data for the Digidow attestation message.
Furthermore, it is clear that every Digidow transaction contributes to the log since the handover beweent the single tasks is done based on files.
Consequently, we expected a runtime dependent on the number of runs and the average and maximum runtime in \autoref{tab:wholeperformance} remains unavailable when IMA is enabled.
Furthermore, it is clear that every Digidow transaction contributes to the log since the handover beween the single tasks is done based on files.
Consequently, we expected a runtime dependent on the number of runs, making average and maximum runtime in \autoref{tab:wholeperformance} unavailable when IMA is enabled.
The graphs of \autoref{fig:time-digidow-transaction} show the runtime of each of the runs on both tested systems and with IMA in fixing or enforcing mode respectively.
\begin{figure}
@ -250,16 +252,17 @@ The graphs of \autoref{fig:time-digidow-transaction} show the runtime of each of
\caption{Time consumption of a Digidow transaction on the tested systems}
\label{fig:time-digidow-transaction}
\end{figure}
\end{figure}\ToDo (Does this really indicate quadratic or exponential trend?)
Each run is split into the four parts of a Digidow transaction.
The graphs clearly show that our expectation of a linear relation between runtime and number of runs were not satisfied.
It seems that collecting the integrity log has an estimated complexity of $O(n^2)$.
Furthermore, it is interesting, that System 1 with the newer AMD processor seems to be faster in the beginning.
When the number of runs reach 10000, the system need significantly more time than System 3 with the Intel processor.
Since the software setup on both systems is comparable (Kernel version, Linux distro, installed programs, setup with respect to \autoref{cha:implementation}), the reason for this difference can probably be found either in the microarchitectural implementation or in (less) optimized code for the AMD CPU.
When the number of runs reach 10,000, the system needs significantly more time than System 3 with the Intel processor.
Since the software setup on both systems is comparable (Kernel version, Linux distro, installed programs, setup with respect to \autoref{cha:implementation}), it is not clear what the reason for this difference is.
It may be found either in the microarchitectural implementation or in (less) optimized code for the AMD CPU.
When IMA is in fixing or enforcing mode, the corresponding log will be filled with information about every accessed file.
The numbers in \autoref{tab:imalogentries} are taken from the integrity log after 10000 Digidow transaction tests.
The numbers in \autoref{tab:imalogentries} are taken from the integrity log after 10,000 Digidow transaction tests.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
@ -286,7 +289,7 @@ The number depends on services and daemons started during the boot sequence.
Not every service is consistently loaded every time and---depending on its individual state---the number of files loaded by the service may differ over several boot attempts.
Predicting the sequence of entries in the log is currently not possible since the kernel is taking advantage of the multicore CPU by starting services and daemons in parallel when possible.
In the example of \autoref{tab:imalogentries}, System 3 loaded parts of the python environment before root could login.
In the example of \autoref{tab:imalogentries}, System 3 loaded parts of the Python environment before root could login.
These resources were partly used by the tensorflow application.
Consequently, these two entries are very volatile and hence hard to predict.
However, the contribution of capture, collect and send as well as every further Digidow transaction are consistent.
@ -322,14 +325,14 @@ Creating a text file via text editor shows exactly this behaviour.
The missing attributes are also a problem when attemping to turn IMA off again.
This requires an updated command line and thereafter an updated unified kernel.
Generating the new kernel work fine but moving the blob into the EFI partition fails due to the missing support of extended file attributes.
Generating the new kernel works fine but moving the blob into the EFI partition fails due to the missing support of extended file attributes.
The copy process seems to create the file, but it fails when trying to write the first blocks.
As a result, the only way to update the kernel on this system is to boot a backup kernel with IMA set to \texttt{fix} or \texttt{off} and moving the file to the EFI partition.
As a result, the only way to update the kernel on this system is to boot a backup kernel with IMA set to \texttt{fix} or \texttt{off} and moving the file to the EFI partition.\ToDo(what about overwriting the whole partition with a new image?)
Another relevant part for attestation is to use the integrity log file do recalculate the produced hashes.
This means on one hand to recalculate the hash in the integrity log entry.
On the other hand the chain of hashes should result into the value held in PCR 10.
A small script shown in \autoref{code:verifyimash} tries to this calculation.
A small script shown in \autoref{code:verifyimash} tries to do this calculation.
\begin{lstlisting}[numbers=none,float, caption={Attempt to recalculate the value of PCR 10}, label={code:verifyimash}]
#!/usr/bin/bash
set -e
@ -343,10 +346,11 @@ A small script shown in \autoref{code:verifyimash} tries to this calculation.
It uses the debug register PCR 16 which is resetable without reboot and has the same initial value as the first 10 PCRs.
When IMA is off, the log holds only one entry of the boot aggregate.
Then the SHA1 value can be computed with that script.
However, comprehending the PCR 10 value with IMA enabled was not possible.
However, it was not possible to reproduce the value in PCR 10 value when enabling IMA.
Our tests took into account that PCR and log file could be modified when loading programs to read these resources the first time.
Loading the log at least two times eventually ends up in a stable log and PCR value (it does not change anymore even when reading the log another time).
The value of PCR 10 was still not reproducible.
Furthermore the documentation of calculating these vaules did not mention how the sha256 hash in PCR 10 is calculated.
Furthermore the documentation of calculating these values does not mention how the sha256 hash in PCR 10 is calculated.
\texttt{tpm2\_pcrextend} requires a sha256 hash as input for the corresponding PCR bank, but the integrity log only provides sha1 hashes.
Hence, any verification procedures regarding the sha256 bank of PCR 10 are currently not implemented.
\ToDo (Does ascii\_runtime\_measurements contain the SHA1 hashes of the file or the history of PCR 10 values after appending the file hash into it?) Figure 2.2 (p16) shows that this should be the template hash
In this chapter, we summarize the test results and discuss the limitations of the current prototype.
Consequently, we show a number of topics worth to investigate in the future before the we conclude this thesis.
We are able to demonstrate in this contribution a working prototype for a Digidow sensor.
Although only a minimal feature set is implemented, it shows a direction where developments can step forward.
Furthermore, this setup is one of the first applications using a group signature scheme.
In context of the Digidow project, a working DAA demo can be useful for other use cases as well.
Consequently, this contribution is essential for further research and development in the Digidow project.
We summarize in this chapter the test results and discuss the limitations of the current prototype.
Consequently, we show a number of topics worth to investigate in the future.
\section{State of Work}
The test results show that the concept can be implemented on a basic level.
Trusted boot works fine with recent linux kernels and bootloaders if required.
Trusted boot works fine with recent Linux kernels and bootloaders if required.
It is furthermore enabled by default on many Linux distributions and works out of the box when disk encryption is not needed.
Similarly, the DAA group signature scheme is working with and without using a TPM.
@ -19,14 +25,14 @@ Linux distributions provide more and more support for IMA in recent years.
Ubuntu's first LTS release with IMA was 20.04 which we used for this work.
The different predefined rulesets work as expected but result in a large set of entries in the integrity log.
The application on top of this setup simulate the start of a Digidow transaction by capturing and processing an image.
The application on top of this setup simulates the start of a Digidow transaction by capturing and processing an image.
This processed image data is then sent to the PIA acting here as a DAA verifier.
We showed in the testresults that this demo application work reliable but yet very inefficient.
We showed in the testresults that this demo application works reliable but yet very inefficient.
The demonstration just shows a part of the workload of a full Digidow transaction.
\section{Limitations}
\label{sec:limitations}
The main contribution of the computation delay is processing the image data which is computed with a tensorflow application.
The main contribution to the computation delay is processing the image data which is computed with a tensorflow application.
The tested systems have no GPU, requiring them to compute the neural network on the CPU.
Similarly, the image capturing part, taking about 1\,s, is very inefficient.
Capturing an image from a camera and saving it to disk should be doable in less than 0.1\,s.
@ -35,32 +41,32 @@ Signing and sending adds another 0.25\,s to the transaction.
When capturing biometric data in an efficient way, the interaction with the TPM will be a major contribution to the whole transaction time.
Besides the slow demo implementation, we found several other limitations while building the environment.
In the context of using the TPM, we faced several problems that are not solved yet.
In the context of using the TPM, we faced several problems that are not solved yet:
\begin{itemize}
\item One TPM2.0 module is not usable since it has an outdated firmware and we were not able to update the TPM.
\item One TPM~2.0 module is not usable since it has an outdated firmware and we were not able to update the TPM.
The manufacturer directed us to the TPM vendor for firmware updates and the vendor seems to ignore any request in that context.
Although it is possible to update the TPM, we were not able to get a recent firmware blob for this TPM.
\item The TPM manufacturer, Infineon in our case, host the certificate chain on a website where only the domain name leads to the manufacturing company.
The website provides further cryptographic trust.
When the certificate chain is broken, it is not clear whether the user posseses a corrupt TPM or the website just provides bogus certificates.
\item The chain of trust from the TPM manufacturer is not complete since there is no cryptographic link between the certified endorsement key and the DAA member key.
The DAA member key is in the current implementation only located in the endorsement hierarchy.
\item The TPM manufacturer, Infineon in our case, hosts the certificate chain on a website where only the domain name leads to the manufacturing company.
The website does not provide further cryptographic trust.
When the certificate chain is broken, it may not be clear whether the user posseses a corrupt TPM or the website just provides bogus certificates.\ToDo(Is this really that much of an issue?)
\item The chain of trust between TPM manufacturer and DAA member key is not complete in the current implementation since there is no cryptographic link between the certified endorsement key and the DAA member key.
The member key is only located in the endorsement hierarchy.
\item The documentation of the TPM software stack is not beginner friendly.
On one hand, the TCG documentation is free to use and provides a narrow definition of a TPM.
On the other hand, it is optimized to be machine readable and it is usually necessary to read parts of Arthur's \emph{A Practical Guide to TPM 2.0}~\cite{arthur15} to understand how the documentation is managed.
\item Using the TPM2 tools for low effort interaction with the TPM is relatively easy. Unfortunately, the parameters are incompatible over its major releases, breaking any scripts depending on that.
On the other hand, it is optimized to be machine readable and it is usually necessary to read parts of Arthur et al. \emph{A Practical Guide to TPM~2.0}~\cite{arthur15} to understand how the documentation is managed.\ToDo(How does this guide not solce the gap? AW: I NEED a guide to be able to read the docs.)
\item Using the TPM~2.0 tools for low effort interaction with the TPM is relatively easy. Unfortunately, the parameters are incompatible over its major releases, breaking any scripts depending on that.
These differences are not documented and not announced publicly, making it hard to update any shell scripts depending on that.
\end{itemize}
Similar to using TPMs, the integrity of the sensor's hardware and software are facing some essential problems.
Similar to using TPMs, the integrity of the sensor's hardware and software are facing some essential problems:
\begin{itemize}
\item The integrity log is currently too large to send it within the attestation message to the DAA verifier.
In the current setup, the integrity documentaaation of this log is key to generate trust between sensor and PIA.
In the current setup, the integrity documentation of this log is key to generate trust between sensor and PIA.
Furthermore, it is still not defined how the PIA can efficiently compute an answer to the question whether to trust the sensor or not, given the attestation message and the integrity log.
\item IMA is only able to provide proves about staic files and resources.
\item IMA is only able to provide proofs about static files and resources.
Using a program which dynamically loads code from remote resources is an efficient way to circumvent any integrity restrictions.
Since the test setup is using the network interface, this is a relevant attack vector against system integrity and trust.
\item The features of IMA are poorly documented and some of the tools only support TPM1.2 which is already outdated.
\item The features of IMA are poorly documented and some of the tools only support TPM~1.2 which is already outdated.
Although the support of Linux distributions increases, it is not clearly stated which release supports IMA and which does not.
\end{itemize}
@ -72,15 +78,15 @@ Similar to using TPMs, the integrity of the sensor's hardware and software are f
%\end{itemize}
\section{Future Work}
Given the limitations in the current setup, we provide some thoughts which might be worth implementing on thop of this contribution.
Given the limitations in the current setup, we provide some thoughts which might be worth implementing on top of this contribution.
Depending on the usage model, it might be worth extending the DAA scheme into a full dynamic group signature scheme.
Camenisch et al.~\cite{camenisch17} discuss how the existing scheme could be extended to support the features of dynamic groups by implementing signature based revocation.
Although their concept seems to work, there is no implementation available in the public and it is not recommended to implement cryptographic algorithms by oneself.
Although their concept seems to work, there is no implementation available in the public and it is not recommended to implement cryptographic algorithms by oneself.\ToDo(Well, that does not really hold in this case)
We discussed in the previous section a missing link in the chain of trust of the TPM.
This gap could be closed by certifying that the DAA membership key is in the endorsement hierarchy.
Since the EK has no signing property, the certification procedure uses the attestation key (AK) and the attestation identity key (AIK) to prove this link.
The theoretical concept is described by Arthur et al.~\cite{arthur15} at pages 109 ff.
The theoretical concept is described by Arthur et al. at pages 109 ff~\cite{arthur15}.
Eric Chieng~\cite{Chieng2021} wrote on his blogpost a practical approach to impelement this certification.
This solution seems to close the missing link in the chain of trust.
@ -93,13 +99,12 @@ Several approaches should be investigated to mitigate this problem:
Therefore the log should remain constant in size or at least independent of the number of transactions.
An approach for that would be to transfer the data between the different steps via pipes.
\item Sign the hashes of static files like binaries or configuration files with the kernel's extended verification module which works on top of IMA.
When files with a vaild signature are accessed, it might not be necessary to add them into the integrity log.
How are updates managed with this setup if even possible?
When files with a valid signature are accessed, it might not be necessary to add them into the integrity log.
\item Make the root partition read only where applicable.
Every file read from this partition can be excluded from the integrity log.
A Ramdisk could then be used to hold all working files of the sensor.
This setup might satisfy similar goals compared to the previous approach, but the update procedure might be easier.
\item Include the firmware of periherals.
\item Include the firmware of peripherals.
In the current setup, the integrity log takes only libraries and drivers into account.
However the peripherals like cameras or fingerprint sensors usually have a firmware onboard which should be measured similarly to BIOS or option ROMs.
Unfortunately we could not test a sensor which allows to extract the firmware that is acually running on the hardware.
@ -111,11 +116,11 @@ Auditd investigates a program during execution and is able to log every system c
It might be necessary to configure the daemon and to integrate the auditd execution log of the sensor's transaction part to the attestation message.
The results in \autoref{ssec:memory-safety} show that the memory safety is not given in every part of the demo.
The results in \autoref{ssec:memory-safety} show that memory safety is not given in every part of the demo.
This is, however, a key contribution to the system's integrity and hence the trust in it.
We recommend therefore to omit any use of scripting environments and to use memory-safe programming languages like Java or Rust.
According to this, the programs should be precompiled and installed only as binaries together with the required external resources.
The productive setup should not have any building tools installed.
The productive setup should not have any build tools installed.
Although we use an Ubuntu 20.04 server minimal setup, the majority of installed programs and services are not necessary for the Digidow sensor.
Consequently, reducing the system to a bare minimum reduces the complexity of auditing and certifying the setup as well as the resulting integrity log and attestation information.
@ -127,10 +132,3 @@ Ideally the transaction delay is independent of which sensor type is used.
Many of the measures above make the computation and hence the transaction time more efficient.
It is therefore necessary to define timing constraints to see whether further measures need to be implemented.
\section{Conclusion}
We are able to demonstrate in this contribution a working prototype for a Digidow sensor.
Although only a minimal feature set is implemented, it shows a direction where developments can step forward.
Furthermore, this setup is one of the first applications using a group signature scheme.
In context of the Digidow project, a working DAA demo can be useful for other use cases as well.
Consequently, this contribution is essential for further research and development in the Digidow project.
