Einige Notizen zum Trusted Platform Module (TPM)
04.01.2025
Auf dieser Seite dokumentiere ich Wissen zum Trusted Platform Module (TPM). Nichts Neues, aber einige Informationen zusammengefasst. Diese Webseite erhebt keinen Anspruch auf Vollständigkeit und ist noch in Bearbeitung.
Index
Allgemein
TPM unter Linux
Security
Fragen
Links
Abkürzungen
Allgemein
TPM ist die Abkürzung für Trusted Platform Module. Das ist ein kleiner Chip auf der Hauptplatine eines Computers. Dieser Chip kann zum Beispiel per Serial Peripheral Interface (SPI) oder Low Pin Count (LPC) Bus an den Platform Controller Hub (PCH) angeschlossen sein oder sich direkt in der CPU befinden (Firmware TPM, fTPM). Auch andere Hardwarevarianten sind möglich. Es gibt verschiedene Spezifikations-Versionen von TPMs. Aktuell (2024) wird von den meisten TPMs Version 2.0 bereitgestellt. Im TPM können zum Beispiel digitale Schlüssel gespeichert werden oder die Platform Configuration Register (PCR) beschrieben werden.
Platform Configuration Register
Der Wert der Platform Configuration Register kann nicht direkt geschrieben werden sondern jeweils nur um einen sogenannten Hash erweitert werden. Diese Platform Configuration Register können zum Beispiel für einen sogenannten "Measured Boot" verwendet werden. Das ist nicht zu verwechseln mit dem "Verfied Boot", der beim Secure Boot benutzt wird. Measured Boot bedeutet lediglich, dass man nach dem Startvorgang prüfen kann, ob der Start so verlaufen ist, wie der Start erwartet wurde. Das funktioniert allerdings nur zuverlässig, wenn Secure Boot sicher ist.
Microsoft Windows BitLocker kann so konfiguriert werden, dass BitLocker beim TPM-only Verfahren die Platform Configuration Register PCR 7 und PCR 11 benutzt [Quelle]. Mit PCR 7 wird Secure Boot nachgewiesen ("Secure Boot Policy") und PCR 11 wird bei Windows als "BitLocker access control" benutzt. Das bedeutet, wenn Secure Boot eingeschaltet ist und der BitLocker Schlüssel noch nicht aus dem TPM gelesen wurde, gibt das TPM den Schlüssel zur Entschlüsselung von BitLocker im Klartext heraus.
Ein Firmware TPM in der CPU bietet zwar Schutz gegen das Belauschen des Schlüssels auf einem Leitungsbus, erzeugt aber neue Probleme. Wenn zum Beispiel die CPU kaputtgeht, muss das TPM mit seinen Schlüsseln mit ausgetauscht werden. Andersrum genauso, wenn das TPM in der CPU nicht mehr funktioniert, dann muss die CPU ausgetauscht werden.
| PCR Index | PCR Usage |
|---|---|
| 0 | SRTM, BIOS, Host Platform Extensions, Embedded Option ROMs and PI Drivers |
| 1 | Host Platform Configuration |
| 2 | UEFI driver and application Code |
| 3 | UEFI driver and application Configuration and Data |
| 4 | UEFI Boot Manager Code (usually the MBR) and Boot Attempts |
| 5 | Boot Manager Code Configuration and Data (for use by the Boot Manager Code) and GPT/Partition Table |
| 6 | Host Platform Manufacturer Specific |
| 7 | Secure Boot Policy |
| 8-15 | Defined for use by the Static OS |
TPM Event Log
Wenn ein Problem mit den Platform Configuration Registern auftritt, weil sie sich zum Beispiel geändert haben, dann ist es hilfreich das Problem analysieren zu können. Zum Debuggen gibt es das TPM Event Log. Dort ist vermerkt, welche Variablen oder Dateien in die PCRs eingeflossen sind. Das TPM Event Log wird zum Teil von der BIOS Firmware geschrieben, zum anderen Teil vom Betriebsystem. Das Event Log wird im Arbeitsspeicher vorgehalten und kann später auf Festplatte geschrieben werden. Wenn das BIOS mit der Initialisierung fertig ist, wird das Event Log mit den unteren PCR-Nummern per ACPI Tabelle an das Betriebsystem übergeben, so dass das Betriebssystem die Events für PCRs mit höheren Nummer schreiben kann [Quelle].
Unter Windows sind die TPM measurement event logs normalerweise unter:
C:\Windows\Logs\MeasuredBoot\
# for example:
C:\Windows\Logs\MeasuredBoot\0000000312-0000000000.log
# extract TBSLogGenerator.exe from the Windows Hardware Lab Kit
msiexec /a "HLK System.Fundamentals Content-x86_en-us.msi" /qb TARGETDIR=C:\Users\username\
# decode event log
TBSLogGenerator.exe -LF C:\Windows\Logs\MeasuredBoot\0000000312-0000000000.log
# in Linux this is here:
cat /sys/kernel/security/tpm0/binary_bios_measurements > tpm_measurement_log.bin
Die TPM event logs liegen in einem binären Format vor. Es gibt verschiedene Tools, mit denen sie sich dekodieren lassen. Weiter unten habe ich das Dekodieren für Linux mit dem Tool "tpm2_eventlog" beschrieben. Im TPM Event Log steht zum Beispiel, dass für PCR 7 die Variable "SecureBoot", der Platform Key (PK), der Key Exchange Key (KEK), die Datenbank mit Zertifikaten (db), die UEFI Revocation List (dbx), ein "Microsoft Windows Production PCA 2011" Zertifikat und andere Werte gespeichert werden. Für Windows gibt es neben TBSLogGenerator.exe zum Beispiel das Programm "PCPTool.exe".
Schlüsselhierarchien
Es gibt 4 Schlüsselhierarchien im TPM: Endorsement, Owner / Storage, Platform und Null (ohne persistenten Speicher). Hierarchie bedeutet einfach nur, dass weitere Schlüssel unter dem Root Key der Hierarchie gespeichert werden können. So können zum Beispiel in der Storage Hierarchie mehrere eigene Schlüssel für Anwendungen gespeichert werden.
Endorsement Key
Endorsement Key kann man mit "Bestätigungsschlüssel" übersetzen. Er kann zusammen mit dem Endorsement Key Zertifikat die Echtheit des TPMs von einem Hersteller bestätigen und den spezifischen TPM identifizieren.
Erstellung und Zertifizierung eines Endorsement Keys
Ein TPM enthält eine feste, eindeutige Zahl: Endorsement Primary Seed (EPS). Diese Zahl wird entweder im TPM generiert oder durch den TPM Hersteller ins TPM gebracht und soll nicht mehr aus dem TPM ausgelesen werden können. Aus dieser Zahl "Endorsement Primary Seed" und einem Template kann ein Endorsement Key (EK) erzeugt werden. Dieser Endorsement Key ist einem TPM fest zugeordnet und kann als Identität des TPMs angesehen werden. Der Endorsement Key kann ein RSA oder ECC Schlüssel sein und zum Entschlüsseln benutzt werden. Theoretisch kann die Endorsement Primary Seed geändert werden, aber das hängt von der tatsächlichen Implementierung des TPM Herstellers ab. Über die tpm2_tools kann die Endorsement Primary Seed mit tpm2_changeeps geändert werden. Der öffentliche Schlüssel des Endorsement Key kann vom TPM Hersteller in ein Zertifikat mit Seriennummer gepackt werden und mit dem privaten Schlüssel des Herstellers unterschrieben werden. Dieses Zertifikat kann entweder im NVRAM des TPMs (non volatile random access memory) oder auf dem Server des TPM-Herstellers gespeichert werden. Das Zertifikat könnte auch von einer anderen Zertifizierungsstelle (CA) unterschrieben werden. Die Gültigkeitsdauer des EK Zertifikats kann damit theoretisch einen TPM nach einigen Jahren für bestimmte Anwendungen unbrauchbar machen. Das Endorsement Key Zertifikat kann mit den öffentlichen Schlüsseln / Zertifikaten des Herstellers überprüft werden (siehe weiter unten). Beim Erstellen des Endorsement Keys kann eine Authorization Policy mitgegeben werden. Bei meinem Infineon TPM ist es "Computing PolicyA". Der Endorsement Key kann Schlüssel unter anderen Schlüssel-Hierarchien bestätigen (siehe "Credential Activation" weiter unten).
Achtung: TPM Hersteller können theoretisch den privaten Endorsement Key kennen.
Storage Root Key
Der Storage Root Key wird vom Besitzer des TPMs oder Administrator eines Computers ins TPM gebracht. Der Storage Root Key kann durch die Storage Primary Seed (SPS) erzeugt werden und kann zum Beispiel mit einem Passwort gesichert werden [Quelle]. Der Storage Root Key kann alle weiteren Schlüssel verschlüsseln. Das ist nötig, da die weitern Schlüssel nicht immer im TPM, sondern auf der Festplatte gespeichert werden. Microsoft Windows BitLocker speichert den BitLocker Volume Master Key (VMK) unter der Storage / Owner Hierarchie. Der BitLocker Key wird durch den Storage Root Key ver- und entschlüsselt und wird erst mit den richtigen PCR-Werten in den Platform Configuration Registern an die CPU übertragen. Diese PCR-Werte wurden beim Speichern des BitLocker Keys mitgespeichert.
Entschlüsseln eines Schlüssels mit dem Storage Root Key
Im oberen Sequenz-Diagramm ist zu sehen, wie ein BitLocker Schlüssel bei der TPM-only Variante entschlüsselt wird. In Schritt 1 wird der verschlüsselte Volume Master Key (VMK) durch BitLocker von der Festplatte in das TPM geladen. Der verschlüsselte Volume Master Key ist auf der Festplatte in sogenannten Metadaten gespeichert - aus Redundanzgründen in mehreren Metadaten-Blöcken. Die beiden Zwischenschritte mit "startauthsession" und "policyauthorize" sind fürs grobe Verständnis uninteressant. Im 4. Schritt wird das TPM aufgefordert, den Volume Master Key mit dem privaten Storage Root Key zu entschlüsseln. Dabei werden die Werte der Platform Configuration Register (PCRs) überprüft, die bei der Verschlüsselung des Volume Master Keys mitgegeben wurden. Wenn die aktuellen PCR-Werte des TPMs mit den PCR-Werten im verschlüsselten VMK übereinstimmen, dann wird der VMK entschlüsselt im Klartext an die BitLocker Software übertragen. In der PCR Bitmap steht, welche Platform Configuration Register zum Vergleich benutzt werden sollen. PCR Bitmap, PCR digest und Policy Digest habe ich als Detail wegen der Übersichtlichkeit im Bild weggelassen und einfach "PCR hash" benutzt. Das Versiegeln (seal) beziehungsweise Verschlüsseln eines Schlüssels funktioniert ähnlich, wobei dann der Public-Teil des Storage Root Keys zum Verschlüsseln benutzt wird. Hier ist ein passendes Sequenzdiagramm für den Seal-Vorgang.
Anhand des Bildes zum Entschlüsseln lassen sich mindestens zwei Probleme erkennen. Bei einer Replay-Attacke können die PCR-Werte im TPM so eingestellt werden, dass das TPM den entschlüsselten VMK auch herausrückt, wenn kein "sicheres" Betriebssystem gestartet wurde. Außerdem ist der VMK nur auf der Festplatte verschlüsselt. Da das TPM zu langsam ist, wird der entschlüsselte VMK im Klartext an BitLocker übergeben um die Festplatte zu entschlüsseln. Der entschlüsselte VMK wäre damit theoretisch durch Schadsoftware im Arbeitsspeicher oder über die Bus-Leitungen zwischen TPM und CPU auslesbar.
Da die Probleme der TPM-only Variante von BitLocker schon länger bekannt sind, empfiehlt Microsoft eine persönliche Identifikationsnummer (PIN) mit dem TPM zu benutzen. Dabei kann die PIN zusätzlich mit PCR-Werten für Unseal kombiniert werden. Was ist der Unterschied zur Festplattenverschlüsselung mit einem Passwort? Das Passwort könnte theoretisch durch einen Brute-Force-Angriff geknackt werden - also mit Durchprobieren von Passwörtern. Bei der Variante TPM + PIN ist ein Brute-Force-Angriff auf die PIN bei TPMs mit Anti-Hammering-Schutz schwieriger. Das TPM lässt nur wenige Fehlversuche hintereinander zu. Ein Brute-Force-Angriff auf den Volume Master Key mit seinen 256 Bit ist deutlich schwieriger als Brute Force auf Passwörter.
Attestation Key
Der Attestation Key dient zur Bescheinigung zum Beispiel von den Platform Configuration Registern (PCR) gegenüber einem externen Computer (remote attestation). Der Attestation Key kann unterhalb jeder Schlüssel-Hierarchie angelegt werden. Wenn der Attestation-Key unter der Endorsement-Hierarchie angelegt wird, dann werden beim bescheinigen der PCRs auch noch TPM-spezifische Informationen rausgegeben. Wird der Attestation Key unter der Storage / Owner Hierarchie angelegt, so ist das Bescheinigen der PCRs etwas anonymer [Quelle]. Theoretisch kann aber die Software auf dem Computer, die die Informationen für Remote Attestation vom TPM weiterleitet ohnehin die TPM-Seriennummer auslesen oder die MAC-Adresse der Netzwerkkarte weitersenden, um den Computer zu identifizieren. Insofern müsste man auch immer der Software vertrauen, die direkt mit dem TPM kommuniziert.
Um zu bestätigen, dass sich der Attestation Key auf demselben TPM wie der Endorsement Key befindet, gibt es den "Credential Activation" Prozess. Bei diesem Prozess wird der Name des Attestation Keys und geheime Daten mit dem Public Key des Endorsement Keys verschlüsselt (EKpub) und ans TPM geschickt. Das TPM entschlüsselt die Daten mit dem Private Key Teil des Endorsement Keys, prüft den Name des Attestation Keys und liefert die entschlüsselten geheimen Daten als Bestätigung zurück.
Credential Activation eines Attestation Keys und Signierung der PCR-Werte
Mit dem Attestation Key kann jetzt zum Beispiel der Zustand der Platform Configuration Register signiert werden (Quote). Zum Prüfen des Quote kann der Public Key des Attestation Keys benutzt werden.
Opal
TODO: Analyse von Self-Encrypting Drives mit Opal
TPM als Dongle
TODO: Einige Computerspiele setzen ein TPM voraus.
TPM unter Linux
Prüfung, ob ein TPM vorhanden ist:
dmesg | grep -i tpm
# possible output
[ 0.015768] ACPI: Reserving TPM2 table memory at [mem 0xb7bb6000-0xb7bb6033]
[ 1.165185] tpm_tis IFX0785:00: 2.0 TPM (device-id 0x1B, rev-id 22)
# list TPM devices:
ls /dev/tpm*
# output:
/dev/tpm0
# or via /sys:
ls /sys/class/tpm/
tpm0
Eine gute Möglichkeit mit einem TPM zu experimentieren sind die quelloffenen TPM2-Tools. Installation der TPM2 Tools unter Linux Mint:
sudo apt install tpm2-tools
Alle TPM-Kommandos, können in den Standardeinstellungen nur von User "root" oder speziellen TPM-Nutzern ausgeführt werden.
Die Bytes der Befehle sind z.B. hier definiert. Um die Bytes der TPM-Kommunikation unter Linux zu tracen:
# add file descriptor for better filtering
strace -f -s 9999 -tt -x tpm2_getrandom 8 2>&1 | egrep -a0 "(read.|write.)"
Anzeigen der Platform Configuration Register:
tpm2_pcrread
# prints the 24 platform configuration registers with the 20 bytes SHA1 and 32 bytes SHA256 hashes
# all 0x00 means no hash has been stored
Das TPM event log für measured boot lesen und dekodieren (hängt von der Version der tpm2-tools ab):
cat /sys/kernel/security/tpm0/binary_bios_measurements > tpm_measurement_log.bin
# install TPM2 tool
apt install tpm2-tools
# check version of TPM2 tools
tpm2_pcrread --version
# version should be greater than or equal to 5
# tool="tpm2_pcrread" version="5.7"
# decode the binary TPM event log
tpm2_eventlog tpm_measurement_log.bin | less -i
# tpm2_eventlog does not seem to work reliable with Windows measured boot log
# get it from C:\Windows\Logs\MeasuredBoot
tpm2_eventlog 0000000802-0000000000.log
# or display some strings that are inside the event log:
strings -e l 0000000802-0000000000.log | grep -v "Microsoft Windows" | grep -v "Microsoft Code Signing PCA 2010"
Die aktuelleste Version der TPM2-Tool konnte ich erfolgreich unter LinuxMint 20.1 compilieren mit den folgenden beiden Anleitungen:
Install Guide von TPM2-TSS
Install Guide von TPM2-Tools
./bootstrap
./configure
make -j 4 LDFLAGS="-ldl"
sudo make install
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib"
tpm2_eventlog tpm_measurement_log.bin
Den Public Key des Endorsement Key Paars lesen:
tpm2_readpublic -c 0x81010001
# possible output
# authorization policy: 837197...
# save public key in file and display
tpm2_readpublic -c 0x81010001 -f pem -o ek.pem
openssl rsa -in ek.pem -pubin -text -noout
Das Endorsement Key Zertifikat lesen (ist für jedes TPM anders):
tpm2_nvread -o ekcert.der 0x1c00002
# can be tpm2_getekcertificate for some vendors
# convert to PEM format:
openssl x509 -inform der -in ekcert.der -out ekcert.pem
# print certificate
openssl x509 -in ekcert.pem -text -noout
# possible output:
Data:
Version: 3 (0x2)
Serial Number: XXXXXXXXXX (0xYYYYYYYY)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = DE, O = Infineon Technologies AG, OU = OPTIGA(TM), CN = Infineon OPTIGA(TM) TPM 2.0 RSA CA 042
Validity
Not Before: Dec 6 12:13:14 2019 GMT
Not After : Dec 6 12:13:14 2034 GMT
# download certificate for RSA for Infineon TPMs
wget https://pki.infineon.com/OptigaRsaMfrCA042/OptigaRsaMfrCA042.crt
# convert certificate of manufacturer:
openssl x509 -inform DER -in OptigaRsaMfrCA042.crt -out OptigaRsaMfrCA042.pem
# download root certificate for RSA for Infineon TPMs
wget https://pki.infineon.com/OptigaRsaRootCA/OptigaRsaRootCA.crt
# convert root certificate of manufacturer:
openssl x509 -inform der -in OptigaRsaRootCA.crt -out OptigaRsaRootCA.pem
# verify Endorsement Key certificate
openssl verify -show_chain -CAfile <(cat OptigaRsaRootCA.pem OptigaRsaMfrCA042.pem) ekcert.pem
ekcert.pem: OK
Einige IDs persistenter Objekte / persistenter Schlüssel im TPM:
- 0x81000001 (Storage Root Key)
- 0x81000002 (Attestation Identity Key, LDevID, long lived device identifier, under storage hierarchy)
- 0x81000009 (under the storage hierarchy, elliptic curve, ecc key, maybe a bootstrapping? key for Azure Device Provisioning?)
- 0x81010001 (Endorsement Key)
# persistent objects on other TPMs
EK - 0x81010001
EK Certificate - 0x01C00002
SRK - 0x81000001
IDevID Key - 0x81020000 (under endorsement hierarchy)
IDevID Certificate - 0x01C90000
Beispiel für PCR extend und die "Computing PolicyA".
printf "$(echo -n 0000000000000000000000000000000000000000000000000000000000000000000001514000000B | sed 's|\(..\)|\\x\1|g')" > extended.bin
# simple PCR extend example:
sha256sum extended.bin
b627b043d329fbeb7dfefbddee7d3d1f4391c9f6cbbd96a1bac6a99ae1775a3a extended.bin
# run sha256sum twice as described for "Computing PolicyA"
printf "$(sha256sum extended.bin | sed -e 's| *extended.bin||g' -e 's|\(..\)|\\x\1|g')" | sha256sum
837197674484b3f81a90cc8d46a5d724fd52d76e06520b64f2a1da1b331469aa
Anzeigen von Inhalten:
tpm2_print -t TPMS_CONTEXT key_context.ctx
# display public key
tpm2_print -t TPM2B_PUBLIC key.pub
Einen Attestation Key unterhalb der Null Schlüsselhierarchie erstellen und mit dem Endorsement Key bestätigen. CTX-Dateien sind lokal gespeicherte Kontext-Dateien.
tpm2_createek --key-algorithm rsa --public endorsement_key.pub --ek-context endorsement_key.ctx
# create primary key of null hierarchy, -Q means quiet
tpm2_createprimary -Q --hierarchy null --key-context null_prim.ctx
# create a child key in the null hierarchy for signing anonymously
tpm2_create -Q --parent-context null_prim.ctx --public null_signingkey.pub --private null_signingkey.priv --key-context null_signingkey.ctx
# get the name of the signing key
tpm2_readpublic -Q --object-context null_signingkey.ctx --name null_signingkey.name
# get size of the key name in bytes
file_size=`stat --printf="%s" null_signingkey.name`
# print key name in ASCII hex string
loaded_key_name=`cat null_signingkey.name | xxd -p -c $file_size`
# store a secret
echo -n "credential-challenge" > secret.data
# prepare the credentials
tpm2_makecredential --encryption-key endorsement_key.pub --secret secret.data --name $loaded_key_name --credential-blob credential.blob
# start an authorization session
tpm2_startauthsession --policy-session --session session.ctx
# couple the authorization of an object to that of an existing object
tpm2_policysecret --session session.ctx --object-context endorsement
# 837197674484b3f81a90cc8d46a5d724fd52d76e06520b64f2a1da1b331469aa
# enable access to the credential qualifier to recover the credential secret
# activate the credential, credential is decoded
tpm2_activatecredential --credentialedkey-context null_signingkey.ctx --credentialkey-context endorsement_key.ctx --credential-blob credential.blob --certinfo-data credential.decrypted --credentialkey-auth session:session.ctx
# certinfodata:63726564656e7469616c2d6368616c6c656e6765 / "credential-challenge"
# remove temporary handles from the TPM
tpm2_flushcontext session.ctx
Die Platform Configuration Register (PCR) mit dem Attestation Key unterschreiben lassen:
tpm2_quote -Q --key-context null_signingkey.ctx --pcr-list sha256:16,17,18 --message non_ek_attestation.quote
# print the signed PCR digest / quote, pcrSelect contains the PCR bitmap
tpm2_print -t TPMS_ATTEST non_ek_attestation.quote
# quote and save the signature and PCR values
tpm2_quote -Q --key-context null_signingkey.ctx --pcr-list sha256:16,17,18 --message non_ek_attestation.quote -s quote.sig -o quote.pcrs -g sha256
# verify the quote
tpm2_checkquote -u null_signingkey.pub -m non_ek_attestation.quote -s quote.sig -f quote.pcrs -g sha256
Die Platform Configuration Register (PCR) mit einem Attestation Key unter der Endorsement Hierarchie unterschreiben lassen:
tpm2_createek --key-algorithm rsa --public endorsement_key.pub --ek-context endorsement_key.ctx
# create an attestation key under the endorsement hierarchy
tpm2_createak --key-algorithm rsa --ek-context endorsement_key.ctx --ak-context attestation_key.ctx --public attestation_key.pub --private attestation_key.priv --ak-name attestation_key.name
# get a quote for PCRs with the attestation key
tpm2_quote -Q --key-context attestation_key.ctx --pcr-list sha256:16,17,18 --message ek_attestation.quote
# print the signed PCR digest / quote, contains non obfuscated firmwareVersion
tpm2_print -t TPMS_ATTEST ek_attestation.quote
Die Platform Configuration Register (PCR) mit einem Attestation Key unter der Storage / Owner Hierarchie unterschreiben lassen:
tpm2_createek --key-algorithm rsa --public endorsement_key.pub --ek-context endorsement_key.ctx
# create primary key of owner hierarchy, -Q means quiet
tpm2_createprimary -Q --hierarchy owner --key-context srk.ctx
# create a child key in the owner hierarchy for signing anonymously
tpm2_create -Q --parent-context srk.ctx --public srk_signingkey.pub --private srk_signingkey.priv --key-context srk_signingkey.ctx
# get the name of the signing key
tpm2_readpublic -Q --object-context srk_signingkey.ctx --name srk_signingkey.name
# get size of the key name in bytes
file_size=`stat --printf="%s" srk_signingkey.name`
# print key name in ASCII hex string
loaded_key_name=`cat srk_signingkey.name | xxd -p -c $file_size`
# store a secret
echo -n "credential-challenge" > secret.data
# prepare the credentials
tpm2_makecredential --encryption-key endorsement_key.pub --secret secret.data --name $loaded_key_name --credential-blob credential.blob
# start an authorization session
tpm2_startauthsession --policy-session --session session.ctx
# couple the authorization of an object to that of an existing object
tpm2_policysecret --session session.ctx --object-context endorsement
# 837197674484b3f81a90cc8d46a5d724fd52d76e06520b64f2a1da1b331469aa
# enable access to the credential qualifier to recover the credential secret
# activate the credential, credential is decoded
tpm2_activatecredential --credentialedkey-context srk_signingkey.ctx --credentialkey-context endorsement_key.ctx --credential-blob credential.blob --certinfo-data credential.decrypted --credentialkey-auth session:session.ctx
# remove temporary handles from the TPM
tpm2_flushcontext session.ctx
# get a quote for PCRs and print it
tpm2_quote -Q --key-context srk_signingkey.ctx --pcr-list sha256:16,17,18 --message srk_attestation.quote
tpm2_print -t TPMS_ATTEST srk_attestation.quote
Sicherheit
Das Konzept der Platform Configuration Register (PCR) sieht für mich nach einem Designfehler aus. So ist es auch nicht verwunderlich, dass 2018 eine TPM Replay Attacke demonstriert wurde [Quelle]. Die Replay Attacke wurde per Software ausgeführt, könnte bei einem externen TPM aber auch über die Bus-Leitung simuliert werden.
Microsoft speichert je nach Verfahren bei BitLocker für Windows den Key Protector im TPM. Der Key Protector ist die Voraussetzung, um den Volume Master Key (VMK) und die Festplatte zu entschlüsseln. Durch einen unabsichtlichen oder absichtlichen Fehler im TPM (Backdoor) kann dieser Key Protector ausgelesen werden und die Festplatte entschlüsselt werden. Wer denkt, dass die eigenen mit BitLocker verschlüsselten Daten sicher sind, irrt.
Auch TPM Hardware kann für Fault Injection Attacken anfällig sein, wie Forscher von der Technischen Universität Berlin zeigten [Quelle]. Bei dieser Attacke war auch das TPM + PIN Verfahren unsicher.
Offenbar arbeitet Microsoft zusammen mit AMD und anderen Herstellern an einem "Pluton-Sicherheitsprozessor" (2024). So wie es aussieht, möchte Microsoft in Richtung Firmware TPM gehen (fTPM).
Die "Anti-Hammering" Technik des TPM kann gegen Brute-Force Angriffe auf Passwörter oder PINs schützen.
Auf einem TPM läuft ein Stück Software, die Eingabedaten von TPM-Befehlen korrekt prüfen und verarbeiten muss. Da ist es nicht verwunderlich, wenn es auch Software-Fehler im TPM gibt. CVE-2023-1017 (Out-of-Bounds-Write) und CVE-2023-1018 (Out-of-Bounds-Read).
Fragen
- Welche Teile des BIOS gehören zum Measurement bzw. werden für die Platform Configuration Register gehasht?
-> das steht teilweise im TPM event log, C:\Windows\Logs\MeasuredBoot\, /sys/kernel/security/tpm0/binary_bios_measurements
binäres Format muss mit einem Tool dekodiert werden
Links
- Spezifikation der Trusted Computing Group
- Verwendung der Platform Configuration Register (PCR)
- TPM Sniffing Attacke (Pulse Security)
- Informationen wie BitLocker das TPM benutzt (itm4n)
- Wie die PIN beim TPM + PIN Verfahren übertragen wird (Cyberlabs)
- Github Repository zum Auslesen für das TPM und PIN Verfahren
- ein anderer Bericht, wie die PIN beim TPM + PIN Verfahren übertragen wird (SCRT)
- faulTPM - fault injection bei einem Firmware TPM der Firma AMD
- (Youtube) Eine Einführung zum TPM unter Linux mit dem Raspberry Pi
- Open Source Tools, die auch ein TPM in Software simulieren
- TPM Replay Attacke
- Bericht über die faulTPM Fault Injection Attacke auf AMDs fTPM
- TCG Spezifikation zum Endorsement Key Credential Profile
- Anleitung für tpm2_tools
Abkürzungen im Zusammenhang mit einem TPM
| ACPI | Advanced Configuration and Power Interface |
| AIK | Attestation Identity Key |
| AK | Attestation Key |
| BIOS | Basic Input Output System |
| CRTM | Core Root of Trust for Measurement |
| CSR | Certificate Signing Request |
| DPS | Device Provisioning Service |
| DRTM | Dynamic Core Root of Trust for Measurement |
| dTPM | discrete Trusted Platform Model |
| ECC | Elliptic Curve Cryptography |
| EFI | Extensible Firmware Interface |
| EK | Endorsement Key |
| EPS | Endorsement Primary Seed |
| fTPM | Firmware Trusted Platform Module |
| GPT | GUID Partition Table |
| IDevID | Initial Device Identifier |
| IPL | Initial Program Load |
| LDevID | Long Lived Device Identifier |
| LPC | Low Pin Count |
| MBR | Master Boot Record |
| NV | Non Volatile (memory) |
| NVRAM | Non Volatile Random Access Memory |
| PI | Platform Initialization |
| PIN | Personal Identification Number |
| PCR | Platform Configuration Register |
| PPS | Platform Primary Seed |
| ROM | Read Only Memory |
| RoT | Root of Trust |
| RSA | Rivest Shamir Adleman |
| RTM | Root of Trust for Measurement |
| RTR | Root of Trust for Reporting |
| RTS | Root of Trust for Storage |
| SED | Self-Encrypting Drive |
| SHA | Secure Hash Algorithm |
| SPDM | Security Protocol and Data Model |
| SPI | Serial Peripheral Interface |
| SPS | Storage Primary Seed |
| SRTM | Static Core Root of Trust for Measurement |
| SRK | Storage Root Key |
| TBB | Trusted Building Block |
| TCG | Trusted Computing Group |
| TCPA | Trusted Computing Platform Alliance |
| TPM | Trusted Platform Module |
| TSS | TPM2 Software Stack |
| UEFI | Unified Extensible Firmware Interface |
| VMK | Volume Master Key |
Letzte Änderung: 2025-01-04