forked from w3c/wot-security
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.html
More file actions
2812 lines (2710 loc) · 162 KB
/
Copy pathindex.html
File metadata and controls
2812 lines (2710 loc) · 162 KB
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
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<link rel="stylesheet" href="tablestyle.css">
<meta charset="utf-8" />
<title>Web of Things (WoT) Security and Privacy Considerations</title>
<script class="remove" async="" src="https://www.w3.org/Tools/respec/respec-w3c-common"></script>
<script class="remove">
var respecConfig = {
specStatus: "ED"
, noRecTrack: "true"
, processVersion: 2017
, shortName: "wot-security"
, copyrightStart: 2017
, wg: "Web of Things Working Group"
, wgURI: "https://www.w3.org/WoT/WG/"
, wgPublicList: "public-wot-wg"
, edDraftURI: "https://w3c.github.io/wot-security/"
, githubAPI: "https://api.github.com/repos/w3c/wot-security"
, issueBase: "https://www.github.com/w3c/wot-security/issues"
, editors: [
{
name: "Elena Reshetova"
, w3cid: "99327"
, company: "Intel Corp."
, companyURL: "https://www.intel.com/"
},
{
name: "Michael McCool"
, w3cid: "93137"
, company: "Intel Corp."
, companyURL: "https://www.intel.com/"
}
]
, otherLinks: [
{
key: "Contributors"
, data: [
{
value: "In the GitHub repository"
, href: "https://github.com/w3c/wot-security/graphs/contributors"
}
]
}
, {
key: "Repository",
data: [
{
value: "We are on GitHub",
href: "https://github.com/w3c/wot-security/"
}
, {
value: "File a bug",
href: "https://github.com/w3c/wot-security/issues"
}
, {
value: "Contribute",
href: "https://github.com/w3c/wot-security/pulls"
}
]
}
]
, localBiblio: {
"CoRE-RD": {
href: "https://tools.ietf.org/html/draft-ietf-core-resource-directory-11"
, title: "CoRE Resource Directory"
, status: "Internet-Draft"
, publisher: "IETF"
, date: "03 July 2017"
},
"Ocf17": {
href: "https://openconnectivity.org/specs/OCF_Security_Specification_v1.0.0.pdf"
, title: "The OCF Security Specification, version 1.0.0"
, publisher: "OCF"
, date: "June 2017"
},
"JWT15": {
href: "https://tools.ietf.org/html/rfc7519"
, title: "JSON Web Token (JWT)"
, publisher: "IETF"
, date: "May 2015"
},
"CBOR17": {
href: "https://tools.ietf.org/pdf/draft-ietf-ace-cbor-web-token-07.pdf"
, title: "CBOR Web Token (CWT)"
, status: "Internet-Draft"
, publisher: "IETF"
, date: "June 2017"
},
"OSCOAP17": {
href: "https://tools.ietf.org/pdf/draft-ietf-core-object-security-04.pdf"
, title: "Object Security of CoAP (OSCOAP)"
, status: "Internet-Draft"
, publisher: "IETF"
, date: "July 2017"
},
"COSE17": {
href: "https://tools.ietf.org/pdf/draft-ietf-cose-msg-24.pdf"
, title: "CBOR Object Signing and Encryption (COSE)"
, status: "Internet-Draft"
, publisher: "IETF"
, date: "May 2017"
},
"Bel89": {
authors: ["S. Bellovin"]
, href: "https://cseweb.ucsd.edu/classes/sp99/cse227/ipext.pdf"
, title: "Security Problems in the TCP-IP Protocol Suite"
, publisher: "Computer Communication Review, Vol. 19, No. 2"
, pages: "32-48"
, date: "April 1989"
},
"Bel13": {
authors: ["S. Bellovin"]
, href: "https://csrc.nist.gov/csrc/media/events/workshop-on-improving-trust-in-the-online-marketpl/documents/presentations/bellovin_ca-workshop2013.pdf"
, title: "Web Security in the Real World"
, publisher: "Workshop on Improving Trust in the Online Marketplace, NIST"
, date: "April 2013"
},
"Ber14": {
authors: ["V. Bertocci"]
, href: "http://www.cloudidentity.com/blog/2014/04/22/authentication-protocols-web-ux-and-web-api/"
, title: "Authentication Protocols, Web UX and Web API"
, date: "April 2014"
},
"Bor14": {
authors: ["C. Bormann", "et al."]
, href: "https://tools.ietf.org/rfc/rfc7228.txt"
, title: "Terminology for Constrained-Node Networks"
, publisher: "IETF RFC 7228"
, date: "May 2014"
},
"Bru14": {
authors: ["C. Brubaker", "et al."]
, href: "https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf"
, title: "Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations"
, publisher: "IEEE Security Privacy"
, date: "2014"
, pages: "114-129"
},
"Coo13": {
authors: ["A. Cooper", "et al"]
, href: "https://tools.ietf.org/html/rfc6973"
, title: "Privacy Considerations for Internet Protocols"
, publisher: "IETF RFC 6973 (IAB Guideline)"
, date: "July 2013"
},
"Lea05": {
authors: ["P. Leach", "et al"]
, href: "https://tools.ietf.org/html/rfc4122"
, title: "A Universally Unique IDentifier (UUID) URN Namespace"
, publisher: "IETF RFC 4122"
, date: "July 2005"
},
"Dur13": {
authors: ["Z. Durumeric", "et al."]
, href: "https://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf"
, title: "Analysis of the HTTPS Certificate Ecosystem"
, publisher: "Proc. of the 2013 conference on Internet measurement conference"
, date: "October 2013"
},
"Ell00": {
authors: ["C. Ellison", "B. Schneier"]
, href: "https://www.schneier.com/paper-pki.pdf"
, title: "Ten Risks of PKI: What You’re not Being Told about Public Key Infrastructure"
, publisher: "Computer Security Journal, v 16, n 1,"
, date: "2000"
, pages: "1-7"
},
"Fu01": {
authors: ["K. Fu", "et al."]
, href: "https://pdos.csail.mit.edu/papers/webauth:sec10.pdf"
, title: "Dos and Don’ts of Client Authentication on the Web"
, publisher: "Proc. 10th USENIX Security Symposium"
, date: "August 2001"
},
"Garcia17": {
authors: ["O. Garcia-Morchon", "S. Kumar", "M. Sethi"]
, title: "State-of-the-Art and Challenges for the Internet of Things Security"
, href: "https://datatracker.ietf.org/doc/draft-irtf-t2trg-iot-seccons/"
},
"Geo12": {
authors: ["M. Georgiev", "et al."]
, href: "https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf"
, title: "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software"
, publisher: "Proc. of the 2012 ACM conference on Computer and communications security"
, date: "2012"
, pages: "38-49"
},
"Gol03": {
authors: ["O. Goldreich"]
, href: "http://www.wisdom.weizmann.ac.il/~oded/foc-sur01.html"
, title: "Cryptography and Cryptographic Protocols"
, publisher: "Distributed Computing, vol. 16"
, pages: "177-199"
, date: "2003"
},
"Gre14": {
authors: ["M. Green"]
, href: "https://blog.cryptographyengineering.com/2014/03/19/how-do-you-know-if-rng-is-working/"
, title: "How do you know if an RNG is working?"
, date: "March 2014"
},
"Gut02": {
authors: ["P. Gutman"]
, href: "https://www.cs.auckland.ac.nz/~pgut001/pubs/notdead.pdf"
, title: "PKI: It’s Not Dead, Just Resting"
, publisher: "IEEE Computer, vol. 35, no. 8"
, date: "Aug. 2002"
, pages: "41-49"
},
"Hea13": {
authors: ["M. Hearn"]
, href: "https://googleblog.blogspot.de/2013/02/an-update-on-our-war-against-account.html"
, title: "An update on our war against account hijackers"
, date: "Feb 2013"
},
"IETFACE": {
title: "IETF Authentication and Authorization for Constrained Environments (ACE)"
, href: "https://tools.ietf.org/wg/ace/"
},
"Iic15": {
authors: ["Industrial Internet Consortium"]
, href: "http://www.iiconsortium.org/IIRA.htm"
, title: "Industrial Internet Reference Architecture"
, date: "June 2015"
},
"IicRA17": {
authors: ["Industrial Internet Consortium"]
, href: "https://www.iiconsortium.org/IIRA.htm"
, title: "The Industrial Internet of Things Volume G1: Reference Architecture"
, publisher: "IIC:PUB:G1:V1.80:20170131"
, date: "Jan 2017"
},
"IicSF16": {
authors: ["Industrial Internet Consortium"]
, href: "https://www.iiconsortium.org/IISF.htm"
, title: "The Industrial Internet of Things Volume G4: Security Framework"
, publisher: "IIC:PUB:G4:V1.0:PB:20160926"
, date: "Sept 2016"
},
"ISF17": {
authors: ["IoT Security Foundation"]
, href: "https://iotsecurityfoundation.org/best-practice-guidelines/"
, title: "IoT Security Foundation Best Practice Guidelines"
, date: "May 2017"
},
"Jon14": {
authors: ["M. Jones"]
, href: "http://www.niso.org/sites/default/files/stories/2017-08/SP_Jones_JSON_isqv26no3.pdf"
, title: "A JSON-Based Identity Protocol Suite"
, publisher: "Information Standards Quarterly, vol. 26, no. 3"
, date: "2014"
, pages: "19–22"
},
"Ken03": {
authors: ["S. Kent", "L. Millet"]
, href: "https://www.nap.edu/read/10656/chapter/1"
, title: "Who Goes There? Authentication Through the Lens of Privacy"
, publisher: "The National Academies Press, Washington D.C."
, date: "2003"
},
"Lam04": {
authors: ["B. Lampson"]
, href: "https://pdfs.semanticscholar.org/6fe5/ba7a096e391d985e7818fef9d0f0636210a0.pdf"
, title: "Computer Security in the Real World"
, publisher: "IEEE Computer, vol. 37, no. 6"
, date: "June 2004"
, pages: "37-46"
},
"Loc05": {
authors: ["H. Lockhart"]
, href: "http://www.oracle.com/technetwork/testcontent/saml-084342.html"
, title: "Demystifying SAML"
, date: "May 2005"
},
"Mel15": {
authors: ["D. Melzer"]
, href: "https://c.ymcdn.com/sites/www.issa.org/resource/resmgr/journalpdfs/feature0615.pdf"
, title: "Securing the Industrial Internet of Things"
, date: "June 2015"
},
"Mic17": {
authors: ["Microsoft"]
, href: "https://docs.microsoft.com/en-us/azure/iot-suite/iot-security-architecture"
, title: "Internet of Things security architecture"
, publisher: "STRIDE threat model for IoT"
, date: "Jan 2017"
},
"Moo02": {
authors: ["T. Moors"]
, href: "https://www.csd.uoc.gr/~hy435/material/moors.pdf"
, title: "A critical review of End-to-end arguments in system design"
, publisher: "Proc. of the IEEE International Conference on Communications"
, date: "2002"
},
"Nis15": {
authors: ["NIST"]
, title: "Guide to Industrial Control Systems (ICS) Security"
, publisher: "NIST Special Publication 800-82"
},
"Oos10": {
authors: ["M. Oosdijk", "et al."]
, href: "https://tnc2011.terena.org/getfile/696"
, title: "Provisioning scenarios in identity federations"
, publisher: "Surfnet Research Paper"
, date: "2010"
},
"Owa17": {
authors: ["OWASP"]
, href: "https://www.owasp.org/index.php/Threat_Risk_Modeling"
, title: "Threat Risk Modeling"
, publisher: "OWASP"
, date: "Jan 2017"
},
"Res03": {
authors: ["E. Rescorla", "et al."]
, href: "https://tools.ietf.org/html/rfc3552"
, title: "Guidelines for Writing RFC Text on Security Considerations"
, publisher: "IETF RFC 3552 (IAB Guideline)"
, date: "2003"
},
"Sch14": {
authors: ["B. Schneier"]
, href: "https://www.wired.com/2014/01/theres-no-good-way-to-patch-the-internet-of-things-and-thats-a-huge-problem/"
, title: "The Internet of Things Is Wildly Insecure — And Often Unpatchable"
, publisher: "Wired"
, date: "Jan. 2014"
},
"Sch99": {
authors: ["B. Scheier", "A. Shostack"]
, href: "https://www.schneier.com/paper-smart-card-threats.pdf"
, title: "Breaking Up Is Hard To Do: Modeling Security Threats for Smart Cards"
, publisher: "USENIX Workshop on Smart Card Technology, USENIX Press"
, date: "1999"
, pages: "175-185"
},
"She14": {
authors: ["Z. Shelby", "et al."]
, href: "https://tools.ietf.org/rfc/rfc7252.txt"
, title: "The Constrained Application Protocol (CoAP)"
, publisher: "IETF RFC 7252"
, date: "June 2014"
},
"Vol00": {
authors: ["J. Vollbrecht", "et al."]
, href: "https://tools.ietf.org/rfc/rfc2904.txt"
, title: "AAA Authorization Framework"
, publisher: "IETF RFC 2904"
, date: "Aug. 2000"
},
"Yeg11": {
authors: ["S. Yegge"]
, href: "https://plus.google.com/+RipRowan/posts/eVeouesvaVX"
, title: "Stevey's Google Platforms Rant"
, publisher: "Blog"
, date: "Oct. 2011"
}
}
};
</script>
</head>
<body>
<section id="abstract">
<p>
This document provides non-normative guidance on Web of Things (WoT) security and privacy.
The Web of Things is descriptive, not prescriptive,
and so is generally designed to support the security models and mechanisms of the systems it describes,
not introduce new ones.
However, a WoT system also has its own unique assets, such as a Scripting API and Thing Descriptions, that
need to be protected and also have security and privacy implications.
</p><p>
We define the general security requirements for a Web of Things system using a threat model.
The WoT threat model defines the main security stakeholders, security-relevant assets,
possible attackers, attack surfaces,
and finally threats for a WoT system.
Using this generic WoT threat model for guidance,
it should be possible to select a specific set of security objectives for a concrete WoT system implementation.
We provide several examples using common scenarios based on home, enterprise, and industrial use cases.
We also provide more general suggestions for the design and deployment of a secure WoT system.
All recommendations are linked to the corresponding WoT threats in the generic woT threat model in order to
facilitate understanding of why they are needed.
</p><p>
It is not the intention of this document to limit the set of security mechanisms that can be used to
secure a WoT network.
In particular, while we provide examples and recommendations based on the best available practices in the industry,
this document contains informative statements only.
Specific normative security aspects of the WoT specification are defined in the corresponding normative WoT documents
for each WoT building block.
</p>
<p class="ednote">
This content should be consistent with the summaries in the
Security sections of other WoT documents, in particular the
<a href="https://www.w3.org/TR/2017/WD-wot-architecture-20170914/#sec-security-considerations">WoT Architecture</a>
document.
</p>
</section>
<section id="sotd">
<p class="ednote" title="The W3C WoT WG is asking for feedback">
Please contribute to this draft using the <a href="https://github.com/w3c/wot-security/issues">GitHub Issue</a> feature of the <a href="https://github.com/w3c/wot-security/">WoT Security and Privacy Considerations</a> repository.
</p>
</section>
<section>
<h1>Introduction</h1>
<p>Security of a WoT system can refer to the security of the Thing Description itself or
the security of the Thing the Thing Description describes.
For details on the Web of Things architecture, please refer to the following:
<ul>
<li>the <a href="https://www.w3.org/WoT/IG/">Interest Group</a> web site</li>
<li>the <a href="https://www.w3.org/WoT/WG/">Working Group</a> web site</li>
<li>the <a href="https://www.w3.org/TR/2017/WD-wot-architecture-20170914/">WoT Architecture</a> document,</li>
<li>the <a href="https://www.w3.org/TR/2017/WD-wot-thing-description-20170914/">WoT Thing Description</a> document,</li>
<li>the <a href="https://w3c.github.io/wot-binding-templates/">WoT Binding Templates</a> document, and</li>
<li>the <a href="https://www.w3.org/TR/2017/WD-wot-scripting-api-20170914/">WoT Scripting API</a> document.</li>
</ul>
</p>
</section>
<section>
<h1>Lifecycle of a WoT device</h1>
<figure id="wot-lifecycle">
<img src="images/WoT_lifecycle_diagram.png"
width="100%"
title="WoT Device Lifecycle"/>
<figcaption>WoT Device Lifecycle</figcaption>
</figure>
<p>The lifecycle of a WoT device is similar to the lifecycles of other IoT devices and services.
Iy may in fact be identical if a WoT Thing Description is being used simply to describe an existing device
implemented using another standard.
However,
for discussion purposes we will use the generic lifecycle shown in Figure <a href="#wot-lifecycle"></a>
which includes the following states:
<ul>
<li><strong>Manufactured:</strong> The WoT device has been manufactured by an OEM.
It might have a WoT runtime present that enables single or multi-tenant users
or it might only have network interfaces exposed present that are compatible with a WoT description.
From the Manufactured state, based on the deployment scenario, the device can transition to either of two states:
the Installation/Commissioning state or the Security Provisioning state.</li>
<li><strong>Installation/Commissioning:</strong> A WoT device has been installed into its intended deployment environment
by a system provider or system integrator and any necessary SW configuration has been performed.
In practice this state may be combined with or reordered with the Security Provisioning state.</li>
<li><strong>Security Provisioning:</strong> A WoT device is provisioned with the security metadata and credentials needed
during its Operational state.
The exact set of necessary credentials will vary based on the WoT device's deployment model and choice of security mechanisms.
The document <cite>The State-of-the-Art and Challenges for the Internet of Things Security</cite> [[Garcia17]]
refers to this stage as "Bootstrapping".</li>
<li><strong>Operational:</strong> The default operational state of WoT devices.
Devices in this state are fully ready to communicate over WoT interfaces and satisfy their deployment's operational roles.
From the Operational state a device can return to the Manufactured state
if it is fully decommissioned and security de-provisioned
(link E in Figure <a href="#wot-lifecycle"></a>).
It is also possible to perform only a partial reset of a device,
if it only requires re-installation and recommissioning without security re-provisioning
(link D in Figure <a href="#wot-lifecycle"></a>).
It is also possible that only security re-provisioning is needed
without re-installation and re-commissioning (link C in Figure <a href="#wot-lifecycle"></a>).</li>
<li><strong>Maintenance and Security Update:</strong>
A state that is entered when the device's software or configuration needs to be updated.
This is an optional state that can be activated remotely or locally (link A in Figure <a href="#wot-lifecycle"></a>)
on a WoT device depending on the deployment model and overall setup.
This state can be required to maintain security,
for example to patch SW vulnerabilities or perform security-related configuration updates,
such as key revocation or certificate refresh.
After maintenance or updates are done,
the device normally returns to the Operational state (link B in Figure <a href="#wot-lifecycle"></a>). </li>
</ul>
The scope of this document only covers the Operational State of a WoT device
with the assumption that all relevant security metadata and credentials has been
successfully provisioned during the Security Provisioning state and
are available transparently to the WoT runtime level.
Security-related system management updates (such as the revocation and update of keys and other credentials),
while important to maintaining the security of a system, are considered to be out of the scope of this document.
</p>
</section>
<section>
<h1>Requirements</h1>
<section>
<h2>General</h2>
<p>
In general using the WoT approach should "do no harm": the security of any protocols should be maintained.
The Web of Things does not introduce new security mechanisms,
but should preserve the functionality and security of existing mechanisms.
We also have the following requirements:
<ul>
<li><strong>Exposing:</strong>
When exposing a TD, especially via the Scripting API,
it should be possible to use best practices for security,
including maintaining the integrity of the TD and delivering it only to authorized recipients.</li>
<li><strong>Consuming:</strong>
A consumed TD should accurately reflect the actual security status of the device it describes.</li>
<li><strong>Protocols:</strong>
The WoT can potentially apply to many protocols but to limit scope in this
discussion we will focus on the needs of HTTP(S), CoAP(S), and MQTT(S).</li>
</ul>
</p>
</section>
<section id="wot-threat-model">
<h2>Threat Model</h2>
<p>
Due to the large diversity of devices, use cases,
deployment scenarios and requirements for WoT Things,
it is impossible to define a single WoT threat model that would fit every case.
Instead we describe here an overall WoT threat model framework that can be adjusted
by OEMs or other WoT system users or providers based on their concrete security requirements.
This framework gives a set of possible threats that implementers should
consider, but which may or may not apply to their system.
</p>
<p>
When selecting suitable mitigations to the WoT threats described, it is important to consider various
criteria that might increase the risk level for a particular WoT architecture, such as handing
privacy-sensitive data, physical safety of individuals or the surrounding environment, high
availability requirements, and so forth.
In addition threat mitigations will always be limited by the capabilities of underlying
devices, their list of supported security protocols, processes isolation capabilities, etc.
</p>
<section id="wot-threat-model-stakeholders">
<h3>WoT Primary Stakeholders</h3>
<p>This section lists the primary WoT stakeholders.</p>
<table>
<tr>
<th>Stakeholder</th>
<th>Description</th>
<th>Security goals</th>
<th>Edge cases</th>
</tr><tr>
<th><dfn data-lt="device manufacturer|device manufacturers|manufacturer|oem">
Device Manufacturer</dfn> (OEM)</th>
<td>
Producer of the HW device.
Implements the WoT runtime on the device,
defines Things that the device provides, and generates TDs for these Things.</td>
<td>
Don't want the devices they make to be used in any form of attack
(due to loss of reputation and possible legal consequences in some countries).
Want to satisfy the security requirements of <a>System users</a>
and <a>System providers</a> to maximize HW sales.</td>
<td></td>
</tr><tr>
<th><dfn data-lt="system provider|system providers">
System Provider</dfn><br/> or
<dfn data-lt="system integrator|system integrators">
System Integrator</dfn><br/> or
<dfn data-lt="system installer|system installers">
System Installer</dfn></th>
<td>
Uses devices from <a>OEM</a>s to build various WoT end solutions
specific to particular WoT use case(s).
An <a>OEM</a> might simultaneously be a System Provider,
although System Providers might also
define new TDs or modify TDs provided by other entities (<a>OEM</a>s).
System Providers
might use the WoT scripting API and runtime to implement their solution
or might do a full reflash of the device to install their own software stack.
A System Provider's scripts and their configuration data might require
confidentiality and/or integrity.
A System Integrator/Installer is similar to a System Provider but tends to
reuse rather than create new technology.
</td>
<td>Don't want their WoT network to be a target of any attacks
(loss of reputation, possible legal consequences in some countries).
Want to satisfy security requirements of System users for better sales.
Don't want security to interfere with usability for better sales
(usability vs. security).
<!-- Is "DOS resistance" a defined term? If so, where are they defined, and do we need links? -->
Want their WoT network to be robust and be resistant to DoS attacks.
Want to hide their proprietary scripts and other relevant data from other parties.
</td>
<td>
There might be several independent system providers (tenants) on a single HW device.
In that case isolation between them is required while (perhaps) sharing
user preferences and identification.
</td>
</tr><tr>
<th><dfn data-lt="system user|system users">System User</dfn></th>
<td>
These might be physical users (e.g. John and his family in their smart home)
or abstract users (e.g. the company running a factory).
The primary characteristic of this stakeholder is the need to use
the WoT Network to obtain some functionality.
System Users entrust WoT systems with their data
(video streams from home cameras or factory plans) or physical capabilities
in the surrounding environment (put lights on in a room or start a machine on the factory line).
They might differ in their access to the WoT network
and transferred data (for example, they might only be able to configure
certain parts of the network or only use it as it is).
</td>
<!-- TODO: Are Data confidentiality and Data integrity defined terms? If so, where are they defined... in requirements? Should they be marked with links? -->
<td>
Don't want their data to be exposed to any other System User,
<a>System Provider</a> or <a>OEM</a> unless intended (Data Confidentiality).
Don't want their data to be modified unless intended (Data Integrity).</td>
<td>Access to user data might be configurable based not only on "who"
is the entity accessing the data (access control subject),
but also his/her/its role,
type of access, or time and context.</td>
</tr><tr>
<th><dfn data-lt="system owner|system owners">System Owner</dfn></th>
<td>
An entity that provisions a thing with the security root of trust
and sets up the initial policies on who can provision/update/remove scripts
to/from the WoT runtimes, if such model is supported.
Any of the above stakholders can be the System Owner depending on the
concrete setup.
A WoT system might have a number of independent System Owners,
each with their own set of provisioned certificates and/or credentials.
Underlying IoT protocol suites may also have their own notion of ownership.
</td>
<td>
Want to have a full control over their own provisioned security credentials,
including their integrity and confidentiality.
</td>
<td></td>
</tr><tr>
<th><dfn data-lt="system maintainer|system maintainers">System Maintainer</dfn></th>
<td>
This is an optional stakeholder.
It administers a WoT system on behalf of a <a>System Provider</a>
or <a>System User</a>
</td>
<td>
Needs to have enough access to the WoT system to perform its dutes.
Should have minimal (ideally none) access to the data of other stakeholders.
</td>
<td></td>
</tr>
</table>
</section>
<section id="wot-threat-model-assets">
<h3>Assets</h3>
<p>This section lists all WoT Assets that are important from a security point of view.</p>
<table>
<tr>
<th>Asset</th>
<th>Description</th>
<th>Who should have access<br/>(Trust Model)</th>
<th>Attack Points</th>
</tr><tr>
<th><dfn data-lt="thing descriptions|td|tds">
Thing Description</dfn> (TD)</th>
<td>Access Control policies for TDs and the resources it describes are part of TDs.
They are managed using a discretionary access control model
(the owner of a TD sets the AC policy).
Some contents of TDs might be privacy sensitive and therefore should not be shared without a specific need.
The integrity of TDs is crucial for the correct operation of a WoT system.
</td>
<td>TD owner: full access<br/>
Others: read only for minimal required part.</td>
<td>Storage on thing itself, cloud storage, in-transfer (network) including TD updates.</td>
</tr><tr>
<th><dfn data-lt="system user data">System User Data</dfn></th>
<td>This includes all data that is produced or processed by the elements of a WoT system,
i.e. sensor readings and their states, user configurations and preferences, actuator commands,
video/audio streams, etc. Can be highly privacy sensitive and confidential.</td>
<td>Different <a>System Users</a> might have different levels of
access to this data based on the use case. In some cases (like user preferences or settings)
the partial access to this asset is also needed by a <a>System Provider</a>.
Non-authorized access must be minimized since access even to a small amount of information
(for example the last timestamp when a door lock API was used) might have severe
privacy concerns (this example would allow an attacker to detect when the owner is away
from his house).
Security mechanisms should be flexible to configure and might also need to include RBAC.<br/>
Others: should have no access unless specifically allowed</td>
<td>Storage on the device itself, remote solution provider storage (Cloud or other),
in-transfer (network)</td>
</tr><tr>
<th><dfn data-lt="system provider scripts|system provider script">
System Provider Data</dfn>
<td>This includes both WoT scripts and any WoT configuration data produced and owned by a
<a>System Provider</a>. It also includes Thing instances, i.e.
run-time representations of scripts running inside a WoT Runtime.
<a>System providers</a> might have Intellectual Property (IP) in their scripts,
making them highly confidential.
Protocol Bindings might be part of System Provider Data,
if a WoT device has a single System Provider that
installs and configures WoT Runtime and Protocol Bindings.
However, these can be also provided and confgured by the OEM,
and the same Protocol Bindings could be used by
multiple System Providers on the same device. </td>
<td><a>System Provider</a>: full access<br/>
Others: no access</td>
<td>Storage on the device itself, runtime memory representation,
in-transfer only for initial provisioning and script updates
</td>
</tr><tr>
<th><dfn data-lt="thing resource">
WoT Thing Resources</dfn><br/> and
<dfn data-lt="wot infrastructure resource">
WoT Infrastructure Resources</dfn></th>
<td>Resources should only be used for legitimate purposes and be available when required.</td>
<td><a>System User</a>, <a>System Provider</a></td>
<!-- TODO: "WoT Interface" is a term for the network API of a Thing
defined in the WoT architecture document. How do we refer to these,
and can we link to their definitions? -->
<td>WoT Interface</td>
</tr><tr>
<th><dfn>WoT Controlled Environment</dfn></th>
<td>WoT devices that have actuator capabilities are able to affect the physical environment
around them.
Such capability must only be used by authorized entities and for legitimate purposes.
An actuator capability also implies a possible safety risk.</td>
<td><a>System User</a>, <a>System Provider</a> and whoever is explicitly authorized by them to control the environment. </td>
<td>WoT Interface</td>
</tr><tr>
<th><dfn>WoT Behavior Metrics</dfn></th>
<td>Indirectly transmitted information (metadata) that represents measurements of
a WoT system's behavior from which other information can be inferred, such as user presence.
For example, the amount of communication between different things,
the APIs used, distribution of communication over time, etc.</td>
<td>It should not be possible to collect/identify indirectly transferable information</td>
<td>In-transfer data and usage of WoT Interface</td>
</tr><tr>
<th><dfn>WoT Basic Security Metadata</dfn></th>
<td>All required security metadata (keys, certificates etc.) that might be provisioned
to the WoT device in order to be able to perform various security-related operations,
such as authenticating another device or WoT client in the WoT network,
authenticating remote authorization service in case the access control to WoT interfaces is done using tokens, etc.</td>
<td>Thing Manager (if present in WoT Runtime), WoT Runtime </td>
<td> On device storage, in-transfer including provisioning and updates of security metadata.
</td>
</tr>
</table>
<p>The term <dfn>Thing Data</dfn> can be used to refer to either
<a>System User Data</a> or <a>System Provider Data</a>.</p>
<p>If a WoT system supports dynamic installation of scripts
inside WoT runtime, the following assets are added:</p>
<table>
<tr>
<th>Asset</th>
<th>Description</th>
<th>Who should have access?</br>(Trust Model)</th>
<th>Attack Points</th>
</tr><tr>
<th><dfn>WoT Script Security Metadata</dfn></th>
<td>Defines who can provision, install, update, and remove scripts and other
<a>System Provider Data</a> inside a WoT runtime.</td>
<td><a>System Provider</a>, <a>System Maintainer</a></td>
<td>WoT Script Management Interface</td>
</tr>
</table>
<p>If a WoT system allows co-existence of different independent <a>System Providers</a> (tenants)
on a single physical device, the following assets are added:</p>
<table>
<tr>
<th>Asset</th>
<th>Description</th>
<th>Who should have access?</br>(Trust Model)</th>
<th>Attack Points</th>
</tr><tr>
<th><dfn>WoT Runtime Isolation Policies</dfn></th>
<td>Access control policies for isolating co-existing system providers on the device.
Not required if a simple baseline policy of "full isolation" is applied
to different WoT Runtimes running scripts from different System providers.
It might be required if some level of data sharing between them is needed. </td>
<td><a>System Provider</a>, <a>System Maintainer</a></td>
<td>Storage on the thing itself, remote storage (if they are backed up to a remote storage),
in-transfer for initial provisioning and policy updates</td>
</tr>
</table>
</section>
<section id="wot-threat-adversaries">
<h3>Adversaries</h3>
<p>The following adversaries are in-scope for the WoT threat model: </p>
<table>
<tr>
<th>Persona</th>
<th>Motivation</th>
<th>Attacker type</th>
</tr><tr>
<th><dfn>Network Attacker</dfn></th>
<td>Unauthorized access or modification of any stakeholder's asset over the network.
Denial of service. Inferring of non-public or privacy sensitive information.
Taking control of the network component of a WoT system. Reasons: money, fame etc.</td>
<td>Network attack: an attacker has network access to a WoT system,
is able to use WoT Interface, perform Man-in-the-Middle (MitM) attacks,
drop, delay, reorder, re-play, and inject messages.
This attacker type also includes a passive network attacker, where an attacker is only able to passively
observe the WoT network traffic.</td>
</tr><tr>
<th><dfn data-lt="malicious authorized solution user|malicious authorized solution users|malicious authorized users">
Malicious Authorized User</dfn></th>
<td>Unauthorized access of private data of any other stakeholder (eavesdropping).
Unauthorized modification of data of any stakeholder
(modification of sensor data, or script modification).
Obtaining higher privileges than originally intended by the <a>System Owner</a>
(for example, a hotel guest trying to control overall hotel lighting).</td>
<td>Local physical access, WoT Client interface (smartphone, web interface, washing machine interface, etc.)</td>
</tr><tr>
<th><dfn data-lt="malicious unauthorized solution user|malicious unauthorized solution users|malicious unauthorized users">
Malicious Unauthorized User</th>
<td>Similar to <a>Malicious Authorized User</a>,
but with no prior access to the WoT system
(examples: guests in a house, guests in a factory).
Denial of service attacks on WoT network.
</td>
<td>Limited local physical network access, can use proximity factor</td>
</tr><tr>
<th><dfn>Malware Developer</dfn></th>
<td>Unauthorized access or modification of any stakeholder's asset.
Denial of service attacks on WoT network.
Taking control of WoT system network components.
Reasons: money, fame etc.</td>
<td>Unprivileged software adversary:
application intentionally gets installed or code injected into
WoT client (user's smartphone, browser, etc.)
or in WoT runtime itself using available WoT Interfaces</td>
</tr>
</table>
<p>The general term <dfn data-lt="malicious users">Malicious User</dfn> may be used to refer to either a
<a>Malicious Authorized User</a> or a <a>Malicious Unauthorized User</a>.</p>
<p>If a WoT system allows the co-existence of different independent System providers (tenants)
on a single physical device, the following adversaries are added:</p>
<table>
<tr>
<th>Persona</th>
<th>Motivation</th>
<th>Attacker Type</th>
</tr><tr>
<th><dfn>Malicious System Provider</dfn></td>
<td>Tries to get access or modify other <a>System Provider Data</a>,
tries to access or modify <a>System User Data</a> from another solution provider.</td>
<td>Unprivileged software adversary:
<a>System provider scripts</a> running on the same HW device, but inside a different WoT runtime</td>
</tr>
</table>
<p>The following adversaries are out of scope of the WoT threat model:</p>
<table>
<tr>
<th>Persona</th>
<th>Motivation</th>
<th>Attacker Type</th>
</tr><tr>
<th><dfn>Malicious OEM</dfn></th>
<td>Intentionally installs HW, firmware or other lower SW level backdoors,
rootkits etc.
in order to get unauthorized access to WoT assets or affect WoT system in any form</td>
<td>Local physical access, privileged access</td>
</tr><tr>
<th><dfn>Careless OEM</dfn></th>
<td>In order to reduce production costs substitutes security validated original
HW parts with low quality unvalidated replacement parts potentially impacting security.</td>
<td>Local physical access, privileged access</td>
</tr><tr>
<th><dfn>Careless System Provider</dfn></th>
<td>In order to reduce solution deployment costs utilizes low quality SW,
performs poor testing, misconfigures hardware or software,
TDs and/or access control policies.</td>
<td>Local physical access, privileged access</td>
</tr><tr>
<th><dfn>Non-WoT End Point Attacker</dfn></th>
<td>Tries to get authorized access/modify any asset stored at non-WoT end points
(Cloud, non-WoT devices etc.) Reasons: monetary, fame etc.</td>
<td>Remote or local attack</td>
</tr>
</table>
</section>
<section id="wot-threat-model-attack-surfaces">
<h3>Attack Surfaces</h3>
<p>In order to correctly define WoT attack surfaces one needs to determine the system's
trust model as well as execution context boundaries.
A high-level view of the WoT architecture from the security point of view is presented in
<a href="#wot-security-fig-attack-surfaces"></a>,
showing all possible execution boundaries.
However, in practice certain execution boundaries might not be present as they are
dependent on the actual device implementation.</p>
<figure id="wot-security-fig-attack-surfaces">
<img src="images/WoTArchSecurityView.png"
width="100%"
title="WoT High-Level Architecture Security View"/>
<figcaption>WoT High-Level Architecture Security View</figcaption>
</figure>
<p>The main execution boundaries for WoT system are:</p>
<table>
<tr>
<th>Boundary</th>
<th>Description</th>
<th>Notes</th>
</tr><tr>
<th><dfn>Script Execution Boundary</dfn></th>
<td>Separates execution contexts between different Thing Instances.
If present,
this boundary should be implemented either as having different script runtime
contexts (with WoT runtime isolation means)
or by having separate process execution contexts
(with OS process isolation means)</td>
<td>This boundary is required if we assume that WoT Runtime can run untrusted scripts
or if some scripts have a higher chance of being compromised remotely</td>
</tr><tr>
<th><dfn>WoT Runtime Instance Execution Boundary</dfn></th>
<td>Separates execution contexts between different WoT Runtime instances.
If present,
this boundary should be implemented using at least with OS process isolation,
but in addition can be implemented using any stronger security measures available
on the device (Mandatory Access Control, OS-kernel level virtualization,
Full Virtualization etc.)</td>
<td>This boundary is required if we assume that we have different <a>System Providers</a>
running on the same device in different WoT Runtime Instances.</td>
</tr><tr>
<th><dfn>WoT Execution Boundary</dfn></th>
<td>Separates execution contexts between WoT runtime
(including WoT Protocol Bindings) and the rest of the system.
If present,
this boundary should be implemented at least using OS process isolation,
but in addition can be implemented using any stronger security measures available
on the device (Mandatory Access Control, OS-kernel level virtualization,
Full Virtualization etc.)</td>
<td>This boundary is required if we assume that WoT Runtime might run untrusted scripts
or there might be untrusted Protocol Bindings present.
It is also required if a device also runs a non-WoT SW stack
and elements of that stack can potentially be compromised</td>
</tr><tr>
<!-- TODO: split into two items? -->
<th><dfn>WoT Runtime and Protocol Bindings Execution Boundaries</dfn></th>
<td>Separate execution contexts between WoT runtime and Protocol Bindings.
If present,
these boundaries should be implemented at least using OS process isolation.</td>
<td>These boundaries might be needed if we assume that a WoT Runtime can run untrusted scripts
and would like to implement additional access control measures
at the Protocol Binding level.</td>
</tr>
</table>
<p>The following WoT attack surfaces are always in-scope for the WoT Security model:</p>
<table>
<tr>
<th>System Element</th>
<th>Compromise Type(s)</th>
<th>Assets Exposed</th>
<th>Attack Method</th>
</tr><tr>
<th>WoT Interface</th>
<td>Modification or unauthorized access to any affected asset,
Unauthorized execution of exposed WoT Interfaces,
Denial of Service</td>
<td><a>TDs</a>,
<a>System User Data</a>,
<a>WoT Thing Resources</a>,
<a>WoT Infrastructure Resources</a>,
<a>WoT Controlled Environment</a>,
<a>WoT Behavior Metrics</a></td>
<td>Network attack</td>
</tr><tr>
<th>WoT Protocol Bindings</th>
<td>Modification or unauthorized access to any affected asset,
Unauthorized execution of exposed WoT Protocol Bindings,
Denial of Service</td>
<td> <a>System User Data</a>,
<a>WoT Thing Resources</a>,
<a>WoT Infrastructure Resources</a>,
<a>WoT Controlled Environment</a>,
<a>WoT Behavior Metrics</a></td>
<td>Network attack</td>
</tr>
</table>
<p>The following WoT attack surfaces are only in-scope for the WoT security model
if we assume a WoT runtime can run untrusted scripts
or we assume co-existence of different <a>System Providers</a> (tenants)
on a single physical device:</p>
<table>
<tr>
<th>System Element</th>
<th>Compromise Type(s)</th>
<th>Assets Exposed</th>
<th>Attack Method</th>
</tr><tr>
<td><a>Script Execution Boundary</a></td>
<td>Modification or unauthorized access to any asset available
to other scripts.
Denial of Service</td>
<td><a>TDs</a>,
<a>System User Data</a>,
<a>WoT Thing Resources</a>,
<a>WoT Infrastructure Resources</a>,
<a>WoT Controlled Environment</a></td>
<td>Local attack by an untrusted WoT script using WoT Scripting
API or any native OS local method.</a></td>
</tr><tr>