요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0-only
TPM Security
============
The object of this document is to describe how we make the kernel's
use of the TPM reasonably robust in the face of external snooping and
packet alteration attacks (called passive and active interposer attack
in the literature). The current security document is for TPM 2.0.
Introduction
------------
The TPM is usually a discrete chip attached to a PC via some type of
low bandwidth bus. There are exceptions to this such as the Intel
PTT, which is a software TPM running inside a software environment
close to the CPU, which are subject to different attacks, but right at
the moment, most hardened security environments require a discrete
hardware TPM, which is the use case discussed here.
Snooping and Alteration Attacks against the bus
-----------------------------------------------
The current state of the art for snooping the `TPM Genie`_ hardware
interposer which is a simple external device that can be installed in
a couple of seconds on any system or laptop. Recently attacks were
successfully demonstrated against the `Windows Bitlocker TPM`_ system.
Most recently the same `attack against TPM based Linux disk
encryption`_ schemes. The next phase of research seems to be hacking
existing devices on the bus to act as interposers, so the fact that
the attacker requires physical access for a few seconds might
evaporate. However, the goal of this document is to protect TPM
secrets and integrity as far as we are able in this environment and to
try to insure that if we can't prevent the attack then at least we can
detect it.
Unfortunately, most of the TPM functionality, including the hardware
reset capability can be controlled by an attacker who has access to
the bus, so we'll discuss some of the disruption possibilities below.
Measurement (PCR) Integrity
---------------------------
Since the attacker can send their own commands to the TPM, they can
send arbitrary PCR extends and thus disrupt the measurement system,
which would be an annoying denial of service attack. However, there
are two, more serious, classes of attack aimed at entities sealed to
trust measurements.
1. The attacker could intercept all PCR extends coming from the system
and completely substitute their own values, producing a replay of
an untampered state that would cause PCR measurements to attest to
a trusted state and release secrets
2. At some point in time the attacker could reset the TPM, clearing
the PCRs and then send down their own measurements which would
effectively overwrite the boot time measurements the TPM has
already done.
The first can be thwarted by always doing HMAC protection of the PCR
extend and read command meaning measurement values cannot be
substituted without producing a detectable HMAC failure in the
response. However, the second can only really be detected by relying
on some sort of mechanism for protection which would change over TPM
reset.
Secrets Guarding
----------------
Certain information passing in and out of the TPM, such as key sealing
and private key import and random number generation, is vulnerable to
interception which HMAC protection alone cannot protect against, so
for these types of command we must also employ request and response
encryption to prevent the loss of secret information.
Establishing Initial Trust with the TPM
---------------------------------------
In order to provide security from the beginning, an initial shared or
asymmetric secret must be established which must also be unknown to
the attacker. The most obvious avenues for this are the endorsement
and storage seeds, which can be used to derive asymmetric keys.
However, using these keys is difficult because the only way to pass
them into the kernel would be on the command line, which requires
extensive support in the boot system, and there's no guarantee that
either hierarchy would not have some type of authorization.
The mechanism chosen for the Linux Kernel is to derive the primary
elliptic curve key from the null seed using the standard storage seed
parameters. The null seed has two advantages: firstly the hierarchy
physically cannot have an authorization, so we are always able to use
it and secondly, the null seed changes across TPM resets, meaning if
we establish trust on the null seed at start of day, all sessions
salted with the derived key will fail if the TPM is reset and the seed
changes.
Obviously using the null seed without any other prior shared secrets,
we have to create and read the initial public key which could, of
course, be intercepted and substituted by the bus interposer.
However, the TPM has a key certification mechanism (using the EK
endorsement certificate, creating an attestation identity key and
certifying the null seed primary with that key) which is too complex
to run within the kernel, so we keep a copy of the null primary key
name, which is what is exported via sysfs so user-space can run the
full certification when it boots. The definitive guarantee here is
that if the null primary key certifies correctly, you know all your
TPM transactions since start of day were secure and if it doesn't, you
know there's an interposer on your system (and that any secret used
during boot may have been leaked).
Stacking Trust
--------------
In the current null primary scenario, the TPM must be completely
cleared before handing it on to the next consumer. However the kernel
hands to user-space the name of the derived null seed key which can
then be verified by certification in user-space. Therefore, this chain
of name handoff can be used between the various boot components as
well (via an unspecified mechanism). For instance, grub could use the
null seed scheme for security and hand the name off to the kernel in
the boot area. The kernel could make its own derivation of the key
and the name and know definitively that if they differ from the handed
off version that tampering has occurred. Thus it becomes possible to
chain arbitrary boot components together (UEFI to grub to kernel) via
the name handoff provided each successive component knows how to
collect the name and verifies it against its derived key.
Session Properties
------------------
All TPM commands the kernel uses allow sessions. HMAC sessions may be
used to check the integrity of requests and responses and decrypt and
encrypt flags may be used to shield parameters and responses. The
HMAC and encryption keys are usually derived from the shared
authorization secret, but for a lot of kernel operations that is well
known (and usually empty). Thus, every HMAC session used by the
kernel must be created using the null primary key as the salt key
which thus provides a cryptographic input into the session key
derivation. Thus, the kernel creates the null primary key once (as a
volatile TPM handle) and keeps it around in a saved context stored in
tpm_chip for every in-kernel use of the TPM. Currently, because of a
lack of de-gapping in the in-kernel resource manager, the session must
be created and destroyed for each operation, but, in future, a single
session may also be reused for the in-kernel HMAC, encryption and
decryption sessions.
Protection Types
----------------
For every in-kernel operation we use null primary salted HMAC to
protect the integrity. Additionally, we use parameter encryption to
protect key sealing and parameter decryption to protect key unsealing
and random number generation.
Null Primary Key Certification in Userspace
===========================================
Every TPM comes shipped with a couple of X.509 certificates for the
primary endorsement key. This document assumes that the Elliptic
Curve version of the certificate exists at 01C00002, but will work
equally well with the RSA certificate (at 01C00001).
The first step in the certification is primary creation using the
template from the `TCG EK Credential Profile`_ which allows comparison
of the generated primary key against the one in the certificate (the
public key must match). Note that generation of the EK primary
requires the EK hierarchy password, but a pre-generated version of the
EC primary should exist at 81010002 and a TPM2_ReadPublic() may be
performed on this without needing the key authority. Next, the
certificate itself must be verified to chain back to the manufacturer
root (which should be published on the manufacturer website). Once
this is done, an attestation key (AK) is generated within the TPM and
it's name and the EK public key can be used to encrypt a secret using
TPM2_MakeCredential. The TPM then runs TPM2_ActivateCredential which
will only recover the secret if the binding between the TPM, the EK
and the AK is true. the generated AK may now be used to run a
certification of the null primary key whose name the kernel has
exported. Since TPM2_MakeCredential/ActivateCredential are somewhat
complicated, a more simplified process involving an externally
generated private key is described below.
This process is a simplified abbreviation of the usual privacy CA
based attestation process. The assumption here is that the
attestation is done by the TPM owner who thus has access to only the
owner hierarchy. The owner creates an external public/private key
pair (assume elliptic curve in this case) and wraps the private key
for import using an inner wrapping process and parented to the EC
derived storage primary. The TPM2_Import() is done using a parameter
decryption HMAC session salted to the EK primary (which also does not
require the EK key authority) meaning that the inner wrapping key is
the encrypted parameter and thus the TPM will not be able to perform
the import unless is possesses the certified EK so if the command
succeeds and the HMAC verifies on return we know we have a loadable
copy of the private key only for the certified TPM. This key is now
loaded into the TPM and the Storage primary flushed (to free up space
for the null key generation).
The null EC primary is now generated using the Storage profile
outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of
this key (the hash of the public area) is computed and compared to the
null seed name presented by the kernel in
/sys/class/tpm/tpm0/null_name. If the names do not match, the TPM is
compromised. If the names match, the user performs a TPM2_Certify()
using the null primary as the object handle and the loaded private key
as the sign handle and providing randomized qualifying data. The
signature of the returned certifyInfo is verified against the public
part of the loaded private key and the qualifying data checked to
prevent replay. If all of these tests pass, the user is now assured
that TPM integrity and privacy was preserved across the entire boot
sequence of this kernel.
.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf
.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network
.. _attack against TPM based Linux disk encryption: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets
.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/
.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
목적과 discrete TPM 범위
1-20이 문서는 외부 snooping과 packet alteration 공격, 문헌에서 passive·active interposer attack이라 부르는 공격에 맞서 kernel의 TPM 사용을 합리적으로 견고하게 만드는 방법을 설명한다. 대상은 TPM 2.0이다.
TPM은 보통 저속 bus로 PC에 연결된 discrete chip이다. CPU 가까운 software environment에서 실행되는 Intel PTT 같은 software TPM은 다른 공격을 받지만, 현재 hardened security environment 다수는 discrete hardware TPM을 요구하므로 문서는 이 사용 사례에 집중한다.
TPM 구현 형태와 이 문서가 다루는 공격 표면을 구분한다.
.. SPDX-License-Identifier: GPL-2.0-only
TPM Security
============
The object of this document is to describe how we make the kernel's
use of the TPM reasonably robust in the face of external snooping and
packet alteration attacks (called passive and active interposer attack
in the literature). The current security document is for TPM 2.0.
Introduction
------------
The TPM is usually a discrete chip attached to a PC via some type of
low bandwidth bus. There are exceptions to this such as the Intel
PTT, which is a software TPM running inside a software environment
close to the CPU, which are subject to different attacks, but right at
the moment, most hardened security environments require a discrete
hardware TPM, which is the use case discussed here.
Bus snooping과 packet alteration
21-40최신 snooping 기법의 사례인 `TPM Genie` hardware interposer는 system이나 laptop에 몇 초 만에 설치할 수 있는 단순한 외부 장치다. Windows BitLocker TPM과 TPM 기반 Linux disk encryption scheme 모두에 실제 공격이 시연되었다.
다음 연구 단계는 bus의 기존 device를 해킹해 interposer로 동작시키는 방향이므로 공격자가 몇 초간 물리 접근해야 한다는 제약조차 사라질 수 있다.
목표는 이 환경에서 가능한 한 TPM secret과 integrity를 보호하고, 공격을 막을 수 없다면 최소한 탐지하는 것이다. Bus 접근 공격자는 hardware reset을 포함한 TPM 기능 대부분을 통제할 수 있으므로 이후 절에서 disruption 가능성을 다룬다.
TPM과 CPU 사이에 개입해 command·response를 관찰하거나 바꾼다.
Snooping and Alteration Attacks against the bus
-----------------------------------------------
The current state of the art for snooping the `TPM Genie`_ hardware
interposer which is a simple external device that can be installed in
a couple of seconds on any system or laptop. Recently attacks were
successfully demonstrated against the `Windows Bitlocker TPM`_ system.
Most recently the same `attack against TPM based Linux disk
encryption`_ schemes. The next phase of research seems to be hacking
existing devices on the bus to act as interposers, so the fact that
the attacker requires physical access for a few seconds might
evaporate. However, the goal of this document is to protect TPM
secrets and integrity as far as we are able in this environment and to
try to insure that if we can't prevent the attack then at least we can
detect it.
Unfortunately, most of the TPM functionality, including the hardware
reset capability can be controlled by an attacker who has access to
the bus, so we'll discuss some of the disruption possibilities below.
PCR measurement integrity
41-66공격자는 TPM에 자체 command를 보낼 수 있으므로 임의 PCR extend로 measurement system을 방해할 수 있다. 이는 denial of service지만, trust measurement에 seal된 entity를 겨냥한 두 가지 더 심각한 공격이 있다.
첫째, system에서 오는 모든 PCR extend를 가로채 자체 값으로 완전히 대체할 수 있다. 변조되지 않은 state를 replay하면 PCR이 trusted state를 attest하는 것처럼 보여 secret이 release될 수 있다.
둘째, 공격 중 TPM을 reset해 PCR을 지운 뒤 자체 measurement를 내려보내 boot-time measurement를 사실상 덮어쓸 수 있다.
첫 공격은 PCR extend와 read command를 항상 HMAC으로 보호하면 막을 수 있다. 값을 바꾸면 response에서 검출 가능한 HMAC failure가 발생한다. Reset 공격은 TPM reset을 거치며 값이 바뀌는 보호 mechanism에 의존해야 탐지할 수 있다.
값 대체와 TPM reset을 서로 다른 신호로 탐지한다.
Measurement (PCR) Integrity
---------------------------
Since the attacker can send their own commands to the TPM, they can
send arbitrary PCR extends and thus disrupt the measurement system,
which would be an annoying denial of service attack. However, there
are two, more serious, classes of attack aimed at entities sealed to
trust measurements.
1. The attacker could intercept all PCR extends coming from the system
and completely substitute their own values, producing a replay of
an untampered state that would cause PCR measurements to attest to
a trusted state and release secrets
2. At some point in time the attacker could reset the TPM, clearing
the PCRs and then send down their own measurements which would
effectively overwrite the boot time measurements the TPM has
already done.
The first can be thwarted by always doing HMAC protection of the PCR
extend and read command meaning measurement values cannot be
substituted without producing a detectable HMAC failure in the
response. However, the second can only really be detected by relying
on some sort of mechanism for protection which would change over TPM
reset.
Secret command의 request·response encryption
67-75Key sealing, private key import, random number generation처럼 TPM으로 들어가거나 나오는 정보는 interception에 취약하다. HMAC은 integrity는 보호하지만 confidentiality까지 제공하지 못한다.
이런 command에는 secret 유출을 막기 위해 request와 response encryption도 함께 적용해야 한다.
Integrity와 confidentiality를 별도 mechanism으로 확보한다.
Secrets Guarding
----------------
Certain information passing in and out of the TPM, such as key sealing
and private key import and random number generation, is vulnerable to
interception which HMAC protection alone cannot protect against, so
for these types of command we must also employ request and response
encryption to prevent the loss of secret information.
Null seed로 초기 신뢰 확립
76-110처음부터 보안을 제공하려면 공격자가 모르는 initial shared secret 또는 asymmetric secret을 확립해야 한다. Endorsement seed와 storage seed로 asymmetric key를 유도할 수 있지만 kernel에 전달하려면 command line과 boot system의 광범위한 지원이 필요하고 hierarchy에 authorization이 설정되지 않았다는 보장도 없다.
Linux kernel은 표준 storage seed parameter를 사용해 null seed에서 primary elliptic curve key를 유도한다. Null hierarchy는 물리적으로 authorization을 가질 수 없어 항상 사용할 수 있고, null seed는 TPM reset마다 바뀐다는 두 장점이 있다.
하루의 시작에 null seed를 신뢰 기반으로 정하면 derived key로 salt한 모든 session은 TPM reset 후 seed가 바뀌면서 실패한다. 따라서 reset 공격을 탐지할 수 있다.
사전 shared secret 없이 null seed를 쓰면 initial public key의 생성·read를 bus interposer가 가로채 대체할 수 있다. TPM은 EK endorsement certificate, attestation identity key와 null seed primary certification을 이용한 key certification mechanism을 제공하지만 kernel 안에서 수행하기에는 너무 복잡하다.
Kernel은 null primary key name의 사본을 보관해 sysfs로 export하고, userspace가 boot 후 전체 certification을 수행하게 한다. Certification이 성공하면 시작 이후 TPM transaction이 안전했음을 알 수 있고, 실패하면 interposer가 존재하며 boot 중 사용한 secret이 누출되었을 수 있음을 알 수 있다.
Reset마다 바뀌는 null seed와 사후 certification을 결합한다.
Establishing Initial Trust with the TPM
---------------------------------------
In order to provide security from the beginning, an initial shared or
asymmetric secret must be established which must also be unknown to
the attacker. The most obvious avenues for this are the endorsement
and storage seeds, which can be used to derive asymmetric keys.
However, using these keys is difficult because the only way to pass
them into the kernel would be on the command line, which requires
extensive support in the boot system, and there's no guarantee that
either hierarchy would not have some type of authorization.
The mechanism chosen for the Linux Kernel is to derive the primary
elliptic curve key from the null seed using the standard storage seed
parameters. The null seed has two advantages: firstly the hierarchy
physically cannot have an authorization, so we are always able to use
it and secondly, the null seed changes across TPM resets, meaning if
we establish trust on the null seed at start of day, all sessions
salted with the derived key will fail if the TPM is reset and the seed
changes.
Obviously using the null seed without any other prior shared secrets,
we have to create and read the initial public key which could, of
course, be intercepted and substituted by the bus interposer.
However, the TPM has a key certification mechanism (using the EK
endorsement certificate, creating an attestation identity key and
certifying the null seed primary with that key) which is too complex
to run within the kernel, so we keep a copy of the null primary key
name, which is what is exported via sysfs so user-space can run the
full certification when it boots. The definitive guarantee here is
that if the null primary key certifies correctly, you know all your
TPM transactions since start of day were secure and if it doesn't, you
know there's an interposer on your system (and that any secret used
during boot may have been leaked).
Boot component 간 trust stacking
111-127현재 null primary 방식에서는 다음 consumer에게 넘기기 전에 TPM을 완전히 clear해야 한다. 다만 kernel은 유도한 null seed key name을 userspace에 넘기고 userspace가 certification으로 검증할 수 있다.
같은 name handoff chain을 명시되지 않은 전달 mechanism을 통해 여러 boot component 사이에도 사용할 수 있다. 예를 들어 GRUB이 null seed 방식으로 보안을 확보하고 boot area에서 name을 kernel에 넘길 수 있다.
Kernel은 key와 name을 독립적으로 다시 유도해 전달받은 값과 비교한다. 다르면 tampering이 발생한 것이다. 각 후속 component가 name을 수집하고 자체 derived key와 검증한다면 UEFI에서 GRUB, kernel로 임의 boot component를 연결할 수 있다.
각 component가 null primary name을 넘기고 다음 component가 재유도해 비교한다.
Stacking Trust
--------------
In the current null primary scenario, the TPM must be completely
cleared before handing it on to the next consumer. However the kernel
hands to user-space the name of the derived null seed key which can
then be verified by certification in user-space. Therefore, this chain
of name handoff can be used between the various boot components as
well (via an unspecified mechanism). For instance, grub could use the
null seed scheme for security and hand the name off to the kernel in
the boot area. The kernel could make its own derivation of the key
and the name and know definitively that if they differ from the handed
off version that tampering has occurred. Thus it becomes possible to
chain arbitrary boot components together (UEFI to grub to kernel) via
the name handoff provided each successive component knows how to
collect the name and verifies it against its derived key.
Salted HMAC session과 보호 유형
128-154Kernel이 사용하는 모든 TPM command는 session을 허용한다. HMAC session은 request·response integrity를 검사하고, decrypt·encrypt flag는 parameter와 response를 가린다.
HMAC과 encryption key는 보통 shared authorization secret에서 유도하지만 많은 kernel operation의 authorization은 알려져 있고 대개 비어 있다. 따라서 모든 kernel HMAC session은 null primary key를 salt key로 사용해 session key derivation에 암호학적 입력을 제공해야 한다.
Kernel은 null primary key를 volatile TPM handle로 한 번 만들고, 모든 in-kernel TPM 사용을 위해 `tpm_chip`에 저장한 saved context로 유지한다. 현재 in-kernel resource manager의 de-gapping 부족으로 operation마다 session을 생성·삭제하지만 향후 하나의 HMAC·encryption·decryption session을 재사용할 수 있다.
모든 in-kernel operation은 null-primary-salted HMAC으로 integrity를 보호한다. 추가로 key sealing에는 parameter encryption, key unsealing과 random number generation에는 parameter decryption을 사용한다.
Operation별 integrity·confidentiality 보호를 구분한다.
Null primary context에서 매 operation용 session key를 유도한다.
Session Properties
------------------
All TPM commands the kernel uses allow sessions. HMAC sessions may be
used to check the integrity of requests and responses and decrypt and
encrypt flags may be used to shield parameters and responses. The
HMAC and encryption keys are usually derived from the shared
authorization secret, but for a lot of kernel operations that is well
known (and usually empty). Thus, every HMAC session used by the
kernel must be created using the null primary key as the salt key
which thus provides a cryptographic input into the session key
derivation. Thus, the kernel creates the null primary key once (as a
volatile TPM handle) and keeps it around in a saved context stored in
tpm_chip for every in-kernel use of the TPM. Currently, because of a
lack of de-gapping in the in-kernel resource manager, the session must
be created and destroyed for each operation, but, in future, a single
session may also be reused for the in-kernel HMAC, encryption and
decryption sessions.
Protection Types
----------------
For every in-kernel operation we use null primary salted HMAC to
protect the integrity. Additionally, we use parameter encryption to
protect key sealing and parameter decryption to protect key unsealing
and random number generation.
EK·AK 기반 userspace certification
155-181각 TPM은 primary endorsement key용 X.509 certificate 몇 개와 함께 출하된다. 문서는 Elliptic Curve certificate가 `01C00002`에 있다고 가정하지만 `01C00001`의 RSA certificate도 같은 방식으로 사용할 수 있다.
첫 단계는 TCG EK Credential Profile template로 endorsement primary를 생성하고 certificate 안의 public key와 일치하는지 비교하는 것이다. EK primary 생성에는 EK hierarchy password가 필요하지만 미리 생성된 EC primary가 `81010002`에 있어야 하며, key authority 없이 `TPM2_ReadPublic()`을 수행할 수 있다.
Certificate가 제조사 website에 게시된 manufacturer root까지 chain되는지 검증한다. 그 뒤 TPM 안에서 attestation key(AK)를 만들고 AK name과 EK public key로 `TPM2_MakeCredential`을 사용해 secret을 암호화한다.
TPM은 `TPM2_ActivateCredential`을 실행하며 TPM·EK·AK binding이 참일 때만 secret을 복구한다. 생성한 AK로 kernel이 export한 name의 null primary key를 certify할 수 있다. `MakeCredential/ActivateCredential`이 복잡하므로 다음 절은 외부에서 만든 private key를 이용한 단순화 과정을 설명한다.
EK certificate에서 null primary로 이어지는 신뢰 object다.
Manufacturer certificate에서 null primary name까지 binding을 검증한다.
Null Primary Key Certification in Userspace
===========================================
Every TPM comes shipped with a couple of X.509 certificates for the
primary endorsement key. This document assumes that the Elliptic
Curve version of the certificate exists at 01C00002, but will work
equally well with the RSA certificate (at 01C00001).
The first step in the certification is primary creation using the
template from the `TCG EK Credential Profile`_ which allows comparison
of the generated primary key against the one in the certificate (the
public key must match). Note that generation of the EK primary
requires the EK hierarchy password, but a pre-generated version of the
EC primary should exist at 81010002 and a TPM2_ReadPublic() may be
performed on this without needing the key authority. Next, the
certificate itself must be verified to chain back to the manufacturer
root (which should be published on the manufacturer website). Once
this is done, an attestation key (AK) is generated within the TPM and
it's name and the EK public key can be used to encrypt a secret using
TPM2_MakeCredential. The TPM then runs TPM2_ActivateCredential which
will only recover the secret if the binding between the TPM, the EK
and the AK is true. the generated AK may now be used to run a
certification of the null primary key whose name the kernel has
exported. Since TPM2_MakeCredential/ActivateCredential are somewhat
complicated, a more simplified process involving an externally
generated private key is described below.
외부 private key import 방식
182-197이 방식은 일반적인 privacy CA 기반 attestation을 단순화한 것이다. TPM owner가 owner hierarchy에만 접근할 수 있는 상태에서 attestation한다고 가정한다.
Owner는 외부 elliptic curve public/private key pair를 만들고 inner wrapping으로 private key를 import 가능하게 감싼 뒤 EC-derived storage primary의 child로 둔다.
`TPM2_Import()`는 EK primary로 salt한 parameter-decryption HMAC session에서 수행하며 EK key authority는 필요하지 않다. Inner wrapping key가 encrypted parameter이므로 TPM이 certified EK를 실제로 소유해야 import를 완료할 수 있다.
Command가 성공하고 반환 HMAC이 검증되면 certified TPM에서만 load할 수 있는 private key 사본을 얻은 것이다. 이 key를 TPM에 load한 뒤 null key 생성을 위한 공간을 확보하려고 Storage primary를 flush한다.
EK-salted encrypted import로 private key를 특정 TPM에 묶는다.
This process is a simplified abbreviation of the usual privacy CA
based attestation process. The assumption here is that the
attestation is done by the TPM owner who thus has access to only the
owner hierarchy. The owner creates an external public/private key
pair (assume elliptic curve in this case) and wraps the private key
for import using an inner wrapping process and parented to the EC
derived storage primary. The TPM2_Import() is done using a parameter
decryption HMAC session salted to the EK primary (which also does not
require the EK key authority) meaning that the inner wrapping key is
the encrypted parameter and thus the TPM will not be able to perform
the import unless is possesses the certified EK so if the command
succeeds and the HMAC verifies on return we know we have a loadable
copy of the private key only for the certified TPM. This key is now
loaded into the TPM and the Storage primary flushed (to free up space
for the null key generation).
Null EC primary name 최종 검증
198-211TCG TPM v2.0 Provisioning Guidance의 Storage profile로 null EC primary를 생성한다. Public area hash인 key name을 계산해 kernel이 `/sys/class/tpm/tpm0/null_name`에 제시한 null seed name과 비교한다. 일치하지 않으면 TPM이 compromised된 것이다.
Name이 일치하면 null primary를 object handle, load한 private key를 sign handle로 하고 randomized qualifying data를 제공해 `TPM2_Certify()`를 수행한다.
반환된 `certifyInfo` signature를 load한 private key의 public part로 검증하고, replay를 막기 위해 qualifying data도 확인한다. 모든 test가 통과하면 이 kernel의 전체 boot sequence에서 TPM integrity와 privacy가 보존되었다고 확신할 수 있다.
Kernel이 시작 때 사용한 null primary가 certified TPM에 속했는지 확인한다.
The null EC primary is now generated using the Storage profile
outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of
this key (the hash of the public area) is computed and compared to the
null seed name presented by the kernel in
/sys/class/tpm/tpm0/null_name. If the names do not match, the TPM is
compromised. If the names match, the user performs a TPM2_Certify()
using the null primary as the object handle and the loaded private key
as the sign handle and providing randomized qualifying data. The
signature of the returned certifyInfo is verified against the public
part of the loaded private key and the qualifying data checked to
prevent replay. If all of these tests pass, the user is now assured
that TPM integrity and privacy was preserved across the entire boot
sequence of this kernel.
공격 사례와 TCG 사양
212-216참고 링크는 TPM Genie interposer 자료, Windows BitLocker TPM 공격, TPM 기반 Linux disk encryption sniffing 공격, TCG EK Credential Profile, TCG TPM v2.0 Provisioning Guidance를 제공한다.
공격 실증과 인증·provisioning 표준을 함께 제공한다.
.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf
.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network
.. _attack against TPM based Linux disk encryption: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets
.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/
.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
요약·해설
tpm-security.rst:1-216Discrete TPM 2.0 bus의 snooping·packet alteration 공격을 HMAC·parameter encryption과 reset마다 바뀌는 null primary로 방어하고, userspace EK 인증으로 전체 boot transaction을 검증하는 절차를 설명합니다.