TCG Guidance for Securing Network
Equipment Using TCG Technology
Version 1.0
Revision 29
Jan 17, 2018
Published

Contact: admin@trustedcomputinggroup.org

TCG Published
Copyright © TCG 2018

TCG

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Disclaimers, Notices, and License Terms
THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANYWARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULARPURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, DOCUMENTOR SAMPLE.
Without limitation, TCG disclaims all liability, including liability for infringement of any proprietary rights,
relating to use of information in this document and to the implementation of this document, and TCG
disclaims all liability for cost of procurement of substitute goods or services, lost profits, loss of use, lossof 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 document 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 documents or (b) developing, testing, or promoting
information technology standards and best practices, so long as you distribute the document withthese disclaimers, notices, and license terms.
Contact the Trusted Computing Group at www.trustedcomputinggroup.org for information on document
licensing through membership agreements.
Any marks and brands contained herein are the property of their respective owners.

Revision 29

2
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

Acknowledgements
Laffey, Mr. Tom (Co-chair)

Hewlett Packard Enterprise

Eckel, Mr. Michael (Co-chair)

Huawei Technologies Co., Ltd.

Fedorkow, Mr. Guy (Editor)

Juniper Networks, Inc.

Kuntze, Dr. Nicolai

Huawei Technologies Co., Ltd.

Latze, Ms. Carolin

Carolin Latze

Bell, Mr. Bob

Cisco Systems

Pritikin, Mr. Max

Cisco Systems

Sulzen, Mr. Bill

Cisco Systems

Jacobs, Mr. Bill

Cisco Systems

Birkholz, Mr. Henk

Fraunhofer Institute for Secure Information
Technology (SIT)

Fuchs, Mr. Andreas

Fraunhofer Institute for Secure Information
Technology (SIT)

Kotani, Dr. Seigo

Fujitsu Limited

McDonald, Mr. Ira

High North Inc

Rudolph, Dr. Carsten

Huawei Technologies Co., Ltd.

Zhang, Ms. Yi

Huawei Technologies Co., Ltd.

Hanna, Mr. SteveInfineon Technologies North America Corp.

Rudy, Mr. Gregory

INTEGRITY Security Services, Inc.

Watsen, Mr. Kent

Juniper Networks, Inc.

Shah, Mr. Atul

MicrosoftThungathurthi, Mr. Bhavani

Microsoft

Proudler, Mr. Graeme

Graeme Proudler

Lorenzin, Ms. Lisa

Pulse Secure, LLC

Schmidt, Mr. Charles

The MITRE Corporation

Fitzgerald-McKay, Ms. Jessica

United States Government

Revision 29

3
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1

Table of Contents

2

1. Scope, Audience and Purpose ......................................................................................................................... 7

3

1.1

Scope .................................................................................................................................................... 7

4

1.2

Audience and Purpose .......................................................................................................................... 75

2. Preface .............................................................................................................................................................. 8

6

2.1

Network Equipment Reference Model .................................................................................................. 87

2.2Internal Structure of Network Equipment .............................................................................................. 98

2.3

Stakeholders ....................................................................................................................................... 1092.4

Key Differences between Network Equipment and PC Applications .................................................. 11

10

2.4.1

Long Life Cycle ............................................................................................................................ 12

11

2.4.2

Privacy and Networking Equipment ............................................................................................. 12

12
13
14

2.5

Summary of Recommendations .......................................................................................................... 13

3. Use Cases ...................................................................................................................................................... 14
3.1

Device Identity ..................................................................................................................................... 14

15

3.1.1

OEM Device Identity and Counterfeit Protection ......................................................................... 14

16

3.1.2

Identity for Network Access ......................................................................................................... 15

17

3.2

Secure Zero Touch Provisioning ......................................................................................................... 15

18

3.3

Securing Secrets ................................................................................................................................. 16

19

3.4

Protection of Configuration Data ......................................................................................................... 17

20

3.5

Remote Device Management .............................................................................................................. 17

21

3.6

Software Inventory .............................................................................................................................. 18

22

3.7

Attestation of Integrity for Network Devices (“Health Check”) ............................................................ 18

23

3.8

Inventory of Composite Devices ......................................................................................................... 18

24

3.9

Integrity-Protected Logs ...................................................................................................................... 19

25

3.10

Entropy Generation ............................................................................................................................. 19

26

3.11

Deprovisioning..................................................................................................................................... 20

27

4. Building Blocks................................................................................................................................................ 21

28

4.1

Chain of Trust ...................................................................................................................................... 21

29

4.2

Secure Boot vs. Measured Boot ......................................................................................................... 22

30

4.3

802.1AR Device Identification ............................................................................................................. 23

31
32
33

5. Technology Recommendations ...................................................................................................................... 25
5.1

Device Identity ..................................................................................................................................... 25

5.1.1

OEM Device Identity and Counterfeit Protection ......................................................................... 26

34

5.1.1.1

Configuring Initial Identity Credentials ........................................................................................ 27

35

5.1.1.2

Signing and Encryption Key Types ............................................................................................. 27

36

5.1.1.3

Identity for Attestation ................................................................................................................. 28

Revision 29

4
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

37

5.1.1.4

Initial Identity with TPM1.2 .......................................................................................................... 29

38

5.1.1.5

Key Types in TPM2.0 .................................................................................................................. 29

39

5.1.1.6

Initial Identity with TPM2.0 .......................................................................................................... 31

40

5.1.1.7

Loss of IDevID Credentials ......................................................................................................... 33

41

5.1.1.8

Compromise of Keys ................................................................................................................... 33

42

5.1.2

43

5.1.2.1

44

How to Install a Local Device ID ................................................................................................. 34

5.1.2.1.1 Conveying TPM Certify Information ........................................................................................ 35

45
46

Local Device Identity .................................................................................................................... 33

5.1.2.2
5.1.3

Attestation with Local Identity ..................................................................................................... 35
Identity for Network Authentication .............................................................................................. 36

47

5.1.3.1

Proving a Link to the TPM ........................................................................................................... 36

48

5.1.3.2

Why Not Just Use EK and Platform Cert for Identity? ................................................................ 36

49

5.2

Secure Zero Touch Provisioning ......................................................................................................... 37

50

5.3

Securing Secrets ................................................................................................................................. 38

51

5.4

Protection of Configuration Data ......................................................................................................... 39

52

5.5

Remote Device Management .............................................................................................................. 40

53

5.6

Software Inventory .............................................................................................................................. 40

54

5.7

Attestation of Integrity for Network Devices (“Health Check”) ............................................................ 41

55

5.7.1

56
57

Linux Integrity Measurement Architecture (IMA) ......................................................................... 43

5.7.1.1
5.7.2

IMA Appraisal .............................................................................................................................. 46
PCR Definitions ............................................................................................................................ 47

58

5.8

Composite Networking Devices .......................................................................................................... 47

59

5.9

Integrity-Protected Logs ...................................................................................................................... 48

60

5.9.1

Functional Requirements ............................................................................................................. 48

61

5.9.2

Integrity-Protected Log Implementation ....................................................................................... 49

62

5.9.2.1

Timekeeping in TPM 1.2 ............................................................................................................. 49

63

5.9.2.2

Timekeeping in TPM 2.0 ............................................................................................................. 50

64

5.9.2.3

Assembling the Log .................................................................................................................... 51

65

5.10

Entropy Generation ............................................................................................................................. 52

66

5.11

Deprovisioning..................................................................................................................................... 53

67

6. References ...................................................................................................................................................... 54

68

7. Glossary .......................................................................................................................................................... 56

69

8. Appendices ..................................................................................................................................................... 57

70

8.1

Use-Cases for Further Study .............................................................................................................. 57

71

8.1.1

Secure Identity in Virtual Machines.............................................................................................. 57

72

8.1.2

Distributed Composite Devices .................................................................................................... 57

73

8.1.3

Device Identity Stability in Highly Available Systems .................................................................. 57

Revision 29

5
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

74

8.2

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Standardization Work for Further Study .............................................................................................. 57

75

8.2.1

Known Good Hashes ................................................................................................................... 57

76

8.2.2

Composite Systems ..................................................................................................................... 58

77

8.2.3

Reference Manifests .................................................................................................................... 58

Revision 29

6
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

78

1. Scope, Audience and Purpose

79
80
81
82
83

This document, the TCG Guidance for Securing Network Equipment, is part of the Trusted
Computing Group’s collection of Reference Documents, written by the Network Equipment
Sub Group (NE-SG) to assist architects and designers determine where and how TCG
technology, including the Trusted Platform Module, can best be used to secure network
equipment such as routers, switches, and firewalls.

84

1.1

85
86
87
88

The TCG Guidance for Securing Network Equipment provides recommendations and detailed
advice on how TCG standards should be used to improve the security of network equipment
such as routers, switches, and firewalls. Physical network functions are considered in thisdocument; virtualized network functions are not considered in this version.

89
90
91

While the TPM’s resistance to physical attack can help protect device identity, and caneffectively prevent the leakage of credentials and other secrets, defense against physicalattack is generally beyond the scope of this document.

92
93
94

TCG technology users are in the midst of a transition between TPM1.2 and TPM2.0; thisdocument is constructed to cover both TPM1.2 and TPM2.0 applications, and to highlightdifferences when they’re important.

95

There is a short glossary of terms in Section 7.

Scope

96
97

1.2

98
99
100
101
102
103
104

Preserving the integrity and security of network equipment is essential to maintaining
customer privacy and network reliability. In the face of increasingly sophisticated attacks on
network equipment, Trusted Computing solutions are desperately needed in this area. Yet
little information is available on how Trusted Computing should be used to secure network
equipment and thus the networks that depend on this equipment. This reference document
provides guidance for using TCG technologies to improve the security of network equipment
and networks.

Audience and Purpose

105

Revision 29

7
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

106

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

2. Preface

107
108

2.1

109
110
111
112

Figure 1 shows a simplified reference model often used for Network Equipment. Customer
Premise Equipment (CPE) or Residential Gateways are often positioned between
administrative domains, and may require special attention for management of access andidentity.

Network Equipment Reference Model

Network Service
ProviderAdministrative
DomainEnterprise
Administrative
DomainCPE
Router /FirewallEnterprise
Router /SwitchNetworkConnected
Endpoints

RouterConsumer /Home Network
Residential
Gateway

NetworkConnected
Endpoints

Devices with
SharedAdministration
113
Figure 1: Simplified Network Reference Model

114
115
116
117
118

It should be noted that there are often many more administrative sub-domains within eachside of the domains depicted in Figure 1. Large enterprises in particular often have IT
departments that act as internal service providers, offering connectivity to departments andgroups, each of which may have considerable autonomy.

119
120
121
122
123

In this context, there may be several points in an overall network where different
administrative domains must share control of a single device; for example, an EnterpriseManaged Gateway CPE device might have interfaces configured by a Service Provider toensure contracted class of service, while the Enterprise would control interfaces that connect
to its own equipment.

124
125
126

Further, it should be noted that the administrator of a given device normally will not havedirect physical connectivity to the device, and will require authenticated remote access tocarry out management functions.

127
Revision 29

8
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

128

2.2

Copyright ©2018 TCG

Internal Structure of Network Equipment

129
130

Networking equipment like routers and switches is often composed of several major units:

131
132
133
134
135



The Forwarding Plane inspects each packet and performs the networking function
required (e.g., L3 routing, L2 switching, Firewall security inspection, etc). The
forwarding plane may be implemented in hardware, microcode, or software on aconventional processor, but in any case, the forwarding plane is typically subservient
to a Control Plane, and would rely on the Control Plane for security.

136
137
138
139
140



The Control Plane is the part of the device that initializes, monitors, configures anddiagnoses the Forwarding Plane. The Control Plane is typically implemented assoftware running on an operating system, hosted on a conventional processor. The
Control Plane typically manages every aspect of Forwarding Plane operation, including
assurance that whatever code runs in the forwarding plane is authenticated.

141
142
143



Some devices implement a separate Management Plane that provides an externalinterface used to configure and manage the device. A management plane would also
typically execute in a conventional OS and processor environment.

144
145
146

Although essentially all networking devices have one or more control-plane processors that
configure and run the device, the term Network Device can cover very small to very large
devices:

147
148
149
150



Many small networking devices are packaged as non-modular units with no fieldreplaceable units (FRUs). A small switch, wireless access point or customer premisedevice might all be non-modular. In this case, the identity (e.g. serial number) of thechassis encompasses all components of the device.

151
152
153
154



Larger networking devices may have pluggable I/O or feature cards. The base chassis
may have a unique identity, but the pluggable modules usually have their own serial
numbers or identity. I/O or feature cards may also have distributed control plane
processors that should be secured.

155
156
157
158
159



Many large networking devices have field-replaceable control plane processors, oftenwith several independent control plane processors for redundancy. In this case, eachcontrol processor may have its own serial number and identity. In some cases, to meet
redundancy goals, the chassis itself may be completely passive, with no active
components to prove identity.

160
161
162

Some architectures use a distributed control plane with many independent,
cooperating processors; in that case, the identity and integrity of each processor may
need to be determined separately.

163
164
165
166
167
168
169
170

Figure 2 shows an abstract view of composite networking devices, that is, those comprising
several independent units. While there are many ways to construct a composite system,
ranging from single-chassis devices with plug-in cards through to self-organizing networks ofelements, a key factor in this context is that there are usually a small number of elementsthat serve as the external management interface for the system, combined with a larger
number of internal units, which mostly are not directly reachable by the externalmanagement system. Each of the elements in Figure 2 may have its own Trusted Computing
Base (TCB).

Revision 29

9
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

TCB

Control Plane TCB
visible to externalmanagement plane

Figure 2: Composite
SystemForwarding
TCB Plane
Forwarding
TCB Plane
Forwarding
TCB Plane

Load-Bearing Interfaces

Control Plane

Interconnect FabricManagement
Interfaces

Control Plane

Other internal TCBs may not
be directly visible to externalmanagement plane

171
172
173
174
175
176

Recommendations in this document relate to the security, identity and integrity of the Control
Plane; if there is Networking Equipment where the forwarding plane can act independently of
the Control Plane, the forwarding plane may need to be protected as if it were a control planeelement.

177

2.3

178
179

There are many stakeholders involved in the use and secure deployment of Network
Equipment:

180



181
182
183
184

Stakeholders

TPM Manufacturero

The TPM manufacturer creates and initializes the TPM. TPM manufacturers
usually equip their devices with a unique Endorsement Key (EK) and EKCertificate.

Device Manufacturer

185
186

o

Device Manufacturers develop and sell Networking Equipment, often referred toalso as OEMs (Original Equipment Manufacturers).

187
188

o

The Device Manufacturer is usually responsible for supplying the equipment
and a software operating environment.

189
190
191

o

Device Manufacturers are often called upon to diagnose and remediate complex
networking problems encountered by Service Provider and Enterprisecustomers.

192
193
194



Network Service ProvideroRevision 29

Service Providers generally provide public network service through defined
gateways.
10
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

195
196

o

Service Providers may also offer private networking services to enterprises, oftendelivered over infrastructure also used for public interconnect.

197

oSecurity and reliability may be offered as a value added service.

198

Enterprise

199
200

o

An Enterprise usually has network equipment for its own use, i.e., not to sell asa service.

201
202
203

o

An Enterprise may use specialized monitoring and configuration services
provided by a remote Maintenance Provider as a way to outsource some of its
own IT support.

204

Consumer

205
206

o

Network Equipment may be purchased by individual consumers or small
businesses (e.g., WiFi gateway routers).

207
208

o

Consumer devices may need to take care of themselves, with little expectation
for active administration.

209
210
211
212
213

In this document, the “Administrator” is considered to be the Service Provider, Enterpriseor Consumer that has primary authority over the device, and can authorize or delegate
access for other stakeholders, including Secondary Administrators. The Administrator
must be able to erase private information without making the device unusable for asubsequent owner. (See Sections 3.11 and 5.11.)

214

2.4

215
216
217

Networking Equipment almost always contains a general-purpose computing environment toconfigure and manage the device. But there are distinct differences between Networking
Equipment and the common PC client and server applications:

Key Differences between Network Equipment and PC Applications

218
219



While Network Equipment may be highly modular, it is usually shipped as a closed
embedded system, integrating hardware and software.1,2

220
221



The chain of security typically does not stop when the OS boots; what matters issecurity of the networking function that’s provided by the unit as a whole.

222
223



Network Equipment typically must boot and operate without manual intervention (e.g.,
no Owner Password can be expected at boot time).

224
225
226



While Network Equipment has an important role in protecting user privacy, theequipment itself typically should not have an ability to hide or mask its own identity.
See Section 2.4.2 for more on Privacy.

227



Network Equipment also may have a very long life cycle (See Section 2.4.1)

1 Even though many Device Manufacturers support an SDK environment, and some are moving

more aggressively to an open-source model, the manufacturer is still usually responsible for
infrastructure security of the device.
2 For a counter-example, see Open Compute Project Networking,

http://www.opencompute.org/projects/networking/
Revision 29

11
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

228
229

2.4.1 Long Life Cycle

230
231
232
233
234

Network Equipment often has a long life cycle, and must stay operational in the network formany years. Certificates with 10-year expiration are often too short for many Network
Equipment applications, as equipment may stay in operation for upwards of 20 years. Device
Manufacturers should ensure that any immutable certificates have lifetimes long enough toextend through the expected life of the platform.

235
236
237

IEEE802.1AR Secure Device Identity [1] requires the following related to the “notAfter” field
in a DevID certificate in Section 7.2.7.2

238
239
240
241

Devices possessing an IDevID are expected to operate indefinitely into the future and should use thevalue 99991231235959Z. Solutions verifying a DevID are expected to accept this value indefinitely. Anyother value in a DevID notAfter field are expected be treated as specified in RFC 5280.

242
243

Network Equipment manufacturers should consider using long or indefinite lifetimes for any
immutable certificates stored in devices (including the EK Certificate).

244
245
246
247

Along with certificates that don’t expire prematurely, manufacturers may want to consider
mechanisms to accommodate cryptographic agility. Key lengths and algorithms do evolve
over time, and mechanisms to update algorithms and replace dated certificates in fielded gear
may extend useful equipment life in some cases.3,4

248
249
250
251
252

Conversely, Administrators may want to configure relatively short lifetimes for locallygenerated certificates such as a Local Device ID (LDevID, see Section 5.1.2), or other vendorspecific applications, as a mechanism to ensure that devices don’t remain forgotten in their
networks past the time when they should be replaced, or past the time when cryptographic
parameters such as key length may have become outdated.

253
254

2.4.2 Privacy and Networking Equipment

255
256

Networking Equipment such as routers, switches and firewalls has a key role to play inguarding the privacy of individuals using the network:

257
258
259
260
261



Packets passing through the device must not be sent to unauthorized destinations.
Some examples include:oRouters often act as Policy Enforcement Points, where individual subscribers
may be checked for authorization to access a network. Subscriber login
information must not be released to unauthorized parties.

3 See National Institute of Standards and Technology, Report on Post-Quantum Cryptography,

NISTIR 8105 [14]4 While Algorithm Agility is not part of TPM1.2, the TPM2.0 specification can accommodate

multiple cryptographic algorithms. TCG specifications do not define whether TPM2.0
implementations are field-updatable to revised cryptographic algorithms or not, but algorithm
upgrade can be addressed by individual TPM vendors.
Revision 29

12
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

262
263

o

Copyright ©2018 TCG

Networking Equipment is often called upon to block access to protectedresources, or from unauthorized users.

264
265



Routing information, such as the identity of a router’s peers, must not be leaked tounauthorized neighbors.

266
267



If configured, encryption and decryption of traffic must be carried out reliably, while
protecting keys and credentials.

268
269

Functions that protect privacy are implemented as part of each layer of hardware andsoftware that makes up the networking device.

270
271
272
273
274

In light of these requirements for protecting the privacy of users of the network, the Network
Equipment must identify itself, and its boot configuration and measured device state (forexample, PCR values), to the Equipment’s Administrator, so there’s no uncertainty as to what
function each device and configuration is configured to carry out5. This allows theadministrator to ensure that the network provides individual and peer privacy guarantees.

275
276

2.5

277
278
279

While Section 5 of this document gives specific recommendations for the use of TCG
technology in enhancing the security of network equipment, the guidance can be summarized
as follows:

Summary of Recommendations280



Devices should use a TPM as a hardware-based root of trust

281
282
283



Cryptographic Device Identity based on IEEE 802.1AR, using the TPM to protect
keys, can provide a reliable way to identify remote devices for applications involving
device management, configuration and authentication

284
285



The TPM can be used to protect confidential data such as VPN keys in network
equipment

286
287



TPM-based Attestation can offer assurance as to the integrity of software running on
network equipment

288
289



Use of the TPM’s random number generator can enhance the strength ofcryptographic protocols by providing additional entropy

290

5 For example, serious privacy violations could occur if embedded software was modified to snoop

traffic, or if unauthorized configuration commands were added to encrypt traffic with an incorrect
key or to replicate traffic to an unencrypted tunnel.
Revision 29

13
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

291

3. Use Cases

292

3.1

293
294
295
296
297

Providing reliable remotely-verifiable device identity for each piece of network equipment is aprerequisite for most use cases related to securing network equipment. This section contains
a few use cases that demonstrate the value of device identity for network equipment and thevariety of ways that device identity can be implemented and used. Within this section, theterm “device” is used to mean a piece of network equipment.

298
299
300
301
302
303
304
305
306

Before getting into use cases, it’s helpful to distinguish two kinds of device identity:
Manufacturer identity and Owner identity. The Manufacturer identity for a particular device
is established, configured and managed by the Device Manufacturer, although it can also be
used (e.g., verified) by the device owner. The Owner identity for a device is established by thedevice Administrator and is generally used only by the Administrator. Manufacturer identity
is6 unique across all products from that manufacturer (e.g., a model number and serial
number) while Owner identity may be unique only within the Administrator’s domain (e.g.,
an asset number). These kinds of device identity are defined as Initial Device ID and Local
Device ID, respectively, in IEEE 802.1AR (See Section 4.1).

307
308

In any case, device identity is implemented using a private key kept secret by the device anda certificate associated with that key, issued to the device by a Certification Authority (CA).

309

3.1.1 OEM Device Identity and Counterfeit Protection

310
311
312
313

Both network equipment owners and Device Manufacturers (OEM’s) need to verify theauthenticity of network equipment, determining whether it is “counterfeit” (made by an
unauthorized party or in an unauthorized manner) or “authentic” (made by authorized parties
in an authorized manner).

314
315
316
317
318
319

Business Drivers: To achieve reliable network operation for end-user customers, Network
Equipment Owners need to be assured that they are using authentic devices from known
manufacturers. At the same time, Device Manufacturers want to reduce lost sales, protect
their brand, prevent returns and warranty repairs of counterfeit equipment. Distributors
want to detect counterfeit devices before they are resold. Auditors want to verify that network
operators are meeting compliance regulations.

320
321
322
323

How It Works: During manufacturing, a signed manufacturer identity is instantiated in thedevice. Manufacturing processes and key types must be selected to ensure that the identity
cannot be copied to, or instantiated in, another device. Later, the authenticity of the device
can be verified by checking the validity of this identity.

324
325
326
327
328

This verification can be done by many parties, as detailed above: the network equipment
owner, the manufacturer, the distributor, auditors, network operators, etc. The verification
may be done locally (by connecting a cable directly to the device) or remotely (across a
network). Device software may also use manufacturer identity to ensure that the underlying
hardware is authentic.

Device Identity

The Manufacturer and Administrator are responsible for managing uniqueness in theirrespective name spaces, but typically these identifiers will not be ‘cryptographically strong’; thepublic key associated with the device identity can also be used as a unique identifier where that’sa factor.
6

Revision 29

14
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

329
330

Copyright ©2018 TCG

If a counterfeit device is detected, various remedial actions could be taken: blocking the device
from the network, disabling device functionality, alerting an operator with a log entry, etc.

331
332

3.1.2 Identity for Network Access

333
334
335
336

Business Drivers: Network operators often wish to ensure that only authorized equipment isconnected to their networks. This is true for telecommunications companies but also for cloudand data center operators, hospitals, enterprises, manufacturing facilities, and otherenvironments where the network needs to be tightly controlled.

337
338
339
340
341

How It Works: Certificates proving device identity may be used to authorize network access.
When a device connects to the network, its device identity is verified and checked against alist of authorized devices. If the device is on the list, it’s permitted to connect to the network.
Either identity configured by the Device Manufacturer, or identity configured by the
Administrator may be used for this purpose.

342
343
344

In the case of CPE equipment, or other situations where administration is shared between
two domains, it may be necessary for a Primary Administrator to grant rights to a Secondary
Administrator to add their own identity.

345
346
347

The Identity for Network Access use-case requires the network equipment to authenticate
itself to the upstream network’s authentication service, and may require that the upstream
network prove its identity to the particular networking device7.

348
349

3.2

350
351

Business Drivers: There are many cases where a networking device may be shipped with nounique configuration, but must be configured before it can be used within a network.

352
353
354
355
356

In these cases, Zero Touch Provisioning (ZTP) may be desirable, requiring a mechanism wherea newly-installed device initiates communication through a public network, but only enoughto obtain the configuration information that would specify policy for operational use. As an
example, downloaded configuration and keys might enable access to a corporate VPN, or
might authorize access to restricted content.

357
358
359

Because the result of loading configuration on to the remote device could be access to an
enterprise’s private network, careful design is required to ensure that only authorized devices
are able to download a configuration.

Secure Zero Touch Provisioning

7 For example, in the process of establishing an RFC 5246 Transport Layer Security (TLS) session,

downstream and upstream devices might exchange DevID certs to prove identity.
Revision 29

15
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Enterprise
RemoteDevicePublicInternet

Authorized
Configuration
Server

360
361
362
363

Part of this use-case may require proof that the device is actually in the hands of an
authorized user before it’s configured, perhaps through the use of out-of-band authorization
information.

364

How It Works: ZTP can be made more secure with several additions:

365
366



The networking device can use a Manufacturer-installed credential to authenticate
itself to the ZTP server.

367
368



The networking device can check a credential supplied by the ZTP server to ensurethat the server is authorized to serve configuration.

369
370
371



The ZTP server can use Remote Attestation (See sections 3.7 and 5.7 of this document)
to verify that the device is running authorized software before completing theconfiguration.

372
373

3.3

374
375
376
377
378
379
380

Business Drivers: Network equipment often contains sensitive information such as traffic
logs or cryptographic keys (e.g., shared secrets, passwords, VPN keys, SSL keys, and stored
data encryption keys). Disclosure of these secrets could result in disclosure of confidential
network traffic and privacy-sensitive information or even enable malicious tampering with
the network. Network operators (especially Service Providers and Enterprises) must protectthese secrets against disclosure to keep their networks secure and reliable, and also to meet
regulatory or customer requirements for confidentiality and privacy.

381
382
383
384
385
386

How It Works: Because network equipment is often located in insecure locations and always
subject to network attacks and exploitation of software vulnerabilities, protection must be
provided against physical attacks, network attacks, and software compromise. Manytechniques can be used to protect keys or shared secrets, depending on the operations thatmust be performed with them, and the frequency with which those operations must be carried
out.

387

There are two sub-cases that can be considered, depending on scaling expectations:

Securing Secrets

388
389
390



Keys may be protected by the TPM and used in the TPM, providing substantial
protection against loss, but signing throughput is limited by the type of key used, andthe TPM’s low-power crypto engine.

391
392
393
394



Alternatively, the TPM may protect a key that’s used outside the TPM, perhaps by ahigh-throughput crypto engine. In this case, the key is well protected by the TPM “atrest”, but must be released by the TPM before it can be used, increasing the risk thatit can be snooped.

Revision 29

16
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

395

Copyright ©2018 TCG

Using a Virtual Private Network gateway device as an example:

396
397
398



A remote customer-premise device may log in to a corporate VPN across the internet.
In this case, a small number of authentication operations may suffice, and keys may
be protected by the TPM and authenticated entirely within the TPM.

399
400
401



However, the centralized VPN gateway may be performance-optimized for highthroughput authentication from thousands of remote devices; in this case, keys may
be held in encrypted storage, but released for use by platform software.

402
403

3.4

404
405
406
407

Business Drivers: Network Equipment usually requires configuration, often involving many
parameters stored in a variety of files. The equipment Owner may wish to retain control overchanges to configuration files on the equipment, with the goal of ensuring that unauthorized
configuration changes don’t compromise their network.

408
409
410
411

How It Works: In this case, the Owner may wish to encrypt and sign configuration files soeach file can only be used on the intended device, and the device will only accept configurationfrom the authorized Owner. Signing or Attestation may also be used to ensure configuration
integrity, i.e. to assure the equipment Owner that the configuration has not been modified.

412
413

In some cases, it may be desirable to prevent rollback to previous versions of configuration
files.

414
415
416
417

Some Network Equipment could also benefit from full-disk encryption to protect data at rest,
to discourage cloning. The document TCG Storage Opal Integration Guidelines [17] gives an
overview of the Trusted Computing Group suite of specifications for self-encrypting storage
devices.

Protection of Configuration Data

418
419

3.5

420
421
422
423
424

Business Drivers: Network equipment Owners with a large number of devices often want tomanage those devices remotely, including the ability to monitor devices and reconfigure them
dynamically. Remote management and reconfiguration is especially important in modern,
flexible computing environments that implement Software-Defined Networking (SDN) or
Network Function Virtualization (NFV).

425
426

Remote Device Management may also include the need for trustworthy decommissioning or
refurbishment (See Section 3.11).

427
428
429
430

How It Works: To perform remote device management securely, the device and management
system must generally establish a secure communications channel with mutual
authentication and confidentiality and integrity protection. This secure channel is used by
the management system to monitor device status and send reconfiguration commands.

Remote Device Management

431

Revision 29

17
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

432

3.6

433
434
435

Business Drivers: Most Network devices rely on complex embedded software to enable basic
features as well as to enforce security policies. This software is often updated on devices
already in the field, using releases and patches usually supplied by the device manufacturer.

436
437
438
439

Network Administrators are left with the task of keeping track of which devices have been
updated to what revision level, sometimes tracking many independent components on a single
complex device. Automating the process could save money and improve security by making
it harder to overlook out-of-date releases.

440
441
442
443
444
445

How It Works: Mechanisms can be implemented to allow the Administrator to query devices
to find which revision level of which components are installed on each network device in their
network. The ISO specification ISO/IEC 19770-2 Information Technology - Software AssetManagement - Part 2: Software Identification Tag [5], (also known as “SWID Tags”), coupledwith the TCG protocol suite Platform Trust Service (PTS), can collect verified software image
information from remote devices.

Software Inventory

446

Attestation of Integrity for Network Devices (“Health Check”)

447

3.7

448
449
450
451

Business Drivers: One extension to remote device management enabled by TCG technology
is an ability to monitor the authenticity of software versions and configurations running oneach device. This allows owners and auditors to detect deviation from approved software andfirmware versions and configurations, potentially identifying infected devices.

452
453
454
455
456
457

How It Works: Networking equipment requires some extension from conventional PC-based
Attestation due to more varied platform architecture, including redundancy, in-service
software updates, and hot-swappable field replaceable components. In addition, the focus
on overall system functionality calls for an extension of the conventional attestation plan toencompass more objects in PCRs, for example, hashes of application executables, OSdaemons and configuration files.8

458
459
460

Attestation may be performed by network management systems. Networking Equipment isoften highly interconnected, so it’s also possible that attestation could be performed byneighboring devices.

461
462

Attestation depends on a process sometimes called Measured Boot; See Section 4.1 for acomparison of boot security procedures.

463
464

3.8

465
466
467

Business Drivers: Many network devices are composed of one or more control ormanagement units plus optional components like line processing units, feature-processing
units and other kinds of field replaceable units (FRUs). The definition of a composite system

Inventory of Composite Devices

8 Following a ‘chain of trust’ model, conventional TCG practice would be to use TPM

measurements to prove that a reliable policy engine is running in the device, and then use thatengine to verify application resources. However, for embedded devices like Network Equipment,
the system designer has quite a bit of latitude in determining which software components are partof the trusted computing base.
Revision 29

18
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

468
469
470
471
472
473
474

and its internal organization, whether it’s homogenous or heterogeneous, hierarchical or flat,
is up to the system designer, but the behavior of the network device is based upon thecomposite behavior of individual components. The security posture of the network device istherefore only accurately represented by a composite measure that includes the posture of
sub-components. Any change to one of these sub-components or even an undetectedexchange endangers the security of the user’s data on the network. A secure inventory allows
determination of the components used and their state.

475
476
477
478

Many network devices allow FRUs to be replaced without triggering a complete system restart(often called ‘hot swap’); for these devices, system-level reboots may be very rare, and thesystem’s security posture must be re-evaluated every time an individual unit is inserted or
removed from the system.

479
480
481

How It Works: Mechanisms may be implemented to provide proof of identity andconfiguration for each modular component, summarized and reported by the management
process for the device.

482
483

3.9

484
485
486
487
488
489

Business Drivers: Various processes in the day-to-day operation of network equipment are
based on information gathered from the system status of servers, routers and sensors. SACM,
SIEM or even legal interception are based on state information of various components.
Tampering with this information, mostly instantiated as log files, can impact the security
protection (e.g. by suppressing intrusion-detection (IDS) data) or impact the integrity of
information delivered by the legal interception interface.

490
491
492
493

Integrity-protected log files can be used by the management or external entities by providing
information on the authenticity and integrity of the file. An integrity-protected log file canshow on which device it was created, plus evidence that it has not been subject tounauthorized modification, and other details dependent on the use case.

494
495
496

This use case does not address the specifics of a SACM, SIEM or legal interception systemand does not specify any part of such a processing entity, but shows the applicability ofTrusted Computing for the protection of log files and other data used in later processes.

497
498
499
500
501

How It Works: A device’s internal log file or system wide log server receives events andpreserves these events for subsequent analysis. The data stored in the log file can be protectedusing TPM-based signatures expressing the origin of the data, along with the time of creationand the state of the device that created the data. All this can later be used in subsequent
analysis to determine the trustworthiness of the data collected.

502

Confidentiality of log information is not covered in this use-case.

Integrity-Protected Logs

503
504

3.10 Entropy Generation

505
506

Business Drivers: Businesses and governments have a need to ensure that traffic that passes
across untrusted network connections is reliably protected by strong cryptographic keys.

507
508

How It Works: Many networking protocols such as SSH and IPsec have a need for
cryptographic-quality random numbers to avoid the generation of predictable session keys.

Revision 29

19
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

509
510
511

In addition, the TCP stack for Network Equipment should use good-quality randomness for
the TCP window starting point as well as in the selection of ephemeral ports. These help tomitigate SYN and RST attacks against the device.

512
513

Network Equipment also often requires good-quality random numbers to generate
Cryptographic Security Parameters (CSPs) such as RSA key-pairs.

514
515
516

Entropy sources used in Network Equipment may have to comply with standards such as
NIST Special Publication 800-90 A/B/C [13] or BSI AIS-31, A Proposal for Functionality Classes
for Random Number Generators [15] [16].

517

The TPM can act as a source for cryptographic-quality entropy.

518
519

3.11 Deprovisioning

520
521
522

Business Drivers: Networking Devices often contain information that’s considered sensitiveby the Administrator, such as customer configurations or routing policies. Once the device
is taken out of service, this information must be reliably destroyed.

523
524
525

How It Works: Confidential information can include TPM keys themselves, or information
encrypted by TPM keys. The TPM mechanisms for deleting keys can ensure that theconfidential information will become inaccessible.

526
527

Revision 29

20
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

528

Copyright ©2018 TCG

4. Building Blocks

529
530

4.1

531
532
533
534
535
536
537

Security of Network Equipment Devices is critically dependent on the integrity of the software
running on the device. Software integrity is usually assured with a chain-of-trust model, witheach stage during startup checking the next stage before execution, as shown in Figure 3.
While that model is extensible to as many stages as needed, there’s clearly a special case forthe first step in the process, the one before which nothing exists to do any checking. This
stage is referred to as the Root of Trust, and code that runs in the Root of Trust must be
trusted implicitly.

Chain of Trust

Loader checks
Kernel Signatures
before handoff

Firmware checks
Loader Signature
before handoff

Start Firmware
Root
of
Trust

Initialize hardware
Check Loader
signature

Firmware provides
Root of Trust to
protect firmware
updates and initialize
the TPMRun Loader
Locate OS Image
Check Kernel
signatures

Run Kernel
Start OS

Figure 3: Chain of Trust

538
539
540
541
542
543
544

Underpinning essentially all of the security mechanisms outlined in this document is areliable Root of Trust, often implemented in code called a Basic Input Output System (BIOS),
and usually stored in non-volatile memory so it’s available to deliver the very first instructions
to the processor for execution after reset. The root of trust has several functions, among
which are initializing the TPM and doing the first measurement, and ensuring that firmware
is not changed without authorization,

545
546
547
548

Although some systems are able to use an immutable root of trust, which cannot be modified
or hacked, most current devices need a capability to upgrade the software that forms the rootof trust, and must rely on some hardware assistance to lock the flash9, as well as code in theroot of trust to protect the device from unauthorized updates or code implants.

549
550

Techniques for assuring protection of BIOS or other boot firmware can be found in NIST SP
800-147, BIOS Protection Guidelines.

Unlike ordinary software, the root of trust must be protected against attacks from the privileged
run-time operating system. This usually results in some kind of hardware feature in theprocessor to lock flash against OS software.
9

Revision 29

21
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

551
552
553

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Although TCG technology is not required to secure the root of trust, NIST SP 800-155 does
specify the use of a TPM as part of a comprehensive software integrity strategy, linking to the
Health Check features covered in Section 5.7 of this document.

554
555
556

4.2

557
558

There are generally two approaches to ensuring that code running on a Networking Device isauthorized, and has not been subject to illicit modification.

Secure Boot vs. Measured Boot

559
560
561
562



Secure Boot (also known as Verified Boot) is a process by which each stage of the bootprocess checks a cryptographic signature on the next stage before executing it. In atypical system, there might be a BIOS that does a check of an OS Loader’s signature,
which in turn might do a check of the OS kernel before launching it.

563
564
565



Measured Boot (also known as Attested or Authenticated Boot) is a process by which
each stage of the boot “measures” or computes and stores the hash of components inthe next stage prior to launching it.

566
567
568

Secure and Measured Boot can be extended to run-time software through mechanisms suchas the Linux Integrity Measurement Architecture [18]. See Section 5.7.1 of this document for
more on the use of IMA.

569
570
571
572
573

Secure Boot is a subset of an overall Secure Computing architecture, which dictates aplatform's behavior, as opposed to Trusted Computing, which enables the Administrator todeduce a platform's behavior. While implementations of secure boot are relatively common,complete Secure Computing or Trusted Computing environments are still difficult to design
and implement.

574

Secure Boot and Measured Boot have some commonality and some differences:

575
576



While Measured Boot depends critically on the TPM to safely store measurements 10(See Section 5.7), Secure Boot can be implemented without the use of TPM technology.

577
578



Both techniques rely on a Root of Trust in the initial BIOS, although Secure boot could
be used to reliably instantiate the Roots of Trust required by Trusted Computing.

579
580
581



While measured boot won’t stop a corrupted system from starting, it is able to verify
the state of a broader range of components in the boot path (e.g. configuration files
that might impact system security, in addition to executables).

582
583
584
585



Secure Boot and Measured Boot have different risk profiles. Secure Boot can convert
an innocent mistake such as a key mismatch into a network outage by refusing tostart, while Measured Boot can allow a corrupted network component to continue
running, risking further damage.

586
587
588



“Sealing”, or encrypting data such that it can only be decrypted when a platform is ina known measured state, is a cost-effective way to protect data-at-rest, even withsecure computing.

10 A measurement is the cryptographic hash of an object such as an executable file

Revision 29

22
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

589
590
591
592



593

4.3

594
595
596

[This Informative summary of 802.1AR appeared first in TCG Infrastructure WG TPM Keys
for Platform Identity for TPM 1.2, May 2015 [4]; it’s been edited in this section for wording andfor applicability to TPM 2.0]

597
598
599
600
601

The IEEE 802.1 working group defined the IEEE 802.1AR Standard for Local andMetropolitan Area Networks Secure Device Identity and it was published on 22 December
2009 [1]. This standard defines a per-device unique identity installed at manufacturing timeand used subsequently in device-to-device authentication exchanges. This standards-based
device identity can also be coupled in multiple ways with user identification.

602
603

The 802.1AR standard defines a secure device identifier (DevID) as “a cryptographic identitythat is bound to a device and used to assert the device’s identity”. It further specifies:

A single system could reasonably execute both Secure Boot and Measured Boot at thesame time. Measured Boot and attestation enhance confidence in a computer's
behavior even when it’s not practical to cryptographically sign each and every object
accessed as the system starts up.11

802.1AR Device Identification604



the DevID is an X.509 credential

605
606



globally unique per-device identifiers and the cryptographic binding of a device to its
identifiers

607
608



the relationship between an initial identity installed during manufacturing andsubsequent locally-significant identities installed by the Administrator

609
610



interfaces and methods for use of DevIDs with existing, and new, provisioning andauthentication protocols

611
612
613
614
615
616

The initially installed identity is defined as an IDevID (“I” for initial) and subsequently locallydefined identities are LDevIDs (“L” for local). An IDevID will be created at manufacturing timeand provides proof that this device has been manufactured by a certain manufacturer. An
LDevID is created on the Administrator’s premises and provides proof that this device isowned by a certain enterprise (or individual).

617
618
619
620
621
622
623

There is another dimension to the IDevID/ LDevID discussion with TPMs prior to andincluding version 1.2. In order to create an IDevID, the Device Manufacturer needs to takeownership of the TPM. However, commands that change ownership make all previously
created keys unusable. Section 5.1.1.4 of this document outlines precautions that must be
taken by the Device Manufacturer to ensure sure that the IDevID cannot easily be madeunusable by the TPM. More on this topic can be found in TPM Keys for Platform Identity for
TPM 1.2 [4], Section 6.

624
625
626

The 802.1AR specification DevID module (covering IDevID and LDevID) contains a service
interface, storage holding a DevID secret and certificate, secure hashing functions, a random
number generator (RNG) and asymmetric cryptography functions. These functions exist inE.g., a Device Manufacturer can’t sign a customer-mutable configuration file, but theAdministrator may know exactly what should be in the file on a fielded machine. Measurement
can report a fingerprint of the contents without requiring a signature on each file.
11

Revision 29

23
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

627
628

the TPM and calls by middleware (such as the TPM Software Stack (TSS) or the TPM API) canbe used to meet interface requirements outlined in 802.1AR.

629
630
631
632
633
634
635
636
637

The IEEE Standard 802.1AR-2009 [1] can be used together with TPM-based keys andcertificates. The TPM acts partly as the Secure Device Identifier Module (DevID Module) which
the standard defines as “a logical security component that will secure, store and operate on
one or more DevID Secret(s) [(private key)] and associated DevID credentials”. The document
TPM Keys for Platform Identity for TPM 1.2 [4] addresses usage of the TPM after provisioning
has occurred and leverages TCG-specified X.509 certificate extensions to prove TPM residencyof the keys, using the Subject Key Attestation Evidence (SKAE) extension [9]. Futurespecifications may detail how TPM 2.0 key attributes and residency are proven for use as
Device Identifiers.

638
639

Revision 29

24
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

640

5. Technology Recommendations

641
642
643

This section outlines approaches for the use of TCG technology to satisfy the Use Cases
outlined above. These sections are not normative, but rather suggest ways that existing TCG
technology can be put to use.

644
645

5.1

646
647
648
649

Device Identity requirements can be satisfied by the use of IEEE 802.1AR Device ID
certificates (See Section 4.1 above). Appendix B of IEEE Std 802.1AR-2009 [1] specifies
implementation of DevIDs using a TPM, including a MIB and some required behavior (enable/
disable for example) that is not specifically addressed in TCG documents.

650

Figure 4 shows the relationship of credentials installed in the TPM during its lifetime:

Device Identity

651
652



The EK and its Certificate are added by the TPM manufacturer to allow proof that the
TPM is authentic.

653
654



Initial Device ID (IDevID) credentials are installed by the device manufacturer to
identify the device’s manufacturer and serial number.

655
656
657



The device manufacturer may also install an Initial Attestation key (IAK) andcertificate to allow attestation without requiring the administrator to set up a CA (See
Section 5.1.1.3).

658
659
660



The device manufacturer can also provide a mechanism to allow an Administrator toconfigure Local Device ID’s (LDevIDs) and their own Attestation keys (LAK) (Section
5.1.2).

Platform Manufacturer Credentials

TPM Manufacturer
Credentials
EK

IAK

IDevID

EK CertIAK Cert

IDevID Cert

UAK
UAK
Cert

Platform
Cert

User
Credentials

Platform Mfg
Credentials(unused in Network Equipment)

LAK
LAK

LDevID
LDevIDLAK Cert
LAK Cert

LDevID Cert
LDevID Cert

Initial Device ID and
Attestation
credentials set by
Manufacturer
Local Device ID and
Attestation
credentials set by
Administrator

Administrator Credentials

Figure 4 : Key Hierarchy for Networking Equipment

Chain of Trust

661
Revision 29

25
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

662
663
664
665

There are several TCG documents that are relevant to the use of TPMs to implement 802.1AR
certificates:

666
667
668



TCG Infrastructure WG: TPM Keys for Platform Identity for TPM 1.2 [4]. This
document gives details useful for DevIDs in TPM1.2, including a number of use-cases
for DevID keys, and techniques for provisioning these keys.

669
670
671
672



TCG Infrastructure WG: TCG TPM v2.0 Provisioning Guidance [7]. This document
gives guidance on TPM 2.0 hierarchies, etc, setting out expectations for the TPM
manufacturer, platform manufacturer and Administrator in the general case of TPMs
in many kinds of equipment.

673
674

To support Device Identity requirements, the Device Manufacturer must configure the TPM:

675
676
677



Either the TPM Manufacturer must ensure that the TPM is configured with an EK
and EK certificate when the chip is manufactured, or the Device Manufacturer must
generate the EK and EK Cert.

678
679
680



Although this happens automatically with TPM2, a TPM1.2 must be configured as“always on”, i.e., Enabled and Activated, when the Device Manufacturer’s product isbuilt.

681
682

The Device Manufacturer must ensure that the TPM is configured with an IDevID key
and an IDevID Certificate before the Device leaves the manufacturing facility.

683
684
685

5.1.1 OEM Device Identity and Counterfeit Protection

686
687
688
689

Device Identity and Counterfeit protection can be provided by an IEEE 802.1AR Initial Device
Identifier (IDevID) certificate, signed by the Device Manufacturer and installed in the device
while it’s still under the manufacturer’s control. This certificate provides cryptographic
evidence that the specific physical device was manufactured by the specified manufacturer.

690
691
692

IEEE 802.1AR certificates include the device serial number and traceability to the
manufacturer’s CA. The combination of manufacturer identity and Device serial number is
expected to be unique.

693
694
695
696
697
698

An individual unit of Network Equipment (e.g. a large router) may comprise many field
replaceable modules (FRUs). In this case, the serial number in the certificate should reflect
the serial number of the FRU which houses the TPM. For example, in equipment withredundant control plane processors, the IDevID should contain the serial number of thecontrol plane processor module itself, and will change if that processor unit is replaced forany reason in a fielded installation.

699
700

Revision 29

26
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

701

5.1.1.1

702
703
704
705

To support Device Identity requirements, the Device Manufacturer must configure acertificate and keys in the TPM. There are differences between TPM1.2 and TPM2.0 in thisprocess; this section outlines common elements, and the subsequent sections give the familyspecific differences.

706
707
708
709

In all cases, the Device Manufacturer must ensure that the TPM is configured with an EK,
EK Certificate, an IDevID key and certificate, before the network equipment leaves the
manufacturing facility. The manufacturer may also want to configure an Initial Attestation
Key (IAK) and cert (see Section 5.1.1.3).

710
711
712
713
714
715

To do this, the Device Manufacturer will create the IDevID key-pair in the TPM, issue a signing
request containing the device serial number and other information to its own CA, and sign
the certificate. Per 802.1AR, the signature should use SHA256. (See Section 5.1.1.4 for how
to do this with TPM1.2). IDevID keys must be created with modes that prevent duplication of
the key from one TPM to another, to ensure that the identity of a Device can’t be moved from
one instance to another. (See Sections 5.1.1.4 and 5.1.1.6.)

716
717
718

TCG EK Credential Profile For TPM Family 2.0 [11] offers the following suggestion for EK
credential lifetime, and the same advice should be considered for IDevID, or other immutable
certificates. To quote Section 2.2.3:

Configuring Initial Identity Credentials

719

2.2.3 EK Credential Lifetime

720
721
722
723
724
725
726
727
728
729

An EK Credential contains fields that express the validity period of the credential. The
validity period is at the discretion of the manufacturer. The credential is not expected to
expire during the normal life expectancy of the platform in which it resides. The lifetime canvary widely between different types of platforms (e.g. while a typical validity period for a
PC Client platform is 5-10 years, non-user device TPMs are expected to operate indefinitely
into the future in which case the value 99991231235959Z should be used as expirationdate). The credential lifetime can also depend on the lifetime of the TPM device and thealgorithm type of the Endorsement Key. The time frame during which the security strengthof the EK is acceptable SHOULD be taken into account by the manufacturer when
determining the credential lifetime (e.g. see SP800-57 [21]).

730
731
732

It is believed that there is not any Personally Identifiable Information in Network Equipment
PCRs, but that determination must be made by the Device manufacturer. (See Section 2.4.1)

733

5.1.1.2

734
735

There are two types of keys that could be used for DevIDs in a TPM, as defined in TPM Keys
for Platform Identity for TPM 1.2 [4] Section 2.4:

Signing and Encryption Key Types736



Signing keys, which are restricted to signing, and allow no other operations

737
738



General Purpose or Combined Keys (aka Legacy keys) which can be used for signing
as well as encryption and decryption

739
740

The key type used for DevIDs should be selected based on the application and security needs
for the equipment in question.

741
742

General-Purpose keys are required in applications that implement different TLS variants that
may use RSA or Diffie-Helman to convey the shared session secret during setup. Keys
Revision 29

27
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

743
744
745
746

capable of decryption are also required for features such as Protection of Configuration Data,described in Section 5.4 in this document. Although 802.1AR does not impose a requirement,
Section 7.2.13 of IEEE 802.1AR-2009 - Secure Device Identity [1] does not require theimposition of restrictions on DevID key usage.

747
748
749
750

Applications that are restricted to variants of TLS using Diffie-Hellman or Elliptic Curve DiffieHellman (DH or ECDH), and are particularly concerned about attacks on keys in the TPM,
may want to use Signing keys for DevID, and provision separate Encryption DevID key-pairs
for other functions that need encryption with identity keys.

751

The trade-off is summarized in Table 1:
General Purpose Keys

Separate Signing and Encryption Keys

Fewer Keys to Keep Track Of

Better Security

Use General-Purpose (signing andencryption) keys for DevID

Use separate DevID keys for signing andencryption

May require more TPM resources

DevID-Signing for non-RSA variantsof TLS

DevID-Encryption for RSA variants of
TLS and other applications such as
Protection of Configuration Data

More state to be stored in, or restored to,
the TPM

752

Table 1: DevID Key Types

753
754

NIST Special Publication 800-57 Part 1, Rev 4 Section 5.2 [21] gives additional guidance on
use of keys.

755

5.1.1.3

756
757
758
759

TPM mechanisms are arranged so that in privacy-sensitive situations, Remote Attestation canbe done either without knowing the exact identity of the target system, or by trusting thecorrelation between platform and attestation identity to a special Privacy CA (also known as
Attestation CA; see Chapter 7 of IWG Reference Architecture for Interoperability (Part 1) [19])

760
761
762
763
764
765
766

For Networking Equipment, where clear identity of the devices in question is usually a criticalrequirement, a simpler approach can be used. In this case, the device manufacturer should
provision an Initial Attestation Key (IAK) and certificate that parallels the IDevID, with thesame device ID information as the IDevID certificate (i.e., the same Subject Name and Subject
Alt Name, even though the key pairs are different). This allows a quote from the device, signedby the IAK, to be linked directly to the device that provided it, by examining the corresponding
IAK certificate.12

767
768

Inclusion of an IAK does not preclude a mechanism whereby an Administrator can define
Local Attestation Keys (LAK’s) if desired (Section 5.1.2.2).

Identity for Attestation

12 As long as the IDevID and IAK are signed by equally-reputable CAs (or more simply, the sameCA) and contain the same Subject Name and Subject Alt Name, this approach eliminates the
Asokan Attack, https://tools.ietf.org/html/rfc6813
Revision 29

28
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

769

5.1.1.4

770

TPM1.2 has relatively limited mechanisms for managing Ownership:

Copyright ©2018 TCG

Initial Identity with TPM1.2

771
772



For TPM1.2, the Device Manufacturer must configure TPM Ownership to make an
SRK, so that an IDevID may be created as a child of the SRK.13

773
774



To ensure that the IDevID credentials are not rendered invalid by deletion of the SRK,
Ownership of the TPM must be locked.

775
776
777
778

In order to prevent the SRK from being deleted, rendering any keys stored under it useless,
TPM Ownership can be locked with the non-volatile TPM_DisableOwnerClear() ordinal. If the
TPM supports physical presence, the volatile TPM_DisableForceClear() ordinal may be used
to block ForceClear on each startup.

779
780

The detailed structure of the 802.1AR certificate for TPM1.2 is given in TPM Keys for Platform
Identity for TPM1.2 [4]

781
782
783
784
785

The 802.1AR document requires the use of SHA256 for signature generation, although the
TPM1.2 can only perform SHA1 signatures using its built-in functions. However, the TPM 1.2
allows the host to compute the hash, prepend the appropriate ASN.1 encoding, and to submit
this to the TPM for SHA256 RSA signature generation using Distinguished Encoding Rules(DER).14

786
787

TCG TPM1.2 documents do not define handles that should be used to identify DevIDs, sothese must be assigned by the Device Manufacturer.

788
789
790

Identity keys in TPM1.2 should be created as non-migratable, or a Certified Migration Key(CMK), to eliminate the chance that a device identity could be improperly copied from one
device to another.15

791

5.1.1.5

792
793

In TPM 1.2, identity keys must be descendants of the Storage Root Key, but in TPM 2.0, there
are a number of options.

Key Types in TPM2.0

794
795
796



Secondary, Internally-Generated keys are like DevID keys in TPM 1.2; the key pair isgenerated in the TPM, and can be configured so the private key is never released. A
Secondary key is always the child of a parent key in the hierarchy.

797
798
799
800
801



Primary keys are unique to TPM 2.0. These keys are also generated in the TPM, butthey are generated using a deterministic Key Derivation Function that starts with ageneric Template, and uses a primary seed in the TPM to generate the key pair.
Primary keys can be deleted and regenerated from the template as long as the seedvalue is unchanged.

For TPM1.2, this is an unavoidable overlap of administrative domains; normally, Ownershipwould be taken by the Administrator, not the Manufacturer, but that’s incompatible with amanufacturer-supplied IDevID13

14

See TPM1.2 Part I Design Principles, Section 31.2.2 TPM_SS_RSASSAPKCS1v15_DER

In TPM1.2, it’s possible to use a Certified Migration Key (CMK) with suitable Migration Selection
Authority (MSA) and Migration Authority (MA) to allow a key to be moved under controlled
conditions. The point, of course, is to make sure that an unauthorized copy of a DevID cannot be
made.
15

Revision 29

29
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

802
803
804
805
806
807
808
809



TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

TPM 2.0 also includes a specialized mechanism where an external entity can generate
the key pair and wrap it so it can only be imported to a specific TPM. This can be used
to circumvent the non-deterministic time taken to generate an RSA key inside the TPM,
or it can be used to meet unique security requirements where an external key generator
must be used. Imported key pairs cannot be Primary keys, and they cannot be marked
as non-duplicable (i.e., they can’t be marked as fixedParent). (Listed in the table below
as “Secondary Imported”)

Table 2 shows the different properties of the key generation approaches.
Primary Key

SecondaryInternally-Generated

Secondary
Imported

Must be created from atemplate; cannot be
Imported

Generated internally

Key generated externally,
wrapped with the parent key

RSA key generation is non-deterministic, and can take along time – possibly a minute or more of elapsed time

Importing keys isdeterministic, as they’rewrapped with a symmetrickey

DevIDs should be Created as non-Duplicable (FixedTPM,
FixedParent)

Imported keys can’t bemarked as Fixed, andrequire a Policy to block
export or migration.

Key may need to be madePersistent to avoid long
regeneration each power-on

Importing the key produces
a version wrapped by theparent, which can bequickly reloaded whenneeded.

Key can be saved, wrappedby its parent, then Loadedon power-up or use.

Certs can only be generated with a multi-step Online
process using Endorsement Credential and
TPM2_ActivateCredential()16

Keys and certs can begenerated externally andinstalled off-line across an
air-gap if necessary.

Key can be re-generated
from a generic template incase of TPM2_Clear()

Wrapped key can be reimported after a
TPM2_Clear() (Assuming theparent is restored, and the
Wrapped key is not lost)

810

Keys are lost in case of a
TPM2_Clear()

Table 2: Key Generation Options for TPM 2.0

811
812

16 Since the key-pair is generated in the TPM, it’s not known in advance, implying the need for a

multi-step procedure to generate the key and then incorporate the public half in a matchingcertificate. Conversely, the public key of an imported key pair is known in advance, so a matchingcertificate can be delivered along with the wrapped key for import.
Revision 29

30
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

813

Copyright ©2018 TCG

For the remainder of this section, we assume the following:

814
815
816
817



In most applications, IDevID keys would be Primary keys installed by the device
manufacturer. The Clear operation may be used to remove user identity and keys froma device, but the IDevID keys can be regenerated from a generic template after a
TPM2_Clear() operation.

818
819



LDevID keys are Secondary, internally-generated keys, and are intended to be deleted
by a TPM2_Clear() operation.

820
821
822
823



Manufacturers can also support Imported DevID keys if they have high-throughput
manufacturing processes where the indeterminate wait for RSA key generation would
be unacceptable, or for specialized customers that want to manage their own key
generation.

824
825
826
827
828
829
830

In TPM 1.2, special Restricted Attestation keys must be used to sign internally-generated
structures such as quotes, to prevent an external actor from spoofing a quote. The TPM 2.0
retains this capability with Restricted Signing Keys, which can sign an internally-generated
quote or external data, as long as the external data doesn’t contain the fixed pattern thatmatches an internally-generated structure. (See Trusted Platform Module Library Family 2.0
Part 1 [2], Section 25.1.2)

831
832
833

Thus, a Restricted Signing Key could be used for both Identity and Attestation, with themicroscopic possibility that the TPM will refuse to sign a nonce that happens to look like aquote.

834
835

However, for the remainder of this section, we assume that Device IDs (IDevID, LDevID) are
separate keys from Attestation keys (IAK, LAK).

836
837

5.1.1.6

838
839

To support Device Identity requirements, the Device Manufacturer must configure keys in the
TPM as described in the TPM v2.0 Provisioning Guidance [7] document.

840
841
842
843
844

IDevID keys must be signing keys. If they are also Restricted, then they can serve as
attestation keys. However due to complexities of using restricted keys with off-the-shelf crypto
software stacks such as OpenSSL17, platform vendors may opt to provision IDevID keys as
unrestricted signing keys. Doing so would necessitate provisioning a separate restrictedsigning key pair for attestation purposes (identified as an IAK in Figure 3).

845
846

Whether IDevID keys are externally-generated keys, as noted in Section 5.1.1.5, or Primarykeys, they should be stored in the Endorsement Hierarchy18.

Initial Identity with TPM2.0

17 Signing external data with a Restricted key requires a Ticket, and there’s some concern thatmanaging tickets would require an involved OpenSSL rewrite. Not impossible, but real work.
18 TPM2.0 embodies three independent key hierarchies: a “platform hierarchy” for platform

protection, independent of specific users, an “endorsement hierarchy” for exposing information
related to identity and a “storage hierarchy” for cryptographic usage related to specific users orapplications.

Revision 29

31
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

847
848
849
850
851
852
853
854
855
856

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

The Device Manufacturer must ensure that the TPM is configured with an EK, EK Certificate,an IDevID Key and IDevID certificate before the network equipment leaves the manufacturing
facility.
•••

The Device Manufacturer must provision the Endorsement Hierarchy
authorization.
The IDevID certificate (if it is stored in the TPM) should be write-locked to prevent
it from being deleted.
The IDevID Template does not need to be stored in the TPM, as it is generic andnot specific to a unique device.

857
858
859
860
861
862

In order to prevent the EPS (Endorsement Primary Seed) from being changed, rendering any
keys stored under it useless, the TPM2_ChangeEPS() command must be blocked. This
command is optional19, and ideally it would not be implemented by the TPM vendor. If it is
implemented and enabled, then the Device Manufacturer must implement strict control,
provisioning the Platform Authentication to a random value or un-fulfillable policy upon every
platform reset.

863
864
865
866
867

TPM2_Clear() resets the endorsement hierarchy authorization, clears the endorsement
hierarchy (including IDevID keypair if stored here), and removes NV-defined indexes which
are not protected by the TPMA_NV_PLATFORMCREATE flag. If the IDevID certificate is stored
in the TPM, it should be placed in the Platform NV hierarchy, by setting its
TPMA_NV_PLATFORMCREATE flag, so it’s not lost by a TPM2_Clear().20

868
869
870

To prevent permanent loss of the IDevID keypair, the Device Manufacturer could either block
execution of the TPM2_Clear() command or recreate the IDevID keypair from a generic
template.

871
872
873

The exact format of an IDevID certificate for TPM2.0 may be the subject of futurespecifications.

874
875

TCG TPM v2.0 Provisioning Guidance [7], Section 7.8 gives defined handles for IDevID
credentials in TPM 2.0.

876
877
878
879
880

It must not be possible to move identity keys from one TPM to another. In TPM 2.0, themechanism to prevent keys from being duplicated depends on the method of creation:

If keys are generated within the TPM, FixedParent and FixedTPM must be set (seeTPM 2.0 Trusted Platform Module Library, Part 2: Structures, Section 8.3 [3]).

IDevID keys are analogous to the EK, but without the privacy restrictions placed on the EK; assuch, they should be stored using the same rules as the EK (i.e., in Endorsement). The Platform
hierarchy could be used, but generally objects in the platform hierarchy should not be required
after the platform OS has launched.
19 The ‘optional choice’ is exercised by the TPM Manufacturer; if the TPM Manufacturer

implements the ordinal, the Device Manufacturer needs to figure out how to block it.
20 There is no Endorsement hierarchy for NV RAM, so the only two choices for the IDevID cert is

Platform (which does survive TPM2_Clear) or Storage (which does not). The EK Cert is stored in
Platform; the IDevID cert should be too.
Revision 29

32
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

881
882



Copyright ©2018 TCG

Imported keys can’t be marked as Fixed, so they must be accompanied by a Policythat prevents export.

883
884

5.1.1.7885
886

OEMs should recognize that loss of IDevID credentials in a fielded device could be hard to
remedy.

887
888
889
890
891

Although the IDevID key-pair must be protected by the TPM to ensure that the private key
remains secret, it’s up to the Device Manufacturer to store the IDevID certificate (and possibly
a wrapped IDevID key) somewhere secure, but not necessarily secret, in the platform. OEM’s
could lock the IDevID certificate and wrapped key into NVRAM in a TPM, although there’s norequirement to do so, and NV space is often at a premium.

892
893

For devices that don’t have space in the TPM NVRAM to store Initial identity credentials, there
are a couple of alternatives:

Loss of IDevID Credentials

894
895
896



If the manufacturer doesn’t track device id information in its own database, loss ofthese credentials would require return to factory where Initial identity keys could be
regenerated.

897
898
899



If the manufacturer does keep track of EK’s, it would be possible to re-create an
IDevID in a fielded device using enrollment based on TPM Certify mechanisms, even
if Ownership is lost. (See TPM Identity Keys for TPM 1.2 [4])

900
901
902



For TPM 1.2, as long as Ownership is maintained, the wrapped IDevID key andmatching certificate could be replaced from a manufacturer’s database. See Sections
5.1.1.4, 5.1.1.6 on locking Ownership.

903
904
905
906

As noted in Section 2.4.1, manufacturers may want to support upgrade of cryptographic
algorithms in devices with long lives. Cryptographic algorithms cannot be changed in
TPM1.2, but the TPM2.0 specification offers a mechanism to add algorithms, although doing
so in fielded devices is vendor-specific, and may not be possible in many cases.

907

5.1.1.8

908
909
910

Private keys associated with the EK and IDevID are immutable; once manufactured, thesekeys are not easily changed in a fielded device. Furthermore, compromise is unlikely, as they
are protected by the TPM.

911
912
913

But manufacturers do need to take care to protect intermediate keys stored in CAs in their
manufacturing facility, since exposure of a signing key could compromise many devices, withlittle recourse to re-secure them short of return-to-factory.

Compromise of Keys

914
915

5.1.2 Local Device Identity

916
917
918

IEEE 802.1AR also includes provision for Local DevID’s, customer-specific credentials thatcan be installed by the Administrator of the Network Equipment, during or after installation.
LDevID certificates will be signed by the Administrator’s CA.

919
920
921

While the LDevID can contain anything the Administrator wants, they’re probably bestthought of as enterprise “asset tags”, providing cryptographic evidence that the Device inquestion is one that was legitimately configured for use within the Administrator’s enterprise.
Revision 29

33
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

922
923

Multiple LDevID tags might be applied to a single device, depending on its organizationalrole(s).

924
925

The Device Manufacturer must provide a mechanism to remove Administrator-installed
LDevID keys without deleting IDevID.

926
927

Modular Network Equipment may contain multiple field replaceable units; as with IDevID
certificates, the basic LDevID can identify the FRU, but not necessarily the overall Device.

928
929
930

5.1.2.1

931
932
933

An Administrator may want to install LDevID credentials remotely, when the device is locatedoff-site (as would be the case for Service-Provider’s Customer-Premise Equipment, see Figure1). As such, care must be taken that the LDevID is being installed in the right device.

934
935
936

The following steps can be used to install an LDevID into a Device that’s already equippedwith an IDevID and IAK. These steps assume Enrolment over Secure Transport (EST; see
IETF RFC 7030).

937
938



How to Install a Local Device ID

Log into the Device using a TLS session that can’t be easily hijacked, authenticated by
the IDevID, and use that session to complete all the steps of enrollment.

939
940
941

o

Use of the IDevID certificate for TLS authentication ensures that the connection
terminates on the right device by showing the serial number assigned by thedevice manufacturer.

942
943

o

The Device’s identity as expressed by the manufacturer’s serial number can betrusted if:

944



The certificate can be traced to the Device Manufacturer.

945
946



The Device can respond to a challenge, proving it holds the IDevID private
key.

947
948

o

949
950

These steps provide proof that there’s a secure connection to the exact device into
which the LDevID should be placed.

951
952
953
954



The Manufacturer’s serial number can be checked against a bill-of-sale toensure it’s the right device.

The device should generate the LDevID key pair and a CSR containing the public key
and the asset information selected by the Administrator.
o

The CSR may also contain TPM_CERTIFY_INFO signed by the IAK key to provethat the LDevID key is in the same TPM as the IDevID21,22.

21 This proof is simple if the IAK contains the same device serial number as the IDevID, andthey’re signed by the same issuing authority. Other mechanisms must be used if the IAK iscreated independently. See Section 5.1.1.3.
22 Use of TPM Certify yields a trustworthy mechanism to get the LDevID into the same TPM as thecorresponding IDevID, even if the control plane software on the device can’t be trusted. If TPM
Certify is not used, there’s a possibility of variations of the Asokan attack, where the Device might

Revision 29

34
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0955The CSR should be returned to the Enterprise CA.

956
957
958
959
960
961

o



Copyright ©2018 TCG

Since an IDevID key must be configured to prevent duplication from one TPM
to another, the enterprise CA can use the TPM_CERTIFY_INFO to convince itself
that the IDevID and LDevID are in the same TPM, and that TPM is in theintended Device.

The Enterprise CA can then create the LDevID certificate with OIDs23 showing TPM
residency, sign it and send it back to the device.

962
963
964

An analogous procedure can be used for cases where an externally-generated key pair isdesired for LDevID (i.e., LDevID doesn’t have to be generated in the TPM for those cases where
an externally-generated key would be more appropriate).24

965
966

Chapter 21 of the book A Practical Guide to TPM 2.0 (W. Arthur & D. Challener) [12] also
outlines techniques that can be used to remotely provisioning DevID credentials.

967
968
969
970
971

5.1.2.1.1
Conveying TPM Certify Information
While there could be a number of ways to get the TPM_CERTIFY_INFO from the TPM to the
CA responsible for signing a DevID, this document suggests uniform practice between TPM
1.2 and TPM 2.0.

972
973
974



For TPM 1.2, TPM_CERTIFY_INFO is added to the Certificate Signing Request as an
X.509 extension. This extension is defined in Subject Key Attestation Evidence (SKAE)
[9].

975
976



The TPM2_Certify structures are more complex, but new certification procedures
specific to TPM2 may be the subject of future specifications.

977
978

5.1.2.2

979
980
981
982
983

Administrators who wish to use LDevIDs for device identity, using their own credentials to
identify devices, may want to provision “local” Attestation Keys (LAK’s) as well, allowing theAttestation system to reliably identify the device within the Administrator’s context. Use of a
Local AK in addition to the LDevID can prove that attestation has not been compromised byan Asokan attack (RFC 6813).

Attestation with Local Identity

have a valid IDevID, but do something that misuses the LDevID, e.g. not putting it a TPM at all, or
passing it off to some other device. TPM Certify must be verified by a CA that puts the TCG OID
indicating TPM key residency into the resulting certificate.
Note that TPM Certify info in TPM2.0 (TPMS_CERTIFY_INFO) is quite different from TPM Certify
info for TPM1.2 (TPM_CERTIFY_INFO and TPM_CERTIFY_INFO2), but they both satisfy therequirement of proving co-residency.
23 For TPM1.2, the appropriate OID is defined in TPM Keys for Platform Identity for TPM 1.2 [4],Section 3.1.1.1.
24 We note that externally-generated keys don’t necessarily have to risk exposure.

An HSM (oranother TPM) could generate an LDevID key pair, and wrap it with a key known only to the TPM
destined to receive the LDevID.
Revision 29

35
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

984
985

5.1.3 Identity for Network Authentication

986
987
988

When presenting identity for network access, the Device may use its IDevID or one of its
configured LDevID certificates, at the discretion of the Administrator. The appropriate
certificate should be chosen by methods controlled by the Device’s operating system software.

989
990
991

IETF’s Transport Layer Security (RFC-5246) Section 7.4.4 defines the mechanism by which aserver can negotiate trust anchors, by, for example, specifying a list of the distinguishednames of acceptable certificate authorities.

992
993
994

5.1.3.1

995
996

DevIDs may be used to authenticate access to various kinds of network services, in whichcase the receiving service must decide how much trust can be placed in the credential.

997
998

DevID private keys that can be shown to be held by a TPM can presumably be judged more
likely to be credible, and less likely to have been compromised.

999
1000

There are two techniques to demonstrate to a network service that a particular DevID key isstored in a TPM:

Proving a Link to the TPM

1001
1002
1003
1004



Sign the DevID cert with a CA that will only be used to sign certificates that are
known by the Administrator to originate in a TPM. For TPM1.2, this may include a
specific TCG OID corresponding to the Certificate Practices Statement (CPS),
referenced below in this section.

1005
1006



Extend the service’s login authentication to parse an additional x.509 extension field
called a Subject Key Attestation Extension (SKAE, TPM1.2 only).

1007
1008
1009

The use of SKAE to send proof to a CA that a DevID key is stored in a TPM1.2 device is
described in TCG Infrastructure Workgroup: Subject Key Attestation Evidence Extension [9].

1010
1011

The CA can certify that the key is in a TPM using the mechanism described in TCG
Infrastructure WG TPM Keys for Platform Identity for TPM 1.2 [4]1012

To quote Section 3.1.1.1:

1013
1014
1015
1016
1017

In order to assert that the CA verified TPM residency for the key used in a DevID certificate, acertificate policy OID unique to the TCG (and for this purpose) MUST be included in the certificate
policy extension of the DevID certificate. The CA MUST perform verification of the AIK signature
over the TPM_CERTIFY_INFO or TPM_CERTIFY_INFO2 prior to including the certificate policy TCG
OID.

1018
1019
1020

5.1.3.2

1021
1022

While the Endorsement Key (EK) must be present in every TPM, and must be unique, that
doesn’t mean it’s a good candidate for device identity.
Revision 29

Why Not Just Use EK and Platform Cert for Identity?

36
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

1023
1024



The conventional use of the EK credential is to prove the provenance of the TPM
itself, by linking to a chain of certificates rooted at the TPM manufacturer’s CA.

1025
1026
1027



But beyond that, the EK is not used directly as a signing key to prove possession of
the EK secret key; to protect privacy in privacy-sensitive applications, that proof canonly be done indirectly through other keys using TPM Certify information.

1028
1029

As a result of these restrictions on EK use, a separate set of credentials traceable to the device
manufacturer is used to identify the device.

1030
1031
1032
1033

Similarly, some Device Manufacturers may supply a Platform Certificate including a
manufacturer’s serial number (see TCG Credential Profiles For TPM Family 2.0 [11]). Whilethat’s similar to a DevID, again, they’re not the same:

1034
1035



The Platform certificate is an Authorization Certificate, not a Public Key Certificate(See RFC 5755).

1036
1037
1038



An Authorization Certificate isn’t bound to a key pair, so it can’t be used for proof ofidentity. The Platform credential does identify the associated EK credential, but has
no key of its own for signing.

1039
1040
1041

In some cases, the platform credential might be used as a link in the chain to create andinstall an IDevID or LDevID after the device has left the manufacturer’s premises, althoughthat use is not described in this document.

1042
1043

5.2

1044
1045

There are many cases where a networking device may be shipped with no uniqueconfiguration, but must be configured before it can be used with a network.

1046
1047
1048
1049
1050

In these cases, Zero Touch Provisioning (ZTP) may be desirable, requiring a mechanism where
the device communicates through the network as soon as it’s activated, to obtain theconfiguration information that would specify policy for operational use. As an example,
downloaded configuration might enable access to a corporate VPN, or might authorize accessto restricted content.

1051
1052
1053

Part of this use-case may require proof that the device is actually in the hands of an
authorized user before it is configured, perhaps through the use of an out-of-band
authorization code.

1054
1055
1056

The IETF Zero Touch Provisioning for NETCONF or RESTCONF based Management and IETF
Autonomic Networking Integrated Model and Approach (anima) bootstrapping work provide
possible frameworks in which the configuration process can work.25 See:

Secure Zero Touch Provisioning1057

https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/1058

https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

1059
1060

TCG technologies can improve the security of ZTP in two ways:

25 As of October 2017, these works are still in Draft format.

Revision 29

37
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1061
1062
1063



A DevID key stored in the TPM (Section 5.1) can provide cryptographic assurance of
the identity of the device attempting to register for configuration.
One way to do this is described in IETF RFC 7030, “Enrollment over Secure Transport”.

1064
1065
1066
1067



The Trusted Network Connect IF-M protocol suite can be used to offer assurance tothe central configuration system that the Device is running authorized software. Thismechanism is described in IETF RFC 5792, “PA-TNC: A Posture Attribute (PA) Protocol
Compatible with Trusted Network Connect (TNC)”. See also Section 5.7 below.

1068
1069
1070

5.3

1071
1072

Network Equipment may need to manage many different kinds of secrets, and it may not be
possible to use a single mechanism to secure all of them.

1073
1074
1075
1076

The same mechanism used to create and store LDevID private keys inside the TPM can beused for other uses of asymmetric keys, as long as the rate at which challenges must be
signed is modest (a few per second for many hardware TPMs26). An advantage of keeping
these keys inside the TPM is that no amount of bus-snooping will reveal the secret.

1077
1078
1079
1080
1081
1082
1083

In cases where higher throughput is needed (e.g. a VPN Gateway that must validate many
thousands of sessions, at a rate of hundreds of sessions per second), or applications where
shared-secret symmetric keys are used, it will be necessary to pass secrets to cryptographic
functions outside of the TPM. In that case, secret keys can be stored in the TPM using amechanism called Sealing, where keys or other secrets are stored in the Device’s file system
in an encrypted file that can only be decrypted with keys released from the TPM when predefined criteria are met.

1084
1085

Sealing is a mechanism provided by TPMs to encrypt small data objects (typically symmetrickeys) using a key that’s kept in the TPM. Sealing and Unsealing offer a couple of capabilities:

Securing Secrets

1086
1087
1088



The object to be encrypted by the TPM is unstructured; that is to say, the TPM regards
the object simply as a string of bytes. In TCG documents, this data object is referred
to as a ‘blob’.

1089
1090
1091



The encrypted object is not stored in the TPM; it’s sent to the TPM along with keying
and access information, using a “Sealing” operation, and the TPM returns the object
encrypted, where it can be stored in the host platform’s file system.

1092
1093



The sealed object can be unsealed when returned to the TPM, assuming a number ofconditions are met:

1094

o

The relevant asymmetric key must be resident in the TPM.

1095

o

Authorization to use the parent key must be present.

1096
1097

o

In addition, the sealed object would usually require that one or more of the PCRs
have a particular value, indicating that the platform is in a known state.27

26 Check individual TPM vendor data sheets for signing specifications.
27 Technically, an object can be sealed without requiring reference to any PCR, but that would

have the same effect as a simpler encrypt/decrypt operation.
Revision 29

38
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

1098
1099
1100
1101

If the conditions are met, the TPM will return the decrypted blob, which the system designer
can use as a structure containing symmetric keys for decrypting a larger object. Alternately,
the decrypted blob could contain keying material for use in high-throughput accelerators orother applications.

1102
1103

The system designer has complete freedom in choosing which, if any, PCRs should be
consulted prior to unsealing the object. Here are two examples:

1104
1105
1106
1107
1108

1. Some secrets need to be accessed just once, early in the boot sequence of a platform.
In that case, the system designer could allocate one PCR specifically for this use, andseal the secret against this PCR with a value of zero (the value after reset). After
retrieving the secret, the system designer could extend that PCR with an arbitraryvalue, preventing the object from being unsealed again by a hacker.

1109
1110
1111
1112
1113

2. The system designer could seal the secret against a number of PCRs that represent theexact versions and configurations of software booted on the device, preventing thesecret from being revealed unless the OS is in the exact right configuration. Thisapproach needs to be used with caution, as a software update that’s not flawlessly
staged could render the secret permanently unintelligible.

1114
1115

5.4

1116
1117

Network Equipment often has many configurable settings that must all be coordinated toachieve secure and reliable network connectivity.

1118
1119
1120

Organizations wishing to enforce network policies may want to create configuration files
centrally, and distribute them to devices in a way that they can’t be changed or moved fromone device to another.

1121
1122
1123
1124

Transport-level security (e.g. a TLS session authenticated with a DevID) would normally be
used with network-connected devices to ensure that the right configuration goes to the rightdevice, but an alternate approach to this that can work across an air-gap is to encrypt andsign configuration files so they can only be decrypted and used on the intended router.

1125
1126
1127
1128

This can be accomplished if the organization managing the network devices creates aconfiguration file for each device, and encrypts each one using a symmetric key, which inturn can be encrypted using the public portion of an IDevID or LDevID key corresponding to
the desired device.28 Authenticity can be assured by signing the package.

1129
1130

Once installed on the device, the configuration file can be decrypted using the TPM_UnBind()(for TPM1.2) or TPM2_Decrypt() (for TPM2.0) to decrypt and execute the file.

1131
1132

Administrators will need to build in enough agility in the provisioning process to encrypt
configuration files with new keys when fielded units must be replaced.

Protection of Configuration Data

1133

28 Some customers may prefer to use separate signing and encryption keys, and not have a single

DevID that must be configured for both. See Section 5.1.1.2 for tradeoffs.
Revision 29

39
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1134

5.5

1135
1136
1137
1138

A management station should be able to perform checks at any time to verify the identity,
software and configuration of each device. Classic issues like missed updates and deviations
in configuration parameters can be detected in an automated way, making establishedmanagement systems more secure in the following ways:

Remote Device Management

1139
1140
1141
1142
1143



Trusted Computing allows monitoring and verifying the state of the devices against
expected values documented in the management system. Deviations can be reported
automatically to the Administrator using Remote Attestation and the PTS protocol
suite (see TCG Attestation PTS Protocol: Binding to TNC IF-M [10]), reducing
operational costs to the customer.

1144
1145



Remote Attestation can also increase confidence in the supply chain, by proving thatdevices have the correct software loaded.

1146
1147
1148



Using a DevID to authenticate the device tightens the ability of the management
station to check the inventory of devices deployed. Unauthorized or changed devices
can be detected without manual checks of the physical devices.

1149
1150

5.6

1151
1152
1153
1154
1155
1156

The International Standards Organization (ISO) has published document ISO/IEC 197702:2009 Information technology -- Software asset management -- Part 2: Software identification
tag [5] describing the format for Software Identification tags (SWID tags), stored in XML files
on a device. SWID tags encode version information and expected hashes for each software
component, and should be updated by the device manufacturer’s software update processeach time a new image or patch is installed.

1157
1158
1159
1160
1161

SWID tags can be retrieved from a device to determine which software was last installed on
the device. Although techniques beyond the scope of this document must be used todetermine if the software installed is the version expected, comparison of the hashes in the
SWID tags with hashes retrieved from the TPM would provide assurance that the installedsoftware matches a valid release from the manufacturer.29

1162
1163
1164
1165
1166

While SWID tags are simply files and can be retrieved with any number of different
mechanisms, the TCG Trusted Network Communications workgroup has incorporated SWID
tag retrieval into the TNC protocol suite. Specified in SWID Message and Attributes for IF-M,
the TNC protocol allows a management station to determine whether each network device isloaded with the expected release.

1167
1168
1169
1170
1171

The presence of a particular SWID tag indicates which software version is probably installed.
For purposes of attestation, the SWID tags must be signed by the network device
manufacturer, or potentially by the Administrator of the device or other organizations,providing authority that the hashes claimed by SWID values are the ones that should bepresent on the device.

1172
1173

SWID tags contain hashes of the software modules they describe; with careful alignment by
the network device manufacturer, these hashes in SWID tags can be used in some cases as

Software Inventory

Of course the definition of what’s being hashed and the hash algorithms have to align to be
useful.
29

Revision 29

40
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

1174
1175

“known good values” for Attestation, and can be compared to what was recorded in the TPM
using a measured-boot process.

1176
1177

This allows a degree of automatic checking as part of the Attestation procedure described in
Section 5.7:

1178
1179



Use the TNC protocol described in SWID Message and Attributes for IF-M to retrieve
signed SWID values showing what should be installed on the device.

1180
1181
1182



Use TNC protocol TCG Attestation PTS Protocol: Binding to TNC IF-M [10] to retrieve
signed PCR values from the TPM, along with boot logs, to determine what was actuallyloaded during the boot process.

1183
1184

Signatures, module names and hashes can then be compared by the external Attestation
Server to detect tampering.

1185
1186

The following documents give details on SWID tags:

1187
1188



ISO/IEC 19770-2:2009(en) Information technology — Software asset management — Part 2:
Software identification tag [5]

1189
1190



Guidelines for the Creation of Interoperable Software Identification (SWID) Tags; NIST
IR 8060 (http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf)

1191
1192



TCG Trusted Network Connect: SWID Message and Attributes for IF-M, Version 1.0,
Revision 27, 2 June 2015

1193
1194
1195

http://www.trustedcomputinggroup.org/files/resource_files/F47E6340-1A4B-B294D0B3F7FF6497F489/SWID_Messages_For_IFM_v1r29.pdfhttp://www.iso.org/iso/ca
talogue_detail.htm?csnumber=53670

1196
1197

Attestation of Integrity for Network Devices (“Health Check”)

1198

5.7

1199
1200
1201
1202
1203
1204

Attestation is a mechanism by which measurements stored in a TPM can be retrieved by aremote attestation server to determine the configuration of the equipment at boot time as well
as at runtime. In the case of Network Equipment, remote attestation might be invoked by amanagement station (called the Challenger or Verifier), causing a networking device to reportits boot (and runtime) configuration. Alternatively, two peer devices might do Mutual
Attestation to prove to each other that their configurations are acceptable.

1205
1206

Attestation of both boot time and run time configuration can include a wide range of objects
that might have a bearing on the security posture of a device.

1207

Boot time objects typically include:

1208



The initial firmware loaded (such as UEFI code)

1209



Options of the initial firmware

1210



Boot loader

1211



OS kernel

1212

When extended to run time, Attestation can include:
Revision 29

41
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1213



Executables launched by the OS

1214



Shared libraries loaded into memory for execution

1215



Policy or configuration files

1216



Scripts

1217
1218



Cryptographic key material and credentials used by the OS, or other relevant sourcesof state information.

1219
1220
1221

As a result of an attestation process, the Challenger will receive a cryptographically signed“quote” and log from the Device indicating which versions of which modules were loaded andrun as the equipment started up.

1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232

Attestation requires that the Device implements “Measured Boot” (Section 4.1), in which,starting at a Root of Trust for Measurement (RTM), each stage computes a hash of the nextstage and stores the result in a TPM Platform Configuration Register (PCR) before launchingit. Each stage of the process can also measure any ancillary files that may be of interest in
determining the device’s security state, as listed above. Along with extending measurements
into PCRs, device software is expected to keep a log file which contains the name and versionof the object along with the hash. The log file does not need to be secure; the management
station can confirm its contents by computing the hash of the hashes and comparing theresult to the signed PCR values. While the contents of the log file are not specified, the log
data structure used by PTS is defined in Section 3.25 of TCG Attestation, PTS Protocol: Binding
to TNC IF-M [10], and could serve as a template.

1233
1234
1235
1236

To obtain attestation information, the Challenger must establish the identity of the Device,and then request the signed quote plus log information. This can be done using the TCG
Platform Trust Services (PTS) protocols, defined in TCG Attestation PTS Protocol: Binding to
TNC IF-M.

1237

Several components are needed for Attestation:

1238
1239
1240
1241



The Device must extend the hash of each boot object into the appropriate PCR, andkeep the corresponding log entries. If runtime integrity must be attested as well, theDevice must extend the hash of each runtime object into the appropriate PCR, andalso keep the corresponding log entries.

1242
1243



The Device must have an Attestation Key (either IAK or LAK) configured, to allow it tosign the quote.

1244
1245



Either a Privacy CA must be used to certify an AK, or the AK should be otherwise
traceable to the device’s identity.30 (See Sections 5.1.1.3 and 5.1.2.2.)

1246
1247



The device must implement the PTS protocol (or equivalent) to deliver attestation
information.

1248

30 Devices in which the AK and DevID are not tightly bound are subject to the “Asokan Attack”(RFC 6813) where an infected device tricks a clean device into attesting on its behalf.
Mechanisms such as TPM_Certify and SKAE can be used to provide proof that the AK and DevID
are resident in the same TPM

Revision 29

42
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1249
1250
1251

Copyright ©2018 TCG

TCG specifications allow the Challenger to obtain attestation information from the Device,
but it’s the Challenger’s task to determine if the hashes are acceptable. Acceptable hashes
for software modules are called Reference Integrity Metrics (RIMs) in TCG documents31, and:

1252



May be obtained directly from the OEM.

1253



Could be learned from ‘known-good’ systems.

1254
1255
1256



Could be retrieved from the device under attestation, assuming the reference
measurements are signed by the entity that’s authorized to provide software for the
product.

1257
1258
1259
1260
1261
1262
1263

Extending Measured Boot into the OS requires additional OS kernel functionality, allowing
for recording of measurements before software execution or reading32 of files identified as
security-critical. Each file identified for analysis is measured and recorded in the TPM, plus
a measurement log. Unlike earlier stages of the boot process though, the OS measurements
may continue as long as the system runs, resulting in incremental changes to logs and PCRs
as different objects are accessed through the system’s life.

1264
1265

5.7.1 Linux Integrity Measurement Architecture (IMA)

1266
1267
1268
1269

In Linux, a part of the security sub-system, called the Integrity Measurement Architecture(IMA), carries out the measurement process. IMA extends the principle of Measured Boot into
the operating system by providing means to measure selected applications started by the OS.
System designers and administrators can benefit from the following:

1270
1271



Measurement of any software executable on the system as it is loaded into memory forexecution, including shared libraries.

1272
1273



Measurement of all files read by a particular user, including programs running withpermissions of that user.

1274
1275



Measurement of all files used by specific packages, such as database systems or web
servers.

1276
1277
1278
1279
1280

The system designer must decide on the OS and application components to be measured.
Executable objects would typically be measured, but measurement may also include anyother kind of object such as those listed in Section 5.7 above. IMA maintains a measurement
log, referred to as Integrity Measurement Log (IML) in TCG documents33.

1281

IMA has many configuration options:
31 For TPM1.2, see TCG Infrastructure Working Group Reference Manifest (RM) SchemaSpecification, Version 2.0, https://www.trustedcomputinggroup.org/tcg-reference-manifest-rm-schemaspecification/.
32 Examples of simple file reads that could have integrity implications are configuration files orinterpreted-language scripts such as shell or Python. These aren’t strictly executable, but they
may be able to trigger unauthorized execution.
33 also known as Stored Measurement Log (SML) in some documents

Revision 29

43
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1282
1283



IMA log formats are configurable using IMA templates, allowing a system designer toadapt the log format to his/her needs.

1284
1285
1286
1287
1288
1289
1290



IMA is configurable using a policy, which to a certain extent allows for definition offiles to be measured. IMA uses that policy to decide whether a file is to be measured
or not according on each file Open(). The policy can be hard-coded and compiled into
the Linux kernel or it can be set dynamically on every boot by writing it to a file in theLinux securityfs filesystem (/sys/kernel/security/ima/policy). It is advisable to always
set the policy as early as possible in the boot process, although Linux kernels of version
4.7 and later allow the policy to be updated after initial boot.

1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302



IMA also supports policies that are based on Linux Security Modules (LSM) rules. LSM
provides an interface for security technologies to extend the Linux kernel’s capabilities
with more security-related features. It is used by technologies such as SELinux,
Simplified Mandatory Access Control Kernel (SMACK), TOMOYO, AppArmor, Yama,
and IMA, as well as others34. IMA is usually used to measure immutable files, so to
exclude all log files—which are, by definition, mutable—the SELinux attribute “logfile”
can be used to tag these, allowing the definition of a policy rule to exclude files thatare tagged with that attribute. Of course, an administrator must create a policy rule toset that attribute on all log files. The same applies to scripts and other interpreted
executables. Using LSM rules an administrator can improve the measurement process
and define more fine-grained IMA policies by including and excluding files dependingon their expected usage.

1303
1304

However, system designers need to be aware of some limitations of IMA, and some impact on
the overall system, including the following:

1305
1306
1307
1308
1309
1310



Files that are accessed by IMA for measuring may cause measurement violations due
to concurrent exclusive file accesses, called the Time of Measure Time of Use (ToMToU)
problem35. Whenever IMA cannot gain read access to a file a measurement violation isindicated by a special log entry, containing a file hash of all zeros, but, in turn, thePCR gets extended with a hash of all ones. System designers may wish to flag thatsituation when analyzing log files.

1311
1312
1313
1314
1315



Binding the platform state to an IMA-maintained PCR might not make a lot of sense inmost cases. As program execution order, even during boot, is non-deterministic onmost modern operating systems, the sequence of measurements in the log is very likely
not to be the same across boot cycles. This will result in unpredictable PCR values,
even if the set of executed programs has not changed.

1316
1317
1318
1319
1320
1321



Verification of IMA measurements requires more complex verification at the
management station. Instead of just comparing a single PCR value to a known-goodvalue, the management station must calculate the accumulated hash over the Integrity
Measurement Log and compare it to the reported hash from the TPM Quote.
Furthermore, the management station must compare all entries of the measurement
log to previously defined reference measurements, RIMs. That is, it must have access

34 See https://wiki.gentoo.org/wiki/Extended_Verification_Module.
35 If a file that is opened exclusively for use/writing (at the time of use), the measurement may fail,as the measurement process cannot also open the file for reading in order to measure it (at thetime of measurement).
Revision 29

44
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1322
1323
1324
1325
1326
1327
1328
1329

Copyright ©2018 TCG

to hundreds or even tens of thousands of reference values for a particular system
configuration. Typically, a search-optimized (indexed) database is used.
As the IMA measurement process continues to operate during the retrieval of a TPM
Quote, there might be some mismatch between the last recorded entry in the PCR andthe last entry in the log, when retrieving it. The log might have advanced while the“quote” operation was running. Accordingly, the appropriate log entry—the last one
that was incorporated in the PCR—must be identified to allow the Challenger to verify
the log. The process for identifying that log entry can look like the following:

1330

1. Retrieve the log for the first time, L1 (with the number of entries |L1|).

1331

2. Generate the TPM Quote.

1332

3. Retrieve the log again, L2 (with the number of entries |L2|).

1333
1334
1335
1336
1337
1338

4. Check whether the log has advanced (|L2| > |L1|36). If so, then the log entry
that has been used for the TPM Quote must be identified, which can either
happen on the device under attestation itself or on the management station,
which, in turn, needs either both of the log files or just the second one (L2)and additionally the number of entries in L1 (|L1|). The process would looksomething like what follows:37

1339

a. Calculate the accumulated hash from the whole first log (L1).

1340
1341
1342

b. Compare the accumulated hash against the hash from the TPM Quote.
If it matches, then return the full log up to the current entry.
Otherwise, continue.

1343
1344

c. Update the accumulated hash by incorporating the next log entry fromlist L2. Then continue with step (b).

1345
1346



In an OS with multiple concurrent processes, the TSS Access Broker should be used
to manage concurrent access from multiple processes to a single TPM.38

1347
1348
1349



While the file hashes are collected, none of the common file metadata is logged by IMA,
so there’s no record of user ID or group ID, either of the file itself or the processaccessing it, or file attributes.

1350
1351
1352
1353
1354
1355
1356
1357



IMA’s policy language cannot distinguish between text files, log files, executable
scripts, and other files. IMA can just detect access to files other than executables.
Affected are all kinds of interpreted languages, such as Java, Python, Ruby, Lua, shell
scripts, etc. Depending on the number of files involved, IMA’s facilities for measuring
every file can be used. The Challenger then is responsible to identify relevant files,
such as scripts. As IMA keeps an internal hash table to avoid adding duplicate entries
to the log, measuring a lot of files may cause that hash table to consume a notableamount of kernel memory and may cause out-of-memory errors. LSM rules in an IMA

36 |Lx| indicates the number of entries in the log.
37 While the order of entries in the log may be non-deterministic, we do assume that the log filecontains entries in exactly the same order as they were measured into the TPM.

38 For example, see http://www.trustedcomputinggroup.org/wp-content/uploads/TSS-TAB-and-Resource-Manager-00-91-PublicReview.pdf
Revision 29

45
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1358
1359

policy, as mentioned above, can be used to restrict measurement only to files that havesecurity significance.

1360
1361

IMA is subject to continuous improvement, and may offer additional desirable features
after this document has been published.

1362

5.7.1.1

1363
1364
1365

IMA Appraisal is the equivalent of Secure Boot extending into the operating system. In
contrast to IMA measurements, IMA Appraisal requires a file to match a known-goodmeasurement in order to allow access.

1366

Known-good measurements can be managed several ways.

1367
1368
1369
1370
1371

One approach is to simply learn the hash of each file from a clean system. For that purpose,a particular boot argument to the Linux kernel must be passed (ima_appraise=fix), instructing
IMA to record the known-good measurements of accessed files. On any subsequent boot, IMA
appraisal can be activated to enforce access of a file only if it matches the known-goodmeasurement, by passing the corresponding kernel boot argument (ima_appraise=enforce).

1372
1373
1374

By default, IMA allows access to files if the measurements match and will update the knowngood measurement if the file is modified after having passed the check on the initial fileopen.39

IMA Appraisal

1375
1376
1377
1378
1379
1380

IMA also supports immutable files utilizing digital signatures on the known-goodmeasurements, generated and signed when the software components are built, prior to
installation on a particular machine. Private keys stay with the build system; only the signer’s
public key(s) must be available in the IMA keyring (currently .ima_root_ca), although theymust be loaded into the keyring early in the boot process, typically in an initramfs.

1381
1382
1383
1384
1385
1386
1387
1388
1389

Digital signatures provide protection against online tampering with the files. Offline
tampering would still be possible by generating a malicious key-pair, re-signing all the files
with the malicious private key, and then replacing the public key with the malicious one. It’s
possible to protect against offline changes to extended file attributes in general, including theattributes used for IMA Appraisal Known-Good Measurements, with the Linux kernel
Extended Verification Module (EVM)40. With EVM, IMA can use a cryptographic hash (HMAC)
or digital signature, with a key loaded at boot time, to verify the extended file attributes on
any access. EVM keys can be protected by the TPM using Sealing, or, in applications where
there’s an interactive user, a password can be used to unlock the EVM key.

1390
1391
1392
1393
1394
1395

A system designer may utilize IMA Appraisal whenever a system must run only approved
software that is known prior to device deployment. While systems which use signaturesgenerated by the device manufacturer’s software build system can readily be updated in thefield (assuming keys don’t change), the software update mechanism on systems that require
re-measurements of software on the system itself is out of scope for this document and is left
to be defined by the system designer.

39

https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture#Registering_the_file_hashes_fo
r_the_system
40

See https://wiki.gentoo.org/wiki/Extended_Verification_Module

Revision 29

46
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

1396
1397

5.7.2 PCR Definitions

1398
1399

The allocation of various functions to specific PCRs depends a lot on the underlying softwarearchitecture of the Network Equipment.

1400
1401

There are two definitions available at the time of this writing to serve as starting points for
Network Equipment:

1402



UEFI-based TCG_PC Client Implementation for BIOS.pdf Section 3.2.3 [22]

1403



Mobile Platforms: TPM2.0 Mobile Common Profile [20] Section 2.5

1404
1405
1406
1407

Guidelines for information to be collected in PCRs can also be found in the following:

NIST SP800-155 BIOS Integrity Measurement Guidelines;
http://csrc.nist.gov/publications/drafts/800-155/draft-SP800-155_Dec2011.pdf

1408
1409
1410

5.8

1411
1412
1413
1414
1415
1416

In modular Network Equipment, there’s usually a control plane that manages field
replaceable units (FRUs) like line cards, each of which may contain complex control
processors with TPMs themselves. FRUs, including control plane processors, can usually be“hot swapped”, that is, inserted and removed while the rest of the system continues to run,yielding a system where components may come and frequently, even though the system as awhole rarely goes down or starts up all at once. This results in several complexities:

Composite Networking Devices

1417
1418
1419
1420



Each time an FRU is inserted or removed, a control plane process typically notes thechange in configuration, initializes the new unit and may alert other components inthe system of the new configuration. These new components should not be admitted
to the system unless they can show that they are in a known-good state.

1421
1422
1423



The conventional definition of attestation may need to be extended with the goal ofreporting not just the attested state of one control plane processor, but including also
the state of the subsidiary FRUs, each with their own processor state.

1424
1425
1426
1427
1428
1429
1430
1431

TCG offers a number of mechanisms that are useful to the design of such systems:
Integrity-Protected logs could be used to keep a tamper-evident record of modules
that were added or subtracted during the life of the system.
Identity - The system designer must set the rules and procedures for determining
membership in the composite device, but Device Identity (e.g., IDevID or LDevID)
could provide a solid basis for determining whether specific devices are eligible to join
a composite or not.

Revision 29

47
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442



1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Internal Attestation among elements – System designers may want elements of asystem to prove not only their identity, but also that they’re running authorizedsoftware. 41
o In some cases, control processes may already know what versions of software
they’ll accept on subsidiary units (e.g. a router control plane may only workwith line cards with certain software revisions, and if the software isn’t up torev, the control plane may force an upgrade.)o In other cases, units may need to provide evidence that software versions
being run are authentic (e.g. signed SWID tags). This might be applicable topeer nodes in a distributed system, where there’s no obvious leader to dictate
expected software versions.
Except for the most aggressively distributed systems, internal attestation would
function inside the composite “device”, and would be designed to suit the
manufacturer’s software environment, without the need for interoperability
specifications. As a result, extensions to standards are not likely needed for thisapplication.

External Attestation – Composite systems will usually elect a leader, either throughhardware or software means, to communicate with the outside world and represent
that state of the system (i.e. provide a management plane and management
interface). One of the functions that might be desired is Remote Attestation, where
an external management device can identify the system, its components and theauthenticity of software running on the system, including all the software running on
subsidiary units which may not be visible to an external management agent.

1456
1457

5.9

1458
1459
1460
1461
1462
1463

Use cases like Security Information and Event Management (SIEM), IETF Security
Automation and Continuous Monitoring (SACM) or even Lawful Interception rely on log files
created by devices deployed in the field outside the direct, physical administration of theoperator or owner. Supporting these use cases requires integrity-protected or nonrepudiable log files created by the device. Protecting the integrity requires evidence of theauthenticity, order, and time of the log file entries.

1464
1465
1466

An integrity-protected log can be utilized in cases like Lawful Interception proving the correct
operation of a particular device or link at the time of data interception, for later forensic or
court-ordered evaluation.

Integrity-Protected Logs

1467
1468

5.9.1 Functional Requirements

1469
1470
1471

Integrity-Protected logged data must be protected against undetected manipulation such as
deletion, insertion of modification of log events, and can additionally provide evidence of thestate of the system at the time of the logged event.

41 For example, a Device shouldn’t use a crypto-accelerator FRU unless it can prove that it’s notbeen tampered with.
Revision 29

48
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1472

Each entry in the log file provides the following information:

1473



Type of event

1474



Date and time

1475



Order relative to other events

1476
1477

Copyright ©2018 TCG

The TPM-issued signature covers the following information, showing it has not been modified
after being signed:

1478



Identity of the log device, based on the DevID

1479
1480
1481



A non-volatile monotonic sequence number showing the order of events and provingthat the current event immediately follows the previous event, so that causal
relationships can be determined, and deletion of events can be detected

1482



(optional) time of signature

1483



(optional) state of device during signature operation

1484
1485

Network Devices may reboot unexpectedly, or they may operate without a reboot for years; assuch, logging mechanisms must typically meet two additional goals.

1486



Log files must persist through a reboot, and retain integrity through the reboot.

1487
1488



But at the same time, devices may produce a lot of logging information, so
mechanisms that “trim” the logs, discarding old entries, are often provided.

1489
1490
1491
1492
1493

The need to discard old log information implies that there can be no expectation of apermanent log that goes all the way back to the first use of the Device; it’s the Administrator’s
responsibility to collect and archive log information periodically if a long-term record isneeded. The intent of the mechanism described here is to allow the Administrator todemonstrate that a set of log files provides a complete record.

1494
1495

5.9.2 Integrity-Protected Log Implementation

1496

Implementation of Integrity-Protected Logs uses a number of TPM mechanisms:

1497
1498



The TPM time-keeping mechanism can be used to generate tamper-resistant timestamps on log entries.

1499
1500



The Monotonic Counter mechanism can be used to sequence log entries and to detect
missing or added entries, even across boot cycles.

1501
1502



The TPM signing mechanism can be used to sign log entries so that any changes in
an individual entry can be detected.

1503
1504

5.9.2.1

1505
1506
1507

While the TPM does not keep a real-time clock, it does provide a mechanism that keeps trackof elapsed time since the last initialization. This relative time measure is called a Tickstamp(TPM1.2 Part 1 Design Principles Chapter 20).

1508
1509
1510

The tick counter increments at a specified rate, but cannot be “set”, and does not relate toany external real time, so there is usually a requirement to establish the correlation between
the monotonic tick-counter of the TPM and a trustworthy external real time clock.
Revision 29

Timekeeping in TPM 1.2

49
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1511
1512
1513
1514
1515
1516

The correlation process works by measuring the difference between an authorized external
time source and the local Tickstamp timer. A Tickstamp is taken prior to the request to an
external source, and then again after the response has been processed, yielding a bounded
uncertainty in time correlation. The internal tick counter of the TPM is subject to drift, so
correlation may have to be repeated periodically to maintain adequate sync. (See TPM 1.2
Part 1 Design Principles Section 20.3 for a detailed description.)

1517

Figure 5 shows the process:
ClientTPM

Time
Authority

Nonce

TS1

TS1
stamp(TS1)stamp(TS1)
TS2

1518
1519

Figure 5 : Time Correlation

1520
1521
1522
1523
1524

The TPM supports the generation of signed tick stamps that include a signature over usersupplied data associated with the current tick count value, the tick increment rate and ticksession nonce. Every time the TPM is reset a new tick session nonce is generated. (See TPM
1.2 Part 1 Design Principles Section 20.1 for a detailed description.)

1525
1526

5.9.2.2

1527
1528
1529
1530
1531
1532
1533

TPM 2.0 offers additional timekeeping facilities, described in TPM 2.0 Part 1 Architecture
Chapter 36.7. Time contains the time in milliseconds since the last startup of the TPM.
resetCount is a counter that increments every time the TPM is successfully reset. Its purpose
is, among other things, to indicate possible discontinuity in Clock. restartCount is used toprovide an indication of discontinuities due to (1) TPM Resume, (2) TPM Restart, or (3)_TPM_Hash_Start; all allowing TPM Time to fall behind real time (TPM 2.0 Part 1 Architecture
Chapter 36.5).

1534
1535
1536
1537
1538
1539
1540
1541

Clock is a volatile value that increments in memory each millisecond. The non-volatile value
NV Clock is updated periodically from that value. On every reboot the value of Clock is set tothe value of NV Clock. However, in case of unexpected power loss the value of Clock may bereported twice as the final Clock value might not have been written to NV Clock. The TPM flag
safe of the TPMS_CLOCK_INFO structure is used to indicate such a situation of unexpected
power loss. Mitigations are described in TPM 2.0 Part 1 Architecture Chapter 36.2. In contrast,
an orderly shutdown of the TPM is possible using the TPM2_Shutdown() command, whichtells the TPM to preserve an appropriate state.
Revision 29

Timekeeping in TPM 2.0

50
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

Copyright ©2018 TCG

1542
1543
1544
1545
1546
1547
1548

Neither the TPM 1.2 nor the TPM 2.0 has a real-time clock that is able to advance time in the
power-off state. The TPM1.2 clock retains no state through a power cycle, but in TPM 2.0,
Clock is non-volatile, and can be set forward (never backward, though, except by installing a
new owner) by external software managing the TPM, allowing for correlation to an external
real-time clock. As the TPM may be driven by an imprecise frequency source, the clock issubject to drifting. To compensate, the TPM 2.0 allows external software to adjust the rate ofadvancement by +/- 15 %.

1549
1550
1551
1552
1553

Attestation data in TPM 2.0 includes the resetCount value, although it is obfuscated topreserve privacy (TPM 2.0 Part 1 Architecture Chapter 36.7). Nevertheless, an attesting
management station can detect a reboot, and hence a possible discontinuity in time, by
checking whether the resetCount value has changed. TPM 2.0 also allows for usage of timing
data in policies, e.g. to limit the usage of keys for a certain amount of time.

1554
1555

5.9.2.3

1556
1557
1558

While this document does not specify the exact format of Integrity-Protected log files, the logs
can be assembled using TPM Monotonic Counters for sequencing, TPM signing for integrity,
and Tickstamps for temporality.

1559
1560
1561
1562
1563
1564
1565
1566

To detect addition or deletion of events in the log, TPM Monotonic Counters (TPM1.2 Design
Principles Chapter 17, TPM Rev 2.0 Part 1 – Architecture Section 37.2.4) can be used. These
counters can be incremented by a TPM user, but can never be decremented or cleared. Thismechanism allows log entries to be created where each entry has a sequence identifier that’s
exactly one larger than the previous entry, allowing deletions or additions to be easily
detected. Old log entries may be deleted, but in the remaining logs, the monotonic countshould increment uniformly from the oldest entry through each intermediate entry to thenewest.

1567

For high-value, low-rate42 log information, a simple mechanism can be used:

Assembling the Log

1568
1569



Each new log entry can be assembled with a Tickstamp or Timestamp to show when
it happened, and the next value from a non-volatile Monotonic Counter.

1570
1571



The log entry can be signed with an IDevID or LDevID key, and appended to the log
file.

1572
1573
1574



Reboots of the system and restarts of the TPM can be detected using the tick session
nonce of a Tickstamp (TPM 1.2 and TPM 2.0) or the values resetCount andrestartCount (TPM 2.0 only).

1575

Any subsequent tampering will invalidate signatures, or show a gap in the sequence numbers.

1576
1577
1578
1579

It should be noted that the TPM also incorporates a mechanism which can be used to audit
the command codes which it has been called upon to execute; this mechanism works bykeeping an internal digest of commands, which can be compared to an external log file ofwhat commands were executed.

1580

42 Average rate of a few log entries per hour; TPMs can’t sign quickly, and the Monotonic Counterin TPM1.2 will wrap and/or wear out if it’s incremented more than once every few minutes.
Revision 29

51
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

1581
1582

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

High-rate logs would require a more complex block-signing mechanism, something beyond
the scope of this document.

1583
1584

5.10 Entropy Generation

1585
1586
1587
1588

Many network protocols rely on a dependable source of random numbers for correct
operation. For security related protocols, random numbers may be used by a cryptographic
element. For other protocols, this might be a TCP sequence identifier, or a source port
number, or some other nonce used to identify a particular session or traffic flow.

1589
1590
1591

The TCG TPM definition includes a requirement for a Random Number Generator, which canbe accessed after the TPM self-test sequence is complete, simply by invoking the
TPM_GetRandom() or TPM2_GetRandom() ordinals.

1592
1593
1594
1595

TCG specifications allow TPM vendors considerable flexibility in implementation choices. A
common design approach, not mandated by TCG, would be a mechanism where a physicalnoise source of some sort (a True Random Number Generator, or TRNG) can be used to seeda Deterministic Random Bit Generator (DRBG), ensuing predictable statistical properties.

1596
1597
1598
1599

For many Network Equipment vendors, compliance to standards such as NIST Special
Publication 800-90A/B/C [13] or BSI AIS-31, A Proposal for Functionality Classes for Random
Number Generators [15], is a requirement; in this case, the OEM designer should consult the
TPM vendor for compliance certifications.

1600

There are two aspects of the standards that OEM designers should consider:

1601
1602
1603
1604

a) The standards require continuous testing of the components of the RNG, in addition
to a self-test at startup. These tests must be done inside the TPM, as they require
access to internal state. If there’s a failure of the self-test at any point, the TPM willreport a failure in response to further requests.

1605
1606

b) The standards require that entropy from a physical source (TRNG) should be added
periodically to the DBRG, so that repeated reads will not exhaust the entropy supply.

1607
1608
1609

A compliant TPM is required to monitor and replenish the entropy level as needed, andmay return fewer bytes of random numbers than requested should requests outpace
generation of new entropy.

1610
1611
1612

Rates at which new entropy is generated within the TPM is not specified by TCG or the
standards, so it’s up to the OEM designer and the TPM vendor to ensure that the TPM
in consideration generates entropy at an adequate rate for the application.

1613
1614
1615
1616
1617

The TPM has a mechanism with which external entropy can be added to the TPM’s DRBG
output (TPM_StirRandom() and TPM2_StirRandom() ). As long as the TPM vendor certifies
that the device generates entropy on its own at an adequate rate, the OEM designer is not
likely to need this ordinal.43

1618
1619

It’s always good practice for the OEM’s operating system to collect and merge entropy fromas many sources as are available. For example, the Linux OS rng-tools can be configured to

43 If a platform has additional sources of entropy, StirRandom can also be used to defend against

a hidden failure of the TPM’s internal entropy source.
Revision 29

52
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1620
1621
1622

Copyright ©2018 TCG

merge entropy from a number of sources such as arrival time of network traffic, or disk
seek times, with the entropy obtained from the TPM to supply /dev/random for OS andapplication needs.

1623
1624

5.11 Deprovisioning

1625
1626
1627

Networking equipment often contains sensitive information that an Administrator would
want to protect from disclosure, and must be destroyed when the device is deprovisioned.

1628

The Device Manufacturer should provide a mechanism to enable deprovisioning.

1629

Upon deprovisioning, the device:

1630



Should delete any LDevID, LAK or other customer-generated keys from the TPM.

1631
1632



Should not erase IDevID or IAK keys, since these indicate the manufacturer’s device
identity, not the Administrator’s.

1633

Any installation-specific configuration files should also be deleted.

1634
1635

Deletion of files from modern flash-based memory systems is not easy; an approach toensure the deletion is reliable would be:

1636



Create a local storage key as a child of the SRK.

1637



Store all configuration files in a partition using disk-encryption technology.

1638
1639

Upon deprovisioning, the TPM can be instructed to delete the local storage key, rendering
the partition unintelligible.

1640

Revision 29

53
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

1641

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

6. References

1642
1643
1644
1645
1646

[1]

IEEE Standard for Local and Metropolitan Area Networks
Borza, Mike (ed.) and Max Pritikin (ed.), “802.1AR-2009 – IEEE Standard for Local
and Metropolitan Area Networks - Secure Device Identity”, IEEE Computer Society,
New York, New York, December 10, 2009,http://www.ieee802.org/1/pages/802.1ar.html

1647
1648
1649
1650
1651

[2]

Trusted Computing Group, Trusted Platform Module Library, Part 1: Architecture,
Family “2.0”, Level 00 Revision 01.16, Oct 30, 2014.
https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1Architecture-01.16.pdf

1652
1653
1654
1655

[3]

Trusted Computing Group, Trusted Platform Module Library, Part 2: Structures,
Family “2.0”, Level 00 Revision 01.38, September, 2016.
https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2Structures-01.38.pdf

1656
1657
1658

[4]

Trusted Computing Group, TPM Keys for Platform Identity for TPM 1.2, Version 1.0,
Revision 3, August 21 2015. https://trustedcomputinggroup.org/wpcontent/uploads/TPM_Keys_for_Platform_Identity_v1_0_r3_Final.pdf

1659
1660
1661
1662

[5]

The International Organization for Standardization/International ElectrotechnicalCommission (ISO/IEC), Information Technology - Software Asset Management - Part 2:
Software Identification Tag, ISO/IEC 19770-2, November 2009https://www.iso.org/obp/ui/#iso:std:iso-iec:19770:-2:ed-1:v1:en

1663
1664
1665

[6]

Trusted Computing Group, Registry of Reserved TPM 2.0 Handles and Localities,
Version 1.0, Revision 1, October 11, 2013. https://trustedcomputinggroup.org/wpcontent/uploads/131011-Registry-of-reserved-TPM2-handles-and-localities.pdf

1666
1667
1668

[7]

Trusted Computing Group, TCG TPM v2.0 Provisioning Guidance, Version 1.0,
Revision 1.0, Mar 15, 2017. https://trustedcomputinggroup.org/wpcontent/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf

1669
1670
1671

[8]

Trusted Computing Group, TCG EK Credential Profile For TPM Family 2.0, Revision
14, November 4, 2014. https://www.trustedcomputinggroup.org/wpcontent/uploads/Credential_Profile_EK_V2.0_R14_published.pdf

1672
1673
1674
1675

[9]

Trusted Computing Group, TCG Infrastructure Workgroup Subject Key Attestation
Evidence Extension, Version 1.0, Revision 7, 16 June 2005.
https://trustedcomputinggroup.org/wp-content/uploads/IWG_SKAE_Extension_100.pdf

1676
1677
1678
1679

[10]

Trusted Computing Group, TCG Attestation PTS Protocol: Binding to TNC IF-M,
Version 1.0, Revision 28, August 24, 2011.
https://www.trustedcomputinggroup.org/wpcontent/uploads/IFM_PTS_v1_0_r28.pdf

1680
1681
1682
1683

[11]

Trusted Computing Group, TCG EK Credential Profile for TPM Family 2.0; Level 0,
Version 2.0, Revision 14, November 4, 2014.
https://trustedcomputinggroup.org/wpcontent/uploads/Credential_Profile_EK_V2.0_R14_published.pdf

1684

[12]

A Practical Guide to TPM 2.0, W. Arthur & D. Challener, Apress; 1st Edition, January

Revision 29

54
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1685

Copyright ©2018 TCG

28, 2015

1686
1687
1688

[13]

National Institute of Standards and Technology, Recommendation for Random
Number Generation Using Deterministic Random Bit Generators, Revision 1, June
2015, http://dx.doi.org/10.6028/NIST.SP.800-90Ar1

1689
1690
1691

[14]

National Institute of Standards and Technology, Report on Post-Quantum
Cryptography, NISTIR 8105
http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf

1692
1693
1694
1695
1696

[15]

Bundesamt für Sicherheit in der Informationstechnik (BSI) AIS-31, A Proposal for
Functionality Classes for Random Number Generators, Version 2.0, 18 September
2011,
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_Functionality_classes_for_random_number_generators_e.pdf

1697
1698
1699

[16]

ISO/IEC 18031:2011 Information technology -- Security techniques -- Random bit
generation, published on: 2011-11,
http://www.iso.org/iso/catalogue_detail.htm?csnumber=54945

1700
1701
1702
1703
1704

[17]

Trusted Computing Group, TCG Storage Opal Integration Guidelines, Version 1.00,
Revision 1.00, March 16, 2016.
https://trustedcomputinggroup.org/wpcontent/uploads/TCG_Storage_ReferenceDocument_Opal_Integration_Guidelines_v1.
00_r1.00.pdf

1705
1706

[18]

Linux Integrity Measurement Architecture, http://linux-ima.sourceforge.net,/https://wiki.gentoo.org/wiki/Project:Integrity

1707
1708
1709

[19]

Trusted Computing Group, IWG Reference Architecture for Interoperability (Part 1),
Version 1.0, Revision 1.0, June 16 2005. https://trustedcomputinggroup.org/wpcontent/uploads/IWG_Architecture_v1_0_r1.pdf

1710
1711
1712

[20]

Trusted Computing Group, TPM 2.0 Mobile Common Profile, Family “2.0” Level 00
Revision 29, 21 December, 2015. https://www.trustedcomputinggroup.org/wpcontent/uploads/Mobile-Common-Profile-v2r29_Public-Review.pdf

1713
1714

[21]

NIST Special Publication 800-57 Part 1, Recommendation for Key Management,
Revision 4, January 2016. http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4

1715
1716
1717
1718
1719

[22]

Trusted Computing Group, PC Client Specific Platform Firmware Profile Specification
Family “2.0”, Level 00 Revision 1.03 Version 51,
https://trustedcomputinggroup.org/pc-client-specific-platform-firmware-profilespecification/

1720

Revision 29

55
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

1721

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

7. Glossary

1722
1723

There are a few terms that are specific to Network Equipment:

1724



Device – a unique piece of network equipment

1725



CPE – Customer Premise Equipment

1726



FRU – Field Replaceable Unit

1727



From IEEE 802.1AR:

1728
1729

o

Initial Secure Device Identifier (IDevID): The Secure Device Identifier
installed on the device by the manufacturer

1730
1731
1732

o

Locally Significant Secure Device Identifiers (LDevIDs): A Secure Device
Identifier credential that is unique in the local administrative domain in which
the device is used

1733
1734
1735

o

Secure Device Identifier (DevID): A device identifier that is cryptographicallybound to the device and is composed of the Secure Device Identifier Secret andthe Secure Device Identifier Credential

1736
1737
1738

TCG-specific acronyms and abbreviations can be found in the TCG Glossary
https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_Glossary_BoardApproved_12.13.2012.pdf

Revision 29

56
TCG PublishedJan 17, 2018

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1739

8. Appendices

1740

8.1

Copyright ©2018 TCG

Use-Cases for Further Study

1741
1742

8.1.1 Secure Identity in Virtual Machines

1743
1744
1745
1746

Manufacturers are starting to incorporate Virtual Machine technology into Network
Equipment, either as an element of an integrated hardware/software product or as asoftware-only product running entirely within a virtual machine environment, as in Network
Function Virtualization.

1747
1748
1749

In either case, there’s often a need to identify the hardware resource underlying the virtual
machine, to ensure that the function is actually executing in the expected environment, andto determine if the software is running in a virtual machine or directly on a physical machine.

1750
1751

8.1.2 Distributed Composite Devices

1752
1753
1754
1755
1756
1757

In today’s infrastructure, composite devices make use of wired or wireless networks asinterconnects to merge management planes or sub-sets of control plane functions. Therefore,
the physical components of a composite device can be geographically distributed, but act asa single entity on the management plane. In addition, network interfaces can be associatedwith more than one composite device; each managed via independent management planesinterfaces.

1758
1759
1760
1761

There is a need to take into account the type of composition used to merge management
planes or control plane functions of distinguishable physical units. Every distributed
composition relies on a specific form of interconnect between physically separated units,
which can be used as a basis for corresponding solutions.

1762
1763

8.1.3 Device Identity Stability in Highly Available Systems

1764
1765
1766
1767
1768

Network equipment is often designed with a considerable degree of redundancy to reduce thechances of service failure. While the current document assumes that Device Identity applies
to each individual non-redundant component that makes up a redundant system, there isoften a need to ensure that redundant devices present uniform and secure identity regardlessof internal failure and recovery mechanisms.

1769

8.2

1770

8.2.1 Known Good Hashes

1771
1772

There are currently no existing protocols that are being used to convey known-good hashes
from the Network Device Manufacturer to Attestation systems that might use these values.

1773
1774
1775
1776

One suggested approach could be for the manufacturer to provide an “oracle”, which could
return a signed quote and a log with an entry for every possible object that could be measured,using the PTS protocol; the Attesting system then would use this list as a data base to lookup expected values.

Standardization Work for Further Study

Revision 29

57
TCG PublishedJan 17, 2018

Copyright ©2018 TCG

TCG Guidance for Securing Network Equipment Using TCG Technology
Version 1.0

1777

8.2.2 Composite Systems

1778
1779
1780

External Attestation of a composite system needs new protocol work. The current attestation
mechanism assumes attestation is being carried out on an integrated unit with one TPM. In
a composite system, attestation might require multiple steps:

1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792






Attest the control plane element that was elected (either by hardware or software) torepresent the device to the outside world. This can be done using conventional PTS.
Ask the control plane element for a list of devices that it currently has accepted into
its configuration. This might be a list of line cards, or a list of stacked switches, or abunch of servers. The list might be flat or hierarchical, as decided by the systemdesigner. All that the management station needs is a list of the elements and how to
identify them.
The management system might then ask for attestation results from some or all of
the units reported. Some units may include a separate TPM, which can be leveraged
to enrich the attestation of the composite device or even allow for direct remoteattestation of a sub-component.

1793
1794
1795
1796

In most cases, the elements that make up the system (e.g. line cards) will not be directly
visible externally, i.e., they won’t have routable IP addresses to their own control plane
processors, resulting in a need for a mechanism to send a request for Attestation that canbe forwarded by the receiving management plane processor to the appropriate internal FRU.

1797

For PTS, this would probably be done by adding an “element id” field to the request/response.

1798
1799

For an SNMP-based mechanism, it might be handled by introducing a layer of hierarchy into
the MIB.

1800
1801
1802

8.2.3 Reference Manifests

1803
1804
1805
1806

The document TCG Infrastructure Working Group Reference Manifest (RM) SchemaSpecification, Version 2.0, https://www.trustedcomputinggroup.org/tcg-reference-manifest-rm-schemaspecification/ defines the XML schema with which integrity information is communicatedbetween entities for TPM1.2.

1807

There currently is not an equivalent document for TPM2.0

1808
1809

Revision 29

58
TCG PublishedJan 17, 2018