S
P
E
C
I
F
I
C
A
T
I
O
N

Canonical Event Log Format

Version: 1.0
Revision: 0.37
August 31, 2021

Contact: admin@trustedcomputinggroup.org

PUBLIC REVIEWWORK IN PROGRESSThis document is an intermediate draft
for comment only and is subject tochange without notice. Readers should
not design products based on thisdocument.

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW© TCG 2021

Canonical Event Log Format

DISCLAIMERS, NOTICES, AND LICENSE TERMS
THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANYWARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR
ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE.
Without limitation, TCG disclaims all liability, including liability for infringement of any proprietary rights, relating to useof information in this specification and to the implementation of this specification, and TCG disclaims all liability forcost of procurement of substitute goods or services, lost profits, loss of use, loss of data or any incidental,
consequential, direct, indirect, or special damages, whether under contract, tort, warranty or otherwise, arising in any
way out of use or reliance upon this specification or any information herein.
This document is copyrighted by Trusted Computing Group (TCG), and no license, express or implied, is granted
herein other than as follows: You may not copy or reproduce the document or distribute it to others without written
permission from TCG, except that you may freely do so for the purposes of (a) examining or implementing TCG
specifications or (b) developing, testing, or promoting information technology standards and best practices, so longas you distribute the document with these disclaimers, notices, and license terms.
Contact the Trusted Computing Group at www.trustedcomputinggroup.org for information on specification licensing
through membership agreements.
Any marks and brands contained herein are the property of their respective owners.

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 1© TCG 2021

Canonical Event Log Format

CHANGE HISTORYREVISIONDATE

DESCRIPTION

1.00/.10

April 3, 2018•

Initial Release of Draft Version 1.00 Revision 0.10.

1.00/.11

June 10, 2018•

To add new rows to the table, hit the TAB key from this last cell.

1.00/.12

Oct 16, 2018•

Change document to an Information Model. Move original
information into back of document for future reference.

1.00/.13

July 16, 2019•

Merged comments and changed from difference files

1.00/.14

July 17, 2019•

Merged in edits and comments from 2019-06-13 Members Meeting(comments merged in are tagged with 2019-06-13 MM)

1.00/.15

September 03.2019•

Incorporated comments from previous WG Reviews

1.00/.16

December 12, 2019•

Introduce table base data model

1.00/.17

April 21, 2020•

Incorporate TLV as an available encoding, use terms consistently.

1.00/.18

April 29, 2020•

Completed and tested IMA-TLV example

1.00/19

May 6, 2020•

Added IMA_LEGACY example, and moved examples to appendix A.

1.00/20

May 20, 2020•

Clarified NV_index and State Transition fields

1.00/21

June 3, 2020•

Added PCCLIENT_STD example

1.00/22

June 10, 2020•

Added CEL_MGT and PCCLIENT_NG

1.00/23

July 22, 2020•

Added CEL-CBOR CDDL

1.00/24

July 29, 2020•

Minor cleanups for consistency

1.00/25

October 7, 2020•

Final cleanup

1.00/26

October 28, 2020•

Reorganize for clarity and address all comments

1.00/27

October 28, 2020•

Added algorithm reference

1.00/28

November 17, 2020••

Usage of term Extend and Quote consistent
Update references to references numbers

1.00/29

December 9, 2020•

Copy for public review

1.00/30

December 11,2020•

Minor edits prior to public review

1.00/31January 20, 2021•

Response to first public comments

1.00/32

February 23, 2021•

Update data model with more details; TPMS_IMA,
TPMU_EVENTCONTENT, and TPMS_PCCLIENT

1.00/33

March 5, 2021•

Added separate JSON example

1.00/34

March 22, 2021•

Restructured and revised CDDL for CBOR and JSON

1.00/35

April 13, 2021•

Final Check

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 2© TCG 2021

Canonical Event Log Format

1.00/36

July 21, 2021•

Third public review, fixes to CDDL and fixes for consistent names inall figures. Fixes for public comments.

1.00/37

August 31, 2021•

Final for public review

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 3© TCG 2021

Canonical Event Log Format

Contents
DISCLAIMERS, NOTICES, AND LICENSE TERMS ................................................................................................... 1
CHANGE HISTORY .................................................................................................................................................... 2
1

Background and Scope ....................................................................................................................................... 6
1.1 Background .................................................................................................................................................. 6
1.2 Scope ........................................................................................................................................................... 6

2

Document Style ................................................................................................................................................... 8
2.1 Key Words ................................................................................................................................................... 8
2.2 Statement Type ............................................................................................................................................ 8

3

References and Terms ........................................................................................................................................ 9
3.1 References ................................................................................................................................................... 9
3.2 Terms ........................................................................................................................................................... 9
3.2.1 Native Event Log Record (NELR) ....................................................................................................... 9
3.2.2 Canonical Event Log (CEL) ................................................................................................................ 9
3.2.3 Canonical Event Log Record (CELR) ................................................................................................. 9
3.2.4 Canonical Event Log Information Model (CEL-IM) .............................................................................. 9
3.2.5 Canonical Event Log Encoding (CEL-EN) .......................................................................................... 9
3.2.6 Event Log Critical Data (ELCD) .......................................................................................................... 9
3.2.7 Event Log Informative Data (ELID) ................................................................................................... 10

4

Canonical Event Log Information Model (CEL-IM)............................................................................................. 11
4.1 Canonical Event Log (CEL) Definition ........................................................................................................ 11
4.2 Canonical Event Log Record (CELR) Definition ......................................................................................... 11
4.2.1 CELR General Requirements ........................................................................................................... 11
4.2.2 Record Number Field ........................................................................................................................ 11
4.2.3 Record PCR or NV Index Field ......................................................................................................... 11
4.2.4 Record Digest Field .......................................................................................................................... 11
4.2.5 Record Event Content Field .............................................................................................................. 12
4.3 CELR data type definitions ......................................................................................................................... 12
4.4 CEL Management Event Types ................................................................................................................. 13
4.5 PCClient_STD Event Types ....................................................................................................................... 15
4.6 IMA_TEMPLATE Event Types ................................................................................................................... 15
4.7 IMA-TLV Event Types ................................................................................................................................ 15

5

Canonical Event Log Encodings (CEL-EN)........................................................................................................ 16
5.1 Canonical Event Log Record Encoding – TLV (CEL-TLV) ......................................................................... 16
5.1.1 CEL_RECNUM TLV .......................................................................................................................... 17
5.1.2 CEL_PCR_NVindex TLV .................................................................................................................. 17

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 4© TCG 2021

Canonical Event Log Format

5.1.3 CEL_DIGESTS TLV .......................................................................................................................... 17
5.1.4 CEL_CONTENT TLV ........................................................................................................................ 18
5.1.5 IMA_TLV Content Layer ................................................................................................................... 18
5.1.6 IMA_TEMPLATE Content Layer ....................................................................................................... 20
5.1.7 PCCLIENT_STD Content Layer........................................................................................................ 22
5.1.8 CEL_MGT Content Layer ................................................................................................................. 25
5.2 Canonical Event Log Encoding - Binary (CEL-CBOR) ............................................................................... 26
5.2.1 CEL Root Encoding Layer CDDL Specification................................................................................. 26
5.2.2 CEL-CBOR CDDL Specification for labels: ....................................................................................... 27
5.3 CEL-JSON encoding .................................................................................................................................. 28
6

Defined types for all examples. .......................................................................................................................... 31

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 5© TCG 2021

Canonical Event Log Format

1 Background and Scope
Attestation is the process of reporting a platform’s operational state. During boot, and optionally during continued
operation, the platform executes components that may impact the trustworthiness of its operational state. To support
Attestation, the identity or state of each of these components is recorded such that those identities or states can bereported as authentic (i.e., they are from the expected platform and are integrity protected). This process is called
Measurement. When using the TPM [1], the measurement process uses the TPM’s Extend1 operation. DICE [6] hassimilar operations2. While this document uses definitions from [1] extensively, it is intended to be applicable to any
Root of Trust for attestation devices.
A Measurement at a minimum performs an Event operation. This results in the Attestation of an accumulated platform
state at a particular point, but there is no visibility into the individual components comprising that point or state. A
particular Measurement, may, therefore, record information about the component being measured. This type ofmeasurement is called an Event Log Record. The collection of the Event Log Records is an Event Log.
The Extend operation provides evidence of the integrity of a measurement. The Event Log may be stored in insecure
locations. Authenticity of the Event Log is performed using a Quote operation3.

1.1 Background
Different platform classes and even different processes with a single platform class may create Event Log Records informats specific and optimized to a particular environment. The PC Client, for example, uses a format [2] defined by
TCG that is optimized for that platform’s firmware. Rather than put serialization information within each record, thisEvent Log Record format is optimized for space by requiring Event Log Records to be sequential in memory topreserve the sequence of the measurements performed using the Extend operations. This is acceptable for firmware
because there are a finite number of measurements during the boot process. Once the platform’s Operating Systemstarts, the firmware stops execution and ceases to create measurements. These limited number of Event Log Records
can be captured leaving storage, transmission, and serialization, if needed, to higher later layers.
Even within the same platform class, when the firmware completes and stops performing measurements, theOperating System may measure runtime events such as the execution of applications. These Event Log Records may
be in historical formats or formats more optimized for the run-time environment. Another significant difference from afirmware measurement is that the Operating System measurement may be continuous, creating more Event Log
Records than can be efficiently stored on the platform. The Event Log Records may, therefore, need to be exported
from the originating platform to an external storage location. As there is no reliance on the transmission and storage
to maintain the Event Log Record sequence, each Event Log Record must contain a unique sequential index number.
Further, embedding sequence information within each Event Log Record enables tracking of Event Log Records thathave been moved or deleted from their originating platform, and enables efficient transmission from host to host.

1.2 ScopeThis specification for the Canonical Event Log covers three layers: a single top-level Information Model, possibly
multiple encoding layers, and multiple content layers. This specification provides a single information model for
representing a Canonical Event Log Record that can encapsulate native Event Log Records from various sources.
This specification also provides a simple Type-Length-Value (TLV) encoding layer, a Concise Binary Object
Representation (CBOR) encoding layer, and a JSON encoding. This specification covers encapsulation of somecontent layers, including CEL Management, PCCLIENT [2] and IMA [5] content. While a content layer

1

Several TPM commands support the Extend operation. Examples are TPM2_PCR_Extend, TPM2_PCR_Event, theTPM2_hash_* sequence, and even the TPM 1.2 TPM_Extend. For the purpose of this specification, these are equivalent
and are collectively called the Extend operation (Note the use of capitalization to distinguish this specific operation.)2
DICE performs a similar operation to Extend by performing a series of hashes over its boot components. This operationis also included in the general term Extend used in this specification.
3
This specification will use the term Quote operation as a general term for the proof of an Attestation such as a series ofmeasurements. A Quote may be performed using the TPM2_PCR_Quote command but other methods are available suchas a TPM2_PCR_Read within an Audit Session.
Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 6© TCG 2021

Canonical Event Log Format

implementation may choose to create an exact binary mapping to this information model as its native Event Log
Record, other implementations may choose to bind this information model to other formats, such as TLV or CBOR.
As an information model, this specification’s normative statements pertain to the type of information which must be
included in any encoding layer format. This specification also normatively states the TLV encoding layer and CBOR
encoding layers which may be used. It also informatively describes JSON encoding, as specified in [8].

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 7© TCG 2021

Canonical Event Log Format

2 Document Style
2.1 Key Words
The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,”“RECOMMENDED,” “MAY,” and “OPTIONAL” in this document’s normative statements are to be interpreted as
described in RFC-2119, Key words for use in RFCs to Indicate Requirement Levels.

2.2 Statement Type
Please note an important distinction between different sections of text throughout this document. There are two
distinctive kinds of text: informative comment and normative statements. Because most of the text in this specification
will be of the kind normative statements, the authors have informally defined it as the default and, as such, havespecifically called out text of the kind informative comment. They have done this by flagging the beginning and end ofeach informative comment and highlighting its text in gray. This means that unless text is specifically marked as of
the kind informative comment, it can be considered a kind of normative statements.

EXAMPLE: Start of informative comment
This is the first paragraph of 1–n paragraphs containing text of the kind informative comment ...
This is the second paragraph of text of the kind informative comment ...
This is the nth paragraph of text of the kind informative comment ...
To understand the TCG specification the user must read the specification. (This use of MUST does not require any
action).
End of informative comment

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 8© TCG 2021

Canonical Event Log Format

3 References and Terms
3.1 References[1] “Trusted Platform Module Library Family 2.0 Level 00 Revision 01.59,
https://trustedcomputinggroup.org/resource/tpm-library-specification/[2] “TCG PC Client Platform Firmware Profile Specification”; Family “2.0” Level 00 Revision 1.04 June 3, 2019,https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/[3] “TCG Algorithm Registry, Family “2.0”, Level 00 Revision 01.24 January 25, 2017https://trustedcomputinggroup.org/resource/tcg-algorithm-registry/[4] “TCG PC Client Platform Firmware Integrity Measurement Specification”; Version 0.15 March 31, 2020,
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PC_Client_FIM_v1_r40_02dec2020.pdf[5] Integrity Measurement Architecture (IMA), Part of the official Linux Kernel, http://kernel.org[6] Dice Architecture: https://trustedcomputinggroup.org/work-groups/dice-architectures/[7] Advanced Configuration and Power Interface (ACPI) Specification, Version 6.3, January 2019,https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf[8] “TCG TSS 2.0 JSON Data Types and Policy Language Specification”, June 11, 2020,
https://trustedcomputinggroup.org/wp-content/uploads/TSS_JSON_Policy_v0p7_r08_pub.pdf

3.2 Terms
Start of informative comment

3.2.1 Native Event Log Record (NELR)This is an Event Log formatted by the native environment that produced the measurement. This may be a TCG
standard (e.g., as defined by the PC Client Platform Specification [2]) or may be a de-facto standard, such as
produced by bootloaders and operating systems.

3.2.2 Canonical Event Log (CEL)The CEL consists of one or more Canonical Event Log Records.

3.2.3 Canonical Event Log Record (CELR)
An Event Log Record, irrespective of the data representation format, which meets the CEL mandatory requirements.
A complete record containing required information for the Verifier to verify the integrity of the information in the
Event Log Record and the information needed to assess a platform’s trustworthiness. A reference to an Event Log
Record does not imply any particular format. For example, a PC Client’s Event Log [2] is a complete Event Log
Record because it contains the information needed to verify the Event Log information, including the PCR number
and the implicit sequence number (that is indicated by the record’s position within the allocated memory). A CELR
also contains the critical data needed by the Verifier to determine a platform’s trustworthiness3.2.4 Canonical Event Log Information Model (CEL-IM)
A specification of the data that must be contained in a CELR, irrespective of Encoding.

3.2.5 Canonical Event Log Encoding (CEL-EN)
A specific data format to meet to the CEL requirements. This may be TLV, CBOR, or a simple binary format.

3.2.6 Event Log Critical Data (ELCD)
This is information required by the Verifier to either verify the integrity of the Event Log Record or information usedby the Verifier to determine a platform’s trustworthiness. A sequence number is an example of Critical Datarequired to verify to the integrity of the Event Log Record. The Verifier must process the series of Event Log
Records in the order they were measured. Another example of ELCD is the PCR number.

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 9© TCG 2021

Canonical Event Log Format

3.2.7 Event Log Informative Data (ELID)
This is information that is helpful to the Verifier but is not measured. For example, while the actual hash of a
firmware component that is Extended is Event Log Critical Data, the Event Log Record may contain otherinformation such as a string representing firmware’s source and version information that may assist in verification. In
this example, if a Platform has had several firmware updates, the Verifier may use this Event Log Informative Data
to lookup (or request) the expected measured value.
End of informative comment

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 10© TCG 2021

Canonical Event Log Format

4 Canonical Event Log Information Model (CEL-IM)
4.1 Canonical Event Log (CEL) Definition
A Canonical Event Log SHALL consist of a list of Canonical Event Log Records (CELR).

4.2 Canonical Event Log Record (CELR) Definition
A Canonical Event Log Record SHALL consist of four fields: a record number, a PCR or NV Index number, a digest
field (which may contain multiple digests for selected banks), and a content field.

4.2.1 CELR General Requirements
4.2.1.1 Maintenance of the Measurement Integrity
A Verifier MUST be able to verify the integrity of all Event Log Critical Data (ELCD) whether the ELCD was
generated directly into CELR or whether a utility transformed a Native Event Log Record (NELR) into a CELR.
4.2.1.2 Event Log Critical Data
A Canonical Event Log Record (CELR) MUST contain all information from the original entity that created themeasurement. If the CELR is created by transforming a Native Event Log Record (NELR), the transformation MUST
allow the Verifier to verify the integrity of the resulting CELR using information from the TPM Quote Operation. Notethat the conversion from NELR to CELR may produce more information in the CELR than was in the original NELR.
For example, the CELR may contain an explicit sequence number when the NELR contained only an implicit one.

4.2.2 Record Number Field
This identifies the sequence of the CELR within a set of measurements. The Value Element is the sequence number
represented as an unsigned integer. This field is referred to as the RECNUM.
The RECNUM value MUST:
1. Start at zero at TPM2_Startup (CLEAR).
2. Monotonically increment with each event log record.
3. Be maintained separately per index, in the case of a log with records for multiple different PCR or NV
indices. (For example, IMA is authoritative only over its PCR (i.e., 10) and need not coordinate RECNUM
with other PCRs.)
4. Increment regardless of whether the Event is measurement or unmeasured.

4.2.3 Record PCR or NV Index Field
This field indicates which PCR or NV Index was associated with the event. Note that some events are unmeasured,and do not affect the indicated PCR. As a measurement can Extend only one PCR or NV index, there is no rationale
for this field being represented as a bitmap (i.e., TPMS_PCR_SELECTION). The field, therefore, MUST be theinteger representation of the PCR or NV index.

4.2.4 Record Digest Field
This field contains the list of the digest values Extended. The Extend method varies with TPM command, so there isno uniform meaning of TPM Extend in this instance, and separate descriptions are unavoidable. If using the
TPM2_PCR_Extend command, this field is the data sent to the TPM (i.e., not the resulting value of the PCR after
the TPM2_PCR_Extend command completes). If using the TPM2_PCR_Event command, this field contains thedigest structure returned by the TPM2_PCR_Event command (that contains the digest(s) submitted to each PCRbank as the internal Extend operation). This field SHALL contain the information from the TPML_DIGEST_VALUES
used in the Extend operation. (Exactly how this information is encoded will be described in the selected encoding
layer).

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 11© TCG 2021

Canonical Event Log Format

4.2.5 Record Event Content Field
This field contains both the Event Log Critical Data (ELCD) and Event Log Informative Data (ELID) as defined by theContent Type Custodian. This specification (CEL) defines the values identifying the Content Type Custodian but the
information within the Event Content Value field is entirely defined by the Content Type Custodian.
Note that there are one or more Content Types assigned to the CEL. These are typically management Events or
determined to be common across all Content Type domains, so they are defined as part of this specification.
The Content Type Custodian defines what components of the Event Content are hashed to create the Extend value.
These components are likely the entire set of Event Log Critical Data (ELCD), but Event Log Informative Data
(ELID) MAY be included.
If multiple PCR Banks are Extended, the same method MUST be used for deriving each PCR Bank’s digest.

4.3 CELR data type definitions
The data type in Table 1 defines the CELR data type TPMS_CEL_EVENT. If a numeric representation is required
for the specific encoding (such as binary or TLV) then the values from the column “value” SHALL be used. (Again,
this Information Model specifies the data content, not the encoded format.) The format follows that of the TCG TPM
Library Specification Part 2 [1].
Table 1 TPMS_CEL_EVENTDATA TYPE
Unsigned Integer
TPMI_DH_PCR

FIELD NAME
recnum
pcr

VALUE
0
1

DESCRIPTION
Unique Record Number
PCR index

TPMI_DH_NV_INDEX
nv_index2
NV Index
TPML_DIGEST_VALUES
digests
3
Digests Extended
TPMI_CEL_CONTENT_TYPE
content_type
See Table 2
TPMU_EVENT_CONTENT
content
CONTENT_TYPE The event data for this CELR
Note that TPML_DIGEST_VALUES (specified in [1]) is a complex structure, including variable length arrays ofstructures. This information model specifies only that the contents and ordinals from TPML_DIGEST_VALUES be
used and does not specify how they are encoded. Section 5.1 shows how this may be encoded using TLV.
Also note that “content_type” is an optional field that can be used if the encoding lists the content type separately
before the content field itself. The “content_type” fields are used by JSON and CBOR encodings. TLV encodings
incorporate the content type within the “content” field as described in section 5.
The enumeration in Table 2 defines the supported content types. If a numeric representation is required for the
specific encoding (such as binary or TLV) then the values from the column “value” SHALL be used.
Table 2 TPMI_CEL_CONTENT_TYPE

NAME
cel
pcclient_std
ima_template
ima_tlv
-

VALUE
4
5
6
7
8
9
10

DESCRIPTION
CEL management; Content managed by TCG / CEL
PC Client WG defined encapsulated structure
reserved
Linux-IMA TEMPLATE format
Linux-IMA TLV format
reserved
reserved

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 12© TCG 2021

Canonical Event Log Format

Table 3 defines the supported content fields.
Table 3 TPMU_EVENT_CONTENT

TYPE

FIELD

SELECTOR

TPMS_EVENT_CELMGT

celmgtcel

TPMS_EVENT_PCCLIENT_STD

pcclient_std

pcclient_std

TPMS_EVENT_IMA_TEMPLATEIMA_TLV

ima_template
ima_tlv

ima_template
ima_tlv

DESCRIPTION
CEL management; Content
managed by TCG / CEL
PC Client WG defined
encapsulated structureLinux-IMA TEMPLATE format
Linux-IMA TLV format

The IMA_TLV content is specified in [5]. Informative examples are included in section 5.

4.4 CEL Management Event Types
A CEL Management Event consists of a type and depending on the type it might contain additional information.
Some of these Events are measured into a PCR whilst others are not. This is denoted accordingly in each part ofsection 4.4.1.
Table 4 defines the content of a CEL Management Event TPMS_EVENT_CELMGT.
Table 4 TPMS_EVENT_CELMGTTYPE
TPMI_CELMGTTYPE
TPMU_CELMGT

FIELD
type
data

VALUE
0
1

DESCRIPTION
The type of CEL event
The data of this CEL event

The VALUE column in Table 5 defines the types of CEL Management Events TPMI_CELMGTTYPE.
Table 5 TPMI_CELMGTTYPE

NAME

VALUE

cel_version

1

firmware_end

2

cel_timestamp

80

State_trans81

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEWDESCRIPTION
Identifies the CEL specification version(Not measured into PCR)
End of firmware events(Not measured into PCR)
Provides a timestamp(Measured into PCR)
Identifies a platform state transition (e.g.,hibernation)(Measured into PCR)

Page 13© TCG 2021

Canonical Event Log Format

Table 6 defines the CEL Management Event content TPMU_CELMGT. The referenced types stem from the TPM
library specification part 2 (TPMS_EMPTY) or are defined in the following sections.
Table 6 TPMU_CELMGTTYPE
TPMS_CEL_VERSION

FIELD
cel_version

SELECTOR
cel_version

TPMS_EMPTY

firmware_end

firmware_end

UINT64

cel_timestamp

cel_timestamp

TPMI_STATE_TRANS

state_transstate_trans

DESCRIPTION
Identifies the CEL specification version
End of firmware events
This event contains not further data, thus
TPMS_EMPTY is matched for the union.
Provides a timestamp as UTC time, in Linuxseconds from the epoch format.
Identifies a platform state transition

4.4.1.1 CEL Version
The Event Content Value Element identifies the specification version this Event Log adheres to. Table 7 defines thecorresponding data types for TPMS_CEL_VERSION.
Table 7 TPMS_CEL_VERSIONTYPEUINT16
UINT16

FIELD
major
minor

VALUE
0
1

DESCRIPTION
Major version (currently 1)
Minor version (currently .0)

This Event SHALL NOT be measured but is included for informational purposes.
4.4.1.2 Firmware End
This Event Content Value Element marks the end of the device’s firmware boot phase and the start of the OS /operational phase. It does not contain any further information.
4.4.1.3 CEL TimestampThis Event Content Value Element contains a timestamp that was Extended.
The data SHALL encoded as UINT64 representing the milliseconds since time-origin (value = 0) according to the
Coordinated Universal Time (UTC).
4.4.1.4 State Trans
This Event Content Value Element contains the device’s state transition. State transitions are platform specific. For
example, ACPI [7] devices that enter suspend (S3) or hibernation (S4) states may want to provide a measured
event indicating this transition. Table 8 defines the structure of event data for this type of CEL Management Event
TPMS_STATE_TRANS.
Table 8 TPMI_STATE_TRANS

NAME
suspendhibernate
kexec

VALUE
0
1
2

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEWDESCRIPTION
System suspending
System is hibernating
System is kexec’ing a new kernel

Page 14© TCG 2021

Canonical Event Log Format

4.5 PCClient_STD Event Types
A PCClient_STD Event consists of a type and depending on the type it might contain additional information. Someof these Events are measured into a PCR whilst others are not, as specified in the TCG PC-Client Firmware Profile
Specification. For this specification, PCClient_STD events SHALL be encapsulated into two fields as defined inTable 9. Detailed informative examples of this encapsulation for different encodings are given in section 5.
PCClient_STD event types are defined in TCG_PCR_EVENT2 structure in [2].
Table 9 defines the content of a PC-Client STD Event TPMS_EVENT_PCCLIENT_STD.
Table 9 TPMS_EVENT_PCCLIENT_STD

TYPE
TPMI_PC_CLIENT_EVENTSBYTEBUFFER

FIELD
event_type
event_data

VALUE
0
1

DESCRIPTION
The type of pc-client event
The data of this pc-client event

TPMI_PC_CLIENT_EVENTS is the event type as specified in [2], Table 9, where the event type can be either the
UINT32 representation or the string representation defined in [2], Table 9.
“BYTEBUFFER” is a field comprising a length delimited set of binary bytes. The exact specification of such fields
may be different for each encoding, and are given for CBOR, TLV and JSON in section 5.

4.6 IMA_TEMPLATE Event Types
An IMA_TEMPLATE Event consists of a template name and template data. The content of the template data ismeasured into a PCR. The format of the template data depends on the template name and this format is defined by
the IMA project.
Table 10 defines the content of an IMA_TEMPLATE Event TPMS_EVENT_IMA_TEMPLATE. The contents of thesefields are defined in [5], and the raw values are encapsulated from the original log data as shown in the informative
examples of this encapsulation in section 5.1.6.
Table 10 TPMS_EVENT_IMA_TEMPLATE

TYPE
StringBYTEBUFFER

FIELD
template_nametemplate_data

VALUE
0
1

DESCRIPTION
The type of IMA event
The data of this IMA event

4.7 IMA-TLV Event Types
The IMA_TLV content field simply consists of the raw BYTEBUFFER field as provided by the Linux kernel. The
content field is fully specified in pending patches to [5], and informative examples are given in section 5. Section 6
provides an informative list of the IMA_TLV content subfield types.

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 15© TCG 2021

Canonical Event Log Format

5 Canonical Event Log Encodings (CEL-EN)
Canonical Event Logs MUST use the information model described in section 4. They MAY use TLV, CBOR, or
JSON as specified in this section. If they do use any of these encodings, they MUST follow the encoding
specifications in this section.
1) Encodings MUST maintain the coherence of the CEL Fields within a CEL Record (CELR)
2) Encodings SHALL either use key value maps to represent TPMS_ structures or ordered lists (arrays) if key
value maps are not supported. The order of these lists SHALL follow the order of the rows in the tables in
section 4.
3) Encodings SHALL use the tag values defined in the enumeration defining tables (Tables 1 – 7 above) if theencodings do not support text-based enumeration values.
4) If encodings support several byte orders the encodings SHOULD use Network byte order.
5) The data type definitions in this specification use the data types from the TPM library specification [1].
Encodings SHALL include the specified data types and their referenced TPM data types accordingly, down tothe base data type definitions of the TPM library specification.

5.1 Canonical Event Log Record Encoding – TLV (CEL-TLV)
In the TLV encoding, every element of a log entry is a Type-Length-Value (TLV) triple (3-tuple) that is defined in Table
11. Figure 1 shows the format of a complete CELR in TLV format, with the four required fields in TLV format.
Table 11 TLV Encoding<T,L,V> Triple

Size / Type

T

8-bit

L

32-bit, unsigned integer, Network Byte Order = Big-EndianV

L bytes/octets

Figure 1 A Canonical Event Log Record in TLV Format

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 16© TCG 2021

Canonical Event Log Format

5.1.1 CEL_RECNUM TLVThe CEL record number field is encoded in a TLV of type RECNUM (Table 12).
Table 12 Record Number<RECNUM> TLV
Trecnum = 0

From Information Model table 1

L

The length in bytes/octets of the value (V). As the value (V) is a sequential number andsince the format is TLV, the length (L) could vary while the log advances. For instance,with a length of 1 (= 1 byte), up to 255 values could be used. After the 255th entry, thelength (L) could be increased to 2, giving enough space for storing 65535 values/numbers.
After that, the length could increase to 3, and so on. This specification fixes the size of L
to 4 bytes, as specified in table 8.

V

The value is the sequential number (an unsigned integer) with the length (L), in network
byte order.

5.1.2 CEL_PCR_NVindex TLV
The CEL PCR or NV Index field is encoded in a TLV as shown in Table 13.
Table 13 PCR or NV Index Field<PCR> TLV
T

pcr = 1, nv_index = 2

Indicates a PCR or NV index

L

The length in bytes/octets of the value (V).
The length (L) could vary: e.g., with a length of 1 (= 1 byte) 255 PCRs could be
differentiated. Larger PCR numbers would need a larger length (L). This specification fixes
the size of L to 4 bytes as specified in table 11.

V

The PCR number (unsigned integer) in network byte order

5.1.3 CEL_DIGESTS TLVThe CEL digest field TLV is nested, with one or more sub-TLV for each bank’s digest, as shown in Table 14.
Table 14 Digests encoding<DIGEST> TLVTDigest = 3

From Information Model table 1

L

Length of the entire digest
content value ‘V’

Network byte orderV

One or more following
digest TLV
T

SHA1

4

SHA256

11

SHA384

12

SHA512

13

From TPML_DIGEST_VALUES

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 17© TCG 2021

Canonical Event Log Format

SM2

27

SM3

18

L

The length of the digest indicated by T

V

The digest of the type indicated by T and the length indicated by L

5.1.4 CEL_CONTENT TLVThe CEL Event Content field is encoded in a TLV as shown in Table 15.
Table 15 Content encoding<CONTENT> TLV
T

CEL

4

Management Content Type from Information Model Table 2

PCCLIENT_STD

5

PC Client WG defined encapsulated structure [2]IMA_TEMPLATE

7

Linux IMA_TEMPLATE format [5]IMA_TLV

8

IMA directly stored in CEL-TLV format

L

The length of the value (V) network byte orderV

The value, according to the type (T)5.1.5 IMA_TLV Content Layer
IMA_TLV is a Linux kernel measurement content layer, in which IMA [5] records are stored directly in CEL format with
TLV encoding using existing fields of the TCG Canonical Event Log Record Information Model (CEL_IM) and TLV
Encoding. In IMA_TLV, the digest field values are hashes across the entire content field TLV data, thus simplifying
the verification, while protecting all the type and length and value information in the field’s TLV and nested TLV’s. The
overall format is shown in figure 2.

Figure 2: IMA_TLV encoding

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 18© TCG 2021

Canonical Event Log Format

A Linux CEL-TLV-IMA content field is a nested TLV with the top-level type IMA_TLV from table 2, containing one ormore CEL-TLV-IMA content fields, as shown in Table 16.
Table 16 IMA_TLV Content Encoding

IMA_TLVT

IMA_TLV_CONTENT_PATH (0)full pathname of the file

IMA_TLV_CONTENT_DATAHASH (1)The hash over the file content.

IMA_TLV_CONTENT_DATASIG (2)A file signature in IMA format, which includes type andkeyid.

IMA_TLV_CONTENT_OWNER (3)File owner (uid)

IMA_TLV_CONTENT_GROUP (4)File group (gid)

IMA_TLV_CONTENT_MODE (5)Linux uint16 bitmask of the file permission bits

IMA_TLV_CONTENT_TIMESTAMP (6)Linux time_t file creation/modification time

IMA_TLV_CONTENT_LABEL (7)LSM security label on the file (e.g., selinux label)L

The length of the value (V).

V

The value (V) containing data of the type (T).

Start of informative comment
The following is a hex/ascii dump of one CELR in the CEL-IMA-TLV format. The dump isrepeated, with each TLV formatted CEL field highlighted and explained.
00000000 00 00 00 00 04 00 00 00 01 01 00 00 00 04 00 00
00000010 00 0a 03 00 00 00 19 04 00 00 00 14 4b 47 65 fa
00000020 62 21 a2 c6 d6 d2 a2 7c 5c e9 22 df b8 93 e9 3f
00000030 08 00 00 00 26 00 00 00 00 08 2f 62 69 6e 2f 66
00000040 6f 6f 01 00 00 00 14 00 01 02 03 04 05 06 07 08
00000050 09 0a 0b 0c 0d 0e 0f 10 11 12 13
Field: ‘0’ (SEQNUM), Length 4, value 00000001|................||............KGe.||b!.....|\."....?||....&...../bin/f||oo..............||...........|

00000000 00 00 00 00 04 00 00 00 01 01 00 00 00 04 00 00
00000010 00 0a 03 00 00 00 19 04 00 00 00 14 4b 47 65 fa
00000020 62 21 a2 c6 d6 d2 a2 7c 5c e9 22 df b8 93 e9 3f
00000030 08 00 00 00 26 00 00 00 00 08 2f 62 69 6e 2f 66
00000040 6f 6f 01 00 00 00 14 00 01 02 03 04 05 06 07 08
00000050 09 0a 0b 0c 0d 0e 0f 10 11 12 13
Field ‘1’ (PCRNUM) length 4, value 10 (decimal)|................||............KGe.||b!.....|\."....?||....&...../bin/f||oo..............||...........|

00000000 00 00 00 00 04 00 00 00 01 01 00 00 00 04 00 00 |................|
00000010 00 0a 03 00 00 00 19 04 00 00 00 14 4b 47 65 fa |............KGe.|
00000020 62 21 a2 c6 d6 d2 a2 7c 5c e9 22 df b8 93 e9 3f |b!.....|\."....?|
00000030 08 00 00 00 26 00 00 00 00 08 2f 62 69 6e 2f 66 |....&...../bin/f|
00000040 6f 6f 01 00 00 00 14 00 01 02 03 04 05 06 07 08 |oo..............|
00000050 09 0a 0b 0c 0d 0e 0f 10 11 12 13|...........|
Field ‘3’ (Digest), Length 25,
Nested TLV, type ‘04’ (SHA1) 20 bytes, 4B4765FA6221A2C6D6D2A27C5CE922DFB893E93F

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 19© TCG 2021

Canonical Event Log Format(The following is the digest of the entire following content TLV (bytes 07..13)00000000 00 00 00 00 04 00 00 00 01 01 00 00 00 04 00 00 |................|
00000010 00 0a 03 00 00 00 19 04 00 00 00 14 4b 47 65 fa |............KGe.|
00000020 62 21 a2 c6 d6 d2 a2 7c 5c e9 22 df b8 93 e9 3f |b!.....|\."....?|
00000030 08 00 00 00 26 00 00 00 00 08 2f 62 69 6e 2f 66 |....&...../bin/f|
00000040 6f 6f 01 00 00 00 14 00 01 02 03 04 05 06 07 08 |oo..............|
00000050 09 0a 0b 0c 0d 0e 0f 10 11 12 13|...........|
Field ‘8’ (IMA-TLV content), length 38 bytes. This has two nested IMA-TLV contents:
IMA Type ’00’ (Path) Length 8, value “/bin/foo” andIMA Type ‘01’ (datahash), length 20, value bytes 00 01…12 13.

End of informative comment

5.1.6 IMA_TEMPLATE Content Layer
The existing IMA_TEMPLATE log [5] uses a named “template” to specify the content format. This section specifies
CEL-TLV encapsulation of records from the “ima-ng” template native format, which includes “d-ng” (file-hash) and“n-ng” (filename) fields.
Start of informative comment“ima-ng” is a binary format with records of:[uint32 little endian pcr]
[20 digest][uint32 little endian template name len = 6]
[template name = “ima-ng” not null terminated][uint32 little endian rec len]d-ng: [uint32 little endian hash len]*[hash id – e.g., “sha1:” null terminated]*[file hash]*n-ng: [uint32 little endian path len]*[path – null terminated]*
For example, the following is a hexdump of the first two records in an actual native log:
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000a0000000b0
000000c0

0a 00 00 00 2d 92 56 f5
3f 44 b9 ab b6 8a 30 ee
6e 67 31 00 00 00 1a 00
5b e8 d5 1b fe af 79 f2
3c 93 8c fc 0f 00 00 00
72 65 67 61 74 65 00 0a
20 ce b0 9a c5 2e 8b 61
00 00 00 69 6d 61 2d 6e00 73 68 61 32 35 36 3a
82 15 81 2b 55 c1 24 34
58 0d 0d 5c 9a ea eb 2d
72 2f 6c 69 62 2f 73 79
73 74 65 6d 64 00

92 9d 55 13 16 09 ff 7c
06 00 00 00 69 6d 61 2d00 00 73 68 61 31 3a 00
ff 71 41 17 1a b7 a5 d3
62 6f 6f 74 5f 61 67 67
00 00 00 46 80 a2 18 f5
c8 12 c2 50 5e 2f 67 06
67 49 00 00 00 28 00 00
00 64 a9 81 99 bc 62 58
e7 a2 61 f7 b6 ed 93 ea
9c 19 00 00 00 2f 75 73
73 74 65 6d 64 2f 73 79|....-.V...U....|||?D....0.....ima-||ng1.......sha1:.||[.....y..qA.....||<.......boot_agg||regate.....F....|| ......a...P^/g.||...ima-ngI...(..||.sha256:.d....bX||...+U.$4..a.....||X..\...-...../us||r/lib/systemd/sy|

This log contains two records: the first is the special “boot_aggregate” event, in which
IMA hashes together PCRS 0-7. The second record, highlighted in yellow, can be parsed as:

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 20© TCG 2021

Canonical Event Log Format[uint32 little endian pcr]
0x0a
[20 digest]
46 80 ... 2f 67<-----------|[uint32 little endian template name len] 0x06|
[template name]"ima-ng"|[uint32 little endian rec len]
0x49|
d-ng:[uint32 little endian hash len]* 0x28->|["id:"]*"sha256:\0"->|[file hash]*
64 a9 ... 2d 9c->|n-ng:[uint32 little endian path len]* 0x19->|
[path]*"/usr/lib/systemd/systemd\0'->|

The digest is of the record data (marked with '*' above):
28 00 00 00 73 68 61 32 35 36 3a 00 64 a9 81 99 bc 62 58 82 15 81 2b 55 c1 24 34 e7
a2 61 f7 b6 ed 93 ea 58 0d 0d 5c 9a ea eb 2d 9c 19 00 00 00 2f 75 73 72 2f 6c 69 62
2f 73 79 73 74 65 6d 64 2f 73 79 73 74 65 6d 64 00
The sha1 of this binary data is:4680a218f520ceb09ac52e8b61c812c2505e2f67
which matches the given digest.
Note that, since the template name, template name length, and record length fields are
not hashed, the parser should use care in using the given values.
End of informative comment

In order to encapsulate IMA_TEMPLATE formatted Event Log Records in CEL_TLV format, add a record number,encapsulate the existing PCR number in TLV, encapsulate the digest(s) (nested), and then nest the template name
TLV, and hashed content TLV, into a content TLV. This makes it simpler to hash the content sub-TLV for
verification, because it is only slightly different from the nominal hashing of the entire content TLV. This
encapsulation is shown in figure 3. The content TLVs SHALL use the type names or numbers as shown in the figure
3. The encapsulation of IMA_TEMPLATE in CEL-TLV SHALL use the field names and values shown in figure 3.

Figure 3 Encapsulating IMA_TEMPLATE in CEL-TLV

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 21© TCG 2021

Canonical Event Log Format

Start of informative comment
A program was written to translate binary ima-ng formatted logs into CEL-TLV-IMA-TEMPLATE
formatted ones. Translating the above ima-ng example yields the following, with all TYPE
bytes in yellow:
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000a0000000b0
000000c0000000d0000000e0000000f00000010000 00 00 00 04 00 00 00
00 0a 03 00 00 00 19 04
92 9d 55 13 16 09 ff 7c
07 00 00 00 41 00 00 00
01 00 00 00 31 1a 00 00
e8 d5 1b fe af 79 f2 ff
93 8c fc 0f 00 00 00 62
65 67 61 74 65 00 00 00
00 00 00 04 00 00 00 0a
00 14 46 80 a2 18 f5 20
12 c2 50 5e 2f 67 07 00
69 6d 61 2d 6e 67 01 00
68 61 32 35 36 3a 00 64
81 2b 55 c1 24 34 e7 a2
0d 5c 9a ea eb 2d 9c 19
6c 69 62 2f 73 79 73 74
65 6d 64 00

00 01 00 00 00 04 00 00
00 00 00 14 2d 92 56 f5
3f 44 b9 ab b6 8a 30 ee
00 06 69 6d 61 2d 6e 67
00 73 68 61 31 3a 00 5b
71 41 17 1a b7 a5 d3 3c
6f 6f 74 5f 61 67 67 72
00 00 04 00 00 00 01 01
03 00 00 00 19 04 00 00
ce b0 9a c5 2e 8b 61 c800 00 59 00 00 00 00 06
00 00 49 28 00 00 00 73
a9 81 99 bc 62 58 82 15
61 f7 b6 ed 93 ea 58 0d
00 00 00 2f 75 73 72 2f
65 6d 64 2f 73 79 73 74|................||............-.V.||..U....|?D....0.||....A.....ima-ng||....1....sha1:.[||.....y..qA.....<||.......boot_aggr||egate...........||................||..F.... ......a.||..P^/g....Y.....||ima-ng....I(...s||ha256:.d....bX..||.+U.$4..a.....X.||.\...-...../usr/||lib/systemd/syst|

tlv_dump parses and verifies this tlv encapsulated IMA TEMPLATE as:
SEQNUM 00000000
PCRNUM 10
DIGEST SHA1 2D9256F5929D55131609FF7C3F44B9ABB68A30EE
TEMPLATE NAME ima-ng
filesha1: 5BE8D51BFEAF79F2FF7141171AB7A5D33C938CFC
path: boot_aggregate
Digest matches content.
SEQNUM 00000001
PCRNUM 10
DIGEST SHA1 4680A218F520CEB09AC52E8B61C812C2505E2F67
TEMPLATE NAME ima-ng
filesha256: 64A98199BC62588215812B55C12434EA261F7B6ED93EA580D0D5C9AEAEB2D9C
path: /usr/lib/systemd/systemd
Digest matches content.
End of informative comment

5.1.7 PCCLIENT_STD Content Layer
Existing PCCLIENT records [2] are converted to TLV format in much the same way as IMA_TEMPLATE records
were specified in section 5.1.6. The overall content is encapsulated in a TLV of type PCCLIENT_STD, whichcontains two nested TLV, one containing the uint32_t EventType, and one containing the EventContent, with thefield values shown in figure 4.
Start of informative comment
The only difference is that in the IMA_TEMPLATE case, all digests were produced by hashing the EventContent
value directly. In the case of PCCLIENT_STD, this is true of some of the EventContents, but not all. For example,
Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 22© TCG 2021

Canonical Event Log Format

EV_NO_ACTION events are advisory only, and the digests (of all zeros) are not Extended. In EV_POST_CODE,
the digests are of the code or data to be measured, and the digests are Extended into the specified PCR, but theevent content contains unverified hints or related information, and not the original data or hash. The TCG PC Client
Platform Firmware Profile Specification [2] contains the details of what is in the contents for all Event Types. Whilean attacker cannot change any of the record number, PCR, and Digest fields without detection by comparison to theactual PCR values, the attacker can freely change all the event type fields and some of the event content fields.
Verifiers must not trust any unverified fields, which are included merely as hints.
End of informative comment
Figure 4 illustrates this encapsulation of the data from the log’s native EVENT2 structure into a CEL-TLV encoding:Figure 4 PCCLIENT encapsulation in CEL_TLV format

Start of informative comment
In more detail, the PCCLIENT event log consists of one EVENT-1 structure, followed by one or more Event-2
structures. The EVENT-1 structure is similar to the EVENT-2 shown but has a single fixed SHA-1 digest of 20 bytes,
without the count or HashAlg fields.
event-1
uint32_t
uint32_t
uint8_tuint32_t
uint8_t
event-2
uint32_t
uint32_t
uint32_t
uint16_t
uint8_t...
uint32_t
uint8_t

PCR_Index
EventTypesha1_digest[20]event_data_size
data[]//little-endian//little-endian

PCR_Index
EventTypedigest_countdigest1_alg
digest1[]//little-endian//little-endian

event_data_size
data[]//little-endian//little-endian//little-endianThe following is a hexdump of the first two PCCLIENT records from an actual system,with the first event highlighted in yellow:
Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 23© TCG 2021

Canonical Event Log Format

00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090

00 00 00 00 03 00 00 00
00 00 00 00 00 00 00 00
53 70 65 63 20 49 44 20
00 00 00 00 00 02 00 02
0b 00 20 00 00 00 00 00
00 04 00 c4 2f ed ad 26
c3 44 e7 9d ae 33 20 0b
13 b8 03 56 80 17 f9 03
3d b3 2b 6e ab ed bb f1
54 0c 1d 55 40 a4 ad 4e00 00 00 00 00 00 00 00
00 00 00 00 25 00 00 00
45 76 65 6e 74 30 33 00
02 00 00 00 04 00 14 00
00 08 00 00 00 02 00 00
82 00 cb 1d 15 f9 78 41
00 d4 72 0b 40 09 43 82
09 3f 6b ea 8a b4 7d 28
55 10 00 00 00 1e fb 6b
f4 bf 17 b8 3a|................||............%...||Spec ID Event03.||................||.. .............||..../..&......xA||.D...3 ...r.@.C.||...V.....?k...}(||=.+n....U......k|Event-1 (highlighted above in yellow):
PCR:
00 00 00 00// PCR0
EventType 03 00 00 00// 3 – EV_NO_ACTION
Sha-1
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Data size 25 00 00 00// 37 bytes
Data
53 70 … 20 00 00
Similarly, Event-2 is:
PCR
00 00 00 00// PCR 0
EventType 08 00 00 00// 8 - EV_S_CRTM_VERSION
Dgstcount 02 00 00 00// two digests
Dgst1Alg 04 00// 4 – sha1
Dgst1
c4 2f ed … ae 33 20
Dgst2Alg 0b 00// sha256
Dgst2
d4 72 0b …bb f1 55
Datasize 10 00 00 00// 16 bytes
Data
1e fb 6b … 17 b8 3a
The following is a hexdump of the same events translated to PCCLIENT_STD format with thefirst event highlighted in yellow:
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000a0000000b0
000000c0000000d0

00 00 00 00 04 00 00 00
00 00 03 00 00 00 19 04
00 00 00 00 00 00 00 00
05 00 00 00 33 00 00 00
00 00 25 53 70 65 63 20
30 33 00 00 00 00 00 00
00 14 00 0b 00 20 00 00
01 01 00 00 00 04 00 00
00 00 00 14 c4 2f ed ad
41 c3 44 e7 9d ae 33 20
40 09 43 82 13 b8 03 56
8a b4 7d 28 3d b3 2b 6e
00 1e 00 00 00 00 04 00
1e fb 6b 54 0c 1d 55 40

00 01 00 00 00 04 00 00
00 00 00 14 00 00 00 00
00 00 00 00 00 00 00 00
00 04 00 00 00 03 01 00
49 44 20 45 76 65 6e 74
02 00 02 02 00 00 00 04
00 00 00 00 04 00 00 00
00 00 03 00 00 00 3e 04
26 82 00 cb 1d 15 f9 78
0b 00 00 00 20 d4 72 0b
80 17 f9 03 09 3f 6b ea
ab ed bb f1 55 05 00 00
00 00 08 01 00 00 00 10
a4 ad 4e f4 bf 17 b8 3a

Event 1 (highlighted above in yellow):
T: 00 L: 00 00 00 04 V: 00 00 00 00
T: 01 L: 00 00 00 04 V: 00 00 00 00
T: 03 L: 00 00 00 19 V: nested
T: 04 L: 00 00 00 14 V: 00 … 00

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW|................||................||................||....3...........||..%Spec ID Event||03..............||..... ..........||..............>.||...../..&......x||A.D...3 .... .r.||@.C....V.....?k.||..}(=.+n....U...||................|// SEQNUM 0// PCRNUM 0// Digest header// sha-1, 16 zero bytes

Page 24© TCG 2021

Canonical Event Log Format

T: 05

L 00 00 00 33 V
nestedT: 00 L: 00 00 00 04 V: 00 00 00 03// Event Type 3
T: 01 L: 00 00 00 25 V: 53 70 … 00 00 // Event Content 37 bytes

Tlv_dump parses and reports these as:
SEQNUM 0 PCRNUM 0 DIGESTS SHA1 0000000000000000000000000000000000000000 PCCLIENTTYPE EV_NO_ACTION CONTENT 53706563204944204576656E74303300000000000002000202000
000040014000B00200000
SEQNUM 1 PCRNUM 0 DIGESTS SHA1 C42FEDAD268200CB1D15F97841C344E79DAE3320 SHA256 D
4720B4009438213B803568017F903093F6BEA8AB47D283DB32B6EABEDBBF155 PCCLIENT TYPE EV_S_CRTM_VERSION CONTENT 1EFB6B540C1D5540A4AD4EF4BF17B83A SHA1 Matches content.

End of informative comment

5.1.8 CEL_MGT Content Layer
CEL_MGT is a simple record, defined directly in native TLV format. Figure 5 shows the format of this record.

Figure 5 CEL Management content in CEL_TLVThe CEL Management tag is ‘4’. Note that multiple management content fields may be in a single Log Record, as
shown in Figure 5.

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 25© TCG 2021

Canonical Event Log Format

5.2 Canonical Event Log Encoding - Binary (CEL-CBOR)
Start of informative comment
RFC 7049 defines a Concise Binary Object Representation (CBOR) format. RFC 8610 defines Concise Data
Definition Language (CDDL), which can be used to specify CBOR encodings. Section 5.2.1 and 5.2.2 provide theroot and label specifications for the CEL-CBOR encoding. This encoding defines raw binary format for a Canonical
Event Log that is compliant with this CEL specification, with content encapsulation using the same defined content
types as in the TLV encodings in section 5.1. As the CDDL specification in 5.2.1 and 5.2.2 can be compiled into
automated processing tools, informative examples, and diagrams of the CEL-CBOR format are not included in thisdocument.
Note that Section 5.2.1 and 5.2.2 contain a complete specification for CEL-CBOR and for the encapsulated
PCCLIENT and IMA content layers. This specification is not authoritative over the TCG PC Client Platform Firmware
Profile [2] and TPM Algorithm Registry [3] definitions, and the relevant values are included in this CEL-CBOR
specification for convenience only. The CDDL sections contain comments on which sections are taken from whichreference, and the indicated references should be consulted for authoritative values.
End of informative comment

5.2.1 CEL Root Encoding Layer CDDL Specification
tcg-canonical-event-log = [ * TPMS_CEL_EVENT-choice ]TPMS_CEL_EVENT-choice = &(TPMS_CEL_EVENT<cel, TPMS_EVENT_CELMGT-choice>,
TPMS_CEL_EVENT<pcclient_std, TPMS_EVENT_PCCLIENT_STD>,TPMS_CEL_EVENT<ima_template, TPMS_EVENT_IMA_TEMPLATE>,
TPMS_CEL_EVENT<ima_tlv, BYTEBUFFER>,* $TPMS_CEL_EVENT-extension,)
TPMS_CEL_EVENT<T,C> = {recnum => uint,
pcr-xor-nv-index,
digests => TPML_DIGEST_VALUES,
content_type => T, ; from TPMI_CEL_CONTENT_TYPE
content => C,; TPMU_EVENTCONTENT group choice}
pcr-xor-nv-index //= ( pcr => 0x00000000..0x00FFFFFF )pcr-xor-nv-index //= ( nv_index => 0x20000000..0x20FFFFFF )TPML_DIGEST_VALUES = [ + TPMT_HA ]TPMT_HA = {hashAlg => $TPMI_ALG_HASH, ; manually added below for completenessdigest => BYTEBUFFER,}
TPMS_EVENT_CELMGT-choice = &(TPMS_EVENT_CELMGT<cel_version, TPMS_CEL_VERSION>,
TPMS_EVENT_CELMGT<cel_timestamp, uint .size 8>,
TPMS_EVENT_CELMGT<state_trans, $TPMI_STATE_TRANS>,

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 26© TCG 2021

Canonical Event Log Format{ celmgt.type => firmware_end },* $$TPMS_EVENT_CELMGT-extensions,)
TPMS_EVENT_CELMGT<T,D> = {celmgt.type => T,; from TPMI_CELMGTTYPE
celmgt.data => D,; from TPMU_CELMGT}TPMS_CEL_VERSION = {major => uint .size 2,
minor => uint .size 2,}$TPMI_STATE_TRANS /= suspend$TPMI_STATE_TRANS /= hibernate$TPMI_STATE_TRANS /= kexec
TPMS_EVENT_PCCLIENT_STD = {event_type => text / uint .size 4,
event_data => BYTEBUFFER,}
TPMS_EVENT_IMA_TEMPLATE = {template_name => text,
template_data => BYTEBUFFER,};; The following rules originate from TCG Algorithm Registry [3];; For convenience, the section below is extracted from;; tcg-algorithm-registry_JSON.cddl. This document should be used;; in conjunction with the original tcg-algorithm-registry.cddl$TPMI_ALG_HASH /= TPM_ALG_SHA$TPMI_ALG_HASH /= TPM_ALG_SHA1$TPMI_ALG_HASH /= TPM_ALG_SHA256$TPMI_ALG_HASH /= TPM_ALG_SHA384$TPMI_ALG_HASH /= TPM_ALG_SHA512$TPMI_ALG_HASH /= TPM_ALG_SM3_256$TPMI_ALG_HASH /= TPM_ALG_SHA3_256$TPMI_ALG_HASH /= TPM_ALG_SHA3_384$TPMI_ALG_HASH /= TPM_ALG_SHA3_512

5.2.2 CEL-CBOR CDDL Specification for labels:; start of CBOR labels
recnum = 0
pcr = 1
nv_index = 2
digests = 3
cel = 4
pcclient_std = 5
ima_template = 7

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 27© TCG 2021

Canonical Event Log Format

ima_tlv = 8
content_type = 9content = 10
hashAlg = 0
digest = 1
celmgt.type = 0
celmgt.data = 1
cel_version = 1
firmware_end = 2
cel_timestamp = 80
state_trans = 81
major = 0minor = 1
suspend = 0
hibernate = 1
kexec = 2
event_type = 0
event_data = 1
template_name = 0
template_data = 1
BYTEBUFFER = bytes;; The following rules originate from TCG Algorithm Registry [3];; For convenience, the section below is extracted from;; tcg-algorithm-registry_CBOR.cddl. This document should be used;; in conjunction with the original tcg-algorithm-registry.cddl
TPM_ALG_SHA = 0x0004
TPM_ALG_SHA1 = 0x0004
TPM_ALG_SHA256 = 0x000B
TPM_ALG_SHA384 = 0x000C
TPM_ALG_SHA512 = 0x000D
TPM_ALG_SM3_256 = 0x0012
TPM_ALG_SHA3_256 = 0x0027
TPM_ALG_SHA3_384 = 0x0028
TPM_ALG_SHA3_512 = 0x0029

5.3 CEL-JSON encoding
Start of informative comment
CEL-JSON encoding is authoritatively specified in TCG TSS 2.0 JSON Data Types and Policy Language
Specification [8], and its CDDL is included here for convenience. This encoding uses the fields and field names as
specified in section 4, with the additional specification that BYTEBUFFER as used in section 4 is encoded as
TPM2B. The following is an illustrative example of a CDDL specification for CEL-JSON labels. It should be
combined with the CEL Root CDDL specification in section 5.2.1 for a complete specification.

; start of JSON labels
recnum = "recnum"
pcr = "pcr"nv_index = "nv_index"
digests = "digests"cel = "cel" / 4Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 28© TCG 2021

Canonical Event Log Format

pcclient_std = "pcclient_std" / 5
ima_template = "ima_template" / 7
ima_tlv = "ima_tlv" / 8content_type = "content_type"content = "content"
hashAlg = "hashAlg"
digest = "digest"
celmgt.type = "type"celmgt.data = "data"
cel_version = "cel_version" / 1
firmware_end = "firmware_end" / 2
cel_timestamp = "cel_timestamp" / 80
state_trans = "state_trans" / 81
major = "major"
minor = "minor"
suspend = "suspend" / 0hibernate = "hibernate" / 1
kexec = "kexec" / 2event_type = "event_type"
event_data = "event_data"
template_name = "template_name"template_data = "template_data"
BYTEBUFFER = text;; The following rules originate from TCG Algorithm Registry [3];; For convenience, the section below is extracted from;; tcg-algorithm-registry_JSON.cddl. This document should be used;; in conjunction with the original tcg-algorithm-registry.cddl
TPM_ALG_SHA = "sha" / 0x0004
TPM_ALG_SHA1 = "sha1" / 0x0004
TPM_ALG_SHA256 = "sha256" / 0x000B
TPM_ALG_SHA384 = "sha384" / 0x000C
TPM_ALG_SHA512 = "sha512" / 0x000D
TPM_ALG_SM3_256 = "sm3_256" / 0x0012
TPM_ALG_SHA3_256 = "sha3_256" / 0x0027
TPM_ALG_SHA3_384 = "sha3_384" / 0x0028
TPM_ALG_SHA3_512 = "sha3_512" / 0x0029
The following is an example of PCCLIENT_STD encoded in CEL-JSON.
[{"content":{"event_type":"EV_COMPACT_HASH","event_data":"44656c6c20436f6e66696775726174696f6e20496e666f726d6174696f6e2032"},"content_type":"pcclient_std","pcr":6,"recnum":2,"digests":[

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 29© TCG 2021

Canonical Event Log Format{"hashAlg":"sha1","digest":"bac9a8935b720760bcdea2faae75152f5d1e4bea"},{"hashAlg":"sha256","digest":"d18bf8d221a3a3b08774c8d077328c4b2ca205e4f1618ad4bac2b5786f453bc7"}]}]
End of informative comment

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 30© TCG 2021

Canonical Event Log Format

6 Defined types for all examples.
Start of informative comment
The following are C code definitions for the CEL-TLV and CEL-CBOR types used in the
Examples in section 5.
/* TCG CEL Top Level Event Types */#define CEL_SEQNUM
0#define CEL_PCR
1#define CEL_NV_INDEX
2#define CEL_DIGESTS
3#define CEL_MGT
4#define CEL_PCCLIENT_STD
5#define CEL_IMA_TEMPLATE
7#define CEL_IMA_TLV
8/* TCG TPM Digest Types */#define TPM_ALG_SHA1#define TPM_ALT_SHA256

411/* CEL_MGT types#define CEL_MGT_TYPE#define CEL_MGT_DATA#define CEL_MGT_CEL_VERSION#define CEL_MGT_CEL_VERSION_MAJOR#define CEL_MGT_CEL_VERSION_MINOR#define CEL_MGT_FIRMWARE_END#define CEL_MGT_CEL_TIMESTAMP#define CEL_MGT_STATE_TRANS#define CEL_MGT_STATE_TRANS_SUSPEND#define CEL_MGT_STATE_TRANS_HIBERNATE#define CEL_MGT_STATE_TRANS_KEXEC

0
1
1
0
1
2
80
81
0
1
2

/* IMA-TLV Specific Content Types */#define IMA_TLV_PATH0#define IMA_TLV_DATAHASH
1#define IMA_TLV_DATASIG
2#define IMA_TLV_OWNER
3#define IMA_TLV_GROUP
4#define IMA_TLV_MODE
5#define IMA_TLV_TIMESTAMP
6#define IMA_TLV_LABEL
7/* IMA_TEMPLATE Specific Content Types */#define IMA_TEMPLATE_NAME
0#define IMA_TEMPLATE_DATA
1/* PCCLIENT_STD content types */#define PCCLIENT_STD_TYPE#define PCCLIENT_STD_CONTENT

01

End of informative comment

Canonical Event Log Format | Version: 1.0 | Revision: 0.37 | 8/31/2021 | PUBLIC REVIEW

Page 31© TCG 2021