@ -64,7 +64,7 @@ The project furthermore aims to specify a scalable solution for nationwide or ev
Mayrhofer et al.~\cite{Mayrhofer2020} provide an overview of the Digidow network as shown in \autoref{fig:digidow-overview}.
Mayrhofer et al.~\cite{Mayrhofer2020} provide an overview of the Digidow network as shown in \autoref{fig:digidow-overview}.
The nodes using the Digidow network and their interactions are not fully specified at the time of this writing.
The nodes using the Digidow network and their interactions are not fully specified at the time of this writing.
Therefore the processes may be adapted when necessary.
Therefore the processes may be adapted when necessary.
DigiDow introduces five main parties which are involved in a common authentication process.
Digidow introduces five main parties which are involved in a common authentication process.
\begin{itemize}
\begin{itemize}
\item\emph{Individual}: The human user who wants to be identified via the Digidow network.
\item\emph{Individual}: The human user who wants to be identified via the Digidow network.
\item\emph{Personal Identity Agent} (PIA): The PIA is the digital shadow of an individual.
\item\emph{Personal Identity Agent} (PIA): The PIA is the digital shadow of an individual.
@ -89,7 +89,7 @@ The procedure is as follows:
\item After receiving the digital representation of the sensor, the PIA identifies the individual if possible.
\item After receiving the digital representation of the sensor, the PIA identifies the individual if possible.
\item When identification was possible, the PIA eventually sends a proof of identification and a claim of the requested attributes to the verifier.
\item When identification was possible, the PIA eventually sends a proof of identification and a claim of the requested attributes to the verifier.
\item The verifier will check the cryptographic proofs of the claim and the sensor data.
\item The verifier will check the cryptographic proofs of the claim and the sensor data.
If successful, the verififier will grant the desired action for the asking individual.
If successful, the verifier will grant the desired action for the asking individual.
\end{enumerate}
\end{enumerate}
The above illustration is an early draft of the whole setup and is under constant development.
The above illustration is an early draft of the whole setup and is under constant development.
@ -134,7 +134,7 @@ Since the Digidow protocols are not yet finalized, some assumptions are defined
\end{itemize}
\end{itemize}
\section{Organization}
\section{Organization}
In the next chapter, we will indroduce and discuss existing contributions in the targeted scientific area.
In the next chapter, we will introduce 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.
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}.
Together with that, we will introduce our theoretical solution for the previously stated problems in \autoref{cha:concept}.
We introduce then in \autoref{cha:implementation} a working implementation with all necessary parts for provisioning the environment and the used hosts accordingly.
We introduce then in \autoref{cha:implementation} a working implementation with all necessary parts for provisioning the environment and the used hosts accordingly.
@ -17,7 +17,7 @@ The hardware itself is strongly defined by the standard and comes in the followi
\item\emph{Dedicated device.} The TPM chip is mounted on a small board with a connector.
\item\emph{Dedicated device.} The TPM chip is mounted on a small board with a connector.
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.
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.
\item\emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard.
Therefore, removing or changing the TPM is imossible.
Therefore, removing or changing the TPM is impossible.
All recent Intel and AMD platforms supporting TPM~2.0 are able to manage a TPM within the BIOS, even as mounted device.
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.
\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.
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.
@ -43,7 +43,7 @@ The last two entries describe vulnerabilities in dedicated TPM chips, which are
Infineon was able to fix that vulnerability per firmware update for all affected TPMs.
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.
The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM implementation.
Infineon TPM also show some non-expected behaviour, but this could not be used for data exfiltration.
Infineon TPM also show some non-expected behavior, but this could not be used for data exfiltration.
STM provided an update like Infineon did for their TPMs.
STM provided an update like Infineon did for their TPMs.
Intel's fTPM required a platform firmware update to solve the issue.
Intel's fTPM required a platform firmware update to solve the issue.
\end{itemize}
\end{itemize}
@ -63,8 +63,8 @@ On top of the cryptographic hardware, the TCG provides several software interfac
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.
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.
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.
The repository additionally provides the \texttt{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 \texttt{tpm2-tools}~\cite{pornkitprasan19-tpmtools}.
\subsection{The Hardware}
\subsection{The Hardware}
\label{sssec:tpm-hardware}
\label{sssec:tpm-hardware}
@ -142,7 +142,7 @@ The function $||$ represents a concatenation of two binary strings and the hash
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
Consequently, both hash results are available for further computations.
Consequently, both hash results are available for further computations.
The formula shows that a new PCR value holds the information of the preceeding value as well.
The formula shows that a new PCR value holds the information of the preceding value as well.
This \emph{hash chain} enables the user to add an arbitrary number of hash computations.
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.
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.
Therefore, the BIOS/UEFI has to provide a deterministic way to compute the hash chain if there is more than one operation necessary.
@ -214,7 +214,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 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 in PCR 8 and higher is not defined by TCG.
The support and the way how the measurements are done in PCR 8 and higher is not defined by TCG.
They only reserver PCR 8--15 for the OS.
They only reserve PCR 8--15 for the OS.
GRUB, for example, measures all executed GRUB commands, the kernel command line and the module command line by default into PCR 8, whereas any file read by GRUB will be measured into PCR 9~\cite{grub19}.
GRUB, for example, measures all executed GRUB commands, the kernel command line and the module command line by default into PCR 8, whereas any file read by GRUB will be measured into PCR 9~\cite{grub19}.
The whole process from initialization over measuring all software parts until the OS is started, is called \emph{Trusted Boot}.
The whole process from initialization over measuring all software parts until the OS is started, is called \emph{Trusted Boot}.
@ -227,7 +227,7 @@ If all values match the expectations, the chain of trust exists between the SRTM
Secure boot is another technology to prevent malware from being executed before the OS kernel is loaded.
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.
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.
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.
The signatures are created with the platform key (PK) which is by default owned and managed by Microsoft.
Although it is possible to install a new own PK and sign relevant software with it, you can only boot software signed from Microsoft by default when secure boot is enabled.
Although it is possible to install a new own PK and sign relevant software with it, you can only boot software signed from Microsoft by default when secure boot is enabled.
@ -248,16 +248,27 @@ An attacker could easily pass the same variables to the kernel, which boots then
As TPM~1.2 chips became available, Intel published an own standard for trusted virtual environments which they called \emph{Trusted Execution Technology} (TXT)~\cite{Intel2012}.
As TPM~1.2 chips became available, Intel published an own standard for trusted virtual environments which they called \emph{Trusted Execution Technology} (TXT)~\cite{Intel2012}.
It extends the standard from TCG by defining a measured launch, similar to trusted boot, for virtual machines.
It extends the standard from TCG by defining a measured launch, similar to trusted boot, for virtual machines.
When booting a VM, it measures the boot process and provides the results to the hypervisor.
When booting a VM, it measures the boot process and provides the results to the hypervisor.
As soon as the measuring results are available, the hypervisor is able to check those against known values and detect modified (= untrusted) machines.
As soon as the measuring results are available, the hypervisor is able to check those against known values and detect modified (= not trusted) machines.
The hypervisor can then act accordingly to defined policies or attest the integrity of the guest machine.
The hypervisor can then act accordingly to defined policies or attest the integrity of the guest machine.
AMD introduced a CPU extension similar to TXT which they called \emph{Secure Virtaul Machine} (SVM).
\subsection{Trusted Execution Environment}
\subsection{Trusted Execution Environment}
\emph{Trusted Execution Environment} (TEE) is in contrast to TXT a more generic approach.
TEE is an execution environment which is separated from the main CPU.
Therefore it defines an independent processor with separated memory and storage capabilities.
Only few \emph{trusted} programs are allowed to execute in this environment like cryptographic algorithms or remote attestation.
An implementation of TEE is, for example, the TPM standard and above mentioned TXT from Intel.
In contrast to TXT and SVM, ARM introduced a TEE where trusted and untrusted programs are executed on the same CPU.
This technology is called TrustZone and is available on Arm Cortex-A and Cortex-M architectures\footnote{\url{https://developer.arm.com/ip-products/security-ip/trustzone}}.
According to Arm's technical report~\cite{Arm2014}, TrustZone uses a Split-World approach where trusted programs can access all untrusted and trusted resources.
However untrusted programs only see the usual untrusted environment.
The trusted environment includes separate RAM, secure boot ROM, interrupt and memory controller and \emph{Direct Memory Access} (DMA) to the main memory.
Switching into the TrustZone is done on hardware level either by an external interrupt or by executing the \emph{Secure Monitor Call} (SMC).
Then the SoC saves the state of the CPU and activates the trusted environment.
After the trusted execution is finished, the saved CPU state is restored and normal operation can continue.
Since TrustZone is a general purpose approach for TEE, it is also possible to run a software TPM on this environment.
Although the name is similar to Intel's TXT, the goal of the \emph{Trusted Execution Environment} (TEE) is quite different.
Instead of \emph{trusting} the whole system, TEE is a separate portion of the main processor with separated memory and storage capabilities.
\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}%
\section{Integrity Measurement Architecture}%
\label{sec:integrity_measurement_architecture}
\label{sec:integrity_measurement_architecture}
@ -278,11 +289,11 @@ The system, however, might still be in a trustworthy state.
Finally, the user might know some additional data to the current value in the PCR register.
Finally, the user might know some additional data to the current value in the PCR register.
Since the value itself does not tell anything to the user, a measurement log must be written for every operation on this PCR index.
Since the value itself does not tell anything to the user, a measurement log must be written for every operation on this PCR index.
IMA comes with three property variables which set the behaviour of the architecture:
IMA comes with three property variables which set the behavior of the architecture:
\begin{itemize}
\begin{itemize}
\item\texttt{ima\_template} sets the format of the produced log.
\item\texttt{ima\_template} sets the format of the produced log.
\item\texttt{ima\_appraise} changes the behaviour when a file is under investigation.
\item\texttt{ima\_appraise} changes the behavior when a file is under investigation.
\item\texttt{ima\_policy} finally defines which resources should be analzyed.
\item\texttt{ima\_policy} finally defines which resources should be analyzed.
\end{itemize}
\end{itemize}
These settings will be discussed in more detail in the following.
These settings will be discussed in more detail in the following.
@ -326,7 +337,7 @@ Consequently, the PCR result of trusted boot is also embedded in the measurement
\label{ssub:ima_appraisal}
\label{ssub:ima_appraisal}
IMA comes with four different runtime modes.
IMA comes with four different runtime modes.
These modes set the behaviour especially when there exists no additional information about the file in question.
These modes set the behavior especially when there exists no additional information about the file in question.
\begin{itemize}
\begin{itemize}
\item\texttt{off}: IMA is completely shut down. The integrity log just holds the entry of the boot aggregate.
\item\texttt{off}: IMA is completely shut down. The integrity log just holds the entry of the boot aggregate.
\item\texttt{log}: Integrity measurements are done for all relevant resources and the integrity log is filled accordingly.
\item\texttt{log}: Integrity measurements are done for all relevant resources and the integrity log is filled accordingly.
@ -374,7 +385,7 @@ 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.
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.
Since then many different approaches of DAA were discussed.
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.
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 also includes the implementation 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.
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.
Unlike the description in the original paper, we describe the practical approach, which will be used in the following concept.
@ -522,7 +533,7 @@ These extensions were omitted in the following to understand the protocol more e
\item checks, that a complete join record $(gsk, (b,d))$ exists, and
\item checks, that a complete join record $(gsk, (b,d))$ exists, and
\item stores $(m, \bsn, r)$.
\item stores $(m, \bsn, r)$.
\end{itemize}
\end{itemize}
\item\tpm[i] completes the signature after it gets permission to do so.%TODO Why?
\item\tpm[i] completes the signature after it gets permission to do so.
\begin{itemize}
\begin{itemize}
\item Retrieve group record $(gsk, (b,d))$ and message record $(m, \bsn, r)$.
\item Retrieve group record $(gsk, (b,d))$ and message record $(m, \bsn, r)$.
@ -63,7 +63,7 @@ Given this environment, there are a number of threats that need to be considered
It is possible to log the protocol of those attached devices via Man-in-the-Middle attack on the USB cable.
It is possible to log the protocol of those attached devices via Man-in-the-Middle attack on the USB cable.
\item\emph{Attribute Extraction}: Similar to metadata extraction, the adversary might directly access the attributes via wiretapping the USB cable.
\item\emph{Attribute Extraction}: Similar to metadata extraction, the adversary might directly access the attributes via wiretapping the USB cable.
The adversary might be able to identify an individual with those attributes.
The adversary might be able to identify an individual with those attributes.
\item\emph{Modification or aggregation of sensitive data within BS}: The program which prepares the sernsor data for transmission could modify the data before sealing it.
\item\emph{Modification or aggregation of sensitive data within BS}: The program which prepares the sensor data for transmission could modify the data before sealing it.
The program can also just save the sensitive data for other purposes.
The program can also just save the sensitive data for other purposes.
\item\emph{Metadata extraction on network}: During transmission of data from the sensor into the Digidow network, there will be some metadata generated.
\item\emph{Metadata extraction on network}: During transmission of data from the sensor into the Digidow network, there will be some metadata generated.
An adversary could use these datasets to generate tracking logs and eventually match these logs to individuals.
An adversary could use these datasets to generate tracking logs and eventually match these logs to individuals.
@ -98,7 +98,7 @@ We decided to use the PC platform as hardware base for the prototype.
There are lots of different form factors available and you can extend the system with a broad variety of sensors.
There are lots of different form factors available and you can extend the system with a broad variety of sensors.
Furthermore, the platform provides full TPM support to enable cryptographic and integrity features.
Furthermore, the platform provides full TPM support to enable cryptographic and integrity features.
Finally, the platform can run almost all Linux variants and supports relevant pieces of software for this project.
Finally, the platform can run almost all Linux variants and supports relevant pieces of software for this project.
A flavour of Linux supporting all features described in this chapter, will be used as OS platform.
A flavor of Linux supporting all features described in this chapter, will be used as OS platform.
The ARM platform seem to be capable of all these features as well.
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.
However, the support for TPMs, the amount of available software and the ease of installation is better on the PC platform.
@ -172,7 +172,7 @@ In the Digidow context, the PIA should get, together with the biometrical measur
To reduce the complexity of this problem, we consider two assumptions:
To reduce the complexity of this problem, we consider two assumptions:
\begin{enumerate}
\begin{enumerate}
\item\emph{Network Discovery}: The PIA is already identified over the Digidow network and there exists a bidirecional channel between BS and PIA
\item\emph{Network Discovery}: The PIA is already identified over the Digidow network and there exists a bidirectional channel between BS and PIA
\item\emph{Secure Communication Channel}: The bidirectional channel is assumed to be hardened against wire tapping, metadata extraction and tampering.
\item\emph{Secure Communication Channel}: The bidirectional channel is assumed to be hardened against wire tapping, metadata extraction and tampering.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
@ -46,7 +46,7 @@ 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.
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.
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.
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 TPM~2.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 proprietary header.
\section{Select the Operating System}
\section{Select the Operating System}
The OS needs to fulfill three requirements for this prototype.
The OS needs to fulfill three requirements for this prototype.
@ -164,7 +164,7 @@ This example works for the default Ubuntu LVM on LUKS configuration.
The parameters activate also IMA which will be discussed later in this chapter.
The parameters activate also IMA which will be discussed later in this chapter.
If FDE is installed, the boot process needs to be aware of how to decrypt the disk.
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.
Therefore, the initramfs needs the LUKS binaries as well as the TPM software stack to unseal the passphrase with the PCR registers.
The unseal operation itself is then done with \autoref{code:tbpassphrasesh}, which also needs to exist in the initramfs.
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}
\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.
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.
@ -175,7 +175,7 @@ Using a clear text password file in the \texttt{/root} directory is not per se c
Furthermore only root has access to the target directory.
Furthermore only root has access to the target directory.
The backup is needed for updating the system and when issues with the TPM appear.
The backup is needed for updating the system and when issues with the TPM appear.
When an updated kernel is booted, the seal cannot be opened anymore since the old PCR values cannot be restored anymore.
When an updated kernel is booted, the seal cannot be opened anymore since the old PCR values cannot be restored anymore.
It is, of course possible to generate a new passphrase every time when the PCR values change intendedly.
It is, of course possible to generate a new passphrase every time when the PCR values change by intention.
In this case no passphrase need to be stored on the file system.
In this case no passphrase need to be stored on the file system.
Finally, \autoref{code:tbupdatekernelsh} creates the unified kernel according to \autoref{tab:efilayout} using the command \texttt{objcopy} and copies it on the EFI disk partition.
Finally, \autoref{code:tbupdatekernelsh} creates the unified kernel according to \autoref{tab:efilayout} using the command \texttt{objcopy} and copies it on the EFI disk partition.
@ -203,7 +203,7 @@ All features of IMA are already implemented in the kernel sources and do not nee
The Gentoo wiki page about IMA~\cite{gentoo19} describes which kernel compiler flags are required to enable IMA in a Gentoo kernel.
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~\cite{RedHat2020}, Redhat 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}.
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.
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 \texttt{/sys/kernel/security/ima/ ascii\_runtime\_measurements}.
Every kernel supporting IMA creates a virtual file at \texttt{/sys/kernel/security/ima/ ascii\_runtime\_measurements}.
@ -218,7 +218,7 @@ The first four parameters used in the kernel command line as shown in \autoref{c
\end{itemize}
\end{itemize}
Unfortunately, the resulting integrity log is between 2000 and 3000 lines long when the system is freshly booted.
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.
The log can blow up to several 10000 lines when the uptime exceeds several days.
Therefore, IMA has a policy language where 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.
It might, for example, be useful to exclude log files from being hashed.
@ -254,7 +254,7 @@ Two options are therefore available:
\item\emph{Attest}: Let the complete integrity log be part of remote attestation and verify the hash values against a trusted known value database.
\item\emph{Attest}: Let the complete integrity log be part of remote attestation and verify the hash values against a trusted known value database.
This makes the verification part very complex but the state of the attesting system is well documented.
This makes the verification part very complex but the state of the attesting system is well documented.
\item\emph{Sign}: Sign hash values for static files like executables or libraries.
\item\emph{Sign}: Sign hash values for static files like executables or libraries.
The host can directly check whether the file was tamepered with and act accordingly.
The host can directly check whether the file was tampered with and act accordingly.
Linux kernels support this feature with the \emph{extended verification module} (EVM).
Linux kernels support this feature with the \emph{extended verification module} (EVM).
\end{itemize}
\end{itemize}
We use the variant where the integrity log is part of the message.
We use the variant where the integrity log is part of the message.
@ -266,7 +266,7 @@ It might be useful in the future to use EVM to prevent executing unsigned or mod
IMA is a comprehensive tool for checking the integrity of a file or executable or library before it gets executed.
IMA is a comprehensive tool for checking the integrity of a file or executable or library before it gets executed.
When access is granted, IMA's job is done.
When access is granted, IMA's job is done.
Hence, IMA is a tool for static system analysis.
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.
An executable can however change its behavior 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.
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.
One approach for runtime analysis is to create a log of syscalls for a certain process.
@ -302,7 +302,7 @@ Other vendors like STM, AMD or Intel may provide certificates via download on th
The root certificate and the intermediate certificate need to be concatenated into one file to allow \texttt{openssl} to check the certificate chain as well.
The root certificate and the intermediate certificate need to be concatenated into one file to allow OpenSSL to check the certificate chain as well.
@ -331,7 +331,7 @@ Only the \emph{trusted} state of the sensor system and the membership in the cor
Hence, the group membership is an essential part to provide trust to the users, requiring a deep knowledge on what hardware and software is installed and which vulnerabilities it might have.
Hence, the group membership is an essential part to provide trust to the users, requiring a deep knowledge on what hardware and software is installed and which vulnerabilities it might have.
The DAA group membership states that the system is provisioned from a trusted party, namely the DAA issuer.
The DAA group membership states that the system is provisioned from a trusted party, namely the DAA issuer.
The level of trust is ultimative since the used version of DAA is only partly dynamic by lacking support of membership removal.
The level of trust is ultimate since the used version of DAA is only partly dynamic by lacking support of membership removal.
During a Digidow transaction, the sensor attests its state by signing a message containing the integrity log and the PCR registers.
During a Digidow transaction, the sensor attests its state by signing a message containing the integrity log and the PCR registers.
Any party interacting with the sensor is then able to check trustworthiness via integrity and valid membership of the sensor.
Any party interacting with the sensor is then able to check trustworthiness via integrity and valid membership of the sensor.
@ -381,7 +381,7 @@ Set the variable \texttt{DECDAA\_TPM\_SUPPORT} respectively:
Now, all prerequisities are installed to build and install the ECDAA network wrapper which is a contribution of this thesis.
Now, all prerequisites are installed to build and install the ECDAA network wrapper which is a contribution of this thesis.
\subsection{DAA Network Protocol}
\subsection{DAA Network Protocol}
\label{ssec:daa-network-protocol}
\label{ssec:daa-network-protocol}
@ -407,7 +407,7 @@ It is designed to match the workflow of a Digidow transaction, affecting the dec
If this is not the case, the member asks for it automatically.
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}.
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.
When the member is eventually part of the DAA group, it is \emph{tusted} by the Issuer, requiring a thorough inspection of the member beforehand.
When the member is eventually part of the DAA group, it is \emph{trusted} by the Issuer, requiring a thorough inspection of the member beforehand.
Since we only show a working demo of the cryptographic concept, we skipped any efforts to check the member system in this implementation.
Since we only show a working demo of the cryptographic concept, we skipped any efforts to check the member system in this implementation.
\begin{figure}
\begin{figure}
\centering
\centering
@ -437,7 +437,7 @@ The message contains, as shown in \autoref{code:daamessageformat} the face embed
Instead of putting the plain integrity log into this message, we decided to use only checksum and the number of entries to keep the message size rather small.
Instead of putting the plain integrity log into this message, we decided to use only checksum and the number of entries to keep the message size rather small.
We continue this discussion in more detail in the next chapter.
We continue this discussion in more detail in the next chapter.
Furthermore, the the ECDAA library limits the message size for signing to 1024 Bytes.
Furthermore, the the ECDAA library limits the message size for signing to 1024 Bytes.
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.
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}
\subsection{Installing the DAA Network Protocol}
The Network Wrapper can be downloaded from the Git repository\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}}.
@ -491,7 +491,7 @@ 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, in this example \texttt{\textasciitilde/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 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.
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 takes care of 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:
With the setup described in the prevoius chapter, we created a system which is able to capture and process biometric data.
With the setup described in the previous chapter, we created a system which is able to capture and process biometric data.
The system encapsulates this data into an attestation message and sends it to the PIA which is the DAA verifier in this configuration.
The system encapsulates this data into an attestation message and sends it to the PIA which is the DAA verifier in this configuration.
We show in the following how well each part of the setup work and which performance the tested devices show.
We show in the following how well each part of the setup work and which performance the tested devices show.
Furthermore we analyze the footprint in memory as well as on the disk.
Furthermore we analyze the footprint in memory as well as on the disk.
@ -23,11 +23,11 @@ This requires a backup password for the disk encryption which allows to bypass t
Otherwise there are no updates possible with the current setup since the affected PCRs are used by the EFI bootloader and cannot be precomputed.
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.
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.
GRUB already supports trusted boot and activation requires a line in the corresponding configuration 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.
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.
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.
Furthermore, only in this case exists a measurable difference in the boot performance since asking the TPM takes around 4\,s.
This is the time when the boot process posts \texttt{unlocking via TPM} and stays there until the disk is unlocked.
This is the time when the boot process posts \texttt{unlocking via TPM} and stays there until the disk is unlocked.
The used amount of memory was not tested here, but it should be comparable to the results when generating a TPM key for the member.
The used amount of memory was not tested here, but it should be comparable to the results when generating a TPM key for the member.
According to these results, we assume that less than 10\,KB are used to hold the TPM stack in memory.
According to these results, we assume that less than 10\,KB are used to hold the TPM stack in memory.
@ -55,7 +55,7 @@ This indicates a linear dependency to the number of accessed files for the log a
The log can easily get over 100,000 entries when the system is running long enough.
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 up time, resulting in about 40\,MB of size.
System 1, for example, had a log file with 214,561 lines after about 15 days of up time, resulting in about 40\,MB of size.
The log file showed that a major impact on the size was the performed system update.
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 together generates several 10,000 lines in the log.
Generating the initramfs 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 enabled, 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.
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.
@ -95,12 +95,12 @@ During the following tests, all software and hardware parts worked as expected.
Neither TPM nor software errors were encountered.
Neither TPM nor software errors were encountered.
Analyzing the occupied resources is only meaningful for the DAA member.
Analyzing the occupied resources is only meaningful for the DAA member.
The implemented protoype of the DAA issuer does only negotiate the membership key.
The implemented prototype 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.
Revocation lists and group management are not implemented yet, although the ECDAA library provides datastructures and functions for that.
Similarly, the DAA verifier only checks the signature of the received message.
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 contribution of each:
\begin{itemize}
\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 join w/o keygen}: Use the DAA key which is already in place and negotiate a group membership with the DAA issuer.
@ -108,7 +108,7 @@ We split the tasks of a Digidow sensor in several parts to document the conrtibu
\item\emph{DAA keygen \& join}: Generate the DAA key pair and save it to disk.
\item\emph{DAA keygen \& join}: Generate the DAA key pair and save it to disk.
Join the DAA group by negotiating a secret with the DAA issuer.
Join the DAA group by negotiating a secret with the DAA issuer.
\item\emph{Digidow sensor capture}: Create an image using \texttt{bs-capture} and save it to disk.
\item\emph{Digidow sensor capture}: Create an image using \texttt{bs-capture} and save it to disk.
\item\emph{Digidow sensor embed}: Extract a face embedding using the tensorflow application \texttt{img2emb}.
\item\emph{Digidow sensor embed}: Extract a face embedding using the TensorFlow application \texttt{img2emb}.
\item\emph{Digidow sensor collect}: Collect the integrity log and save it to disk.
\item\emph{Digidow sensor collect}: Collect the integrity log and save it to disk.
Create a sha512sum of the file and put it together with all PCRs and the face embedding data into one message.
Create a sha512sum of the file and put it together with all PCRs and the face embedding data into one message.
Calculate another sha512sum from the message itself and save it to disk.
Calculate another sha512sum from the message itself and save it to disk.
@ -122,7 +122,7 @@ All programs besides the face embedding application are rather small, the binari
The installing process is still manual requiring a local build environment for C and Rust.
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.
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.
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.
Similarly, 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}
\subsection{Memory Usage}
First, we look into the memory footprint of each part by using \texttt{/usr/bin/time}.
First, we look into the memory footprint of each part by using \texttt{/usr/bin/time}.
@ -230,7 +230,7 @@ The used shell commands may not free every allocated block, however valgrind sti
The \emph{first} run is stated separately, because it is done immediately after a system reboot where the resources cached by the kernel are not loaded yet.
The \emph{first} run is stated separately, because it is done immediately after a system reboot where the resources cached by the kernel are not loaded yet.
The major delay in the first run is caused by the face embedding program, especially when IMA is enabled.
The major delay in the first run is caused by the face embedding program, especially when IMA is enabled.
As stated in \autoref{ssub:integrity_log}, each resource has to be hashed and extended into PCR 10 before access is granted, making the first access significantly longer.
As stated in \autoref{ssub:integrity_log}, each resource has to be hashed and extended into PCR 10 before access is granted, making the first access significantly longer.
Especially the tensorflow application requires significantly more time for the first run.
Especially the TensorFlow application requires significantly more time for the first run.
With IMA set to enforcing, the kernel furthermore manages access to the file asked to read.
With IMA set to enforcing, the kernel furthermore manages access to the file asked to read.
This decision does not require additional resources compared to the fixing mode.
This decision does not require additional resources compared to the fixing mode.
@ -240,7 +240,7 @@ 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.
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.
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 beween the single tasks is done based on files.
Furthermore, it is clear that every Digidow transaction contributes to the log since the handover between 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.
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.
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.
@ -261,7 +261,7 @@ Compared to the 3.18s in the last run of above tests the slowdown is 22.91.
This result supports the complexity estimation of $O(n^2)$ when collecting the integrity log by expecting a slowdown of above 16 for a 4 times larger $n$.
This result supports the complexity estimation of $O(n^2)$ when collecting the integrity log by expecting a slowdown of above 16 for a 4 times larger $n$.
Furthermore, it is interesting, that System 1 with the newer AMD processor seems to be faster in the beginning.
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 10,000, the system needs significantly more time than System 3 with the Intel processor, indicating an even worse asymptotic complexity.
When the number of runs reach 10,000, the system needs significantly more time than System 3 with the Intel processor, indicating an even worse asymptotic complexity.
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.
Since the software setup on both systems is comparable (Kernel version, Linux distribution, 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 differently optimized code for the two processor architectures.
It may be found either in the microarchitectural implementation or in differently optimized code for the two processor architectures.
When IMA is in fixing or enforcing mode, the corresponding log will be filled with information about every accessed file.
When IMA is in fixing or enforcing mode, the corresponding log will be filled with information about every accessed file.
@ -293,7 +293,7 @@ Not every service is consistently loaded every time and---depending on its indiv
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.
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.
These resources were partly used by the TensorFlow application.
Consequently, these two entries are very volatile and hence hard to predict.
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.
However, the contribution of capture, collect and send as well as every further Digidow transaction are consistent.
The six entries per Digidow transaction are the changing working files for each run and one file in \texttt{/tmp}.
The six entries per Digidow transaction are the changing working files for each run and one file in \texttt{/tmp}.
@ -308,9 +308,9 @@ While executing \texttt{apt upgrade}, the package manager downloads the deb pack
These files, however, do not have the \texttt{security.ima} attribute when the download is finished.
These files, however, do not have the \texttt{security.ima} attribute when the download is finished.
The kernel prevents any access due to this missing attribute and breaks the upgrade process.
The kernel prevents any access due to this missing attribute and breaks the upgrade process.
It is not clear why the files are not hashed although apt is run by root and every file created by root must be hashed according to the active IMA policy.
It is not clear why the files are not hashed although apt is run by root and every file created by root must be hashed according to the active IMA policy.
Creating a text file via text editor shows exactly this behaviour.
Creating a text file via text editor shows exactly this behavior.
The missing attributes are also a problem when attemping to turn IMA off again.
The missing attributes are also a problem when attempting to turn IMA off again.
This requires an updated command line and thereafter an updated unified kernel.
This requires an updated command line and thereafter an updated unified kernel.
Generating the new kernel works 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.
The copy process seems to create the file, but it fails when trying to write the first blocks.
@ -321,7 +321,7 @@ Creating a backup is done with the following command:
\begin{lstlisting}[numbers=none]
\begin{lstlisting}[numbers=none]
dd if=/dev/nvme0n1p1 of=/root/efi-backup.img
dd if=/dev/nvme0n1p1 of=/root/efi-backup.img
\end{lstlisting}
\end{lstlisting}
When the kernel runs with IMA in enforcing mode, the keernel still allows to restore the backup with:
When the kernel runs with IMA in enforcing mode, the kernel still allows to restore the backup with:
\begin{lstlisting}[numbers=none]
\begin{lstlisting}[numbers=none]
dd if=/root/efi-backup.img of=/dev/nvme0n1p1
dd if=/root/efi-backup.img of=/dev/nvme0n1p1
\end{lstlisting}
\end{lstlisting}
@ -347,6 +347,6 @@ However, it was not possible to reproduce the value in PCR 10 value when enablin
Our tests took into account that PCR and log file could be modified when loading programs to read these resources the first time.
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).
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.
The value of PCR 10 was still not reproducible.
Furthermore the documentation of calculating these values does 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.
\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.
Hence, any verification procedures regarding the SHA256 bank of PCR 10 are currently not implemented.
@ -32,7 +32,7 @@ The demonstration just shows a part of the workload of a full Digidow transactio
\section{Limitations}
\section{Limitations}
\label{sec:limitations}
\label{sec:limitations}
The main contribution to 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.
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.
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.
Capturing an image from a camera and saving it to disk should be doable in less than 0.1\,s.
@ -48,7 +48,7 @@ In the context of using the TPM, we faced several problems that are not solved y
Although it is possible to update the TPM, we were not able to get a recent firmware blob for this TPM.
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, hosts the certificate chain on a website where only the domain name leads to the manufacturing company.
\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.
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.
When the certificate chain is broken, it may not be clear whether the user possesses a corrupt TPM or the website just provides bogus certificates.
\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.
\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.
The member key is only located in the endorsement hierarchy.
\item The documentation of the TPM software stack is not beginner friendly.
\item The documentation of the TPM software stack is not beginner friendly.
@ -88,7 +88,7 @@ We discussed in the previous section a missing link in the chain of trust of the
This gap could be closed by certifying that the DAA membership key is in the endorsement hierarchy.
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.
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. at pages 109 ff~\cite{arthur15}.
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.
Eric Chieng~\cite{Chieng2021} wrote on his blogpost a practical approach to implement this certification.
This solution seems to close the missing link in the chain of trust.
This solution seems to close the missing link in the chain of trust.
Verifying the integrity of the sensor is still not solved.
Verifying the integrity of the sensor is still not solved.
@ -103,7 +103,7 @@ Several approaches should be investigated to mitigate this problem:
When files with a valid signature are accessed, it might not be necessary to add them into the integrity log.
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.
\item Make the root partition read only where applicable.
Every file read from this partition can be excluded from the integrity log.
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.
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.
This setup might satisfy similar goals compared to the previous approach, but the update procedure might be easier.
\item Include the firmware of peripherals.
\item Include the firmware of peripherals.
In the current setup, the integrity log takes only libraries and drivers into account.
In the current setup, the integrity log takes only libraries and drivers into account.
