-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-fedorkow-rats-network-device-attestation-01c.txt
1904 lines (1298 loc) · 80.3 KB
/
draft-fedorkow-rats-network-device-attestation-01c.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
RATS Working Group G. Fedorkow, Ed.
Internet-Draft Juniper Networks, Inc.
Intended status: Informational J. Fitzgerald-McKay
Expires: December 3, 2019 National Security Agency
June 1, 2019
Network Device Attestation Workflow
draft-fedorkow-rats-network-device-attestation-latest
Abstract
This document describes a workflow for network device attestation.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 3, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 1]
Internet-Draft Network Device Attestation Workflow June 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Description . . . . . . . . . . . . . . . . . . . 5
1.4. Solution Requirements . . . . . . . . . . . . . . . . . . 6
1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8
1.5.2. Why Remote Integrity Verification? . . . . . . . . . 8
1.5.3. Network Device Attestation Challenges . . . . . . . . 8
1.5.4. Why is OS Attestation Different? . . . . . . . . . . 10
2. Solution Outline . . . . . . . . . . . . . . . . . . . . . . 10
2.1. 2.1 RIV Software Configuration Attestation using TPM . . 10
2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 12
2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 13
2.4.1. DevID Alternatives . . . . . . . . . . . . . . . . . 14
2.4.2. Additional Attestation of Platform Characteristics . 14
2.4.3. Root of Trust for Measurement . . . . . . . . . . . . 15
2.4.4. Reference Integrity Measurements (RIMs) . . . . . . . 15
2.4.5. Attestation Logs . . . . . . . . . . . . . . . . . . 16
3. Standards Components . . . . . . . . . . . . . . . . . . . . 17
3.1. Reference Models . . . . . . . . . . . . . . . . . . . . 17
3.1.1. IETF Reference Model for Challenge-Response Remote
Attestation . . . . . . . . . . . . . . . . . . . . . 17
3.2. RIV Workflow . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Layering Model for Network Equipment Attester and
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 20
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Implementation Notes . . . . . . . . . . . . . . . . . . 22
5.2. Comparison with TCG PTS / IETF NEA . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
There are many components to consider in fielding a trusted computing
device, from operating systems to applications. Part of that is a
trusted supply chain, where manufacturers can certify that the
product they intended to build is actually the one that was installed
at a customer's site.
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 2]
Internet-Draft Network Device Attestation Workflow June 2019
Attestation is defined here as the process of creating, conveying and
appraising assertions about Platform trustworthiness characteristics,
including Roots of Trust, supply chain trust, identity, platform
provenance, shielded locations, protected capabilities, software
configuration, hardware configuration, platform composition,
compliance to test suites, functional and assurance evaluations, etc.
The supply chain itself has many elements, from validating suppliers
of electronic components, to ensuring that shipping procedures
protect against tampering through many stages of distribution and
warehousing. One element that helps maintain the integrity of the
supply chain after manufacturing is Attestation.
Within the Trusted Computing Group context, attestation is the
process by which an independent Verifier can obtain cryptographic
proof as to the identity of the device in question, evidence of the
integrity of software loaded on that device when it started up, and
then verify that what's there is what's supposed to be there. For
networking equipment, a verifier capability can be embedded in a
Network Management Station (NMS), a posture collection server, or
other network analytics tool (such as a software asset management
solution, or a threat detection and mitigation tool, etc.). While
informally referred to as attestation, this document focuses on a
subset defined here as Remote Integrity Verification (RIV). RIV
takes a network equipment centric perspective that includes a set of
protocols and procedures for determining whether a particular device
was launched with untampered software, starting from Roots of Trust.
While there are many ways to accomplish attestation, RIV sets out a
specific set of protocols and tools that work in environments
commonly found in Networking Equipment. RIV does not cover other
platform characteristics that could be attested, although it does
provide evidence of a secure infrastructure to increase the level of
trust in other platform characteristics attested by other means.
This profile outlines the RIV problem, and then identifies components
that are necessary to get the complete attestation procedure working
in a scalable solution using commercial products.
This document focuses primarily on software integrity verification
using the Trusted Platform Module (TPM) as a root of trust.
Attestation information of course must be protected by means of
cryptographic techniques to assure its validity.
It's important to note that TCG technologies are available to use
either symmetric key encryption with shared keys, or public key
cryptography using private/public key pairs.
The two techniques can each produce secure results, but do require
different provisioning mechanisms.
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 3]
Internet-Draft Network Device Attestation Workflow June 2019
The RIV document currently focuses on asymmetric keying approaches
only; future work might include techniques for attestation using
symmetric keys.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Goals
As a part of a trusted supply chain, Attestation requires two
interlocking services:
o Platform Identity, the mechanism providing trusted identity, can
reassure network managers that the specific devices they ordered
from authorized manufacturers for attachment to their network are
those that were installed, and that they continue to be present in
their network. As part of the mechanism for Platform Identity,
cryptographic proof of the identity of the manufacturer is also
provided.
o Software Measurement is the mechanism that reports the state of
mutable components on the device, and can assure network managers
that they have known, untampered software configured to run in
their network.
The RIV attestation workflow outlined in this document is intended to
meet the following high-level goals:
o Provable Device Identity - The ability to identify a device using
a cryptographic identifier is a critical prerequisite to software
inventory attestation.
o Software Inventory - A key goal is to identify the software
release installed on the device, and to provide evidence of its
integrity.
o Verification - Verification of software and configuration of the
device shows that the software that's supposed to be installed on
there actually has been launched, without unauthorized
modification.
This document itself is non-normative; the document does not define
protocols, but rather identifies protocols that can be used together
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 4]
Internet-Draft Network Device Attestation Workflow June 2019
to achieve the goals above, and in some cases, highlights gaps in
existing protocols.
1.3. Problem Description
RIV is a procedure that assures a network operator that the equipment
on their network can be reliably identified, and that untampered
software of a known version is installed on each endpoint. In this
context, endpoint might include the conventional connected devices
like servers and laptops, but also connected devices that make up the
network equipment itself, such as routers, switches and firewalls.
RIV can be viewed as a link in a trusted supply chain, and includes
three major processes:
o Creation of Evidence is the process whereby an endpoint generates
cryptographic proof (evidence) of claims about platform
properties. In particular, the platform identity and its software
configuration are of critical importance
* Platform Identity refers to the mechanism assuring the
attestation relying party (typically a network administrator)
of the identity of devices that make up their network, and that
their manufacturers are known.
* Software used to boot a platform can be described as a chain of
measurements, started by a Root of Trust for Measurement, that
normally ends when the system software is loaded. A
measurement signifies the identity, integrity and version of
each software component registered with the TPM, so that the
subsequent appraisal stage can determine if the software
installed is authentic, up-to-date, and free of tampering.
Clearly the second part of the problem, attesting the state of
mutable components of a given device, is of little value without
reliable identification of the device in question. By the same
token, unambiguous identity of a device is necessary, but is
insufficient to assure the operator of the provenance of the
device through the supply chain, or that the device is configured
to behave properly.
o Conveyance of Evidence is the process of reliably transporting
evidence from the point in a connected device where a measurement
is stored to an appraiser/verifier, e.g. a management station.
The transport is typically carried out via a management network.
The channel must provide integrity and authenticity, and, in some
use cases, may also require confidentiality.
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 5]
Internet-Draft Network Device Attestation Workflow June 2019
o Appraisal of Evidence is the process of verifying the evidence
received by a verifier/appraiser from a device, and using verified
evidence to inform decision making. In this context, verification
means comparing the device measurements reported as evidence with
the configuration expected by the system administrator. This step
can work only when there is a way to express what should be there,
often referred to as golden measurements, or Reference Integrity
Measurements, representing the intended configured state of the
connected device.
An implementation of RIV requires three technologies
1. Identity: Platform identity can be based on IEEE 802.1AR Device
Identity [IEEE-802-1AR], coupled with careful supply-chain
management by the manufacturer. The DevID certificate contains a
statement by the manufacturer that establishes the provenance of
the device as it left the factory. Some applications with a
more-complex post-manufacture supply chain (e.g. Value Added
Resellers), or with privacy concerns, may want to use an
alternate mechanism for platform authentication based on TCG
Platform Certificates [Platform-Certificates].
RIV currently relies on asymmetric keying for identity; alternate
approaches might use symmetric keys.
2. Platform Attestation provides evidence of configuration of
software elements throughout the product lifecycle. This form of
attestation can be implemented with TPM PCR, Quote and log
mechanisms, which provide an authenticated mechanism to report
what software actually starts up on the device each time it
reboots.
3. Reference Integrity Measurements must be conveyed from the
software authority (often the manufacturer for embedded systems)
to the system in which verification will take place
Service Providers benefit from a trustworthy attestation mechanism
that provides assurance that their network comprises authentic
equipment, and has loaded software free of known vulnerabilities and
unauthorized tampering.
1.4. Solution Requirements
The RIV attestation solution must meet a number of requirements to
make it simple to deploy at scale.
1. Easy to Use - This solution should work "out of the box" as far
as possible, that is, with the fewest possible steps needed at
the end-user's site. Eliminate complicated databases or
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 6]
Internet-Draft Network Device Attestation Workflow June 2019
provisioning steps that would have to be executed by the owner of
a new device. Network equipment is often required to "self-
configure", to reliably reach out without manual intervention to
prove its identity and operating posture, then download its own
configuration. See [RFC8572] for an example of Secure Zero Touch
Provisioning.
2. Multi-Vendor - This solution should identify standards-based
interfaces that allow attestation to work with attestation-
capable devices and verifiers supplied by different vendors in
one network.
3. Scalable - The solution must not depend on choke points that
limit the number of endpoints that could be evaluated in one
network domain.
4. Extensible - A network equipment attestation solution needs to
expand over time as new features are added. The solution must
allow new features to be added easily, providing for a smooth
transition and allowing newer and older architectural components
to continue to work together. Further, a network equipment
attestation solution and the specifications referenced here must
define safe extensibility mechanisms that enable innovation
without breaking interoperability.
5. Efficient - A network equipment attestation solution should, to
the greatest extent feasible, continuously monitor the health and
posture status of network devices. Posture measurements should
be updated in real-time as changes to device posture occur and
should be published to remote integrity validators. Validation
reports should also be shared with their relying parties (for
example, network administrators, or network analytics that rely
on these reports for posture assessment) as soon as they are
available.
1.5. Scope
This document includes a number of assumptions to limit the scope:
o This solution is for use in non-privacy-preserving applications
(for example, networking, Industrial IoT), avoiding the need for a
Privacy Certificate Authority for attestation keys
o This document applies primarily to "embedded" applications, where
the device manufacturer ships the software image for the device.
o The approach outlined in this document assumes the use of TPM 1.2
or TPM 2.0.
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 7]
Internet-Draft Network Device Attestation Workflow June 2019
1.5.1. Out of Scope
o Run-Time Attestation: Run-time attestation of Linux or other
multi-threaded operating system processes considerably expands the
scope of the problem. Many researchers are working on that
problem, but this document defers the run-time attestation
problem.
o Multi-Vendor Embedded Systems: Additional coordination would be
needed for devices that themselves comprise hardware and software
from multiple vendors, integrated by the end user.
o Processor Sleep Modes: Network equipment typically does not
"sleep", so sleep and hibernate modes are not considered.
o Virtualization and Containerization: These technologies are
increasingly used in Network equipment, but are not considered in
this revision of the document.
1.5.2. Why Remote Integrity Verification?
Remote Integrity Verification can go a long way to solving the "Lying
Endpoint" problem, in which malicious software on an endpoint may
both subvert the intended function, and also prevent the endpoint
from reporting its compromised status. Man-in-the Middle attacks are
also made more difficult through a strong focus on device identity
Attestation data can be used for asset management, vulnerability and
compliance assessment, plus configuration management.
1.5.3. Network Device Attestation Challenges
There have been demonstrations of attestation using TPMs for years,
accompanied by compelling security reasons for adopting attestation.
Despite this, the technology has not been widely adopted, in part,
due to the difficulties in deploying TPM-based attestation. Some of
those difficulties are:
o Standardizing device identity. Creating and using unique device
identifiers is difficult, especially in a privacy-sensitive
environment. But attestation is of limited value if the operator
is unable to determine which devices pass attestation validation
tests, and which fail. This problem is substantially simplified
for infrastructure devices like network equipment, where identity
can be explicitly coded using IEEE 802.1AR, but doing so relies on
adoption of 802.1AR [IEEE-802-1AR] by manufacturers and hardware
system integrators.
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 8]
Internet-Draft Network Device Attestation Workflow June 2019
o Standardizing attestation representations and conveyance.
Interoperable remote attestation has a fundamental dependence on
vendors agreeing to a limited set of network protocols commonly
used in existing network equipment for communicating attestation
data. Network device vendors will be slow to adopt the changes
necessary to implement remote attestation without a fully-realized
plan for deployment.
o Interoperability. Networking equipment operates in a
fundamentally multi-vendor environment, putting additional
emphasis on the need for standardized procedures and protocols.
o Attestation evidence is complex. Operating systems used in larger
embedded devices are often multi-threaded, so the order of
completion for individual processes is non-deterministic. While
the hash of a specific component is stable, once extended into a
PCR, the resulting values are dependent on the (non-deterministic)
ordering of events, so there will never be a single known-good
value for some PCRs. Careful analysis of event logs can provide
proof that the expected modules loaded, but it's much more
complicated than simply comparing reported and expected digests,
as collected in TPM Platform Configuration Registers (PCRs).
o Software configurations can have seemingly infinite variability.
This problem is nearly intractable on PC and Server equipment,
where end users have unending needs for customization and new
applications. However, embedded systems, like networking
equipment, are often simpler, in that there are fewer variations
and releases, with vendors typically offering fewer options for
mixing and matching.
o Standards-based mechanisms to encode and distribute Reference
Integrity Measurements, (i.e., expected values) are still in
development.
o Software updates can be complex. Even the most organized network
operator may have many different releases in their network at any
given time, with the result that there's never a single digest or
fingerprint that indicates the software is "correct"; digests
formed by hashing software modules on a device can only show the
correct combination of versions for a specific device at a
specific time.
None of these issues are insurmountable, but together, they've made
deployment of attestation a major challenge. The intent of this
document is to outline an attestation profile that's simple enough to
deploy, while yielding enough security to be useful.
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 9]
Internet-Draft Network Device Attestation Workflow June 2019
1.5.4. Why is OS Attestation Different?
Even in embedded systems, adding Attestation at the OS level (e.g.
Linux IMA, Integrity Measurement Architecture [IMA]) increases the
number of objects to be attested by one or two orders of magnitude,
involves software that's updated and changed frequently, and
introduces processes that begin in unpredictable order.
TCG and others (including the Linux community) are working on methods
and procedures for attesting the operating system and application
software, but standardization is still in process.
2. Solution Outline
2.1. 2.1 RIV Software Configuration Attestation using TPM
RIV Attestation is a process for determining the identity of software
running on a specifically-identified device. Remote Attestation is
broken into two phases, shown in Figure 1:
o During system startup, measurements (i.e., digests computed as
fingerprints of files) are extended, or cryptographically folded,
into the TPM. Entries are also added to an informational log.
The measurement process generally follows the Chain of Trust model
used in Measured Boot, where each stage of the system measures the
next one, and extends its measurement into the TPM, before
launching it.
o Once the device is running and has operational network
connectivity, a separate, trusted server (called a Verifier in
this document) can interrogate the network device to retrieve the
logs and a copy of the digests collected by hashing each software
object, signed by an attestation private key known only to the
TPM.
The result is that the Verifier can verify the device's identity by
checking the certificate containing the TPM's attestation public key,
and can validate the software that was launched by comparing digests
in the log with known-good values, and verifying their correctness by
comparing with the signed digests from the TPM.
It should be noted that attestation and identity are inextricably
linked; signed evidence that a particular version of software was
loaded is of little value without cryptographic proof of the identity
of the device producing the evidence.
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 10]
Internet-Draft Network Device Attestation Workflow June 2019
+-------------------------------------------------------+
| +--------+ +--------+ +--------+ +---------+ |
| | BIOS |--->| Loader |-->| Kernel |--->|Userland | |
| +--------+ +--------+ +--------+ +---------+ |
| | | | |
| | | | |
| +------------+-----------+-+ |
| Step 1 | |
| V |
| +--------+ |
| | TPM | |
| +--------+ |
| Router | |
+--------------------------------|----------------------+
|
| Step 2
| +-----------+
+--->| Verifier |
+-----------+
Reset---------------flow-of-time-during-boot--...------->
Figure 1: TCG Attestation Model
In Step 1, measurements are "extended" into the TPM as processes
start. In Step 2, signed PCR digests are retrieved from the TPM for
off-box analysis after the system is operational.
2.2. RIV Keying
TPM 1.2 and TPM 2.0 have a variety of rules separating the functions
of identity and attestation, allowing for use-cases where software
configuration must be attested, but privacy must be maintained.
To accommodate these rules, enforced inside the TPM, in an
environment where device privacy is not normally a requirement, the
TCG Guidance for Securing Network Equipment [NetEq] suggests using
separate keys for Identity (i.e., DevID) and Attestation (i.e.,
signing a quote of the contents of the PCRs), but provisioning an
Initial Attestation Key (IAK) and x.509 certificate that parallels
the IDevID, with the same 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, signed by the IAK, to be linked directly to the device that
provided it, by examining the corresponding IAK certificate.
Inclusion of an IAK by a vendor does not preclude a mechanism whereby
an Administrator can define Local Attestation Keys (LAKs) if desired.
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 11]
Internet-Draft Network Device Attestation Workflow June 2019
2.3. RIV Information Flow
RIV workflow for networking equipment is organized around a simple
use-case, where a network operator wishes to verify the integrity of
software installed in specific, fielded devices. This use-case
implies several components:
1. A Device (e.g. a router or other embedded device, also known as
an Attester) somewhere and the network operator wants to examine
its boot state.
2. A Verifier (which might be a network management station)
somewhere separate from the Device that will retrieve the
information and analyze it to pass judgement on the security
posture of the device.
3. A Relying Party, which has access to the Verifier to request
attestation and to act on results.
4. This document assumes that signed Reference Integrity
Measurements (RIMs) (aka "golden measurements") can either be
created by the device manufacturer and shipped along with the
device as part of its software image, or alternatively, could be
obtained a number of other ways (direct to the verifier from the
manufacturer, from a third party, from the owner's observation of
what's thought to be a "known good system", etc.). Retrieving
RIMs from the device itself allows attestation to be done in
systems which may not have access to the public internet, or by
other devices that are not management stations per-se (e.g., a
peer device). If reference measurements are obtained from
multiple sources, the Verifier may need to evaluate the relative
level of trust to be placed in each source in case of a
discrepancy.
These components are illustrated in Figure 2.
A more-detailed taxonomy of terms is given in
[I-D.birkholz-rats-architecture]
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 12]
Internet-Draft Network Device Attestation Workflow June 2019
+---------------+ +-------------+ +---------+--------+
| | | Attester | Step 1 | Verifier| |
| Asserter | | (Device |<-------| (Network| Relying|
| (Device | | under |------->| Mngmt | Party |
| Manufacturer | | attestation)| Step 2 | Station)| |
| or other | | | | | |
| authority) | | | | | |
+---------------+ +-------------+ +---------+--------+
| /\
| Step 0 |
-----------------------------------------------
Figure 2: RIV Reference Configuration for Network Equipment
In Step 0, The Asserter (the device manufacturer) provides a Software
Image accompanied by Reference Integrity Measurements (RIMs) to the
Attester (the device under attestation) signed by the asserter. In
Step 1, the Verifier (Network Management Station), on behalf of a
Relying Party, requests Identity, Measurement Values (and possibly
RIMs) from the Attester. In Step 2, the Attester responds to the
request by providing a DevID, Quotes (measured values), and
optionally RIMs, signed by the Attester.
See Section 3.1.1 for more narrowly defined terms related to
Attestation
2.4. RIV Simplifying Assumptions
This document makes the following simplifying assumptions to reduce
complexity:
o The product to be attested is shipped with an IEEE 802.1AR DevID
and an Initial Attestation Key (IAK) with certificate. The IAK
cert contains the same identity information as the DevID
(specifically, the same Subject Name and Subject Alt Name, signed
by the manufacturer), but it's a type of key that can be used to
sign a TPM Quote. This convention is described in TCG Guidance
for Securing Network Equipment [NetEq]. For network equipment,
which is generally non-privacy-sensitive, shipping a device with
both an IDevID and an IAK already provisioned substantially
simplifies initial startup. Privacy-sensitive applications may
use the TCG Platform Certificate and additional procedures to
install identity credentials on the platform after manufacture.
(See Section 2.3.1 below for the Platform Certificate alternative)
o The product is equipped with a Root of Trust for Measurement, Root
of Trust for Storage and Root of Trust for Reporting that is
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 13]
Internet-Draft Network Device Attestation Workflow June 2019
capable of conforming to the TCG Trusted Attestation Protocol
(TAP) Information Model [TAP].
o The vendor will ship Reference Integrity Measurements (i.e.,
known-good measurements) in the form of signed CoSWID tags
[I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference
Integrity Measurement Manifest [RIM].
2.4.1. DevID Alternatives
Some situations may have privacy-sensitive requirements that preclude
shipping every device with an Initial Device ID installed. In these
cases, the IDevID can be installed remotely using the TCG Platform
Certificate [Platform-Certificates].
Some administrators may want to install their own identity
credentials to certify device identity and attestation results. IEEE
802.1AR [IEEE-802-1AR] allows for both Initial Device Identity
credentials, installed by the manufacturer, (analogous to a physical
serial number plate), or Local Device Identity credentials installed
by the administrator of the device (analogous to the physical Asset
Tag used by many enterprises to identify their property). TCG TPM
2.0 Keys documents [Platform-DevID-TPM-2.0] and
[PC-Client-BIOS-TPM-2.0] specifies parallel Initial and Local
Attestation Keys (IAK and LAK), and contains figures showing the
relationship between IDevID, LDevID, IAK and LAK keys.
Device administrators are free to use any number of criteria to judge
authenticity of a device before installing local identity keys, as
part of an on-boarding process. The TCG TPM 2.0 Keys document
[Platform-DevID-TPM-2.0] also outlines procedures for creating Local
Attestation Keys and Local Device IDs (LDevIDs) rooted in the
manufacturer's IDevID as a check to reduce the chances that
counterfeit devices are installed in the network.
Note that many networking devices are expected to self-configure (aka
Zero Touch Provisioning). Current standardized zero-touch mechanisms
such as [RFC8572] assume that identity keys are already in place
before network on-boarding can start, and as such, are compatible
with IDevID and IAK keys installed by the manufacturer, but not with
LDevID and LAK keys, which would have to be installed by the
administrator.
2.4.2. Additional Attestation of Platform Characteristics
The Platform Attribute Credential [Platform-Certificates] can also be
used to convey additional information about a platform from the
manufacturer or other entities in the supply chain. While outside
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 14]
Internet-Draft Network Device Attestation Workflow June 2019
the scope of RIV, the Platform Attribute Credential can deliver
information such as lists of serial numbers for components embedded
in a device or security assertions related to the platform, signed by
the manufacturer, system integrator or value-added-reseller.
2.4.3. Root of Trust for Measurement
The measurements needed for attestation require that the device being
attested is equipped with a Root of Trust for Measurement, i.e., some
trustworthy mechanism that can compute the first measurement in the
chain of trust required to attest that each stage of system startup
is verified, and a Root of Trust for Reporting to report the results
[Roots-of-Trust].
While there are many complex aspects of a Root of Trust, two aspects
that are important in the case of attestation are:
o The first measurement computed by the Root of Trust for
Measurement, and stored in the TPM's Root of Trust for Storage, is
presumed to be correct.
o There must not be a way to reset the RTS without re-entering the
RTM code.
The first measurement must be computed by code that is implicitly
trusted; if that first measurement can be subverted, none of the
remaining measurements can be trusted. (See [NIST-SP-800-155]
2.4.4. Reference Integrity Measurements (RIMs)
Much of attestation focuses on collecting and transmitting 'evidence'
in the form of PCR measurements and attestation logs. But the
critical part of the process is enabling the verifier to decide
whether the measurements are "the right ones" or not.
While it must be up to network administrators to decide what they
want on their networks, the software supplier should supply the
Reference Integrity Measurements, (aka Golden Measurements or "known
good" hash digests) that may be used by a verifier to determine if
evidence shows known good, known bad or unknown software
configurations.
In general, there are two kinds of reference measurements:
1. Measurements of early system startup (e.g., BIOS, boot loader, OS
kernel) are essentially single threaded, and executed exactly
once, in a known sequence, before any results could be reported.
In this case, while the method for computing the hash and
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 15]
Internet-Draft Network Device Attestation Workflow June 2019
extending relevant PCRs may be complicated, the net result is
that the software (more likely, firmware) vendor will have one
known good PCR value that "should" be present in the PCR after
the box has booted. In this case, the signed reference
measurement simply lists the expected hash for the given version.
2. Measurements taken later in operation of the system, once an OS
has started (for example, Linux IMA[16.]), may be more complex,
with unpredictable "final" PCR values. In this case, the
Verifier must have enough information to reconstruct the expected
PCR values from logs and signed reference measurements from a
trusted authority.
In both cases, the expected values can be expressed as signed CoSWID
tags, but the SWID structure in the second case is somewhat more
complex. An example of how CoSWIDs could be incorporated into a
reference manifest can be found in the IETF Internet-Draft "A SUIT
Manifest Extension for Concise Software Identifiers"
[I-D.birkholz-suit-coswid-manifest].
The TCG has done exploratory work in defining formats for reference
integrity manifests under the working title TCG Reference Integrity
Manifest [RIM].
2.4.5. Attestation Logs
Quotes from a TPM can provide evidence of the state of a device up to
the time the evidence was recorded, but to make sense of the quote in
most cases an event log of what software modules contributed which
values to the quote during startup must also be provided. The log
must contain enough information to demonstrate its integrity by
allowing exact reconstruction of the digest conveyed in the signed
quote (e.g., PCR values).
TCG has defined several event log formats:
o Legacy BIOS event log (TCG PC Client Specific Implementation
Specification for Conventional BIOS,
Section 11.3[PC-Client-BIOS-TPM-1.2])
o UEFI BIOS event log (TCG EFI Platform Specification for TPM Family
1.1 or 1.2, Section 7 [EFI])
o Canonical Event Log [Canonical-Event-Log]
It should be noted that a given device might use more than one event
log format (e.g., a UEFI log during initial boot, switching to
Canonical Log when the host OS launches).
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 16]
Internet-Draft Network Device Attestation Workflow June 2019
The TCG SNMP Attestation MIB [SNMP-Attestation-MIB] will support any
record-oriented log format, including the three TCG-defined formats,
but it currently leaves figuring out which log(s) are in what format
up to the Verifier.
3. Standards Components
3.1. Reference Models
3.1.1. IETF Reference Model for Challenge-Response Remote Attestation
Initial work at IETF defines remote attestation as follows:
The Reference Interaction Model for Challenge-Response-based Remote
Attestation is based on the standard roles defined in
[I-D.birkholz-rats-architecture]:
o Attester: The role that designates the subject of the remote
attestation. A system entity that is the provider of evidence
takes on the role of an Attester.
o Verifier: The role that designates the system entity and that is
the appraiser of evidence provided by the Attester. A system
entity that is the consumer of evidence takes on the role of a
Verifier.
The following diagram illustrates a common information flow between a
Verifier and an Attester, specified in
[I-D.birkholz-rats-reference-interaction-model]:
Attester Verifier
| |
| <------- requestAttestation(nonce, authSecID, claimSelection) |
| |
collectAssertions(assertionsSelection) |
| => assertions |
| |
signAttestationEvidence(authSecID, assertions, nonce) |
| => signedAttestationEvidence |
| |
| signedAttestationEvidence ----------------------------------> |
| |
| verifyAttestationEvidence(signedAttestationEvidence, refassertions)
| attestationResult <= |
| |
Figure 3: IETF Attestation Information Flow
Fedorkow & Fitzgerald-McExpires December 3, 2019 [Page 17]
Internet-Draft Network Device Attestation Workflow June 2019
The RIV approach outlined in this document aligns with the RATS
reference model.
3.2. RIV Workflow
The overall flow for an attestation session is shown in Figure 4. In
this diagram:
o Step 0, positioning of the signed reference measurements, may
happen in two ways:
o Step 0A below shows a verifier obtaining reference measurements
directly from a software configuration authority, whether it's the
vendor or another authority chosen by the system administrator.
The reference measurements are signed by the Asserter (i.e., the
software configuration authority).
o - Or - Step 0B, the reference measurements, signed by the
Asserter, may be distributed as part of software installation,
long before the attestation session begins. Software installation
is usually vendor-dependent, so there are no standards involved in
this step. However, the verifier can use the same protocol to
obtain the reference measurements from the device as it would have
used with an external reference authority
o In Step 1, the Verifier initiates an attestation session by
opening a TLS session, validated using the DevID to prove that the
connection is attesting the right box.
o In Step 2, measured values are retrieved from the Attester's TPM
using a YANG or SNMP interface that implements the TCG TAP model
(e.g. YANG Module for Basic Challenge-Response-based Remote
Attestation Procedures
[I-D.birkholz-yang-basic-remote-attestation]).
o In Step 3, the Attester also delivers a copy of the signed
reference measurements, using Software Inventory YANG module based
on Software Identifiers [I-D.birkholz-yang-swid].