@ -9,7 +9,7 @@ These embedded systems form the so called \emph{smart} devices.
All these new devices made life a lot easier in the past decades.
Many of them automate services to the public like managing the bank account, public transportation or health services.
The list of digital service is endless and will still grow in the future.
The list of digital services is endless and will still grow in the future.
The downside of all these digital services is that using these services generate a lot of data.
Besides the intended exchange of information, many of the services try to extract metadata as well.
@ -44,14 +44,14 @@ Unfortunately, this does not apply to a fingerprint since a human usually has on
\section{Trust}
When using a system with an authentication method, trust plays a key role.
For black box systems this trust is cast to the vendor of the system or device.
There is however no mathematical proof that the device is indeed executing the software as intended from the vendor.
There is however no mathematical proof that the device is indeed executing the software as intended by the vendor.
This thesis will therefore use the term \emph{trust} as a cryptographic chain of proofs, that a system is behaving in an intended way, a so called \emph{Chain of Trust}.
By providing a Chain of Trust, a user can ask the vendor for a certification of its devices and consequently comprehend the state of the system at hand.
The Chain of Trust will be separated into two parts, namely the creation of trust on a certain system, and the transfer of trust over the network for verification purposes.
\section{Project Digidow}
The Institute for Networks and Security is heavily using the cryptographic form of trust in the project \emph{Digital Shadow} (Digidow).
The Institute of Networks and Security is heavily using the cryptographic form of trust in the project \emph{Digital Shadow} (Digidow).
Digidow introduces an electronic authentication system, which aims to minimize any generation of metadata on system and network level and hence maximizes the level of privacy for their users.
The project furthermore aims to specify a scalable solution for nationwide or even worldwide applications including provable trust and integrity to the user.
@ -75,12 +75,12 @@ DigiDow introduces five main parties which are involved in a common authenticati
\item\emph{Verifier}: This is the party that verifies the whole authentication process and may finally trigger the desired action.
It is usually strongly connected with the sensor which starts the identification process.
\item\emph{Sensor}: For authentication, an individual has to be uniquely identified.
Therefore, the sensor records biometric data from the individual and passes it to the PIA via the Dididow network.
Therefore, the sensor records biometric data from the individual and passes it to the PIA via the Digidow network.
Sensors are not limited to sensing biometric data.
However, we focus in this thesis on developing a prototype of a biometric sensor (BS).
\end{itemize}
When an individual wants to be identified by Digidow, he will eventually step in front of a sensor.
When an individual wants to be identified by Digidow, she or he will eventually step in front of a sensor.
This defines the beginning of a Digidow transaction.
The procedure is as follows:
\begin{enumerate}
@ -93,7 +93,7 @@ The procedure is as follows:
\end{enumerate}
The above illustration is an early draft of the whole setup and is under constant development.
Latest developments the whole system will be published on the Digidow project page\footnote{\url{https://digidow.eu}}.
Latest developments of the whole system will be published on the Digidow project page\footnote{\url{https://digidow.eu}}.
\section{Our Contribution: Deriving Trust from the Biometric Sensor}
The Digidow network is designed to preserve privacy and to build trust for any user.
@ -123,22 +123,22 @@ Since the Digidow protocols are not yet finalized, some assumptions are defined
\begin{itemize}
\item Any network discovery is omitted. BS and PIA are assumed to be reachable directly via TCP/IP.
\item We look into a protocol which proves trustworthiness from BS to PIA.
Any further proofs necessary for a verifier are also not focused in this thesis.
Any further proofs necessary for a verifier exceed the contribution of this thesis.
\item The sensitive datasets will be transmitted in cleartext between BS and PIA.
It is considered easy to provide an additional layer of encryption for transportation.
However this should be considered in the Digidow network protocol design.
This thesis focuses only on the trust part between BS and PIA.
\itemAny built system is considered secure on a hardware level.
Any threats which are attacking the system without changing any running software on the system may remain undetected.
This includes USB wire tapping or debug interfaces within the system revealing sensitive information.
\itemWe assume that any built system is secure against any hardware level threats.
Attacks targeting the system without changing any running software on the system may remain undetected.
For example, USB wire tapping or debug interfaces within the system may reveal sensitive information.
\end{itemize}
\section{Organization}
In the next chapter, we will indroduce and discuss existing contributions in the targeted scientific area.
This includes especially the theoretical foundations of the network protocol which is part of our contribution.
Together with that, we will introduce our theoretical solution for the previously stated problems in \autoref{cha:concept}.
\autoref{cha:implementation} introduces then a working implementation with all necessary parts for provisioning the environment and the used hosts accordingly.
Finally we will present the results and limitations in \autoref{cha:conclusion} and give an overview of future work.
We introduce then in \autoref{cha:implementation} a working implementation with all necessary parts for provisioning the environment and the used hosts accordingly.
Finally we will present the results and limitations in \autoref{cha:state-of-work-and-conclusion} and give an outlook on future work.
@ -10,7 +10,7 @@ The generated trust should then be provable by an external party---in our case t
\label{sec:trusted_platform_module_tpm_}
The \emph{Trusted Platform Module} (TPM) is a small coprocessor that introduces a variety of cryptographic features to the platform.
This module is part of a standard developed by the Trusted Computing Group (TCG), which released the current revision 2.0 in 2014\cite{tcg20}.
This module is part of a standard developed by the Trusted Computing Group (TCG), which released the current revision 2.0 in 2014~\cite{tcg20}.
The hardware itself is strongly defined by the standard and comes in the following flavors:
\begin{itemize}
@ -20,7 +20,7 @@ The hardware itself is strongly defined by the standard and comes in the followi
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.
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.
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.
\item\emph{TPM Simulator.} For testing reasons, it is possible to install a TPM simulator.
@ -31,7 +31,7 @@ Dedicated and mounted devices are small microcontrollers that run the TPM featur
fTPMs will be updated with the platform updates of the CPU manufacturers.
The combination of well constrained hardware and features, an interface for updates and well defined software interfaces make TPMs trustworthy and reliable.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it returns 23 entries\cite{mitre18}.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it returns 23 entries~\cite{mitre18}.
Eight of them were filed before the new standard has been released.
Another seven entries refer to vulnerabilities in custom TPM implementations.
Six entries refer to the interaction between the TPM and the operating system, especially the TPM library and the shutdown/boot process.
@ -39,11 +39,11 @@ The last two entries describe vulnerabilities in dedicated TPM chips, which are
\begin{itemize}
\item\emph{CVE-2017-15361}: TPMs from Infineon used a weak algorithm for finding primes during the RSA key generation process.
This weakness made brute force attacks against keys of up to 2048 bits length feasible.
According to Nemec et al.\cite{Nemec17}, 1024 bit keys required in the worst case scenario 3 CPU months and 2048 bit keys needed 100 CPU years when using one core of an Intel Xeon E5-2650 v3 CPU.
According to Nemec et al.~\cite{Nemec17}, 1024 bit keys required in the worst case scenario 3 CPU months and 2048 bit keys needed 100 CPU years when using one core of an Intel Xeon E5-2650 v3 CPU.
Infineon was able to fix that vulnerability per firmware update for all affected TPMs.
\item\emph{CVE-2019-16863}: This vulnerability is also known as "TPM fail" \cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and lattice attacks.
\item\emph{CVE-2019-16863}: This vulnerability is also known as ``TPM fail''~\cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and lattice attacks.
The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM implementation.
Infineon TPM showalso some non-expected behaviour, but this could not be used for data exfiltration.
Infineon TPM also show some non-expected behaviour, but this could not be used for data exfiltration.
STM provided an update like Infineon did for their TPMs.
Intel's fTPM required a platform firmware update to solve the issue.
\end{itemize}
@ -60,15 +60,15 @@ On top of the cryptographic hardware, the TCG provides several software interfac
Although the interface was formally published from the beginning, an implementation is available only since end of 2019.
\end{itemize}
The reference implementation of these APIs is published on Github\cite{tpmsoftware20} and is still under development.
The reference implementation of these APIs is published on Github~\cite{tpmsoftware20} and is still under development.
The repositories are maintained by members of TCG.
At the point of writing stable interfaces are available for C and C++, but other languages like Rust, Java, C\# will be served in the future.
The repository additionally provides the tpm2-tools toolset which provides the FAPI features to the command line.
Unfortunately, the command line parameters changed several times during the major releases of tpm2-tools\cite{pornkitprasan19-tpmtools}.
Unfortunately, the command line parameters changed several times during the major releases of tpm2-tools~\cite{pornkitprasan19-tpmtools}.
\subsection{The Hardware}
\label{sssec:tpm-hardware}
With the previous mentioned software layers the TCG achieved independence of the underlying hardware.
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.
@ -76,14 +76,14 @@ It is a passive device with some volatile and non-volatile memory, which provide
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.
Since TCG published its documents, several IT security teams investigated the concept and implementations of TPMs.\ToDo
\subsection{TPM Key Hierarchies}%
\label{sub:tpm_key_hierarchies}
A TPM comes with four different key hierarchies.
These hierarchies fulfill different tasks and are used in different use cases on the whole platform.
Will Arthur et al.\cite{arthur15} provide a more detailed description on how the hierarchies work together.
Arthur et al.~\cite{arthur15} provide a more detailed description on how the hierarchies work together.
\begin{itemize}
\item\emph{Platform Hierarchy}: This hierarchy is managed by the platform manufacturer. The firmware of the platform is interacting with this hierarchy during the boot process.
\item\emph{Storage Hierarchy}: The storage of a platform is controlled by either an IT department or the end user and so is the storage hierarchy of the TPM.
@ -93,7 +93,7 @@ Will Arthur et al.\cite{arthur15} provide a more detailed description on how the
\item\emph{NULL Hierarchy}: The NULL hierarchy is the only non-persistent hierarchy when rebooting the platform. It provides many features of the other hierarchies for testing purposes.
\end{itemize}
Each of the persistent hiearchies represent its own tree of keys, beginning with a root key.
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.
The process of key generation described below is similar to all three persistent hierarchies.
@ -109,10 +109,10 @@ The \emph{Endorsement Key} (EK) is the root key for the corresponding hierarchy.
\autoref{fig:ek-key-generation} illustrates the certificate chain of building a new EK.
Every TPM has, instead of the full EK, a unique key seed to derive root keys from.
The EK can then be generated with a \emph{key derivation function} (KDF) which allows to add additional entropy to that of the TPM.
According to Arthur et al.\cite[arthur15] in chapter 15, this additional entropy is not used and the parameter field is filled with zeroes.
According to chapter 15 of Arthur et al.~\cite{arthur15}, this additional entropy is not used and the parameter field is filled with zeroes.
As a result, although it is possible to generate an arbitrary number of EKs, the TPM generates always the same by default.
Only this default EK comes with a corresponding certificate which is signed by the TPM manufacturer by using its own root \emph{Certificate Authority} (CA).
Since the platform supports generating and using multiple root keys at a time, it is also possible to encrypt temporaily unused keys and store it on an external storage, e.g. on the platform disk.
Since the platform supports generating and using multiple root keys at a time, it is also possible to encrypt temporarily unused keys and store them on an external storage, e.g. on the platform disk.
Consequently it is quite easy to have different EKs at once to address privacy features also between different functions of the endorsement hierarchy.
\section{Trusted Boot}%
@ -133,7 +133,7 @@ In this context, \emph{Measuring} means a simple cryptographic extension functio
The function "$||$" represents a concatenation of two binary strings and the hash function is either SHA1 or SHA256.
The function $||$ represents a concatenation of two binary strings and the hash function is either SHA1 or SHA256.
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
Consequently, both hash results are available for further computations.
@ -142,13 +142,13 @@ This \emph{hash chain} enables the user to add an arbitrary number of hash compu
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 with the support with the newer SHA256 algorithm.
For TPM2.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.
The measured firmware blobs may still be the same.
So the TPM standard defines 24 PCRs for the PC platform, each with a special role and slightly different feature set.
The purpose of every PCR is well defined in Section 2.3.3 of the \emph{TCG PC Client Platform Firmware Profile}\cite{tcg-pc19} and shown in table \ref{tab:PCR}.
The purpose of every PCR is well defined in Section 2.3.3 of the \emph{TCG PC Client Platform Firmware Profile}~\cite{tcg-pc19} and shown in table \ref{tab:PCR}.
Especially those PCRs involved in the boot process must only be reset according to a platform reset.
During booting and running the system these registers can only be \emph{extended} with new measurements.
\begin{table}[ht]
@ -186,10 +186,10 @@ Later, when UEFI became popular, the PCR descriptions got adopted for the new pl
\label{sub:static_root_of_trust_for_measurement}
The standard defines which part of the platform or firmware has to perform the measurement.
Since the TPM itself is a purely passive element, executing instructions provided by the CPU, the BIOS/UEFI firmware has to initiate the measurement beginning with the binary representation of the firmware itself.
Since the TPM itself is a purely passive element executing instructions provided by the CPU, the BIOS/UEFI firmware has to initiate the measurement beginning with the binary representation of the firmware itself.
This procedure is described in the TCG standard and the platform user has to \emph{trust} the manufacturer for expected behavior.
It is called the \emph{Static Root of Trust for Measurement} (SRTM) and is defined in section 2.2 of the TCG PC Client Platform Firmware Profile\cite{tcg-pc19}.
As the mainboard manufacturer do not publish their firmware code, one may have to reverse engineer the firmware to prove correct implementation of the SRTM.
It is called the \emph{Static Root of Trust for Measurement} (SRTM) and is defined in section 2.2 of the TCG PC Client Platform Firmware Profile~\cite{tcg-pc19}.
As the mainboard manufacturers do not publish their firmware code, one may have to reverse engineer the firmware to prove correct implementation of the SRTM.
The SRTM is a small immutable piece of the firmware which is executed by default after the platform was reset.
It is the first piece of software that is executed on the platform and measures itself into PCR~0.
@ -208,8 +208,8 @@ It is noteworthy that the bootloader itself and its configuration payload is mea
This guarantees that the chain of trust keeps intact when the bootloader/OS takes control.
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 of 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}.
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
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.
@ -220,7 +220,7 @@ If all values match the expectations, the chain of trust exists between the SRTM
\label{sub:secure_boot}
Secure boot is another technology to prevent malware from being executed before the OS kernel is loaded.
Microsoft describe on their Documentation for Windows and UEFI what requirements are needed and how the secure boot process looks like\cite{microsoft14}.
Microsoft describe on their Documentation for Windows and UEFI what requirements are needed and how the secure boot process looks like~\cite{microsoft14}.
It is part of the UEFI specification and uses, similar to trusted boot, checksums of firmware, option roms and the boot loader.
These checksums are checked against a signature database, which is held within the platform's NVRAM.
The signatures are created with the platform key (PK) which is by default owned and managed by Microsoft.
@ -228,10 +228,10 @@ Although it is possible to install a new own PK and sign relevant software with
Shim is the gatekeeper for OSes not maintained by Microsoft.
The binary is signed with the official PK and uses itself a self signed CA to sign further executables.
A detailed description how shim works on Ubuntu is shown on their corresponding Wiki page\cite{ubuntuwiki20}.
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 instead of the TPM conventional NVRAM 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.Although 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.
@ -241,9 +241,9 @@ The benefit of using it seems to be very limited when not using a Microsoft OS.
\label{sec:integrity_measurement_architecture}
The \emph{Integrity Measurement Architecture} (IMA) is a Linux kernel extension to extend the chain of trust to the running application.
IMA is officialy supported by RedHat and Ubuntu and there exists documentation to enable IMA on Gentoo as well.
IMA is officially supported by RedHat and Ubuntu and there exists documentation to enable IMA on Gentoo as well.
Other OS providers may not use a kernel with the required compile flags and/or do not provide userland software required to manage IMA.
The IMA project page describes the required kernel features for full support in their documentation\cite{ima-overview}.
The IMA project page describes the required kernel features for full support in their documentation~\cite{ima-overview}.
The process of keeping track of system integrity becomes far more complex on the OS level compared to the boot process.
First, there are far more file system resources involved in running a system.
@ -271,7 +271,7 @@ IMA uses the \emph{integrity log} to keep track of any changes of local filesyst
This is a virtual file that holds every measurement that leads to a change on the IMA PCR.
When IMA is active on the system, the integrity log can be found in \texttt{/sys/kernel/security/ima/ascii\_runtime\_measurements}.
Before a file is accessed by the kernel, IMA creates an integrity log entry as it is shown in \autoref{fig:integrity-log-entry}.
Before a file is accessed by the kernel, IMA creates an integrity log entry as shown in \autoref{fig:integrity-log-entry}.
@ -280,11 +280,11 @@ Before a file is accessed by the kernel, IMA creates an integrity log entry as i
\end{figure}
Depending on the settings for IMA, a SHA1 or SHA256 hash is created for the file content.
The resulting \emph{filedata hash} will be concatenated with the corresponding metadata.
This concatenation will again be hashed into the so called \emph{template hash} which is independently of the previous algorithm a SHA1 checksum.
This concatenation will again be hashed into the so called \emph{template hash} which is independent of the previous algorithm a SHA1 checksum.
Finally, the template hash is the single value of the whole computation that will be extended into the PCR.
The integrity log holds at the end the filedata hash, the metadata and the template hash as well as the PCR index and the logfile format.
Unfortunately, recomputing the hash chain was not possible in the demonstration setup.
We discuss that problem in \autoref{cha:conclusion}.
We discuss that problem in \autoref{cha:state-of-work-and-conclusion}.
IMA knows three different file formats, where two of them can be used in recent applications.
The only difference between these formats lies in the used and logged metadata:
@ -325,13 +325,13 @@ 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}.
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}%
\label{sub:other_system_integrity_approaches}
Schear et al.\,\cite{keylime16} developed a full featured trusted computing environment for cloud computing.
Schear et al.~\cite{keylime16} developed a full featured trusted computing environment for cloud computing.
They show in their paper how a TPM of a hypervisor can be virtualized and used by the guest operating system.
This includes trusted bootstrapping, integrity monitoring, virtualization, compatibility with existing tools for fleet management and scalability.
The concept of a well known virtual environment does, however, not apply to our use case.
@ -351,8 +351,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. in \cite{camenisch16} and \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 im the TPM1.2 standard.
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.
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.
@ -394,7 +394,7 @@ The one-way protocol consists of three procedures:
\end{equation*}
\item\emph{Verify.} The verifier knows the values of $y$ and $g$, as they are usually public. The message $m$ comes with the signature values $c$ and $s$.
He computes the value
It computes the value
\begin{equation*}
c':=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^sy^c)\quad\text{and verifies, that}\quad c' = c\,\text{.}
\end{equation*}
@ -542,15 +542,14 @@ The feature of linking messages together requires further security features with
\begin{itemize}
\item\emph{Non-frameability}: No one can create signatures that the platform never signed, but that link to messages signed from that platform.
\item\emph{Correctness of link}: Two signatures will link when the honest platform signs it with the same basename.
\item\emph{Symmetry of Link}: It does not matter in which order the linked signatures will be proven. The link algorithm will always output the same result.
\item\emph{Symmetry of link}: It does not matter in which order the linked signatures will be proven. The link algorithm will always output the same result.
\end{itemize}
%TODO Überleitung zum nächsten Kapitel und FIDO einbauen
\subsection{Standardization of DAA}%
\label{sub:standardization_of_daa}
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, 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}
This standard implements a close variant of the previously described concept.
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.
@ -41,7 +41,7 @@ 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 TPM2.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.
@ -51,7 +51,7 @@ With a wiring adapter any TPM board would work on any mainboard supporting TPM2.
\section{Select the Operating System}
The OS needs to fulfill three requirements for this prototype.
First, the TPM must be supported by the kernel.
Second, the OS has to support a recent version of the TPM software stack (TSS 3.0.x or newer at the point of writing) for using the Xaptum ECDAA\cite{xaptum21}
Second, the OS has to support a recent version of the TPM software stack (TSS 3.0.x or newer at the point of writing) for using the Xaptum ECDAA~\cite{xaptum21}
project with enabled hardware TPM.
Similarly, the \texttt{tpm2-tools} must be available in a version newer than \texttt{4.0.0}.
Finally, the support for the Integrity Measurement Architecture (IMA) must be activated in the kernel and supported by the OS.
@ -92,13 +92,13 @@ 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}.
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.
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.
Embedded systems like a productive 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
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
and Arch respectively.
This large EFI file contains the initramfs, kernel command line and the kernel itself.
@ -197,7 +197,7 @@ 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:
The Gentoo wiki page about IMA~\cite{gentoo19} describe which kernel compiler flags are related to IMA:
@ -34,7 +34,7 @@ According to these results, we assume that less than 10\,KB are used to hold the
IMA appears to have an easy setup but a complex set of consequences.
First, we show the impact on disk usage when IMA is enabled.
In this case, the file hashes will be stored as extended file attributes.
According to the xattr man page\cite{XattrMan2021}, the ext4 file system creates therefore a single block per file where all extended attributes must find place.
According to the xattr man page~\cite{XattrMan2021}, the ext4 file system creates therefore a single block per file where all extended attributes must find place.
The block size of the used filesystem is 4\,KB.
The number of files is determined with the following command
@ -47,7 +47,7 @@ In the context of using the TPM, we faced several problems that are not solved y
The DAA member key is in the current implementation 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.
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.
These differences are not documented and not announced publicly, making it hard to update any shell scripts depending on that.
\end{itemize}
@ -74,14 +74,14 @@ Similar to using TPMs, the integrity of the sensor's hardware and software are f
\section{Future Work}
Given the limitations in the current setup, we provide some thoughts which might be worth implementing on thop 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.
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.
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.
Eric Chieng\cite{Chieng2021} wrote on his blogpost a practical approach to impelement this certification.
The theoretical concept is described by Arthur et al.~\cite{arthur15} at pages 109 ff.
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.
Verifying the integrity of the sensor is still not solved.
%% Hier Informationen für den rechten Block unter dem JKU-Logo eingeben, wobei die Elemente mit einem Buchstaben jeweils für die Beschreibung und mit Doppelbuchstaben für den Inhalt sind.
%% Anzuführen bei Masterarbeit: Eingereicht von, Anfegertigt am, BeurteilerIn, Mitbetreuung.
@ -28,17 +28,17 @@
\def\elementBB{\textbf{Institute for Networks and Security}}
