-----Original Message-----
From: Zimmer, Vincent <vincent.zimmer@...>
Sent: Friday, December 11, 2020 1:34 AM
To: Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io;
dick_wilkins@...
Subject: RE: The code that creates the TCG Event Log needs an audit

Responsive to Jiewen's message below one can find "Understanding the
Trusted Boot Chain Implementation" at the following links:

HTML: https://tianocore-docs.github.io/edk2-TrustedBootChain/release-
1.00/
PDF: https://tianocore-docs.github.io/edk2-TrustedBootChain/release-
1.00/edk2-TrustedBootChain-release-1.00.pdf
MOBI: https://tianocore-docs.github.io/edk2-TrustedBootChain/release-
1.00/edk2-TrustedBootChain-release-1.00.mobi
EPUB: https://tianocore-docs.github.io/edk2-TrustedBootChain/release-
1.00/edk2-TrustedBootChain-release-1.00.epub

These binaries are compiled from https://github.com/tianocore-docs/edk2-
TrustedBootChain. Feel free to post any feedback to this list or the latter
repo (issues, PR's), too.

Vincent

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, November 17, 2020 9:55 PM
To: rfc@edk2.groups.io; dick_wilkins@...
Cc: Yao, Jiewen <jiewen.yao@...>; Zimmer, Vincent
<vincent.zimmer@...>
Subject: RE: The code that creates the TCG Event Log needs an audit

Good suggestion. Thanks Dick.
Vincent and I have plan to refresh our TPM2 whitepaper recently.
We will definitely take it into consideration, to add more detail on
describing the EDK2 intent and implementation.

Thank you
Yao Jiewen

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Dick
Wilkins
Sent: Wednesday, November 18, 2020 2:23 AM
To: rfc@edk2.groups.io
Subject: [edk2-rfc] The code that creates the TCG Event Log needs an
audit

[RFC] The code that creates the TCG Event Log needs an audit Problem
Statement The TCG support code included in the EDK2 tree is in place
to enable the two major features provided by a platform TPM. 1) To
"seal" secrets in to TPM memory (i.e., Bitlocker keys), and 2) to
enable remote attestation and verification of a platform's security
status after boot ("measured boot").
The first feature is widely being used. Use of the second has been
described in NIST SP 800-155 but not widely implemented. The industry
and several standard groups are attempting to enable this attestation
and verification process. To make that happen they need, not just the
PCR recorded measurements, but also the accompanying event log. The
even log is used by a verifier to understand the how PCR values were
created and decide if those values have a negative security effect on a

platform.

Researchers, attempting to implement proof-of-concept verifiers that
can parse the event logs produced by the wide variety of platform
types across the industry, have generally found they are unable to
parse the logs. They have found problems with missing data,
misunderstandings of what should have been logged, and outright code

bugs.

Enablement of measured boot and verification is a primary purpose of
the code in \SecurityPkg\Tcg and supporting functions. Since the EDK2
code is the implementation of this support most widely used across the
industry, the community needs to make sure it provides its intended

functionality.

Proposals
We need to audit the existing code to make sure it is doing what it is
supposed to do per specification and is as bug free as we can make it.
And we need to make sure it continues to provide correct functionality
as it is updated and maintained.
To make sure the code is doing what it is supposed to do, it has been
suggested that the community audit the existing code and develop a
design document describing the existing implementation, including each
event type enumerated along with a specification of its contents. The
process of reviewing the code to provide this document would have a
positive side effect of doing a code inspection that may result in
finding current implementation bugs.
It has been reported that the TCG specifications may be hard to
understand and that may result in implementations that do not provide
the intended functionality. Also, the TCG specs point to UEFI specs
for some details and as the specifications drift over time, this may
result in implementor confusion and errors.
With a document describing the EDK2 intent and implementation details,
members of TCG workgroups and the team implementing the proof-of-
concept parser/verifier can provide input on where implementation has
diverged from the intent of the relevant specifications.
To insure the EDK2 code continues to function properly, the community
also needs to provide tests for this code to reduce the likelihood of
future regressions in functionality.


Dick Wilkins, Ph.D.
Principal Technology Liaison
Phoenix Technologies, Ltd.
Dick_Wilkins@...<mailto:Dick_Wilkins@...>
+1-425-503-4639 Cell

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Dick
Wilkins
Sent: Wednesday, November 18, 2020 2:23 AM
To: rfc@edk2.groups.io
Subject: [edk2-rfc] The code that creates the TCG Event Log needs an
audit

[RFC] The code that creates the TCG Event Log needs an audit Problem
Statement The TCG support code included in the EDK2 tree is in place
to enable the two major features provided by a platform TPM. 1) To
"seal" secrets in to TPM memory (i.e., Bitlocker keys), and 2) to
enable remote attestation and verification of a platform's security
status after boot ("measured boot").
The first feature is widely being used. Use of the second has been
described in NIST SP 800-155 but not widely implemented. The industry
and several standard groups are attempting to enable this attestation
and verification process. To make that happen they need, not just the
PCR recorded measurements, but also the accompanying event log. The
even log is used by a verifier to understand the how PCR values were
created and decide if those values have a negative security effect on a platform.
Researchers, attempting to implement proof-of-concept verifiers that
can parse the event logs produced by the wide variety of platform
types across the industry, have generally found they are unable to
parse the logs. They have found problems with missing data,
misunderstandings of what should have been logged, and outright code bugs.
Enablement of measured boot and verification is a primary purpose of
the code in \SecurityPkg\Tcg and supporting functions. Since the EDK2
code is the implementation of this support most widely used across the
industry, the community needs to make sure it provides its intended functionality.
Proposals
We need to audit the existing code to make sure it is doing what it is
supposed to do per specification and is as bug free as we can make it.
And we need to make sure it continues to provide correct functionality
as it is updated and maintained.
To make sure the code is doing what it is supposed to do, it has been
suggested that the community audit the existing code and develop a
design document describing the existing implementation, including each
event type enumerated along with a specification of its contents. The
process of reviewing the code to provide this document would have a
positive side effect of doing a code inspection that may result in
finding current implementation bugs.
It has been reported that the TCG specifications may be hard to
understand and that may result in implementations that do not provide
the intended functionality. Also, the TCG specs point to UEFI specs
for some details and as the specifications drift over time, this may
result in implementor confusion and errors.
With a document describing the EDK2 intent and implementation details,
members of TCG workgroups and the team implementing the proof-of-
concept parser/verifier can provide input on where implementation has
diverged from the intent of the relevant specifications.
To insure the EDK2 code continues to function properly, the community
also needs to provide tests for this code to reduce the likelihood of
future regressions in functionality.


Dick Wilkins, Ph.D.
Principal Technology Liaison
Phoenix Technologies, Ltd.
Dick_Wilkins@...<mailto:Dick_Wilkins@...>
+1-425-503-4639 Cell

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Dick Wilkins
Sent: Wednesday, November 18, 2020 2:23 AM
To: rfc@edk2.groups.io
Subject: [edk2-rfc] The code that creates the TCG Event Log needs an audit

[RFC] The code that creates the TCG Event Log needs an audit
Problem Statement
The TCG support code included in the EDK2 tree is in place to enable the two
major features provided by a platform TPM. 1) To "seal" secrets in to TPM
memory (i.e., Bitlocker keys), and 2) to enable remote attestation and
verification of a platform's security status after boot ("measured boot").
The first feature is widely being used. Use of the second has been described
in NIST SP 800-155 but not widely implemented. The industry and several
standard groups are attempting to enable this attestation and verification
process. To make that happen they need, not just the PCR recorded
measurements, but also the accompanying event log. The even log is used by
a verifier to understand the how PCR values were created and decide if those
values have a negative security effect on a platform.
Researchers, attempting to implement proof-of-concept verifiers that can
parse the event logs produced by the wide variety of platform types across
the industry, have generally found they are unable to parse the logs. They
have found problems with missing data, misunderstandings of what should
have been logged, and outright code bugs.
Enablement of measured boot and verification is a primary purpose of the
code in \SecurityPkg\Tcg and supporting functions. Since the EDK2 code is the
implementation of this support most widely used across the industry, the
community needs to make sure it provides its intended functionality.
Proposals
We need to audit the existing code to make sure it is doing what it is
supposed to do per specification and is as bug free as we can make it. And
we need to make sure it continues to provide correct functionality as it is
updated and maintained.
To make sure the code is doing what it is supposed to do, it has been
suggested that the community audit the existing code and develop a design
document describing the existing implementation, including each event type
enumerated along with a specification of its contents. The process of
reviewing the code to provide this document would have a positive side
effect of doing a code inspection that may result in finding current
implementation bugs.
It has been reported that the TCG specifications may be hard to understand
and that may result in implementations that do not provide the intended
functionality. Also, the TCG specs point to UEFI specs for some details and as
the specifications drift over time, this may result in implementor confusion
and errors.
With a document describing the EDK2 intent and implementation details,
members of TCG workgroups and the team implementing the proof-of-
concept parser/verifier can provide input on where implementation has
diverged from the intent of the relevant specifications.
To insure the EDK2 code continues to function properly, the community also
needs to provide tests for this code to reduce the likelihood of future
regressions in functionality.


Dick Wilkins, Ph.D.
Principal Technology Liaison
Phoenix Technologies, Ltd.
Dick_Wilkins@...<mailto:Dick_Wilkins@...>
+1-425-503-4639 Cell