@ -39,7 +39,7 @@ The last two entries describe vulnerabilities in dedicated TPM chips, which are
\begin{itemize}
\begin{itemize}
\item\emph{CVE-2017-15361}: TPMs from Infineon used a weak algorithm for finding primes during the RSA key generation process.
\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.
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.
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.
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 "\emph{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 "\emph{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.
@ -109,10 +109,11 @@ The \emph{Endorsement Key} (EK) is the root key for the corresponding hierarchy.
\end{figure}
\end{figure}
\autoref{fig:ek-key-generation} illustrates the certificate chain of building a new EK.
\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.
Every TPM has, instead of the full EK, a unique key seed to derive root keys from.
This key seed comes with a corresponding certificate.
The EK can then be generated with a \emph{key derivation function} (KDF) which allows to add additional entropy to that of the TPM.
This TPM certificate is signed by the TPM manufacturer by using its own root \emph{Certificate Authority} (CA).
According to Arthur et al.\cite[arthur15] in chapter 15, this additional entropy is not used and the parameter field is filled with zeroes.
When the platform user wants to create a new EK, a \emph{Key Derivation Function} (KDF) generates this new EK such that the TPM certificate identifies it and the chain keeps intact.
As a result, although it is possible to generate an arbitrary number of EKs, the TPM generates always the same by default.
Since the platform supports root key generation, it is also possible to encrypt the key and store it on an external storage, e.g. on the platform disk.
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.
Consequently it is quite easy to have different EKs at once to address privacy features also between different functions of the endorsement hierarchy.
Consequently it is quite easy to have different EKs at once to address privacy features also between different functions of the endorsement hierarchy.
\begin{lstlisting}[float,language=bash, caption={Verifying the TPM Certificate}, label={code:verifytpmcert}]
When OpenSSL returns \texttt{OK}, the certificate chain is intact and the TPM is indeed one from Infineon.
root@amd1:~# tpm2_nvread -C o 0x1c00002 -o amd1_1.cert
To be correct: The website, probably hosted by infineon, provides a certificate chain which matches and the links to the corresponding parent certificate is correct.
root@amd1:~# tpm2_nvread -C o 0x1c0000a -o amd1_2.cert
Unfortunately, Infineon do neither provide any website certification nor any checksums of the provided certificates.
@ -8,6 +8,12 @@ Still hard to set up a system like that.
Documentation is available, but hardly any implementations for DAA and IMA.
Documentation is available, but hardly any implementations for DAA and IMA.
\section{Future Work}
\section{Future Work}
\subsection{Closing the chain of trust between TPM manufacturer and DAA issuer}
Activate a credential with to certify that the Membership key is in the Endorsement hierarchy, which can be verified with the TPM certificate.
\begin{itemize}
\item Theoretical concept in the \emph{Practical Guide to TPM 2.0, pp 109 ff}
\item Practical approach: with EK, AK and AIK to show validity of EK:\\\url{https://ericchiang.github.io/post/tpm-keys/?utm_campaign=Go%20Full-Stack&utm_medium=email&utm_source=Revue%20newsletter#credential-activation}
