TCG Guidance for Securing ResourceConstrained Devices
Version 1.0
Revision 22
March 13, 2017

Contact: admin@trustedcomputinggroup.org

TCG TCG Published
Copyright © TCG 2003 - 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Disclaimers, Notices, and License Terms
THIS DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDINGANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY
PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL,
DOCUMENT OR 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 ofuse, loss of data or any incidental, consequential, direct, indirect, or special damages, whether undercontract, 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 22

2
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

Acknowledgements
The TCG wishes to thank all those who contributed to this reference document. This document builds
on considerable work done in the various work groups in the TCG.
Special thanks to the members of the IoT-SG who participated in the development of this document:
Graeme Proudler (Editor)

Independent

Ira McDonald (Editor)

High North

Steve Luther

United States Government

Additional thanks to those who provided comments on this document during review:
Steve Hanna (Infineon), Sung Lee (Intel), Alan Tatourian (Intel)

Revision 22

3
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

1

Table of Contents

2

List of Tables ........................................................................................................................................................... 6

3

1. Scope and Audience ......................................................................................................................................... 7

4

1.1

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

5

1.2

Audience ............................................................................................................................................... 7

6

1.3

References ............................................................................................................................................ 77

2. Preface ............................................................................................................................................................ 108

3. Implementation Guidance for Countering Threats .......................................................................................... 11

9

3.1

Tampering with Hardware ................................................................................................................... 11

10

3.2

Subversion of Algorithms .................................................................................................................... 11

11

3.3

Access to Concealed Data .................................................................................................................. 12

12

3.3.1

Physical Isolation of data ............................................................................................................. 13

13

3.3.2

Cryptographic Isolation of Data .................................................................................................... 13

14

3.3.3

Access controls ............................................................................................................................ 14

15

3.4

Device Impersonation ......................................................................................................................... 14

16

3.5

Subversion by Malware ....................................................................................................................... 1517

4. Implementation Guidance for Trusted Platform Services ............................................................................... 18

18

4.1

Cryptography ....................................................................................................................................... 18

19

4.2

Isolation ............................................................................................................................................... 18

20

4.3

Random Number Generator ................................................................................................................ 19

21

4.4

Protected Storage ............................................................................................................................... 19

22

4.4.1

Bounded Storage ......................................................................................................................... 19

23

4.4.2

Mass Storage ............................................................................................................................... 19

24

4.4.3

Unbounded Storage ..................................................................................................................... 20

25

4.4.3.1

Protected Storage Hierarchy ....................................................................................................... 20

26

4.4.3.2

Multi-tasking ................................................................................................................................ 20

27

4.4.3.3

Duplication of Stored Objects ..................................................................................................... 21

28

4.4.4

Authorization methods ................................................................................................................. 21

29

4.4.4.1

Password .................................................................................................................................... 2130

4.4.4.2

HMAC .......................................................................................................................................... 21

31

4.4.4.3

Enhanced .................................................................................................................................... 21

32

4.5

Device Identification ............................................................................................................................ 22

33

4.5.1

Signature verification ................................................................................................................... 22

34

4.5.2

Signing ......................................................................................................................................... 23

35
36

4.6
4.6.1

Privacy Enhancements ....................................................................................................................... 23
Privacy during identification ......................................................................................................... 23

Revision 22

4
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

37
38

4.6.2
4.7

Copyright ©2017 TCG

Privacy during recognition ............................................................................................................ 24
Trust Enhancements ........................................................................................................................... 24

39

4.7.1

Sealed Storage ............................................................................................................................ 25

40

4.7.2

Attestation .................................................................................................................................... 26

41

4.8

Secure Device Updates ...................................................................................................................... 26

42

4.9

Device Software .................................................................................................................................. 27

43

4.9.1

Protected Storage Software ......................................................................................................... 27

44

4.9.2

Conventional Security Software ................................................................................................... 27

45

4.9.3

Attestation Software ..................................................................................................................... 27

46

5. Cryptographic resources used by Trusted Platforms ..................................................................................... 2947

6. Appendix ......................................................................................................................................................... 34

48

6.1

Overlay Networks ................................................................................................................................ 34

49

Revision 22

5
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

50
51
52
53
54
55
56

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

List of Tables
Table 1: Attributes of Identification Secrets ........................................................................................................... 15
Table 2: Cryptographic Primitives ......................................................................................................................... 29
Table 3: Cryptographic Primitives used to implement Trusted Platform services................................................. 29
Table 4: Common Uses for Trusted Platform services ......................................................................................... 32

Revision 22

6
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

57
58

1. Scope and Audience

59

1.1

60
61

This reference document provides implementation guidance for trusted platforms built withresource-constrained devices.

62

This reference document is not a TCG Specification and therefore is not normative.

63

1.2

64
65
66
67
68

The intended audience for this reference document is designers, developers andmanufacturers of resource-constrained devices, software, and services. This reference
document is intended to assist in the determination of whether an embedded device could
be a trusted platform and (if so) what resources the device will need to be a trusted
platform. Typically those resources are those found in Trusted Platform Modules (TPMs).

69

1.3 References

70
71
72

The date upon which a URL was last verified by TCG is the date inside the brackets
following the URL. For example, a URL verified during November 2016 is followed by[November 2016].

Scope

Audience

73
74
75
76
77

[1] NIST, Special Publication (SP) 800-90A Revision 1, Recommendation for Random
Number
Generation
Using
Deterministic
RandomBit
Generators,
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf[November 2016]

78
79[2] NIST, Randomness Beacon, www.nist.gov/itl/csd/ct/nist_beacon.cfm [November
2016]

80
81

[3] Trusted Computing Group, Trusted Platform Module Library 2.0, listed at
www.trustedcomputinggroup.org/tpm-library-specification/ [November 2016]

82
83[4] Trusted Computing Group, TPM 2.0 Mobile Reference Architecture Family, listed
at www.trustedcomputinggroup.org/work-groups/mobile/ [November 2016]84
85[5] Trusted
ComputingGroup,
Multiple
Stakeholder
Model,
listedwww.trustedcomputinggroup.org/work-groups/mobile/ [November 2016]86
87[6] Trusted Computing Group,
TPM Software Stack specifications, listed at
www.trustedcomputinggroup.org/work-groups/software-stack/ [November 2016]88
89[7] Trusted Computing Group, Enterprise and Opal Secure Encrypting Drives, listed
at www.trustedcomputinggroup.org/work-groups/storage/ [November 2016]

Revision 22

7
TCG PublishedatMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

9091[8] Trusted Computing Group, TCG Storage Architecture Core Specification, listed at
www.trustedcomputinggroup.org/work-groups/storage/ [November 2016]

92
93
94

[9] Trusted Computing Group, “TCG Storage Interface Interactions Specification(SIIS)”,
listedatwww.trustedcomputinggroup.org/work-groups/storage/[November 2016]

95
96
97

[10]
Storage Security Industry Forum (SSIF), Guide to Data-At-Rest Solutions,listed at www.trustedcomputinggroup.org/solutions-guide-data-rest/ [November
2016]

98
99
100

[11]
Trusted Computing Group , “TCG EK Credential Profile for TPM Family 2.0”,
listed at www.trustedcomputinggroup.org/work-groups/infrastructure/ [November
2016]

101
102
103

[12]
Trusted Computing Group, “TCG Credential Profiles For TPM Family 1.2”
listedatwww.trustedcomputinggroup.org/infrastructure-work-group-tcgcredential-profiles-specification/ [November 2016]

104
105
106

[13]
Trusted Computing Group “TPM Keys for Platform Identity for TPM 1.2”, listed
atwww.trustedcomputinggroup.org/work-groups/infrastructure/[November
2016]

107
108
109

[14]
Trusted Computing Group, “A CMC Profile for AIK Certificate Enrollment”,
listed at www.trustedcomputinggroup.org/work-groups/infrastructure/ [November
2016]

110
111
112
113

[15]
TrustedComputingGroup,
TrustedNetworkCommunication,
www.trustedcomputinggroup.org/work-groups/trusted-network-communications/points to“TNC Resources” at www.trustedcomputinggroup.org/workgroups/trusted-network-communications/tnc-resources/ [November 2016]

114
115

[16]
Open Source Trusted Network Communications software, “StrongSwan”,
https://strongswan.org/ [November 2016]

116
117

[17]
Trusted Computing Group, “TPM 1.2 Protection Profile”,
listedwww.trustedcomputinggroup.org/work-groups/pc-client/ [November 2016]

118
119

[18]
Trusted Computing Group, “TCG EFI Protocol Specification”,
listed at
www.trustedcomputinggroup.org/work-groups/pc-client/ [November 2016]

120
121
122

[19]
Trusted Computing Group, IF-MAP Metadata for ICS Security,
www.trustedcomputinggroup.org/work-groups/trusted-networkcommunications/tnc-resources/ [November 2016]

123
124

[20]
International Society of Automation, ISA-100, https://www.isa.org/isa100/[November 2016]

125
126

[21]
AllSeenAlliance,
The
AllJoynhttps://allseenalliance.org/framework [November 2016]

Revision 22

8
TCG Publishedatlisted at

Framework,

March 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

127
128

[22]
Intel, TPM Software Stack software, https://github.com/01org/TPM2.0-TSS ,[November 2016]

129
130

[23]
IBM,
TPM
SoftwareStack
https://sourceforge.net/projects/ibmtpm20tss , [November 2016]

software,

131
132

[24]
Microsoft,
TPM
SoftwareStack
https://github.com/Microsoft/TSS.MSR [November 2016]

software,

Revision 22

9
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

133

2. Preface

134
135
136
137

This reference document provides (section 3) guidance for countering threats using trusted
platform services, (section 4) guidance for providing trusted platform services, and indicates(section 5) how to calculate the code sizes and working memory resources needed to
implement trusted platform services and use cases.

138
139
140
141
142
143
144
145
146
147

An ideal trusted platform has a stack of security services, each layer either relying upon
services or protections provided by previous layers, or enhancing the services provided byprevious layers. The bottom-most service (that underpins all security and privacy) is theisolation of processes. Arguably the next-most critical layer is a service that provides
random numbers. Then most platforms have a service that protects secrets, and services
that use secrets for identity and confidentiality. More advanced services release secrets tospecific processes, enable reasoning about the trustworthiness of a device, and enableprivacy. This stack of trusted platform security services supports operating systems andapplications, which can continue to use conventional security protocols (to communicate
over the Internet, for example).

Revision 22

10
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

148

3. Implementation Guidance for Countering Threats

149
150

This section briefly describes the use of Trusted Platforms to address the threats indicatedin the titles.

151

3.1

152
153
154
155
156
157
158
159
160

The amount of hardware protection (especially tamper resistance) required by a device
depends on the degree of access by a rogue to the device, the effect of loss of access to theinformation the device provides, and the effect of misinformation. For example, if a device’s
information is low value or low importance, the device probably needs little hardware
protection. If a device is in a secure environment, it probably needs little hardware
protection. On the other hand, a device in an insecure environment might benefit from alimited amount of protection if the device cannot easily be removed for detailed inspection,or might need a sophisticated level of protection if the device contains valuable data andcan be removed to an environment with extensive inspection facilities.

161
162
163
164
165

This document does not include a substantive description of methods for the protection ofdevices from hardware tampering. The intricacies of hardware protection mechanisms are
rarely revealed because that would assist attackers. For the same reason, manufacturers
may advertise just the well-known threats that are addressed by their products, not all
threats known to the manufacturer.

166
167
168

The TCG has published a rigorous Common Criteria Protection Profile [17] for TPMs.
However, the TCG doesn’t currently provide guidance on methods for the hardware
protection of devices, or hardware protection of computation within devices.

169
170
171
172
173
174
175

Some products include tamper resistant computing environments. Many Hardware Security
Modules provide a sophisticated hardware-protected computing environment. Other devices
such as ordinary Personal Computers don’t provide hardware protection when sensitive
data is processed, but may have hardware-protected TPMs that protect small amounts ofdata-at-rest. Some secure microprocessors have hardware-protected processing
environments. A TCG-certified TPM is known to provide a good level of protection from
hardware tampering.

176

3.2

177
178
179

Replay attacks on protocols are hindered if nonces (numbers that are used only once) are
included in protocols. Brute-force attacks on algorithms that use nonces and cryptographic
keys are hindered if nonces and keys are long random numbers.

180
181
182
183

Nonces tend to be used in large quantities and hence almost certainly require a device to
use a random number generator. Cryptographic keys may be provisioned during device
manufacture but generating keys after deployment requires a device to use a random
number generator.

184
185

Random numbers may be generated by initializing a state machine with high entropy data
and using a hash algorithm to whiten the output of the state machine.

186
187
188
189

Devices may be provisioned with high entropy data during manufacture. The device itself
may obtain limited amounts of additional high entropy data by under-sampling a signal
obtained by measuring the device’s environment or the actions of a human user. The device
itself may obtain high entropy data from a reliable external source, albeit this requires a

Tampering with Hardware

Subversion of Algorithms

Revision 22

11
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

190
191
192

communication channel with confidentiality and integrity. Preferably the device itself
obtains additional high entropy data by measuring random physical processes within thedevice.

193
194
195
196
197
198
199
200

One instance of entropy data cannot initialize more than one individual instance of a statemachine (because the act of initializing an individual state machine consumes all theentropy). In other words, different individual devices must be initialized with different
entropy data. Once a state machine has been initialized with entropy data, neither theentropy data nor the state machine’s state must be revealed (because that could enableprediction of the random numbers produced by the state machine). The state machine mustnot be reset (because that would discard any entropy that was provided and could cause
predictable random numbers).

201

Devices should derive nonces and cryptographic keys from a random number generator.

202

Devices should contain a generator that derives random numbers from high entropy data.

203
204

The random number generator in each device should be initialized with a fresh instance ofhigh entropy data.

205

Devices should contain a source of high entropy data.

206
207
208
209
210
211
212
213
214

The NIST define random number generators in Special Publication SP800-90A“Recommendation for Random Number Generation Using Deterministic Random Bit
Generators” [1]. The TCG defines a random number generator for TPMs in the “Random
Number Generator (RNG) Module” section of Part-1 of the TPM2.0 specification [3]. A true
hardware random number generator is an ideal way of generating high quality random
numbers. Some microprocessors have internal random number generators. A TCG-certified
TPM is known to output high quality random numbers via the command
TPM2_GetRandom(). The NIST’s Randomness Beacon [2] is a source of good quality random
data.

215

3.3

216
217
218

Preventing information discovery and information tampering requires isolation of the data
representing the information, isolation of the engine processing the data, and authorization
controls that are enforced by the engine when data is accessed via the engine.

219

Devices should isolate secret data.

220

Devices should isolate the engines that process isolated data.

221
222

Devices may isolate data sent to or from engines that process isolated data, depending upon
the data and the device’s environment.

223
224
225
226
227

Device isolation mechanisms may be physical or logical, albeit the isolation of a mechanism
providing logical isolation ultimately depends on physical isolation. Simple physicalisolation of data is simpler and more nuanced than cryptographic isolation of data, butmore expensive. The TCG’s documents “Multiple Stakeholder Model” [5] and “TPM Mobile
Reference Architecture” [4] discuss some techniques for the isolation of engines.

228
229
230
231
232

Generic communication security mechanisms can be used to isolate data when data is sent
to or from engines that process isolated data. Generic communication security mechanisms
for communication confidentiality and integrity are common knowledge, and are notdiscussed here apart from the communication of passwords, which is discussed in section
3.3.3 “Access Controls” and in section 4.4.4 “Authorization Methods”.

Access to Concealed Data

Revision 22

12
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

233

3.3.1 Physical Isolation of data

234
235

Data can be isolated using a device comprising memory (with a storage capacity as large as
the size of data) and a processing engine (that controls access to the stored data).

236
237
238
239
240

The memory simply stores plain-text data and the processing engine implements aninterface that prevents arbitrary access to the plain-text data. The engine prevents arbitrary
inspection of stored data and prevents tampering with the stored data. The combination ofmemory and engine ensures data persistence, data confidentiality, data integrity, andguarantees erasure when unique data is deleted.

241
242

Devices should be capable of storing at least small amounts of plain-text secret data andshould implement an interface that prevents arbitrary access to that plain-text secret data.

243
244
245

This type of device could comprise semiconductor memory with an interface controlled byprocessor, or might be a spinning magnetic platter with an interface controlled by aprocessor (a conventional Hard Disk Drive, in other words).

246
247
248
249
250
251
252

A chip TPM’s NV Storage usually comprises semiconductor memory with an interface
controlled by a processing engine. It can store a limited amount of data. Space for data isallocated using the command TPM2_NV_DefineSpace(). Ordinary data is written into an
allocated space via the command TPM2_NV_Write(), and data is read from that space via thecommand TPM2_NV_Read(). Other NV Storage commands are intended to enable an
operating system to use NV Storage for monotonic counters, sticky-bit fields, and hashingregisters.

253
254
255
256

Enterprise and Opal Secure Encrypting Drives (SEDs) [7] are mass-storage devices that
automatically encrypt data written to storage and automatically decrypt data read fromstorage. SEDs are capable of storing large amounts of data and are accessed via ordinary
read/write/modify commands.

257

3.3.2 Cryptographic Isolation of Data

258
259
260

Data can be isolated using a device comprising memory (with a storage capacity smaller
than the size of data) and a processing engine (that controls access to the small memory),plus additional memory with a capacity larger than the size of data.

261
262
263
264
265
266
267

The device stores encrypted integrity-protected data in the additional memory. The device
prevents the arbitrary inspection of its internal plain-text data and prevents tampering with
its plain-text data. The combination of the device and additional memory ensures data
confidentiality and data integrity, but does not guarantee data persistence in the additional
memory or erasure of data from the additional memory. Even so, data in additional memory
can reliably “be put beyond use” by erasing those cryptographic keys in the device that arenecessary to decrypt the data in the additional memory.

268

Devices that provide cryptographic isolation of data should:

269
270
271
272
273
274

•
•
•

be capable of storing small amounts of plain-text secret data;
implement an interface that prevents arbitrary access to small amounts of plain-text
secret data; andimplement an interface to store an encrypted integrity-protected version of plain-text
secret data in unprotected memory, and to retrieve that encrypted integrity-protected
data from the unprotected memory.

Revision 22

13
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

275
276

This type of device could comprise semiconductor memory with an interface controlled byprocessor, plus additional memory of any sort.

277
278
279
280
281
282
283
284
285
286
287
288
289

The chip version of a TPM’s Protected Storage Hierarchy usually comprises semiconductor
memory with an interface controlled by a processing engine. It can store an unrestrictedamount of data in additional memory but requires a non-trivial amount of management.
Management software must create the root of an encrypted integrity-protected hierarchy in
the TPM via the command TPM2_CreatePrimary() and then either create (via TPM2_Create())
or import (via TPM2_Import()) a tree of cryptographic decryption keys that is wide enough toaccommodate all users and deep enough to provide the required control resolution. Only
then can user data (passwords and keys) be attached to the hierarchy, using TPM2_Create()or TPM2_Import(). Keys and user data are retrieved from the encrypted integrity-protectedhierarchy via the command TPM2_Load(). Once loaded, keys and user data can be used insigning commands such as TPM2_Sign() or returned to the caller via the command
TPM2_Unseal(). Once loaded, keys and user data can be duplicated to other TPMs or toarbitrary software via the command TPM2_Duplicate().

290

3.3.3 Access controls

291
292

Isolated data is useless unless it can be accessed. Therefore devices should provide aninterface for callers to prove they have sufficient privilege to use or read isolated data.

293
294
295
296
297
298

The best method of proving sufficient privilege depends on device architecture and networkarchitecture. If nothing can observe or tamper with the path between a caller and theengine controlling access to isolated data, a simple password (passed as plain text) issufficient. Otherwise it is prudent to send nonces along with data, sign the combination ofnonce and data with a secret, and pass the HMAC signature but not the secret. If a caller
cannot be online, it may be necessary to use asymmetric digital signatures.

299
300
301
302
303
304
305
306
307
308

TPMs provide a plethora of access control mechanisms including passwords, HMAC,
asymmetric digital signatures, hardware signals (locality) that indicate a level of privilege ina software stack, a logical or hardware signal that indicates the physical presence of aperson, measurements (in Platform Configuration Registers) of the software currently
executing on a device, Boolean comparison with isolated data, and combinations of thesemechanisms. Authorization sessions are described in TPM2 specification [3] Part-1 section“Authorizations and Acknowledgments”. All types of authorization session are started with
the TPM command TPM2_StartAuthSession(). Temporary session secrets can be createdfrom a secret value (a salt) already loaded into the TPM or by using the authorization of a
key or data already loaded into the TPM.

309
310
311

TCG’s “TCG Storage Architecture Core Specification” [8] describes the intended security
architecture of an SED. TCG’s “Storage Interface Interactions Specification” [9] describes
how to manage the security properties of SEDs.

312

3.4

313
314
315
316
317

The behavior of a device is unpredictable unless the device can be identified. Remote
identification of a device requires devices to use secrets to uniquely distinguish between
devices. Hence a device’s identification secret should be concealed from any entity thatmight pretend to be the device. This normally requires a device’s secret to be concealed bothwhen it is stored and when it is used.

318

Secrets inside a component fixed to a device can be used as that device’s secrets.

Device Impersonation

Revision 22

14
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

319
320
321
322

Often the most difficult aspect of device identification is the initialization of an identification
secret. Once one secret has been initialized, that secret can be used to initialize anothersecret. The initialization of all identification secrets should be done in isolated environmentsthat vouch for the properties of the device containing the secret.

323
324
325
326

Often using an identification secret is the easiest aspect of device identification. The type ofidentification secret that is used depends on the trustworthiness of the channel over which
the device connects and the trustworthiness of the destination to which the device
connects.

327
328

Table 1: Attributes of Identification Secrets
Type of Secret

ChannelDestination Channel Data

Plain-text
passwordtrustedtrustedSymmetric key

untrusted trusted

Data (HMAC) signed by medium
symmetric key

Asymmetrickey

untrusted untrusted

Data
signedby highasymmetric private key

Data accompanied
password

Identification
Complexity
by low

329
330
331
332
333

Privacy during identification is impossible if the device must be unambiguously identified.
Privacy during recognition is possible if different identification secrets are used for different
destinations, or if the same identification secrets are used in anonymous or pseudonymous
signing schemes.

334
335
336
337
338
339
340
341
342
343
344

TCG-certified TPMs are known to be suitable for storing device identification secrets for adevice. TPMs are typically initialized with a secret called an Endorsement Key and acertificate that says (words to the effect that) “the device containing this Endorsement Key isa genuine TPM”. Once initialized, TPMs can initialize other secrets by (1) importing secrets
from trusted entities via the command TPM2_Import(), or (2) by creating secrets inside the
TPM via the command TPM2_Create() and then obtaining credentials for the new secretfrom a trusted entity via the command TPM2_ActivateCredential(). The TPM’s authorization
mechanisms use passwords, or symmetric secrets, or asymmetric secrets, and enablesecrets inside a TPM to be used as proxy secrets for the device containing the TPM. TPMs
can perform both ordinary signing schemes and an anonymous or pseudonymous
asymmetric signing scheme called Direct Anonymous Attestation.

345

3.5

346
347
348
349
350

Certain types of malware infection can be prevented by the method called “verified boot” or“secure boot”: when a platform boots, the platform compares a measurement of installedsoftware against an expected value; if the measured value is different from the expectedvalue, the platform replaces and reinstalls the software before executing it; if the measured
value is the same as the expected value, the platform just executes the installed software.

351
352

Trusted platforms provide a more flexible boot strategy: “measured boot” assumes that it
doesn’t matter what software executes on a platform as long as software can’t pretend to be

Subversion by Malware

Revision 22

15
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

353
354
355

other software, and software can’t access secrets belonging to other software. Measured
boot requires both a Root-of-Trust-for-Measurement and Platform Configuration Registers
that are protected from rogues.

356
357
358
359
360
361
362
363

The first software to execute on a trusted platform is called a Root-of-Trust-forMeasurement, which must be trustworthy and trusted because its behavior cannot be
dynamically verified. An RTM measures the second software (whatever it may be) that will
execute on the platform, records the result in a Platform Configuration Register, andexecutes the second software. Then the second software measures the third software(whatever it may be) that will execute on the platform, records the result in a PCR, andexecutes the third software. And so on until either a Trusted OS or Trusted Computing
Base should have been instantiated, but may not have been.

364
365
366
367
368
369
370

Complex devices typically cease recording measurements in PCRs at this level in thesoftware stack. The reason is that it is difficult to deduce the trustworthiness of a device
after multiple applications have executed, unless a Trusted OS or Trusted Computing Basecan isolate applications. If a Trusted OS or Trusted Computing Base has been measured
and applications are isolated, it is sufficient for the Trusted OS or Trusted Computing Baseitself to provide applications’ keys, plus report on the applications that are currently
executing.

371
372

Typically only simpler devices, such as those with a simple OS and just one application that
executes until the device reboots, would record a measurement of that application in a PCR.

373
374

Devices should contain a trusted measurement process called a Root-of-Trust-forMeasurement that is the first software to execute after a device is released from reset.

375
376
377

Devices should contain one or more Platform Configuration Registers (PCR) in which an
RTM and other measurement agents can record measurements of software before thesoftware is executed.

378
379
380
381

If the value in a PCR is subsequently signed by a platform’s cryptographic identity, thesigned PCR value constitutes evidence to a third party of whatever OS or hypervisor exists
in the platform. The third party can inspect the signed PCR value and decide whether it
indicates that the platform is in a trustworthy state before interacting with the platform.

382
383

Devices should contain trusted services that use the values in PCRs as evidence of thesoftware executing on the device.

384
385
386
387
388
389
390

If the value in a PCR is compared by a TPM with a value stored with a secret, the TPM canensure that only the intended software has access to that software’s secrets. This is aprocess called “sealing”, which is exclusive to trusted platforms: when a secret (a signing
key or password) is given to the TPM to be protected by the TPM, the caller can state thePCR values that must exist when the secret is used; if current PCR values do not match thevalues stored with a secret, the TPM refuses to allow the caller to use the signing key, or
refuses to reveal the password to the caller.

391
392
393

Devices should contain trusted services that use the values in PCRs to prevent secrets
being used by inappropriate software, or prevent secrets being revealed to inappropriate
software.

394

TPMs provide PCRs and trusted functions that use those PCRs, including:395•

TPM2_Extend() and TPM2_Event() that record measurements in PCRs,

396•

TPM2_PCR_Read() and TPM2_Quote() that report the current value of PCRs,

Revision 22

16
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

397•

TPM2_Create() that associates secrets with PCR values,398•

TPM2_Sign() that determines whether secrets can be used when signing data, and399•

TPM2_Unseal() that determines whether secrets can be revealed outside the TPM.

Revision 22

17
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

400

4. Implementation Guidance for Trusted Platform Services

401

4.1

402
403

Many devices use cryptography to protect data that persists when the device is switched off.
All devices use cryptography to protect communications over shared networks.

404
405
406

If devices use cryptography, devices should use standardized cryptographic algorithms.
Private cryptographic algorithms may be safe but (unless one has expert advice) it is safer touse cryptography that has been studied by the cryptographic community.

407
408
409
410
411

Devices should use cryptographic algorithms in only the ways those algorithms aredesigned to be used. It may be tempting to modify cryptographic algorithms or use them in
unusual ways, but one might break an assumption that the algorithms depend upon for
their security. For example, one should not modify the iterative process in a block
encryption algorithm, or use a mask function as an encryption function.

412
413
414
415
416
417

Devices should be cryptographically agile, meaning that devices should have the ability touse different cryptographic algorithms for each task. Without cryptographic agility, a device
might be unsuitable for both mass markets and for specialist markets, or a device could be
rendered obsolete overnight when a cryptographic algorithm is found to be flawed.
Cryptographic agility requires processes to use data structures that name the specificalgorithm which will be used with the rest of the data in that structure.

418

4.2

419
420
421
422

Devices should isolate processes from each other. In particular, if some processes are notintended to access particular sensitive data, devices should isolate the processes that are
intended to access those particular sensitive data from processes that have no legitimate
right of access.

423
424
425
426
427
428
429

While isolation will in principle protect any amount of sensitive data, isolation must be
physically enforced when a platform is switched off, and isolating hardware may be
expensive. In practice, therefore, isolating hardware can store only a bounded amount ofsensitive data. The cost of isolating hardware is minimized, and there is still (in principle)
no bound on the amount of stored data, if isolating hardware protects just a single
encryption key, and that key is used to encrypt other keys and data that are held in nonisolating hardware (non-protecting hardware).

430
431
432
433
434
435

Isolation prevents processes from interfering with each other, or misusing secrets, and isarguably the most substantial and onerous implementation aspect of a trusted embedded
platform. Dynamic isolation mechanisms include sand boxes, visualization, and trusted
execution environments. The only static isolation mechanism is physical separation. The
TCG’s documents “Multiple Stakeholder Model” [5] and “TPM Mobile Reference Architecture”[4] discuss isolation techniques, but do not define them.

436
437
438
439
440
441
442

The functionality of a single function device may be physically isolated from other functions,but processes within that device that are intended to access secrets should still be isolated
from processes that are not intended to access those secrets. Unless there is some way of
isolating the process that uses a secret from a process that shouldn’t use that secret, thedevice cannot ensure that secrets are properly used. If nothing else, trusted platform
primitives and facilities must be isolated from processes that are not trusted platform
primitives and facilities. For example, TPMs must be isolated from the rest of a device.

Cryptography

Isolation

Revision 22

18
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

443
444
445
446

Depending on the degree of security that is provided by a given method of isolation, TPMs
may be physically isolated or logically isolated. The TCG’s documents “Multiple Stakeholder
Model” [5] and “TPM Mobile Reference Architecture” [4] discuss isolation for TPMs in mobile
devices. TCG-certified TPMs are known to provide a robust degree of isolation.

447

4.3

448
449
450
451
452

If a device generates cryptographic keys or nonces, the device should have a Random
Number Generator engine that produces non-deterministic numbers. This is because thesecurity of most cryptographic algorithms is critically dependent upon numbers whose
values cannot be predicted, even when other numbers supplied by the same source are
known.

453
454

The TPM2_GetRandom() command of a TCG-certified TPM is known to provide good quality
random numbers.

455
456

Methods of generating random numbers are described in publications of standardization
organizations, such as the NIST’s “Recommendation SP800-90A” [1].

457

4.4

458
459

Trusted platforms provide three types of services to protect stored data. They differ in theamount of data that can be stored and their ability to prevent or facilitate erasure.

460

4.4.1 Bounded Storage

461
462
463

The amount of data that can be stored in Protected Bounded Storage is limited by the sizeof isolated memory in a device, and there may be limits on the size of individual pieces of
data.

464
465
466

Protected Bounded Storage uses isolating hardware to guarantee data persistence,
confidentiality, and integrity, with guaranteed erasure if the data has not been duplicatedelsewhere.

467
468
469

Protected Bounded Storage should comprise isolated semiconductor memory. A Protected
Bounded Storage service should ensure data persistence, confidentiality, and integrity, as
well as guaranteeing erasure if the data has never been copied.

470
471
472

The TPM’s NV (Non Volatile) Storage service stores a limited number of data objects andprovides them with access controls. The service ensures persistence, data confidentiality,
data integrity, and guarantees erasure when unique data is deleted.

473

4.4.2 Mass Storage

474
475

The amount of data that can be stored in Protected Mass Storage is limited by the size ofmemory in a mass storage drive.

476
477
478

Protected Mass Storage uses isolated hardware and cryptography to guarantee data
persistence, confidentiality, and integrity with guaranteed erasure if the data has not been
duplicated elsewhere.

479
480

Protected Mass Storage should comprise enhanced Hard Disk Drives, CD drives, etc.
connected to a device. A Protected Mass Storage service should ensure data persistence,

Random Number Generator

Protected Storage

Revision 22

19
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

481
482

confidentiality, and integrity, as well as guaranteeing erasure if the data has never been
copied.

483
484
485
486
487

One example of Protected Mass Storage is a mass-market Secure Encrypting Drive (SED).
SEDs automatically encrypt data written to storage and automatically decrypt data readfrom storage, and enforce access controls over both drive management services and dataretention services. The TCG has published SED specifications [7]. The Storage Security
Industry Forum has published the white paper “SSIF Guide to Data-At-Rest Solutions” [10].

488

4.4.3 Unbounded Storage

489
490

There is no inherent limit on the amount of data that can be stored in Protected Unbounded
Storage, although there may be limits on the size of individual pieces of data.

491
492
493

Protected Unbounded Storage uses isolating hardware and cryptography to guarantee data
confidentiality and detection of data alteration, but does not guarantee data persistence,and cannot guarantee data erasure.

494
495
496
497

Protected Unbounded Storage should comprise isolated semiconductor memory for small
amounts of keys and sensitive data, plus non-isolated memory for unrestricted amounts ofkeys and sensitive data. A Protected Unbounded Storage service should ensure data
confidentiality and integrity.

498

4.4.3.1

499
500
501
502
503
504
505

If a device stores copies of one or more cryptographic keys or sensitive data objects in a
non-isolating environment, devices should provide cryptographic confidentiality andintegrity protection for those keys and sensitive data. Encrypting keys should be encryptedby another key and form a branch of a tree of encrypted keys whose root key is permanently
plain-text and isolated by hardware from processes that have no legitimate right to accessthe root key. Devices may store plain-text copies of other encrypted keys and data in
isolated hardware, in order to provide faster access to those keys and data.

506
507
508
509
510
511
512

TPMs provide Storage Hierarchy functionality whose root key is permanently plain-text andisolated from processes that should not access the root key. The TPM’s Storage Hierarchy
provides confidentiality and integrity protection for encrypted keys and data held outside
the TPM in a non-isolating environment. This functionality enables plain-text copies of keys
and data to be temporarily loaded within the TPM’s isolation boundary, and used. The
TPM’s Storage Hierarchy also includes means to store a small number of plain text copies ofencrypted keys and data within the TPM’s isolation boundary, and use them.

513

4.4.3.2

514
515
516
517
518
519
520

If a device is single tasking but it is preferable that the device appears to be multi-tasking,the device should provide replay protection plus cryptographic confidentiality and integrity
protection for sensitive data-in-use stored in a non-isolating environment. The replay
protection method should ensure that out-of-date copies of data-in-use are rejected. The
cryptographic confidentiality method should ensure that only the device can obtain a plaintext copy of the data-in-use. The cryptographic integrity protection should ensure that only
legitimate data-in-use will be interpreted by the device as data-in-use.

521
522

TPMs provide Storage Hierarchy functionality that enables plain-text copies of keys anddata to be temporarily safely stored outside the TPM’s isolation boundary.
Revision 22

Protected Storage Hierarchy

Multi-tasking

20
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

523

4.4.3.3

524
525
526

If it is preferable that a device is able to export sensitive keys and data to other devices, thedevice should provide cryptographic confidentiality and integrity protection for thatsensitive data before it leaves the device’s protection.

527
528
529

If it is preferable that a device is able to import sensitive keys and data from other devices,the device should accept only sensitive data that has cryptographic confidentiality andintegrity protection.

530
531
532

TPMs provide Storage Hierarchy functionality that enables plain-text copies of keys anddata to be encrypted and integrity protected such that the plain-text keys and data can berecovered using a specific encryption key.

533

4.4.4 Authorization methods

534
535

If it is preferable for a device to restrict the usage of keys or data objects, devices should
enforce access controls that apply to those keys and data.

536

4.4.4.1

537
538

If a device can prevent a man-in-the-middle from seeing authorization information sent to adata store, the device should allow authorization information to be a plain-text password.

539
540
541

Passwords are useful for commands sent from a device’s Trusted Computing Base, because
the Trusted Computing Base is presumably able to prevent processes from inspecting data
sent to the data store.

542
543

TPMs provide Storage Hierarchy functionality that enables plain-text passwords to be used
for access control. Passwords are sent as plain-text to the TPM.

544

4.4.4.2

545
546
547
548

If a device can’t prevent a man-in-the-middle from seeing authorization information sent toa data store, the device should allow authorization information comprising HMAC
signatures over data attached to nonces sent to the data store and nonces sent from thedata store. A plain-text password should be the HMAC signing key.

549
550

HMAC signatures are useful for commands sent from remote entities, which must be online because each exchange of authorization information signs a new nonce.

551
552
553

TPMs provide Storage Hierarchy functionality that enables plain-text passwords to HMACsign requests and responses together with a nonce from the caller and a nonce from the
TPM.

554

4.4.4.3

555
556

A device may provide enhanced authorization methods to enable combinations of privileges,delegation of privilege, and restricted privileges.

557
558
559
560

TPMs provide Storage Hierarchy functionality with Enhanced Authorization (EA). EA allows
Boolean combinations of authorization using passwords, HMAC signatures, and asymmetricsignatures, as well as authorization comparisons with counter values, timer values anddata values stored on the TPM.

Revision 22

Duplication of Stored Objects

Password

HMAC

Enhanced

21
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

561

4.5

562
563
564

A device’s attributes are its name (a label) and its characteristics (such as its purpose,manufacturer, isolation mechanisms, method of generating random numbers, storage
mechanisms, and its stored keys and data).

565
566
567
568

Device identification is the process of disclosing a device’s attributes. Unless a device can becompletely inspected, device identification requires a trusted entity to vouch for a device’s
attributes by signing a credential comprising a description of some (or all) of the device’s
attributes.

569
570
571
572
573

Some trusted entity should vouch for a device by signing a credential comprising thedevice’s attributes. Any type of cryptographic signature scheme may sign a credential
comprising a description of device attributes. For unambiguous identification, nothing but
the trusted entity should sign credentials with the key that signs credentials comprising adescription of a device’s attributes.

574
575
576
577

Often a trusted entity cannot vouch for all of a device’s attributes because some attributes(such as keys and data) are generated after the trusted entity vouches for the device. Unlessa trusted entity vouches for all of a device’s attributes, the attributes signed by the trusted
entity should include an endorsement key stored by the device.

578
579
580
581
582

If all entities other than the device are trusted not to sign data purporting to come from thedevice, the endorsement key may be a symmetric key. Otherwise, the endorsement key inthe credential should be the public component of an asymmetric key whose privatecomponent is known only to the device. If a device does not require privacy, theendorsement key should be a signing key.

583
584
585
586
587
588
589
590

The TCG specifies [11][12] Endorsement Credentials that vouch for a TPM’s attributes,
albeit the TPMs in these specifications have an encrypting Endorsement Key. TCG
Endorsement Credentials are signed by some trusted entity (typically the TPM’s
manufacturer) and include the public component of an Endorsement Key whose privatecomponent is unique to a TPM. If these Endorsement Keys were signing keys, the specified
TPM could sign different types of attribute credential using the Endorsement Key via the
TPM commands TPM2_Certify(), TPM2_CertifyCreation(), TPM2_GetSessionAuditDigest(),
TPM2_GetTime(), and TPM2_NV_Certify().

591
592
593
594
595
596

A device may itself vouch for some or all of its attributes (a stored key or data object, forexample) by signing a credential comprising those attributes, using another signing key thatis itself an attribute in a credential issued by a trusted entity. Nothing but the device should
use the signing key to sign credentials. The signing key should be stored in Protected
Bounded Storage or Protected Mass Storage if the key cannot be replaced. Otherwise thekey should be stored in Protected Unbounded Storage.

597
598
599

TPMs
can
use
the
TPM2_GetSessionAuditDigest(),protected signing key.

600

4.5.1 Signature verification

601
602
603

If a device must identify itself or other entities using symmetric signatures, the device
should be able to sign an HMAC signature using a password. If the signature is crucial toproper device operation, the password should be stored in Protected Bounded Storage or

Device Identification

Revision 22

commands
TPM2_Certify(),
TPM2_CertifyCreation(),
TPM2_GetTime(), and TPM2_NV_Certify(), with any

22
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

604
605

Protected Mass Storage. Otherwise, the password should be stored in Protected Unbounded
Storage.

606
607
608
609
610

If a device must identify itself or other entities using asymmetric signatures, the device
should be able to verify an asymmetric signature using a public key. If the signature is
crucial to proper device operation, the public key should be stored in Protected Bounded
Storage or Protected Mass Storage. Otherwise the public key MAY be stored in unprotected
memory.

611

The TPM verifies signatures using the TPM command TPM2_VerifySignature().

612

4.5.2 Signing

613
614
615
616
617

If a device must be identified using symmetric signatures, the device should be able togenerate a symmetric HMAC signature using a password. If the signature is crucial toproper device operation, the password should be stored in Protected Bounded Storage orProtected Mass Storage. Otherwise, the password should be stored in Protected Unbounded
Storage.

618
619
620
621
622

If a device must be identified using asymmetric signatures, the device should be able togenerate an asymmetric signature using a private key. If the signature is crucial to proper
device operation, the private key should be stored in Protected Bounded Storage orProtected Mass Storage. Otherwise, the private key should be stored in Protected
Unbounded Storage.

623
624
625
626

The TPM signs arbitrary data using the TPM commands TPM2_HMAC() for symmetricsignatures and TPM2_Sign() for asymmetric signatures. The TPM signs credentials with the
TPM commands TPM2_Certify(), TPM2_CertifyCreation(), TPM2_GetSessionAuditDigest(),
TPM2_GetTime(), TPM2_NV_Certify().

627

4.6

628
629
630

A device may or may not need privacy when it communicates. Whether a device needs
privacy depends on the purpose of the device, what information is revealed to other entities,
and what other entities could do with that information.

631
632
633
634
635

Two aspects of device identity are privacy sensitive. The first aspect is the ability to
distinguish a device from other devices: in other words, whether a device’s attributes
include something unique to that device. The second aspect is the ability to distinguish asigned credential from other signed credentials: in other words, whether the same
cryptographic key is used to verify all identity credentials.

636

4.6.1 Privacy during identification

637
638
639
640

For privacy during identification, a device should not sign a credential comprising adescription of attributes that uniquely distinguish the device; similarly, the credential(issued by a trusted entity) comprising the description of the verifying key should notinclude a description of attributes that uniquely distinguish the device.

641
642
643

Privacy during identification is often impossible because many device attributes are uniqueto a device but must be disclosed. This may not be an issue. Usually the real privacy
concern is privacy during recognition.

Privacy Enhancements

Revision 22

23
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

644
645
646
647
648
649
650

The TCG specifies [11][12] Endorsement Credentials for TPMs with an encrypting
Endorsement Key. The encrypting Endorsement Key is used in a privacy-preserving (moreaccurately, repudiation-preserving) protocol [13][14] with a Certification Authority to obtaina privacy-preserving credential [12] for an Attestation Key (sometimes called an Attestation
Identity Key) protected by the TPM, which the TPM can use to sign [13] credentials. The
privacy-preserving property of an Attestation Key credential is that it certifies that the key
belongs to a genuine TPM but does not uniquely distinguish the TPM.

651

4.6.2 Privacy during recognition

652
653

Device recognition is the process of matching a device’s identity against an existing set of
identities.

654
655
656
657
658
659
660

The same credential signed with the same key using an ordinary cryptographic signaturescheme enables a device to be recognized, because the verification key and the verification
key credential are always the same. An anonymous cryptographic signature scheme
prevents a device being recognized, because the verification key and its credential arealways different. A pseudonymous cryptographic signature scheme enables a device to berecognized on multiple occasions by separate entities, because the verification key and its
credential are always the same for the same entity but different for different entities.

661
662
663
664

To prevent recognition, a device should use a different signing key every time it signs acredential. To permit separate recognition by separate entities, a device should use thesame signing key when it signs a credential for the same entity but use different signingkeys when it signs credentials for different entities.

665
666
667
668
669

TPMs can protect an unrestricted number of signing keys whose credentials have been
justified with a TPM’s Endorsement key. Since an ordinary cryptographic signature with asingle key does not protect privacy during recognition, the TCG’s TPM credential
specifications [11][12] deliberately specify an encrypting Endorsement Key instead of asigning Endorsement Key.

670
671
672

Alternatively, to prevent recognition a device should use the same signing key in ananonymous signing scheme; or, to permit separate recognition by separate entities, a device
should use the same signing key in a pseudonymous signing scheme.

673
674
675
676
677
678
679

TPMs support a cryptographic signing scheme called Direct Anonymous Attestation (DAA)
which can create anonymous or pseudonymous signatures. A DAA signature requires a
TPM2_Commit() command followed by an ordinary ECC signature created by one of theTPM’ssigningcommands:
TPM2_Sign(),TPM2_Certify(),
TPM2_CertifyCreation(),
TPM2_GetSessionAuditDigest(), TPM2_GetTime(), TPM2_NV_Certify(). The disadvantages of
DAA are that it is not widely implemented and it requires considerably more processing
than ordinary cryptographic signing schemes.

680

4.7

681
682

Trusted platforms provide services that enable device behavior to be used as authorizationto access secrets, or authorization to access networks and other resources such as servers.

683
684
685
686

The fixed behavior of fixed functionality devices can be inferred from fixed identities. Other
types of devices have multiple functions, or are reprogrammable, or can be upgraded. The
variable behavior of these devices can be inferred from a variable identity, specifically an
identity containing an indication of the software currently executing on the device.

Trust Enhancements

Revision 22

24
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

687
688
689
690
691
692
693
694
695

Trusted platforms are distinguished by a permanent function called a Root of Trust for
Measurement (RTM) that performs the first operation immediately after device initialization.
An RTM measures the next operation that will be performed by the platform, and records
the measurement in a safe place where it can be read but can’t be altered. The
measurement can be used as a proxy of initial device behavior. If the first operation
includes a measurement agent that measures the second operation that will be performedby the platform, and records the measurement in a safe place where it can be read but can’tbe altered, then that second measurement can also be used as a proxy of device behavior.
Obviously, the second operation can include another measurement agent, and so on.

696
697
698
699
700

Trusted platforms should contain a Root of Trust for Measurement and may containmeasurement agents. The RTM and any measurement agents measure software before it
executes and record the measurements by extending measurements into Platform
Configuration Registers (PCRs). The values of PCRs should be used as predictors of thedevice’s behavior.

701
702
703
704
705
706

TCG specification “TCG EFI Protocol Specification” [18] for a PC-Client platform serves toillustrate how an RTM works. TCG specification “Trusted Platform Module Library 2.0” [3]defines a TPM that contains Platform Configuration Registers and can use PCR values forsealed storage (using device behavior as authorization to access secrets) and for attestation(using device behavior as authorization to access networks and other resources such asservers).

707

4.7.1 Sealed Storage

708
709
710

Sealed storage is particularly useful for preventing secrets being revealed to the wrong
software, or preventing secrets being used by the wrong software, especially when a device
boots.

711
712
713
714
715

A service on a device might have put sensitive data in protected storage. If that service canbe replaced, the sensitive data should be protected from replacement services that have nolegitimate right of access. If there is more than one way that a device might provide aservice, the sensitive data should be protected from the versions of the service that have nolegitimate right of access.

716
717
718
719
720
721
722
723
724

Protected bound storage and protected unbound storage have an authorization method
called unsealing, which precisely verifies which service requested access to sensitive data inprotected storage, or requested the use of sensitive data by protected storage. Whensensitive data is sealed to a version of a service, the effect is that version of that service
must be executing on the device before the sensitive data will be revealed by protectedstorage or can be used by protected storage. Sealing is particularly useful for revealing
sensitive data to whatever operating system or hypervisor has booted on a device, since it isnormally the OS or hypervisor that protects sensitive data once it has been released fromprotected storage.

725
726
727
728
729
730

A TPM seals by storing sensitive data with a measurement of the software that has
legitimate access to that sensitive data. When a request is made to reveal a sealed data
object, a TPM compares its PCR measurements of the current software environment withthe measurements stored with the data object. If the measurements match, the TPM reveals
the data object. Similarly, when a request is made to use a sealed cryptographic key, a TPM
compares its PCR measurements of the current software environment with the

Revision 22

25
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

731
732

measurements stored with the key. If the measurements match, the TPM allows the key tobe used.

733

4.7.2 Attestation

734
735

Attestation is particularly useful for helping a third party, such as a network, determine
whether a device will behave as anticipated.

736
737
738
739

A service on a device might have access to a network. If that service can be replaced, thenetwork should be protected from replacement services that have no legitimate right ofaccess. If there is more than one way that a device might provide a service, the network
should be protected from the versions of the service that have no legitimate right of access.

740
741
742
743
744

Protected bound storage and protected unbound storage have a signing method called
attestation, which reveals the software environment currently on the device. Attestation isparticularly useful for revealing which operating system or hypervisor has booted on a
device, since it is normally an OS or hypervisor that enforces a device’s characteristics andreports what applications are executing.

745
746
747
748

A TPM attests by including a PCR measurement of the current software environment insigned data. When a request is made to access a network, a router or server (for example)
compares the signed measurement with the expected measurement. If the PCR values
match, the device is admitted to the network.

749

4.8

750

In order to preserve confidence in a device, a secure update process should:

Secure Device Updates

751•

Ensure that only genuine updates can be applied (obviously).

752•

Have a rollback mechanism in case the update fails (obviously).

753
754
755

•

Verify that the device’s legitimate administrator has given timely permission for an
upgrade to be implemented. This minimizes loss of service while the upgrade isperformed.

756
757
758
759

•

Preserve existing sensitive data unless the device’s legitimate administrator expressly
gives permission for existing sensitive data to be erased. This is important because
the loss of some sensitive data, such as cryptographic keys, may irreversibly prevent
access to other important data.

760
761
762

•

Invalidate any credentials, particularly those of cryptographic signing keys that wereinvalidated by the upgrade. This may be the case when an upgrade significantly
changes a device’s functionality or security properties.

763
764
765

•

Preserve the manufacturer’s means of issuing endorsement credentials for the device,unless the device’s legitimate administrator expressly gives permission. Otherwise
the device may become incapable of demonstrating that it is a genuine device.

766
767
768
769
770

If one successfully installs the newest update available but discovers that the resultant
device is flawed, one may need to revert to an older version of the device. One need notinstall an old update if an old-but-secure update can be promptly reissued, so it becomesthe newest update. Otherwise, an old update may be installed if the update process obtains
permission from a person with physical access to the device, assuming rogues do not have

Revision 22

26
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

771
772

physical access to the device. It is unwise to install an old update that creates devices witha publicly known vulnerability.

773
774

The section “Field Upgrade Mode” of TCG specification “Trusted Platform Module Library
2.0” [3] describes a method of securely updating a TPM.

775

4.9

776

Devices should use standardized software interfaces.

777

4.9.1 Protected Storage Software

778
779

Protected storage software reduces the amount of knowledge and effort needed to accessand use sensitive data.

780
781

Devices that host software applications should provide protected storage software thatmanages protected storage, and provides a convenient interface to protected storage.

782
783
784
785
786
787

When protected storage software is essential for correct platform behavior, protected storage
software must be properly designed, implemented, and protected. However, protectedstorage software doesn't need to be trusted because all it does is manipulate secrets inside
a TPM, which protects those secrets until/unless secrets are revealed to platform software.
(Platform software that receives secrets obviously should be correctly designed,
implemented, protected, and trustworthy.)

788
789
790
791
792

The Trusted Computing Group has published TPM Software Stack (TSS) specifications [6].
This TSS manages the TPM and provides high level TPM interfaces for applications.
Examples of protected storage software have been published, by IBM [23], Intel [22], andMicrosoft [24], for example. Some of these software libraries are implementations of the TCG
TSS specifications and some are not.

793

4.9.2 Conventional Security Software

794
795

If a device has sufficient resources, the device should use conventional security software
when necessary and appropriate.

796
797
798
799
800
801
802
803
804

Applications, operating systems and hypervisors often access secrets via conventional
software interfaces such as MS-CAPI and JAVA-CSP, and use secrets in conventional
internet security protocols such as PKCS. Trusted platform services augment such
conventional security software, albeit the resultant increase in protection is accompanied byincreased complexity. The reasons are that authorization services are required to accesssecrets in protected storage, trusted platform duplication protocols are required to duplicate
secrets stored in protected storage, and protected storage must be managed. PC-Client andserver platforms commonly use trusted platform services to improve the protection provided
by conventional security software.

805

4.9.3 Attestation Software

806
807

If a device has sufficient resources and supports attestation, the device should use
protocols that enable the device to participate in network attestation services.

Device Software

Revision 22

27
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

808
809
810

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

The TCG’s “Trusted Network Communications (TNC) Work Group” has defined standards[15] for endpoint integrity, and can use attestation provided by a TPM. Some TNC
specifications have been implemented as StrongSwan [16] open-source software.

Revision 22

28
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG

811

5. Cryptographic resources used by Trusted Platforms

812
813
814
815
816
817

Cryptographic primitives are needed to implement trusted platform services. Trusted
platform services implemented as software require executable code, memory and aprocessing engine. Given a library of cryptographic primitives and their RAM and ROM
requirements, one may use the tables in this section to estimate how much RAM and ROM
is required to implement in software a trusted platform service or trusted computing use
case.

818
819
820
821
822

Some constrained devices have very limited memory resources and consequently won’t beable to implement trusted platform services and use cases unless the device has hardware
cryptographic accelerators (for SHA, AES, RSA, ECC, etc.). Hardware accelerators have theadditional advantage of stronger process isolation and tamper-resistance than software.
Hardware Roots of Trust provide substantially stronger protection than software alone.

823

Table 2 summarizes the cryptographic primitives used by trusted platforms.

824
825

Table 2: Cryptographic Primitives
Cryptographic Primitive(p1) Random Number Generator (RNG)(p2) Protected persistent data store(p3) Hash(p4) Extend(p5) Encrypt/decrypt

Symmetric cryptography(p6) HMAC(p7) Encrypt/decrypt

Asymmetric cryptography(p8) Sign/verify(p9) Direct Anonymous Attestation
826
827
828

Table 3 illustrates which cryptographic primitives are used to implement specific trusted
platform services.

829
830

Table 3: Cryptographic Primitives used to implement Trusted Platform services
Trusted Platform service

Cryptographic
primitives(s1) Isolation (prevent processes from interfering with each other, or fromusing resources belonging to other processes)none(s2) Random Number Generator (a source of unpredictable numbers)

p1

Revision 22

29
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Protected Unbounded Storage(Store an unrestricted number of copies of
one or more keys or data objects withaccess controls and confidentiality andintegrity protection. A limited number ofstored keys and data objects can haveguaranteed
erasureandpersistenceprotection)(s3) Storage Hierarchy of p1 p2 p3 p5 p6
keys and data(asingleprotected
persistent plain-text key
provides access to anunrestricted number ofprotected keys or data
objects)(s4) Temporary cachep1 p5 p6

(enables multi-threading)(s5) Key and data object p5 p6 p7
duplication(exports and imports keys
and data objects)
Authorization methods(s6) password

p3(recognize a local Trusted
Computing Base)(s7) HMAC

p1 p3 p6

(recognize remote entities)(s8) enhanced(authorization via a richcombination of methods)(s9) TPM Software(software that manages trusted functions provided by a TPM, andprovides a convenient interface to those trusted functions, but doesn’t
itself need to be trusted)(s10) Protected Bounded Storage

p1 p2 p3 p4 p6p8
p1 p3 p4 p5 p6
p7 p8 p9

p2

(Store a limited number of copies of one or more data objects with access
controls, confidentiality, integrity, an erasure guarantee, and persistenceprotection)(s11) Protected Mass Storage(a storage device capable of protecting potentially large amounts of dataat-rest)
Basic signature services

Privacy enhanced signing

Revision 22

p1 p2 p3 p4 p5
p6 p7 p8(s12) Signature verificationp8(s13) Sign datap8(s14) Sign credentials

p8

(s15)
Anonymous
pseudonymous signing

30
TCG Publishedor p9

March 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG(create a signature)(s16)
Obtainprivacy p7
enhanced credentials froma third party(vouch for the attributes ofany key or data object)(s17) Internet security Protocols

p1 p3 p5 p6 p7
p8

PKCS
MS-CAPI
JAVA-CSP(conventional security software)

Trust enhancements for storage and (s18) Root of Trust for p3
signature services on reprogrammable Measurement
devices(An engine that measures(Protect keys and data objects from software and records thoseunintended software.
measurements in PCRs)
Enable remote parties to verify the software (s19) PCRs and “enhanced” p2 p3 p4
executing on a device)authorization(Confine the usage ofstored keys and data
objects
accordingtomeasurements of software)
Trusted signing(s20)
Endorsement p1 p2 p3 p5 p6
Hierarchy of keys
(Protect keys that vouchthatthedeviceistrustworthy)(s21)
Obtaintrusted p7
credentials from a thirdparty(vouch for the attributes ofany key or data object)

Enhanceddevicessigninginreprogrammable (s22) sign PCRs

(Perform attestation health checks)

p2(vouch for measurementsof software)(s23) secure software/firmware update mechanism

p3 p5 p7 p8(safely modify or update a device)(s24) TNC protocols

Revision 22

unknown

31
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0(network performs health checks)
831
832
833
834
835
836
837

Table 4 lists some common uses of trusted platforms, the mandatory services needed tosupport them, and the optional services needed to support them. Use cases are collected
together if they require the same services. More complex use cases rely upon simpler use
cases, and hence the services for more complex use cases are supersets of the services for
simpler use cases. For convenience and simplicity, Table 4 also indicates the primitives
required by a given set of services.

838
839

Table 4: Common Uses for Trusted Platform services
Use case

Cumulative
use cases

Cumulative mandatory Cumulative
optional
services (and supporting services (and supporting
cryptographic primitives) cryptographic
primitives)(u1) Can you protect yourself
against hardware tampering?

u1 to u2

s1

none

u1 to u3

s1 s2

none

(u2)
Can
you
protect
computation from tampering(u3) Can you safely engage incryptographic protocols?

(p1 p3 p4 p5 p6 p7 p8p9)(u4) Can you protect theconfidentiality of data fromtampering?

u1 to u7

s1 s2 s3 s6 s8 s9

s4 s5 s7 s10 s11(p1 p2 p3 p4 p5 p6 p7 (p1 p2 p3 p4 p5 p6 p7
p8 p9)p8)(u5) Can you protect integrityof data from tampering?
(u6) Can you maintain theconfidentiality, integrity, andavailability of data at rest?
(u7) Can you prepare a deviceforresaleordecommissioning?

u1 to u10(u8) Who are you?
(u9) Can you support common
models of provisioning?

(p1 p2 p3 p4 p5 p6 p7 (p1 p2 p3 p4 p5 p6 p7
p8 p9)
p8 p9)(u10) Can you be managed
remotely?

u1 to u15(u11) Can I trust you?
(u12)
Can
you
protect
computation from tampering
(u13)
Can
you
maintain evidence?

securely(u14) Can you detect malware
infections?

Revision 22

s1 s2 s3 s6 s8 s9 s12 s4 s5 s7 s10 s11 s15
s13 s14 s17 s20
s16

s1 s2 s3 s6 s8 s9 s10 s4 s5 s7 s10 s11 s15
s12 s13 s14 s17 s18 s19 s16
s20 s21 s22 s24(p1 p2 p3 p4 p5 p6 p7(p1 p2 p3 p4 p5 p6 p7 p8 p9)
p8 p9)

32
TCG PublishedMarch 13, 2017

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

Copyright ©2017 TCG(u15) Can you maintainsecrets while infected?
(u16) Can you stay healthy?

u1 to u17

s1 s2 s3 s6 s8 s9 s10 s4 s5 s7 s10 s11 s15
s11 s12 s13 s14 s17 s18 s16
s19 s20 s21 s22 s23 s24(p1 p2 p3 p4 p5 p6 p7(p1 p2 p3 p4 p5 p6 p7 p8 p9)
p8 p9)

u1 to u18

s1 s2 s3 s6 s8 s9 s10 s4 s5 s7 s10 s11 s15
s11 s12 s13 s14 s17 s18 s16
s19 s20 s21 s22 s23 s24(p1 p2 p3 p4 p5 p6 p7(p1 p2 p3 p4 p5 p6 p7 p8 p9)
p8 p9)(u17) Can you recover from
infections?

(u18) Can You Secure Legacy
Hardware?

840

Revision 22

33
TCG PublishedMarch 13, 2017

Copyright ©2017 TCG

841

TCG Guidance for Securing Resource-Constrained Devices
Version 1.0

6. Appendix

842
843
844
845
846

This appendix introduces overlay networks, which provide perimeter security for devices
that are connected via that overlay network. Even so, if devices connected by an overlay
network have no inherent security, a successful attack on one device may still enableattacks on other devices.

847

6.1

848
849
850
851

An overlay network may be able to plug gaps in the protection of devices that have an
incomplete set of trusted platform services: if a device can identify itself and provide some
simple attestation, a gateway in the overlay network might be able to provide additional key
provisioning, secure communication, software update, and other trusted platform services.

852
853

Therefore devices should be provided with a cryptographic identity and be capable ofattestation.

854
855

One definition of an overlay network is that given in the International Society ofAutomation’s ISA-100 [20].

856
857
858
859
860

The TCG’s “IF-MAP Metadata for ICS Security” specification [19] describes an overlay
network intended to facilitate “secure deployment and management of large-scale industrial
control systems by creating virtual OSI layer 2 and/or layer 3 overlay networks on top of
standard shared IP network infrastructure - particularly (though not necessarily) TNCcompliant IP network infrastructure”.

861
862
863
864
865
866
867
868
869
870
871

The AllJoyn overlay network [21] is a derivative of the Linux D-bus. AllJoyn devices can bedirectly plugged into a WindowsTM platform or connected to the same wired or wirelessnetwork as a Windows platform. AllJoyn routers on a Windows platform use broadcasts toshare information about provider devices and consumer devices. The device directory is
dynamic, so devices can come and go. The router establishes secure end-to-end
communications between providers and consumers, and enables reading of a value, callinga function and getting a value back, sending an asynchronous command with no response,
and requesting a notification. Two devices can be configured to talk directly to each other.
For example, a light switch can be configured to send an “ON” or “OFF” command to a lightbulb. Windows also includes a gateway that interfaces with legacy networks like ZigBee orBluetooth, translating the legacy protocols into AllJoyn.

872
873

TPMs currently support many cryptographic algorithms, but currently not the efficient(symmetric) GCM encryption/identification that is used by many low-power devices.

Overlay Networks

Revision 22

34
TCG PublishedMarch 13, 2017