-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
2417 lines (1980 loc) · 267 KB
/
index.html
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">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<link rel="stylesheet" type="text/css" href="style.css">
<title>Vera Clemens | Master's Thesis | Software Updates for the Internet of Things</title>
</head>
<body>
<main id="wrapper">
<div id="titlepage-triangle"></div>
<div id="titlepage-triangle-text">
<a href="https://github.com/vera/vera.github.io" target="_blank">
Find this page on<br/>
<img src="img/github-logo.svg" alt="GitHub"/></a>
</div>
<header id="titlepage">
<div>
<h1 id="title">Software Updates for the Internet of Things</h1>
<p id="subtitle">An Extension and Evaluation of the SUIT Implementation in RIOT</p>
</div>
<p id="thesis-type">Master's Thesis</p>
<p id="author">Vera Clemens</p>
<div>
<p id="supervisors">
Supervisor: Prof. Dr. rer. nat. Mesut Güneş<br/>
Assisting Supervisor: M.Sc. Marian Buschsieweke
</p>
<hr>
<p id="institution">Institute for Intelligent Cooperating Systems, Otto von Guericke University Magdeburg</p>
</div>
<p>July 01, 2021</p>
</header>
<nav id="nav">
<div id="prev-section-link">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="22px" height="18px" viewBox="-0.5 -0.5 22 18"><defs/>
<g>
<path d="M 1 1 L 11 6" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow3" />
<path d="M 10.1 6 L 20.1 1" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow3" />
<path d="M 1 6 L 11 11" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow2" />
<path d="M 10.1 11 L 20.1 6" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow2" />
<path d="M 1 11 L 11 16" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" id="section-arrow1" />
<path d="M 10.1 16 L 20.1 11" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow1" />
</g>
</svg>
<span>Swipe for prev. section</span>
</div>
<a href="#toc" id="toc-link">Jump to ToC</a>
<div id="next-section-link">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="22px" height="18px" viewBox="-0.5 -0.5 22 18"><defs/>
<g>
<path d="M 1 6 L 11 1" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow1" />
<path d="M 10.1 1 L 20.1 6" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow1" />
<path d="M 1 11 L 11 6" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow2" />
<path d="M 10.1 6 L 20.1 11" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow2" />
<path d="M 1 16 L 11 11" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow3" />
<path d="M 10.1 11 L 20.1 16" fill="none" stroke="rgb(68,85,255)" stroke-width="2" stroke-miterlimit="10" pointer-events="none" class="section-arrow3" />
</g>
</svg>
<span>Swipe for next section</span>
</div>
</nav>
<section id="abstract">
<h1>Abstract</h1>
<p>Firmware updates are essential for the secure operation of <a href="#acr-iot">IoT</a> devices, as several recent examples of uncovered security flaws in <a href="#acr-iot">IoT</a> device firmware show.
Firmware update mechanisms must fulfil several requirements.
Firstly, as <a href="#acr-iot">IoT</a> devices are constrained in terms of available computing power, memory, battery power, and network bandwidth, firmware update processes must be designed with special consideration to these constraints.
Secondly, firmware update mechanisms must be secure; if they are not, they allow an attacker to exhaust the device's resources through a <a href="#acr-dos">DoS</a> attack, block the installation of security patches, or even install arbitrary firmware.
Thirdly, ease of use for the <a href="#acr-iot">IoT</a> device owner must be considered; ideally, it should be possible to install firmware updates without manual user intervention and they should cause minimal service downtime.
The <a href="#acr-suit">SUIT</a> working group at the <a href="#acr-ietf">IETF</a> has published a draft for a standardized firmware update process that is designed to fulfil these requirements.
<a href="#acr-suit">SUIT</a> has already been implemented for the <a href="#acr-iot">IoT</a> operating system RIOT using <a href="#acr-coap">CoAP</a> as the application layer protocol to transmit the update.
In this work, we first analyse the requirements for secure software update mechanisms in the context of the <a href="#acr-iot">IoT</a> and provide a survey of existing mechanisms.
We then design a new transport mechanism that uses <a href="#acr-mqttsn">MQTT-SN</a> and extend RIOT's implementation with it.
Finally, we evaluate and compare the transport mechanisms <a href="#acr-mqttsn">MQTT-SN</a> and <a href="#acr-coap">CoAP</a> in a realistic testbed environment with respect to their resource requirements (flash memory, RAM and energy consumption), network protocol overhead, total update duration, and their scalability, i.e. ability to update multiple devices in parallel.
</section>
<section id="toc">
<h1>Contents</h1>
<ol>
<li><a href="#chapter1">Introduction</a></li>
<li>
<a href="#chapter2">Background: Application Layer Protocols for the Internet of Things</a>
<ol>
<li><a href="#sec-background-coap">Constrained Application Protocol (CoAP)</a></li>
<li><a href="#sec-background-mqtt">Message Queuing Telemetry Transport (MQTT)</a></li>
<li><a href="#sec-background-mqtt-sn">MQTT for Sensor Networks (MQTT-SN)</a></li>
<li><a href="#sec-app-layer-comp">Comparison</a></li>
</ol>
</li>
<li>
<a href="#chapter3">Related Work</a>
<ol>
<li><a href="#sec-rel-work-comp">Comparative Evaluations of CoAP, MQTT and MQTT-SN</a></li>
<li><a href="#sec-requirements">Requirements for Software Update Mechanisms</a></li>
<li><a href="#sec-lit-review">Software Update Mechanisms</a></li>
</ol>
</li>
<li>
<a href="#chapter4">Thesis Contribution: A New Transport Mechanism for SUIT Using MQTT-SN</a>
<ol>
<li><a href="#sec-design">Design</a></li>
<li><a href="#sec-implementation">Implementation</a></li>
</ol>
</li>
<li>
<a href="#chapter5">Thesis Outcome: Evaluation and Comparison</a>
<ol>
<li><a href="#sec-eval-setup">Setup</a></li>
<li><a href="#sec-eval-methods">Methods</a></li>
<li><a href="#sec-eval-results">Results</a></li>
<li><a href="#sec-eval-conclusion">Conclusion</a></li>
</ol>
</li>
<li>
<a href="#chapter6">Conclusion</a>
<ol>
<li><a href="#sec-summary">Summary</a></li>
<li><a href="#sec-future-work">Future Work</a></li>
</ol>
</li>
<li><a href="#bibliography">Bibliography</a></li>
</ol>
</section>
<section id="acronyms">
<h1>Acronyms</h1>
<dl>
<dt id="acr-6lowpan">6LoWPAN</dt>
<dd>IPv6 over Low-Power Wireless Personal Area Networks</dd>
<!-- <dd><a href="">Return to text</a></dd> -->
<dt id="acr-amqp">AMQP</dt>
<dd>Advanced Message Queueing Protocol</dd>
<dt id="acr-cbor">CBOR</dt>
<dd>Concise Binary Object Representation</dd>
<dt id="acr-coap">CoAP</dt>
<dd>Constrained Application Protocol</dd>
<dt id="acr-cose">COSE</dt>
<dd>CBOR Object Signing and Encryption</dd>
<dt id="acr-ddos">DDoS</dt>
<dd>Distributed Denial of Service</dd>
<dt id="acr-dds">DDS</dt>
<dd>Data Distribution Service</dd>
<dt id="acr-dos">DoS</dt>
<dd>Denial of Service</dd>
<dt id="acr-dtls">DTLS</dt>
<dd>Datagram Transport Layer Security</dd>
<dt id="acr-http">HTTP</dt>
<dd>Hypertext Transfer Protocol</dd>
<dt id="acr-iana">IANA</dt>
<dd>Internet Assigned Numbers Authority</dd>
<dt id="acr-ieee">IEEE</dt>
<dd>Institute of Electrical and Electronics Engineers</dd>
<dt id="acr-ietf">IETF</dt>
<dd>Internet Engineering Task Force</dd>
<dt id="acr-iot">IoT</dt>
<dd>Internet of Things</dd>
<dt id="acr-ip">IP</dt>
<dd>Internet Protocol</dd>
<dt id="acr-ipv6">IPv6</dt>
<dd>Internet Protocol version 6</dd>
<dt id="acr-lwm2m">LwM2M</dt>
<dd>Lightweight Machine-to-Machine</dd>
<dt id="acr-maclayer">MAC</dt>
<dd>Media Access Control</dd>
<dt id="acr-mac">MAC</dt>
<dd>Message Authentication Code</dd>
<dt id="acr-miot-lab">MIoT Lab</dt>
<dd>Magdeburg Internet of Things Lab</dd>
<dt id="acr-mqtt">MQTT</dt>
<dd>Message Queuing Telemetry Transport</dd>
<dt id="acr-mqttsn">MQTT-SN</dt>
<dd>MQTT For Sensor Networks</dd>
<dt id="acr-mtu">MTU</dt>
<dd>Maximum Transmission Unit</dd>
<dt id="acr-nist">NIST</dt>
<dd>National Institute of Standards and Technology</dd>
<dt id="acr-os">OS</dt>
<dd>Operating System</dd>
<dt id="acr-ota">OTA</dt>
<dd>Over-The-Air</dd>
<dt id="acr-qos">QoS</dt>
<dd>Quality of Service</dd>
<dt id="acr-ram">RAM</dt>
<dd>Random Access Memory</dd>
<dt id="acr-rsmb">RSMB</dt>
<dd>Really Small Message Broker</dd>
<dt id="acr-rssi">RSSI</dt>
<dd>Received Signal Strength Indication</dd>
<dt id="acr-rtt">RTT</dt>
<dd>Round Trip Time</dd>
<dt id="acr-suit">SUIT</dt>
<dd>Software Updates for Internet of Things</dd>
<dt id="acr-tcp">TCP</dt>
<dd>Transmission Control Protocol</dd>
<dt id="acr-tdma">TDMA</dt>
<dd>Time Division Multiple Access</dd>
<dt id="acr-tuf">TUF</dt>
<dd>The Update Framework</dd>
<dt id="acr-udp">UDP</dt>
<dd>User Datagram Protocol</dd>
<dt id="acr-uri">URI</dt>
<dd>Uniform Resource Identifier</dd>
<dt id="acr-xmpp">XMPP</dt>
<dd>Extensible Messaging and Presence Protocol</dd>
</dl>
</section>
<section id="chapter1" class="chapter" data-chapter-num="1">
<header>
<p class="chapter-num"></p>
<h1>Introduction</h1>
</header>
<p>In contrast to the standard Internet, where humans are senders or receivers of information, the <a href="#acr-iot">IoT</a> consists of non-human “things”, e.g. lightbulbs or fridges, that communicate with each other using Internet protocols.
They are usually low-powered devices with relatively limited memory and computing capabilities.
Since the expected lifetimes of those devices are of considerable length, it must be possible to update their firmware when bugs or security problems become known. Otherwise, the devices run the risk of malfunctioning or becoming compromised, especially if they are connected to the public Internet.</p>
<p>Several cases of security flaws in <a href="#acr-iot">IoT</a> devices that have become known in the past couple of years have illustrated why software updates for <a href="#acr-iot">IoT</a> devices are so important.
For example, in 2016, security flaws were found in <a href="#acr-iot">IoT</a> surveillance cameras that had been sold in German and Swiss supermarkets. The cameras came with an insecure default configuration in which no password is set for the control panel, and automatically set up a port forwarding in the home router to make their video and audio streams publicly available over the Internet.
A firmware update addressing the vulnerability had actually been available for months at the time of publication, however, over a third of scanned devices were still vulnerable <a href="#heise2016ip">[1]</a>.
In 2020, the so-called “Ripple20” vulnerabilties were found in a TCP/IP implementation which was used by hundreds of millions of embedded and <a href="#acr-iot">IoT</a> devices. Some of them allowed remote code execution. In response to this, an updated version of the implementation was released; however, it was difficult to identify all of the affected devices,
and it was expected that some of the affected devices cannot or will not ever have their firmware updated <a href="#jsof2020cve11896">[2]</a>.
An analysis of firmware images for over sixty different HP printer models found that over 80% of them contained third-party software with known vulnerabilities <a href="#cui2013firmware">[3]</a>.
Finally, the Mirai botnet illustrates the magnitude of attacks that are possible using <a href="#acr-iot">IoT</a> devices. The botnet was involved in some of the largest known <a href="#acr-ddos">DDoS</a> attacks ever in 2016. At its peak, it had infected approximately 600,000 <a href="#acr-iot">IoT</a> and embedded devices worldwide <a href="#antonakakis2017understanding">[4]</a>.</p>
<p>These examples make it obvious that software updates are an important part of the operation and maintenance phase in the lifecycle of an <a href="#acr-iot">IoT</a> device.
The need for software updates for <a href="#acr-iot">IoT</a> devices is already widely acknowledged by security experts, but more recently also by the European legislature.
At the time of writing, the most recent security guidelines published by the German Federal Office for Information Security (German: “Bundesamt für Sicherheit in der Informationstechnik” (BSI))
and the American <a href="#acr-nist">NIST</a> both list the installation of firmware updates, especially security patches, as a basic requirement for the secure operation of <a href="#acr-iot">IoT</a> devices <a href="#bsi2020iot">[5, pp. 3–4]</a><a href="#nistir8259a">[6, p. 9]</a>.
The issue has even been acknowledged by European legislature: In May 2019, the European parliament passed a directive <a href="#eu2019-771">[7]</a> which establishes a new right for consumers to receive necessary software updates for purchased goods with digital elements such as <a href="#acr-iot">IoT</a> devices.
The German Federal Ministry of Justice and Consumer Protection
has already published a draft bill implementing the directive <a href="#refe-wkrl">[8]</a>, which assumes an average length of five years during which the manufacturer is required to provide these software updates, starting at the date of purchase.</p>
<p>However, there are several different problems with the current practices for <a href="#acr-iot">IoT</a> software updates.
Some of them have been noted by Schneier <a href="#schneier2014unpatchable">[9]</a>,
who points out that there are currently not enough incentives for <a href="#acr-iot">IoT</a> device vendors to provide software updates, and that there is no system through which device owners get notified of new software updates.
Furthermore, ease of use and user acceptance must be considered.
Currently, some device owners may lack the expertise required to install firmware updates on their devices.
One survey found that in general, the average user is not likely to immediately install software updates when prompted, e.g. due to inconvenience or past negative experiences with buggy updates <a href="#ion2015no">[10]</a>.
It must also be taken care that the software update process itself is secure and does not introduce new attack vectors, such as installation of a malicious software, rollbacks of security fixes, and <a href="#acr-dos">DoS</a> attacks that exhaust a device's resources (e.g. battery power) by continually attempting illegitimate updates.
For example, a vulnerability was found in the remote firmware update functionality used in HP LaserJet printers that allowed an attacker to install arbitrary firmware because updates were only authenticated using checksums and not signed <a href="#cui2013firmware">[3]</a>. The printers also did not require any administrator user authentication; anyone who was allowed to print could also install updates.
Even if cryptographic signatures are used, attackers may compromise the signing keys. For example, Ronen et al. were able to extract the secret key used to encrypt and sign updates which was shared by many Philips Hue devices, and use it to sign and install malicious firmware <a href="#ronen2017iot">[11]</a>.</p>
<p>In answer to these problems, the working group <a href="#acr-suit">SUIT</a> at the <a href="#acr-ietf">IETF</a>
is currently working on a standardized software update solution for <a href="#acr-iot">IoT</a> devices.
The solution is intended to work even for constrained devices with as little as ~10 KiB <a href="#acr-ram">RAM</a> and ~100 KiB flash memory (Class 1 devices <a href="#rfc7228">[12]</a>).
Their efforts focus mainly on standardizing a format for the software's metadata (also known as “manifest”), the software update architecture and the security mechanisms used to prevent attacks.
They do not aim to standardize the mechanisms for transmitting the update to the devices,
since <a href="#acr-iot">IoT</a> device operators are expected to already have certain infrastructure in place.
Thus, <a href="#acr-suit">SUIT</a> aims to support all application layer (e.g. <a href="#acr-mqtt">MQTT</a>, <a href="#acr-coap">CoAP</a>) and lower layer protocols (e.g. WiFi, IEEE 802.15.4) commonly used by <a href="#acr-iot">IoT</a> devices.
It must be noted that the majority of the <a href="#acr-suit">SUIT</a> documents [<a href="#rfc9019">13</a>, <a href="#ietf-suit-manifest-12">14</a>, <a href="#ietf-suit-information-model-11">15</a>] are still in draft status and <a href="#acr-suit">SUIT</a> must thus be considered a work in progress.</p>
<p>The aim of this work is firstly to design and implement an extension of the <a href="#acr-suit">SUIT</a> implementaton that is part of <a href="https://riot-os.org/">RIOT</a> <a href="#baccelli2012riot">[16]</a>, an <a href="#acr-os">OS</a> for the <a href="#acr-iot">IoT</a>, which allows it to use another application layer protocol for update transmission.
Prior to this work, only <a href="#acr-coap">CoAP</a> is supported.
Secondly, the aim is to evaluate resource requirements, communication overhead and duration of the software update transmission in an <a href="#acr-iot">IoT</a> testbed.
In summary, the contributions of this work are:</p>
<ul>
<li>Analysis and discussion of requirements for secure software update mechanisms in the context of the <a href="#acr-iot">IoT</a></li>
<li>Survey of other proposed update solutions and comparison with SUIT</li>
<li>Design and implementation of a new transport mechanism for <a href="#acr-suit">SUIT</a> using <a href="#acr-mqttsn">MQTT-SN</a></li>
<li>
Evaluation of the implementation and comparison of different transport mechanisms (<a href="#acr-mqttsn">MQTT-SN</a> and <a href="#acr-coap">CoAP</a>) in an <a href="#acr-iot">IoT</a> testbed under realistic conditions
<ul>
<li>Resource requirements (e.g. flash memory, <a href="#acr-ram">RAM</a>, energy consumption)</li>
<li>Network protocol overhead</li>
<li>Total duration of the firmware update</li>
<li>Scalability (updating multiple devices at once)</li>
</ul>
</li>
</ul>
<h5>Thesis Structure</h5>
The rest of this work is structured as follows:
<a href="#chapter2">Chapter 2</a> provides background information on the <a href="#acr-iot">IoT</a> networking stack, especially the application layer protocols <a href="#acr-coap">CoAP</a>, <a href="#acr-mqtt">MQTT</a>, and <a href="#acr-mqttsn">MQTT-SN</a>.
<a href="#chapter3">Chapter 3</a> gives an overview over related works: It contains a survey of performance comparisons of <a href="#acr-coap">CoAP</a>, <a href="#acr-mqtt">MQTT</a>, and <a href="#acr-mqttsn">MQTT-SN</a>.
It also contains the discussion of the general requirements of a secure software update mechanism for <a href="#acr-iot">IoT</a> devices, a survey on other proposed software update mechanisms in the literature, and finally a comparison of the different ways in which these solutions and <a href="#acr-suit">SUIT</a> aim to fulfil the requirements.
<a href="#chapter4">Chapter 4</a> describes the details of our implementation and also contains a discussion of design choices that were made.
<a href="#chapter5">Chapter 5</a> describes the design of our evaluation and its results.
<a href="#chapter6">Chapter 6</a> provides a summary and some pointers for future work on the topic.
</section>
<section id="chapter2" class="chapter" data-chapter-num="2">
<header>
<p class="chapter-num"></p>
<h1><a href="#chapter2">Background</a></h1>
</header>
<p>In this chapter, we provide background information on the application layer protocols used in this work: <a href="#acr-coap">CoAP</a>, <a href="#acr-mqtt">MQTT</a> and <a href="#acr-mqttsn">MQTT-SN</a>.</p>
<p>Below the application layer, we use a widely used network stack for the <a href="#acr-iot">IoT</a> that consists of IEEE 802.15.4, <a href="#acr-ipv6">IPv6</a> and <a href="#acr-udp">UDP</a> or <a href="#acr-tcp">TCP</a> [<a href="#palattella2012standardized">17</a>, <a href="#sheng2013survey">18</a>].
Because IEEE 802.15.4 limits the frame length to 127 B, but <a href="#acr-ipv6">IPv6</a> requires a minimum <a href="#acr-mtu">MTU</a> of 1280 B,
an adaptation layer is required in between.</p>
<p>This is provided by <a href="#acr-6lowpan">6LoWPAN</a>, which allows the transmission of <a href="#acr-ipv6">IPv6</a> packets over IEEE 802.15.4 by fragmenting them <a href="#rfc4944">[19]</a>. It also provides compression for <a href="#acr-ipv6">IPv6</a> and <a href="#acr-udp">UDP</a> headers to decrease overhead and prevent fragmentation for small payloads <a href="#rfc6282">[20]</a>.
See <a href="#fig-iot-stack">Figure 1</a> for a visual overview.</p>
<figure id="fig-iot-stack">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="331px" height="121px" viewBox="-0.5 -0.5 331 121"><defs></defs><g><rect x="0" y="0" width="330" height="120" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="10" y="90" width="180" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 1px; height: 1px; padding-top: 100px; margin-left: 12px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">(1) Host-to-Network Layer</div></div></div></foreignObject><text x="12" y="104" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="12px">(1) Host-to-Network Layer</text></switch></g><rect x="190" y="90" width="130" height="20" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 128px; height: 1px; padding-top: 100px; margin-left: 191px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 13px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">IEEE 802.15.4</div></div></div></foreignObject><text x="255" y="104" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="13px" text-anchor="middle">IEEE 802.15.4</text></switch></g><rect x="190" y="50" width="130" height="20" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 128px; height: 1px; padding-top: 60px; margin-left: 191px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 13px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">IPv6</div></div></div></foreignObject><text x="255" y="64" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="13px" text-anchor="middle">IPv6</text></switch></g><rect x="10" y="50" width="130" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 1px; height: 1px; padding-top: 60px; margin-left: 12px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">(2) Network Layer</div></div></div></foreignObject><text x="12" y="64" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="12px">(2) Network Layer</text></switch></g><rect x="190" y="30" width="130" height="20" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 128px; height: 1px; padding-top: 40px; margin-left: 191px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 13px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">TCP, UDP</div></div></div></foreignObject><text x="255" y="44" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="13px" text-anchor="middle">TCP, UDP</text></switch></g><rect x="10" y="30" width="140" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 1px; height: 1px; padding-top: 40px; margin-left: 12px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">(3) Transport Layer</div></div></div></foreignObject><text x="12" y="44" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="12px">(3) Transport Layer</text></switch></g><rect x="190" y="10" width="130" height="20" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 128px; height: 1px; padding-top: 20px; margin-left: 191px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 13px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">CoAP, MQTT,...</div></div></div></foreignObject><text x="255" y="24" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="13px" text-anchor="middle">CoAP, MQTT,...</text></switch></g><rect x="10" y="10" width="140" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 1px; height: 1px; padding-top: 20px; margin-left: 12px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">(4) Application Layer</div></div></div></foreignObject><text x="12" y="24" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="12px">(4) Application Layer</text></switch></g><rect x="190" y="70" width="130" height="20" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 128px; height: 1px; padding-top: 80px; margin-left: 191px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 13px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">6LoWPAN</div></div></div></foreignObject><text x="255" y="84" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="13px" text-anchor="middle">6LoWPAN</text></switch></g><rect x="10" y="70" width="150" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 1px; height: 1px; padding-top: 80px; margin-left: 12px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">(1.5) Adaptation Layer</div></div></div></foreignObject><text x="12" y="84" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="12px">(1.5) Adaptation Layer</text></switch></g></g><switch><g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/><a transform="translate(0,-5)" xlink:href="https://www.diagrams.net/doc/faq/svg-export-text-problems" target="_blank"><text text-anchor="middle" font-size="10px" x="50%" y="100%">Text is not SVG - cannot display</text></a></switch></svg>
<figcaption>The <a href="#acr-iot">IoT</a> network stack used in this work.</figcaption>
</figure>
<h2 id="sec-background-coap"><a href="#sec-background-coap">Constrained Application Protocol (CoAP)</a></h2>
<p><a href="#acr-coap">CoAP</a> is an application layer protocol for the <a href="#acr-iot">IoT</a> used to retrieve, update or delete resources <a href="#rfc7252">[21]</a>. It was designed in the “request-response” style of the <a href="#acr-http">HTTP</a>, and uses similar request methods and response codes, e.g. “GET” and “404 (Not Found)”.
Also similar to <a href="#acr-http">HTTP</a>, resources are identified by <a href="#acr-uri">URIs</a>, which consist of the following parts:</p>
<figure>
<code>
coap[s]://<host>[:<port>]<path>[?<query>]
</code>
</figure>
<p>The special path prefix <code>/.well-known/</code> can be used to retrieve site-wide metadata, e.g. a list of all available resources.
For an example <a href="#acr-coap">CoAP</a> request and response, see <a href="#fig-example-coap">Figure 2a</a>.</p>
<p>However, in contrast to <a href="#acr-http">HTTP</a>, <a href="#acr-coap">CoAP</a> is more suitable for constrained devices.
It does not require connection establishment prior to the exchange of requests and responses.
The <a href="#acr-coap">CoAP</a> header can be as small as 4 B, while
the <a href="#acr-http">HTTP</a> header has a fixed length of 9 B <a href="#rfc7540">[22, p. 12]</a>.
Additionally, <a href="#acr-coap">CoAP</a>'s default transport layer protocol is <a href="#acr-udp">UDP</a> instead of <a href="#acr-tcp">TCP</a>. This is beneficial for multiple reasons. Firstly, <a href="#acr-udp">UDP</a> is more lightweight than <a href="#acr-tcp">TCP</a> because it offers fewer guarantees, e.g. messages are not acknowledged, retransmitted and may be delivered out of order.
Secondly, <a href="#acr-udp">UDP</a> headers can be compressed by the <a href="#acr-6lowpan">6LoWPAN</a> adaptation layer (from 8 B to 2 B at maximum compression), while <a href="#acr-tcp">TCP</a> headers (20 B) cannot <a href="#rfc6282">[20, pp. 17--20]</a>.
Finally, <a href="#acr-tcp">TCP</a>'s congestion control mechanism is known to cause performance issues for wireless and mobile devices <a href="#caceres1994effects">[23]</a>.</p>
<p>Due to the unreliability of <a href="#acr-udp">UDP</a>, <a href="#acr-coap">CoAP</a> itself implements an optional reliability feature using 2 B long message IDs that are contained in every <a href="#acr-coap">CoAP</a> message.
Using this ID, duplicated messages can be discarded, and so-called “confirmable” messages can be acknowledged by the receiver. A <a href="#acr-coap">CoAP</a> message is marked as confirmable in the 2 bit “Type” header field. If a confirmable message is not acknowledged, it is periodically re-sent after timeout periods which exponentially increase in length until it is acknowledged or a maximum number of retransmissions is reached <a href="#rfc7252">[21, pp. 21 f.]</a>.</p>
<p><a href="#acr-coap">CoAP</a> messages should fit inside a single <a href="#acr-ip">IP</a> packet to avoid fragmentation. Therefore, a maximum payload size of 1024 B is recommended <a href="#rfc7252">[21, p. 25]</a>.
To transmit larger amounts of data, block-wise transfer can be used <a href="#rfc7959">[24]</a>.
In lossy networks, <a href="#acr-coap">CoAP</a> block-wise transfer is more efficient than <a href="#acr-6lowpan">6LoWPAN</a> fragmentation: When at least one of the <a href="#acr-6lowpan">6LoWPAN</a> fragments is still missing after a maximum wait time of 60 s, all other fragments are flushed and must be retransmitted <a href="#rfc4944">[19, p. 13]</a>, while <a href="#acr-coap">CoAP</a> blocks are individually acknowledged and retransmitted.
The block sizes of the request and response payloads are set separately using the “Block1” and “Block2” option, respectively.
The block options each consist of three fields: a block number (4–20 bit), a bit indicating whether more blocks are following (“more bit”), and a block size (3 B).
Block sizes of [2<sup>4</sup>, 2<sup>5</sup>,..., 2<sup>10</sup>] B are supported.
When the block option is used by a client when requesting a resource, the server must respond using a block size no larger than the one requested.
See <a href="#fig-example-coap-block-wise">Figure 2b</a> for an example <a href="#acr-coap">CoAP</a> exchange using block-wise transfer.</p>
<figure class="has-subfigures">
<figure id="fig-example-coap">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="241px" height="231px" viewBox="-0.5 -0.5 241 231"><defs></defs><g><rect x="0" y="0" width="80" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 40 40 L 40 230" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="39.5" y="17">CoAP</text><text x="39.5" y="33">Client</text></g><rect x="35" y="70" width="10" height="110" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="160" y="0" width="80" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 200 40 L 200 230" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="199.5" y="17">CoAP</text><text x="199.5" y="33">Server</text></g><rect x="195" y="70" width="10" height="110" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 45.1 99.81 L 186.72 99.91" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 193.72 99.92 L 186.72 103.41 L 186.72 96.41 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="rgb(255, 255, 255)" stroke="none" x="58" y="66" width="125" height="32" stroke-width="0"/><text x="119.6" y="78.37">CON</text><text x="119.6" y="94.37">GET /suit-manifest</text></g><path d="M 195 148.76 L 53.2 148.76" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 46.2 148.76 L 53.2 145.26 L 53.2 152.26 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="rgb(255, 255, 255)" stroke="none" x="67" y="115" width="108" height="32" stroke-width="0"/><text x="119.5" y="127.26">ACK</text><text x="119.5" y="143.26">2.05 <payload></text></g></g></svg>
<figcaption>Using confirmable messages: When the client sends a confirmable GET request for a resource to the server, the server must acknowledge the request. Here, it sends the requested resource payload in the same message as the acknowledgment.</figcaption>
</figure>
<figure id="fig-example-coap-block-wise">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="281px" height="231px" viewBox="-0.5 -0.5 281 231"><defs></defs><g><rect x="0" y="0" width="80" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 40 40 L 40 230" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="39.5" y="17">CoAP</text><text x="39.5" y="33">Client</text></g><rect x="35" y="70" width="10" height="150" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="200" y="0" width="80" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 240 40 L 240 230" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="239.5" y="17">CoAP</text><text x="239.5" y="33">Server</text></g><rect x="235" y="70" width="10" height="150" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 44.84 79.9 L 226.68 79.9" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 233.68 79.9 L 226.68 83.4 L 226.68 76.4 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="51" y="48" width="179" height="30" stroke-width="0"/><text x="139.34" y="60.4">GET /suit-manifest</text><text x="139.34" y="74.4">Block1 Nr 0, More 0, Size 32</text></g><path d="M 234.84 119.95 L 53.03 119.81" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 46.03 119.8 L 53.03 116.31 L 53.03 123.31 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="51" y="88" width="179" height="30" stroke-width="0"/><text x="139.34" y="100.37">2.05 <payload></text><text x="139.34" y="114.37">Block2 Nr 0, More 1, Size 32</text></g><path d="M 45.18 159.7 L 226.88 159.84" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 233.88 159.85 L 226.88 163.34 L 226.88 156.34 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="51" y="128" width="179" height="30" stroke-width="0"/><text x="139.68" y="140.28">GET /suit-manifest</text><text x="139.68" y="154.28">Block1 Nr 1, More 0, Size 32</text></g><path d="M 235.08 200.05 L 53.03 199.91" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 46.03 199.9 L 53.03 196.41 L 53.03 203.41 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="51" y="168" width="179" height="30" stroke-width="0"/><text x="139.58" y="180.48">2.05 <payload></text><text x="139.58" y="194.48">Block2 Nr 1, More 0, Size 32</text></g></g></svg>
<figcaption>Using block-wise transfer: The client requests a resource block by block. The server responds with the requested blocks using the requested block size. The final block is sent with the more bit unset.</figcaption>
</figure>
<figcaption>Example <a href="#acr-coap">CoAP</a> requests and responses.</figcaption>
</figure>
<p><a href="#acr-coap">CoAP</a> also supports so-called cross-protocol proxies, which translate requests and responses between <a href="#acr-coap">CoAP</a> and another protocol.
Because <a href="#acr-coap">CoAP</a> is quite similar to <a href="#acr-http">HTTP</a>, translation between <a href="#acr-coap">CoAP</a> and <a href="#acr-http">HTTP</a> can be easily done.
This allows <a href="#acr-iot">IoT</a> devices that communicate over <a href="#acr-coap">CoAP</a> to access resources that are served by <a href="#acr-http">HTTP</a> servers, and vice versa.</p>
<h2 id="sec-background-mqtt"><a href="#sec-background-mqtt">Message Queuing Telemetry Transport (MQTT)</a></h2>
<p>The <a href="#acr-mqtt">MQTT</a> protocol <a href="#mqtt-5.0">[25]</a> is based on the “publish/subscribe” paradigm, which means that devices can subscribe to so-called “topics” to receive data that they are interested in, e.g. <code>living-room/temperature</code>, as well as
publish data on a topic.
The subscriptions are managed by a “broker”.
When the broker receives published data, it checks which active clients are subscribed to the topic and forwards it to them.
See <a href="#fig-example-mqtt">Figure 3</a> for an example message exchange between a publisher, a subscriber and a broker.
The size of the <a href="#acr-mqtt">MQTT</a> header depends on the message type, e.g. <span class="sc">Publish</span> or <span class="sc">Subscribe</span>. The <span class="sc">Publish</span> header has a minimum length of 3 B, plus the topic length.</p>
<figure id="fig-example-mqtt">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="521px" height="261px" viewBox="-0.5 -0.5 521 261"><defs></defs><g><rect x="0" y="0" width="100" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 50 40 L 50 260" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="49.5" y="25">MQTT Client</text></g><rect x="45" y="70" width="10" height="180" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="210" y="0" width="100" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 260 40 L 260 260" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="259.5" y="25">MQTT Broker</text></g><rect x="255" y="70" width="10" height="180" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 55 120 L 246.88 120" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 253.88 120 L 246.88 123.5 L 246.88 116.5 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="80" y="89" width="152" height="30" stroke-width="0"/><text x="154.5" y="100.5">SUBSCRIBE</text><text x="154.5" y="114.5">living-room/temperature</text></g><path d="M 254.81 149.92 L 63.52 149.23" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 56.52 149.2 L 63.53 145.73 L 63.51 152.73 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="127" y="133" width="56" height="15" stroke-width="0"/><text x="154.31" y="144.06">SUBACK</text></g><rect x="420" y="0" width="100" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 470 40 L 470 260" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="469.5" y="17">MQTT Client</text><text x="469.5" y="33">(IoT Device)</text></g><rect x="465" y="70" width="10" height="140" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 464.97 79.94 L 273.12 80" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 266.12 80 L 273.12 76.5 L 273.12 83.5 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="278" y="48" width="182" height="30" stroke-width="0"/><text x="368.47" y="60.47">PUBLISH</text><text x="368.47" y="74.47">living-room/temperature 24.2</text></g><path d="M 264.97 109.78 L 456.36 109.9" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 463.36 109.9 L 456.36 113.4 L 456.36 106.4 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="337" y="93" width="56" height="15" stroke-width="0"/><text x="364.47" y="104.34">PUBACK</text></g><path d="M 254.81 200.32 L 63.12 200.32" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 56.12 200.32 L 63.12 196.82 L 63.12 203.82 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="68" y="169" width="182" height="30" stroke-width="0"/><text x="158.31" y="180.82">PUBLISH</text><text x="158.31" y="194.82">living-room/temperature 24.4</text></g><path d="M 54.93 230.2 L 246.69 229.85" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 253.69 229.84 L 246.7 233.35 L 246.69 226.35 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="127" y="214" width="56" height="15" stroke-width="0"/><text x="154.43" y="224.52">PUBACK</text></g><path d="M 465.13 160.02 L 273.25 160" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 266.25 160 L 273.25 156.5 L 273.25 163.5 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="279" y="129" width="182" height="30" stroke-width="0"/><text x="368.63" y="140.51">PUBLISH</text><text x="368.63" y="154.51">living-room/temperature 24.4</text></g><path d="M 264.97 189.88 L 456.85 189.84" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 463.85 189.84 L 456.85 193.34 L 456.85 186.34 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="12px"><rect fill="rgb(255, 255, 255)" stroke="none" x="337" y="173" width="56" height="15" stroke-width="0"/><text x="364.47" y="184.36">PUBACK</text></g></g></svg>
<figcaption>Example <a href="#acr-mqtt">MQTT</a> publish and subscribe messages: Clients can both subscribe and publish to topics. The broker forwards all published messages on a topic to the currently subscribed clients. The success of publish and subscribe actions is indicated using <span class="sc">PubAck</span> and <span class="sc">SubAck</span> messages when using a <a href="#acr-qos">QoS</a> level >0.</figcaption>
</figure>
<p><a href="#acr-mqtt">MQTT</a> extends the basic publish/subscribe paradigm with additional features, such as:</p>
<dl>
<dt><a href="#acr-qos">QoS</a></dt>
<dd>Data can be published using three different <a href="#acr-qos">QoS</a> levels:
<ul>
<li>Level 0 (“at most once”) does not use any kind of acknowledgements (besides <a href="#acr-tcp">TCP</a> acknowledgements between the client and the broker).</li>
<li>Level 1 (“at least once”) additionally uses <span class="sc">PubAck</span> messages that are sent by the receiver (may be either client or broker) upon receiving the message.
Duplicates of the message may still arrive after the <span class="sc">PubAck</span> has been sent. They must be treated like new messages, because the message ID is free for reuse after the message has been acknowledged.</li>
<li>Level 2 (“exactly once”) uses a three-step process to ensure reliability and prevent duplicates: The receiver sends a <span class="sc">PubRec</span> (“Publish Receive”) message upon receiving the message, which lets the sender know to stop storing and retransmitting the message.
The sender confirms this with a <span class="sc">PubRel</span> (“Publish Release”) message, which lets the receiver know it no longer needs to store the message ID to detect duplicates. The receiver finally replies with a <span class="sc">PubComp</span> (“Publish Complete”).</li>
</ul>
If <span class="sc">PubAck</span> (<a href="#acr-qos">QoS</a> level 1) or <span class="sc">PubRec</span> (<a href="#acr-qos">QoS</a> level 2) are missing, the message is retransmitted until it times out.
</dd>
<dt>Wildcard Subscriptions</dt>
<dd>Two different wildcard symbols may be used to subscribe to multiple topics at once:
<ul>
<li>The wildcard symbol <code>#</code> may only be placed on the final level of the subscribed topic, e.g. <code>living-room/#</code>. It matches the top-level topic and all subtopics, e.g. <code>living-room</code>, <code>living-room/temperature</code>, <code>living-room/light-status/lamp1</code> and <code>living-room/light-status/lamp2</code>.</li>
<li>The wildcard symbol <code>+</code> may be placed at any level of the subscribed topic, e.g. <code>house/+/temperature</code>. It matches any single level, e.g. <code>house/living-room/temperature</code> and <code>house/dining-room/temperature</code>.</li>
</ul>
</dd>
<dt>Retained Messages<dt>
<dd>
<p>When the <span class="sc">Retain</span> bit is set in a <span class="sc">Publish</span> message, the <a href="#acr-mqtt">MQTT</a> broker must store the message and send it to future subscribers of the topic upon subscription.
It is useful when updates on a topic are irregular or infrequent because it ensures that any subscriber receives an initial value directly after subscribing.</p>
<p>There can be at most one retained message for a topic at any given time. If another message is published with the <span class="sc">Retain</span> bit set, it replaces the previous retained message.</p>
<p>If the <a href="#acr-qos">QoS</a> level of the retained message is set to 0, it may be discarded by the broker at any time; if the <a href="#acr-qos">QoS</a> level is 1 or 2, the semantics of the level must be honored, i.e. the retained message must be delivered at least once or exactly once to each future subscriber.
</dd>
</dl>
<h2 id="sec-background-mqtt-sn"><a href="#sec-background-mqtt-sn">MQTT for Sensor Networks (MQTT-SN)</a></h2>
<p>In the <a href="#acr-iot">IoT</a> context, one downside of the <a href="#acr-mqtt">MQTT</a> protocol is that it can only be operated using <a href="#acr-tcp">TCP</a> on the transport layer, while <a href="#acr-udp">UDP</a> is generally preferred for constrained, mobile and wireless devices, as discussed in <a href="#sec-background-coap">Chapter 2.1</a>.
Thus, a second standard called <a href="#acr-mqttsn">MQTT-SN</a> <a href="#mqtt-sn-1.2">[26]</a> was developed specifically for these use cases, which uses <a href="#acr-udp">UDP</a> instead of <a href="#acr-tcp">TCP</a>.
It supports all of the features described in <a href="#sec-background-mqtt">Chapter 2.2</a> and the full set of message types defined by the <a href="#acr-mqtt">MQTT</a> protocol, except for <span class="sc">Auth</span> messages, which are used for authentication using challenge/response methods.</p>
<p>In architecture, <a href="#acr-mqttsn">MQTT-SN</a> can be considered an extension of <a href="#acr-mqtt">MQTT</a>. Besides an <a href="#acr-mqtt">MQTT</a> broker, it additionally requires an <a href="#acr-mqttsn">MQTT-SN</a> gateway, which may be integrated with the broker or standalone. The standalone case is shown in <a href="#fig-mqtt-sn-arch">Figure 4</a>.</p>
<figure id="fig-mqtt-sn-arch">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="501px" height="61px" viewBox="-0.5 -0.5 501 61"><defs></defs><g><rect x="380" y="0" width="120" height="60" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="439.5" y="27">MQTT-SN Client</text><text x="439.5" y="43">(IoT Device)</text></g><rect x="190" y="0" width="120" height="60" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="249.5" y="27">MQTT-SN</text><text x="249.5" y="43">Gateway</text></g><rect x="0" y="0" width="120" height="60" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="59.5" y="35">MQTT Broker</text></g><path d="M 119.52 10.14 L 183.63 10.01" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 188.88 10 L 181.89 13.52 L 183.63 10.01 L 181.88 6.52 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><path d="M 190 50 L 126.37 49.98" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 121.12 49.98 L 128.12 46.48 L 126.37 49.98 L 128.12 53.48 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><path d="M 310 10 L 378.23 10.18" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 383.48 10.2 L 376.47 13.68 L 378.23 10.18 L 376.49 6.68 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><path d="M 379.76 49.92 L 316.37 49.99" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 311.12 50 L 318.11 46.49 L 316.37 49.99 L 318.12 53.49 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><rect x="120" y="9" width="70" height="40" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 29px; margin-left: 155px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 11px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><div style="font-size: 11px;">MQTT</div><div style="font-size: 11px;">over TCP</div></div></div></div></foreignObject><text x="155" y="32" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="11px" text-anchor="middle">MQTT...</text></switch></g><rect x="305" y="9" width="80" height="40" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 29px; margin-left: 345px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 11px; font-family: Georgia; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><div style="font-size: 11px;">MQTT-SN</div><div style="font-size: 11px;">over UDP</div></div></div></div></foreignObject><text x="345" y="32" fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="11px" text-anchor="middle">MQTT-SN...</text></switch></g></g><switch><g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/><a transform="translate(0,-5)" xlink:href="https://www.diagrams.net/doc/faq/svg-export-text-problems" target="_blank"><text text-anchor="middle" font-size="10px" x="50%" y="100%">Text is not SVG - cannot display</text></a></switch></svg>
<figcaption>Architecture components used by <a href="#acr-mqttsn">MQTT-SN</a>: In addition to an <a href="#acr-mqtt">MQTT</a> broker, <a href="#acr-mqttsn">MQTT-SN</a> requires a gateway that translates between its clients, which speak <a href="#acr-mqttsn">MQTT-SN</a> over <a href="#acr-udp">UDP</a>, and the broker, which speaks <a href="#acr-mqtt">MQTT</a> over <a href="#acr-tcp">TCP</a>. The gateway may be integrated with the broker or it may be a standalone component, as shown here.</figcaption>
</figure>
<p>Besides the <a href="#acr-udp">UDP</a> support, <a href="#acr-mqttsn">MQTT-SN</a> offers the following advantages for constrained devices and wireless networks:</p>
<dl>
<dt>Support for Topic IDs</dt>
<dd>
<p>Instead of variable-length topic names, which can cause a large overhead on top of published messages, <a href="#acr-mqttsn">MQTT-SN</a> uses 2 B long “topic IDs”.
Prior to use, they must be registered either by the gateway or by the client.
Alternatively, <a href="#acr-mqttsn">MQTT-SN</a> also supports pre-defined topic IDs which can be used without registration.</p>
<p>Topic IDs can also be used in version 5 of <a href="#acr-mqtt">MQTT</a> itself, where they are called “topic aliases”. However,
brokers are not required by the specification to keep using topic aliases when forwarding messages that were published using a topic alias. This is because publishers and subscribers are meant to be independent from one another, and thus a publisher's decision to use a topic alias cannot automatically carry over to subscribers.
As a result, topic aliases are simply translated and never used for outgoing <span class="sc">Publish</span> messages by some broker implementations such as the widely used <a href="https://github.com/eclipse/mosquitto">Mosquitto</a>.
<p>At the time of writing, the issue of using topic aliases for outgoing <span class="sc">Publish</span> messages in Mosquitto is being discussed (see <a href="https://github.com/eclipse/mosquitto/issues/1757">here</a> and <a href="https://www.eclipse.org/lists/mosquitto-dev/msg02505.html">here</a>) and the feature is planned to be added in an upcoming version (see <a href="https://github.com/eclipse/mosquitto/commit/de9780343b09d2d2d1c2bda6f2747c961e2fa2c1">here</a>).
</dd>
<dt>Server/Gateway Discovery</dt>
<dd>
Gateways may periodically broadcast <span class="sc">Advertise</span> messages to allow clients to keep an updated list of online gateways.
Additionally, clients may broadcast <span class="sc">SearchGw</span> messages to let others in the network know that they are looking for a gateway. Gateways or other clients may respond to this using a <span class="sc">GwInfo</span> message, which includes the address of an available gateway.
</dd>
<dt>Keep-Alive for Sleeping Clients</dt>
<dd>
<p>A client may let the gateway know that it is about to enter a sleep state by setting the “Sleep Duration” field in the <span class="sc">Disconnect</span> message. For that duration, the gateway will buffer packets on subscribed topics and deliver them when the client next comes back online and sends a <span class="sc">PingReq</span> to the gateway. After sending all buffered packets, the gateway answers the ping and the client may go back to sleep.</p>
<p>A similar feature is also included in <a href="#acr-mqtt">MQTT</a>: If the “Clean Start” flag in the <span class="sc">Connect</span> message is set to zero, a persistent session is started. After it ends, the broker will continue buffering messages on the client's subscribed topics and deliver them when the client next connects. However, this is only mandatory for messages with <a href="#acr-qos">QoS</a> >0, and the <span class="sc">Connect</span> procedure is less lightweight than the <span class="sc">PingReq</span> procedure.
</dd>
<dt><a href="#acr-qos">QoS</a> Level -1</dt>
<dd>
Clients may publish messages without any previous connection setup with a gateway using the <a href="#acr-qos">QoS</a> level -1. This offers even less assurances than <a href="#acr-qos">QoS</a> level 0, because it is unclear whether the gateway adress is correct or the gateway is still online. However, this also saves the overhead of connection setup and teardown.
</dd>
</dl>
<h2 id="sec-app-layer-comp"><a href="#sec-app-layer-comp">Comparison</a></h2>
<p>In this section, we discuss advantages and disadvantages of <a href="#acr-coap">CoAP</a>, <a href="#acr-mqtt">MQTT</a> and <a href="#acr-mqttsn">MQTT-SN</a> based on the protocol specifications which we briefly described in the previous sections.
For an overview over performance comparisons of <a href="#acr-coap">CoAP</a>, <a href="#acr-mqtt">MQTT</a> and <a href="#acr-mqttsn">MQTT-SN</a> implementations, see <a href="#sec-rel-work-comp">Chapter 3.1</a>.</p>
<p>The publish/subscribe model used by <a href="#acr-mqtt">MQTT</a> and <a href="#acr-mqttsn">MQTT-SN</a> has some advantages over the request/response model used by <a href="#acr-coap">CoAP</a>.
As mentioned, <a href="#acr-mqtt">MQTT</a> and <a href="#acr-mqttsn">MQTT-SN</a> can easily support sleeping devices by buffering packets at the broker.
Additionally, the broker simplifies one-to-many or many-to-many communication between larger numbers of <a href="#acr-iot">IoT</a> devices, since they do not need to know each others network addresses to communicate, only the broker's network address.
It must be noted that a publish/subscribe extension for <a href="#acr-coap">CoAP</a> exists <a href="#ietf-core-coap-pubsub-09">[27]</a>, but it is still in draft status and thus has not been widely implemented.</p>
<p>Currently, another advantage of <a href="#acr-mqtt">MQTT</a> over <a href="#acr-coap">CoAP</a> is that it has a larger user base <a href="#iot-developer-survey-2018">[28, pp. 38 f.]</a>.
There is no data on the number of users of <a href="#acr-mqttsn">MQTT-SN</a>, but it can be assumed that it is the least used out of all three protocols. This is reflected in a much lower number of <a href="#acr-mqttsn">MQTT-SN</a> implementations available, which also receive much lower contribution activity. For a short overview of available <a href="#acr-mqttsn">MQTT-SN</a> implementations, see <a href="#sec-choice-mqtt-sn-impl">Section 4.2.1</a>.</p>
<p>In summary, <a href="#acr-mqtt">MQTT</a> and <a href="#acr-mqttsn">MQTT-SN</a> are most suited for the exchange of small amounts of current information such as sensor data in many-to-many fashion.
<a href="#acr-mqttsn">MQTT-SN</a> is more suitable for wirelessly connected constrained devices than <a href="#acr-mqtt">MQTT</a>, but it has a much smaller user base and lacks well-maintained software support.
<a href="#acr-coap">CoAP</a> is most suited for the transfer of data of any size from servers to clients. Especially the transfer of large amounts of data is well-supported through the block-wise transfer option. It also provides interoperability with other protocols used in the wider Internet using cross-protocol proxies, most notably for <a href="#acr-http">HTTP</a>.
</section>
<section id="chapter3" class="chapter" data-chapter-num="3">
<header>
<p class="chapter-num"></p>
<h1><a href="#chapter3">Related Work</a></h1>
</header>
<p>In this chapter, we present and discuss related works.
The first section presents an overview over previous comparative evaluations of the two application layer protocols <a href="#acr-coap">CoAP</a> and <a href="#acr-mqtt">MQTT</a>.
The second section describes general requirements for secure firmware update solutions.
The third section presents an overview over works describing firmware update mechanisms, including <a href="#acr-suit">SUIT</a>, and finally compares how they fulfill the requirements.</p>
<h2 id="sec-rel-work-comp"><a href="#sec-rel-work-comp">Comparative Evaluations of CoAP, MQTT and MQTT-SN</a></h2>
<p>The performance of application layer protocols for the <a href="#acr-iot">IoT</a> has been evaluated and compared by several authors using several different metrics.
This section gives an overview.</p>
<p>A similar survey of evaluations of application layer protocols, which includes not only <a href="#acr-coap">CoAP</a> and <a href="#acr-mqtt">MQTT</a>, but also <a href="#acr-dds">DDS</a>, <a href="#acr-amqp">AMQP</a> and <a href="#acr-xmpp">XMPP</a>, was published by Dizdarević et al. <a href="#dizdarevic2019survey">[29]</a>
Unfortunately, <a href="#acr-mqttsn">MQTT-SN</a> is not included in their survey.</p>
<p>It must be noted that not all performance differences measured can be ascribed to the protocols themselves. The specific implementation used obviously also has an impact on the measured performance.
For example, a comparison of different <a href="#acr-coap">CoAP</a> implementations by Iglesias-Urkia et al.
found significant differences in <a href="#acr-rtt">RTT</a>, CPU and memory usage between them, even when they were implemented in the same programming language <a href="#iglesias2017analysis">[30]</a>.</p>
<h3>Transmission times</h3>
<p>The message transmission time, delay or <a href="#acr-rtt">RTT</a> is a well-studied metric that is included in most evaluations.
Several of them find that <a href="#acr-mqtt">MQTT</a> performs better than <a href="#acr-coap">CoAP</a>, especially when packet losses and retransmissions occur:</p>
<p>Thantharate et al.
measured the transmission duration of five consecutive messages in a simulated <a href="#acr-iot">IoT</a> testbed <a href="#thantharate2019coap">[31]</a>.
Their results show that the average transmission time of <a href="#acr-mqtt">MQTT</a> messages with both <a href="#acr-qos">QoS</a> level 1 or 2 is at least three times as fast as that of <a href="#acr-coap">CoAP</a> confirmable messages.
<a href="#acr-mqtt">MQTT</a> with <a href="#acr-qos">QoS</a> level 2 is slightly slower than <a href="#acr-qos">QoS</a> level 1 due to the increased acknowledgement overhead.
However, it is unclear what causes the measured time differences. By default, <a href="#acr-coap">CoAP</a> uses a stop-and-wait protocol which allows only one outstanding request or unacknowledged message at a time, while <a href="#acr-mqtt">MQTT</a> runs over <a href="#acr-tcp">TCP</a>, which uses a sliding window protocol with larger window sizes.
<a href="#acr-coap">CoAP</a> may have achieved better transmission durations if it was also configured to use larger window sizes.</p>
<p>Similarly, Bideh et al. measured transmission times
and found that <a href="#acr-mqtt">MQTT</a> is up to seven times as fast as <a href="#acr-coap">CoAP</a> <a href="#bideh2020energy">[32]</a>.
They state this is because <a href="#acr-tcp">TCP</a> uses a more efficient retransmission algorithm which uses <a href="#acr-rtt">RTT</a> measurements, while <a href="#acr-coap">CoAP</a> uses an arbitrary fixed value range (between <code>ACK_TIMEOUT</code> and <code>ACK_TIMEOUT</code> · <code>ACK_RANDOM_FACTOR</code>) for its acknowledgment wait timeout.
Thus, <a href="#acr-tcp">TCP</a> can trigger a first retransmission faster than <a href="#acr-coap">CoAP</a> when the network <a href="#acr-rtt">RTT</a> is low.
The effect can be lessened by decreasing the <code>ACK_TIMEOUT</code> parameter. However, even when decreasing it to the minimum of 1 s, they find that <a href="#acr-coap">CoAP</a> still performs worse than <a href="#acr-mqtt">MQTT</a>.</p>
<p>Collina et al. also found that <a href="#acr-mqtt">MQTT</a> performs with lower latencies when there is high packet loss <a href="#collina2014internet">[33]</a>. They also state that this is because of <a href="#acr-tcp">TCP</a>'s faster retransmissions.
Like Bideh et al., they were able to improve the performance of <a href="#acr-coap">CoAP</a> by lowering the parameters <code>ACK_TIMEOUT</code> and <code>ACK_RANDOM_FACTOR</code>. With these tuned parameters, <a href="#acr-coap">CoAP</a> achieves a performance similar to <a href="#acr-mqtt">MQTT</a>.
However, the lowered parameters cause risk of unnecessary retransmissions, which may congest the network. RFC 7252 states that additional congestion control mechanisms must be used if <code>ACK_TIMEOUT</code> is decreased from its default value <a href="#rfc7252">[21, p. 28]</a>.</p>
<p>Two evaluations consider the transmission of larger amounts of data.
Bideh et al. measured transmission durations for a large file (870 KiB), which is transmitted in 870 blocks when using <a href="#acr-coap">CoAP</a> and in a single message when sent over <a href="#acr-mqtt">MQTT</a> <a href="#bideh2020energy">[32]</a>. In this case, <a href="#acr-mqtt">MQTT</a> is twice as fast.
Mun et al. performed time measurements
of the transmission of 50 kB large messages using different block sizes from 128–1920 B and found that <a href="#acr-mqtt">MQTT</a> performs better for large block sizes of more than 1024 B because there is less fragmentation <a href="#mun2016assessment">[34]</a>. When sent over <a href="#acr-coap">CoAP</a>, these blocks are fragmented twice due to its limited payload size.
These results show that fragmentation has a negative impact on transmission durations.</p>
<p>In some cases, <a href="#acr-coap">CoAP</a> performs similar to or even better than <a href="#acr-mqtt">MQTT</a>.
In the evaluation by Mun et al., <a href="#acr-coap">CoAP</a> performs better than <a href="#acr-mqtt">MQTT</a> when messages are smaller than 1024 B <a href="#mun2016assessment">[34]</a>.
Collina et al. find that when there is low packet loss, <a href="#acr-mqtt">MQTT</a> and <a href="#acr-coap">CoAP</a> perform the same <a href="#collina2014internet">[33]</a>.
Mijovic et al.
also found that <a href="#acr-coap">CoAP</a> and <a href="#acr-mqtt">MQTT</a> with <a href="#acr-qos">QoS</a> level 0 achieve very similar <a href="#acr-rtt">RTTs</a>, but <a href="#acr-mqtt">MQTT</a> with <a href="#acr-qos">QoS</a> 1 is slowed down by the additional application layer acknowledgements by a factor between 2 and 3 <a href="#mijovic2016comparing">[35]</a>.</p>
<p>In their survey, Dizdarević et al. also found that the transport layer protocol is a major factor for performance, and that <a href="#acr-tcp">TCP</a>-based protocols often achieve worse latencies in evaluations than the <a href="#acr-udp">UDP</a>-based ones <a href="#dizdarevic2019survey">[29]</a>.
Larmo et al. found in network simulations that <a href="#acr-mqtt">MQTT</a> messages arrive with increased delays when the <a href="#acr-tcp">TCP</a> session is terminated in between messages due to <a href="#acr-tcp">TCP</a>'s three-way handshake <a href="#larmo2018comparison">[36]</a>.
They also found that if the <a href="#acr-iot">IoT</a> device's radio is periodically turned off to conserve energy (“duty cycling”), a minimum delay is added to each transmission originating at the device, especially if it is using <a href="#acr-tcp">TCP</a>, because it cannot receive downlink messages such as the <a href="#acr-tcp">TCP</a> <span class="sc">Syn Ack</span> of a connection establishment until it is awake again.</p>
<p><a href="#acr-mqttsn">MQTT-SN</a> is not included in many evaluations.
Gündoğan et al. compared it against <a href="#acr-coap">CoAP</a> <a href="#gundogan2018ndn">[37]</a>.
using ARM Cortex M3 nodes in the FIT <a href="#acr-iot">IoT</a> testbed <a href="#adjih2015fit">[38]</a>.
They found that with a push/pull interval of 5 s,
the push-based <a href="#acr-coap">CoAP</a> <span class="sc">Put</span> and <a href="#acr-mqttsn">MQTT-SN</a> <span class="sc">Publish</span> do not differ significantly in the time required for the transmission,
whereas the pull-based <a href="#acr-coap">CoAP</a> <span class="sc">Get</span> is slightly slower.
With a shorter push/pull interval of 50 ns, the delays for confirmable <a href="#acr-coap">CoAP</a> <span class="sc">Put</span> messages increase significantly due to application layer retransmissions. <a href="#acr-coap">CoAP</a> <span class="sc">Get</span> and <a href="#acr-mqttsn">MQTT-SN</a> <span class="sc">Publish</span> messages do not experience significantly decreased delays.
In the evaluation by Mun et al., <a href="#acr-mqttsn">MQTT-SN</a> performs the worst overall; however, they note that this may be due to the low level of maturity of the implementation used (Eclipse Paho) <a href="#mun2016assessment">[34]</a>.</p>
<h3>Energy consumption</h3>
<p>Dizdarević et al. found that <a href="#acr-coap">CoAP</a> is more energy-efficient than <a href="#acr-mqtt">MQTT</a> in all surveyed comparisons, though both are more efficient than non-<a href="#acr-iot">IoT</a>-specific protocols like <a href="#acr-http">HTTP</a> <a href="#dizdarevic2019survey">[29]</a>.</p>
<p>Larmo et al. also found in their network simulations that <a href="#acr-mqtt">MQTT</a> causes more energy consumption than <a href="#acr-coap">CoAP</a> due to the increased amount of radio transmission time caused by <a href="#acr-tcp">TCP</a> overhead such as the three-way-handshake <a href="#larmo2018comparison">[36]</a>.</p>
<p>Bideh et al. transmitted payloads of different sizes
and found that <a href="#acr-coap">CoAP</a> consumes slightly less energy for payloads of up to 1024 B since the overhead of connection setup is the dominant factor for such small payloads <a href="#bideh2020energy">[32]</a>.
They conclude that data should be aggregated as much as possible to minimize energy consumption, since more frequent transmissions of small payloads are costly, especially when the communication setup and teardown need to be performed every time.
For larger payloads, <a href="#acr-coap">CoAP</a> consumes significantly more energy than <a href="#acr-mqtt">MQTT</a>, again due to the fragmentation.</p>
<p>In the comparison of <a href="#acr-coap">CoAP</a>, <a href="#acr-mqtt">MQTT</a> and <a href="#acr-mqttsn">MQTT-SN</a> done by Mun et al. <a href="#mun2016assessment">[34]</a>,
the energy usage measurements are highly similar to the total transmission times measured, which means that as described before,
<a href="#acr-coap">CoAP</a> performs the best, except for large messages of more than 1024 B, where <a href="#acr-mqtt">MQTT</a> performs better due to less fragmentation, and <a href="#acr-mqttsn">MQTT-SN</a> performs the worst overall.
Mun et al. also find that the energy usage of all three protocols is heavily influenced by the network conditions (e.g. jitter and <a href="#acr-rtt">RTT</a>): The worse the network conditions are, the more energy they consume.</p>
<h3>Traffic overhead</h3>
<p>Obviously, the traffic overhead incurred by headers and control traffic increases with the <a href="#acr-qos">QoS</a> level for <a href="#acr-mqtt">MQTT</a>. For <a href="#acr-coap">CoAP</a>, it increases when confirmable messages are used.
In their survey, Dizdarević et al. found that <a href="#acr-coap">CoAP</a> consumes less bandwidth than <a href="#acr-mqtt">MQTT</a> in all surveyed comparisons <a href="#dizdarevic2019survey">[29]</a>.
Our survey arrives at the same result.
Unfortunately, <a href="#acr-mqttsn">MQTT-SN</a> is not included in any overhead evaluations.</p>
<p>Chen et al. found that <a href="#acr-mqtt">MQTT</a> sends approximately 76 B of header and control data for every 100 B of payload, while <a href="#acr-coap">CoAP</a> sends only approximately 36 B for every 100 B of payload when using non-confirmable messages <a href="#chen2016performance">[39]</a>.
This increased overhead of <a href="#acr-mqtt">MQTT</a> is probably due to the control messages that are necessary before actually transmitting any payload, i.e. the <span class="sc">Connect</span> and <span class="sc">ConnAck</span> messages.</p>
<p>Mijovic et al. also found that <a href="#acr-coap">CoAP</a> has less protocol overhead than <a href="#acr-mqtt">MQTT</a> (both <a href="#acr-qos">QoS</a> 0 and 1), because the <a href="#acr-udp">UDP</a> header is smaller and there are no transport-layer acknowledgments <a href="#mijovic2016comparing">[35]</a>.
When transmitting 100 B of payload, the payload makes up more than 30 % of transmitted bytes when using <a href="#acr-coap">CoAP</a>, but less than 20 % of transmitted bytes when using <a href="#acr-mqtt">MQTT</a>.</p>
<h3>Packet loss rates</h3>
<p>Chen et al. found that <a href="#acr-mqtt">MQTT</a> experiences no packet loss even in lossy network conditions at the cost of increased latency for the received packets and increased control traffic overhead, while <a href="#acr-coap">CoAP</a> experiences packet loss rates approximately equal to the network packet loss rate <a href="#chen2016performance">[39]</a>.
This is not surprising, since lost <a href="#acr-mqtt">MQTT</a> messages will be retransmitted by <a href="#acr-tcp">TCP</a> even when <a href="#acr-qos">QoS</a> level 0 is used, while the <a href="#acr-udp">UDP</a>-based <a href="#acr-coap">CoAP</a> does not retransmit packets by default.
Unfortunately, they have not included <a href="#acr-coap">CoAP</a>'s confirmable messages in their evaluation.</p>
<p>Gündoğan et al. also found in their measurements in the FIT <a href="#acr-iot">IoT</a> testbed that with a short transmission interval of 50 ms, significant packet loss occurs for non-confirmable <a href="#acr-coap">CoAP</a> messages, while
confirmable <a href="#acr-coap">CoAP</a> and <a href="#acr-mqttsn">MQTT-SN</a> PUBLISH messages did not experience packet loss because missing packets could be successfully retransmitted <a href="#gundogan2018ndn">[37]</a>.</p>
<h3>Conclusion</h3>
<p>In conclusion, <a href="#acr-mqtt">MQTT</a>'s largest downside when compared to <a href="#acr-coap">CoAP</a> appears to be the overhead caused by <a href="#acr-tcp">TCP</a> due to the required connection setup and teardown and its larger header size.
This overhead can lead to increased message transmission durations, energy consumption and traffic overhead, especially when the connection is re-established frequently.
However, <a href="#acr-tcp">TCP</a> also offers some advantage against <a href="#acr-coap">CoAP</a>, namely through its sliding window protocol compared to <a href="#acr-coap">CoAP</a>'s stop-and-wait and its faster retransmissions.
This gives <a href="#acr-mqtt">MQTT</a> an advantage especially in environments with high packet loss, where retransmissions are frequent.
However, <a href="#acr-coap">CoAP</a>'s approach is more suitable for constrained devices, because it does not require to keep <a href="#acr-rtt">RTT</a> measurements or to support multiple simultaneously outstanding acknowledgments.</p>
<p><a href="#acr-mqttsn">MQTT-SN</a> is unfortunately not included in many evalutions. Gündoğan et al.'s results suggest that it offers a performance similar to <a href="#acr-coap">CoAP</a>. However, further evaluation is needed. As Mun et al. noted, the lacking maturity of implementations that are currently available may also negatively impact <a href="#acr-mqttsn">MQTT-SN</a>'s performance results.</p>
<p>Several evaluations note the negative performance impact of fragmentation. Here, <a href="#acr-coap">CoAP</a> is disadvantaged because it has a much lower maximum payload size than <a href="#acr-mqtt">MQTT</a> (1024 B vs. ~256 MB) and therefore forces more fragmentation at the application layer. However, <a href="#acr-coap">CoAP</a>'s maximum payload size is much more realistic for constrained devices and networks and thus, in practice and for a fair comparison, <a href="#acr-mqtt">MQTT</a> should also be limited to a similar payload size.</p>
<h2 id="sec-requirements"><a href="#sec-requirements">Requirements for Software Update Mechanisms</a></h2>
<p>In this section, we survey requirements that apply to all secure software update mechanisms.</p>
<p>First, we must clarify terminology, particularly the difference between the terms “firmware updates” and “software updates”.
“Firmware update” refers to the complete replacement of a device's entire software, while “software update” refers more generally to the replacement of some part of a device's software with a newer version. It is less specific to the <a href="#acr-iot">IoT</a> or embedded context and also describes the update of a package on a Linux system, for example.
Currently, most constrained <a href="#acr-iot">IoT</a> devices use full firmware updates only, however, it has been suggested that <a href="#acr-iot">IoT</a> software may become less monolithic in the future, so that different parts of it will need to be updated independently <a href="#padilla2016future">[40]</a>.
(For example, the embedded <a href="#acr-os">OS</a> <a href="https://www.tockos.org">Tock</a> uses a non-monolothic approach. It separates the core <a href="#acr-os">OS</a> from (third-party) applications that are dynamically loadable at runtime <a href="#levy2017multiprogramming">[41]</a>.)
Smaller update sizes would also reduce network traffic and therefore the update duration and energy consumption [<a href="#bauwens2020over">42</a>, <a href="#mottola2008figaro">43</a>].
Thus, we use the more general term “software update” throughout this work where it is possible, as the <a href="#acr-suit">SUIT</a> standard drafts also do.</p>
<p>We now present a list of security requirements for software update mechanisms based on a survey of several other works.
Firstly, the general information security principles of confidentiality, integrity, availability, and authenticity, which are named in the ISO~27000 standards series as the defining aspects of “information security” <a href="#iso27000">[44, p. 4]</a>, apply to firmware update mechanisms:</p>
<h3>Confidentiality</h3>
<p>It must be possible to encrypt both the software image and the metadata to ensure its confidentiality and prevent ”read attacks”. Attackers may use unencrypted images for reverse-engineering.</p>
<h3>Integrity of the Image and Metadata</h3>
<p>The integrity of the software itself and its metadata must be verified.
The device must check the integrity of the firmware update, i.e. that the update has not been tampered with along the way from the source to the <a href="#acr-iot">IoT</a> device.</p>
<h3>Availability of the Updated Device</h3>
<p>An <a href="#acr-iot">IoT</a> device usually provides some service using its sensors and actuators. A software update usually requires a device to reboot and thus temporarily disrupts this service. It must be possible to schedule updates so that the availability of the service is not disrupted at critical times.
The update process should also include fail-safes, e.g. for the case when a firmware update turns out to be invalid after it is received or the reboot fails <a href="#padilla2016future">[45]</a>.</p>
<h3>Authentication and Authorization of the Update Source</h3>
<p>The update source must be authenticated and authorized.
No unauthenticated or unauthorized source should be able to initiate a firmware update of a device.
This can be done using cryptographic signatures, for example.
Trust anchors or keys used by the device to perform the authentication may expire or change so that it is necessary to update them [<a href="#rfc8240">46</a>, <a href="#zandberg2019secure">47</a>].
Ideally, the device manufacturer or vendor should not be the only authorized source <a href="#cui2013firmware">[3]</a>, so that the devices do not become obsolescent when they are no longer actively supported by the manufacturer or the manufacturer shuts down <a href="#klint2016nest">[48]</a>, which is undesirable both from a customer's and from an ecological perspective.</p>
<p>Samuel et al. define a set of principles that make a software update system resilient against attacks when a subset of signing keys has been compromised <a href="#samuel2010survivable">[49]</a>.
Firstly, there should be separation of responsibilities over multiple keys so that the attacker's power is limited when a key is compromised.
Secondly, signatures using multiple keys should be required.
Thirdly, it must be possible to revoke keys. Keys may also be automatically revoked after a certain amount of time or number of uses to encourage frequent replacement.
Finally, keys used for very security-sensitive purposes should be stored on systems not connected to the public Internet or not connected to a network at all.
To prevent key compromises in the first place, widely trusted cryptographic algorithms and large key sizes should be used.
They also identify the information that must be authenticated by a software update mechanism: the content of the updates,
the availability of the updates, and the
repository state (i.e. software versions available).
They applied these principles in the design of <a href="#acr-tuf">TUF</a>, which is described in <a href="#sec-tuf">Section 3.3.2</a>.</p>
<p>Secondly, there are security requirements related to the specific potential weaknesses of software update mechanisms.
Some cases of such weaknesses were already described in <a href="#chapter1">Section 1</a>.
Cappos et al. classify several types of attacks on software repositories <a href="#cappos2008look">[50]</a>: replay attacks (resending older versions), arbitrary package attacks (sending a different software than requested), freeze attacks (freezing the version a client sees and preventing updates; this type of attack was also previously described by Bellissimo et al. <a href="#cappos2008look">[51]</a>), extraneous dependency attacks (inserting additional dependencies that must be satisfied), and endless data attacks (sending endless amounts of data instead of the software image).
These attack types can be carried out when an attacker compromises a software repository, i.e. is able to respond to client requests with arbitrary data, but they do not require a signing key to be compromised.
Cappos et al. suggest that extraneous dependency attacks can be mitigated by signing update metadata which contains the dependency list,
and replay attacks can be mitigated by including a timestamp in the software metadata that must not be older than the timestamp of the currently installed software.
Endless data attacks can be mitigated by placing a cap on the maximum amount of data downloaded.
To detect freeze attacks, they recommend to use signed root metadata files that contain hashes of all package metadata files served by the repository. The files are small, so they can have short expiry times and be updated and resigned frequently <a href="#cappos2008look">[50]</a>.</p>
<p>Karthik et al. describe further types of attacks <a href="#karthik2016uptane">[52]</a>: read attacks (reading contents of firmware updates, e.g. to reverse-engineer), slow retrieval attack (slowing down transmission of firmware updates to exploit vulnerabilities in the meantime), and drop-request attacks (blocking network traffic of firmware updates).</p>
<p>In addition to replay attacks, an attacker may also send an outdated software version that is newer than the currently installed version, but still not the latest available one <a href="#ietf-suit-information-model-11">[15, p. 18]</a>. Langiu et al. call this the “update freshness” property <a href="#langiu2019upkit">[53]</a>, which must be ensured.</p>
<p>Finally, there are also some usability requirements that should be met by a software update solution:</p>
<h3>Suitability for Constrained <a href="#acr-iot">IoT</a> Devices</h3>
<p>An attempt at a definition of the term “constrained device” has been made in RFC 2778 <a href="#rfc7228">[12]</a>.
According to this RFC, devices can be “constrained” in the sense of limited amount of flash memory, <a href="#acr-ram">RAM</a>, processing power, available (battery) power or accessibility once deployed.
Additionally,
the networks to which they are connected may themselves be constrained in some way, e.g. by low throughput or high packet loss rates.</p>
<p>The software update mechanism must adhere to these constraints. It cannot require memory or processing power exceeding the capabilities of constrained devices. It should have minimal energy consumption, which means that the network traffic and the total processing and transmission time spent on the update should be minimized [<a href="#itani2009petra">54</a>, <a href="#mottola2008figaro">43</a>].</p>
<p>Additionally, <a href="#acr-iot">IoT</a> devices are sometimes installed in inaccessible locations. Therefore, software updates must be possible over wireless connections [<a href="#itani2009petra">54</a>, <a href="#mottola2008figaro">43</a>].
Devices may also not be constantly connected to a network if they are mobile. In these cases, pull-based approaches are preferable over push-based approaches <a href="#cappos2008look">[51]</a>.</p>
<h3>Minimal User Interaction</h3>
<p>Software updates are expected to work automatically, i.e. with minimal or even no user involvement or attendance [<a href="#rfc9019">14</a>, <a href="#padilla2016future">40</a>, <a href="#schneier2014unpatchable">10</a>, <a href="#frisch2017ota">45</a>].
Some types of <a href="#acr-iot">IoT</a> devices may not be able to ask for confirmation because they lack an appropriate user interface <a href="#cappos2008look">[51]</a>.</p>
<p>However, there are several reports of <a href="#acr-iot">IoT</a> devices losing certain functionalities or even being bricked after installing software updates [<a href="#doctorow2015philips">55</a>, <a href="#doctorow2016hp">56</a>, <a href="#carman2017smart">57</a>].
Also, software updates may include “breaking” changes. A software update that changes the behaviour and output of an <a href="#acr-iot">IoT</a> device, e.g. the format of the sensor data it reports, may break systems that rely on this output down the line <a href="#rfc8240">[46, p. 18]</a>.
Therefore, it must be possible to turn off automatic updates.</p>
<h3>Targeting Subsets of Devices</h3>
<p>It should be possible to limit the installation of a firmware update to a certain subset of devices [<a href="#mottola2008figaro">43</a>, <a href="#frisch2017ota">45</a>]. Most obviously, a firmware should only be installed on the devices with the matching type of hardware. Additionally, updates may be targeted using other device attributes, such as location or group (e.g. test or production devices).
Some use cases may additionally require that the update mechanism ensures atomicity, i.e. that either none or all of the targeted nodes successfully install an update [<a href="#bauwens2020over">42</a>, <a href="#mottola2008figaro">43</a>].</p>
<h3>Monitoring</h3>
<p>It should be possible to monitor the state of the <a href="#acr-iot">IoT</a> devices, including at least their currently installed firmware version and whether an update was successful or not [<a href="#frisch2017ota">45</a>, <a href="#rfc8240">46</a>].</p>
<h3>Partial or Differential Updates</h3>
<p>As discussed before, an <a href="#acr-iot">IoT</a> device's software may be modular. In that case, the software update mechanism needs to support partial updates, which may be installed e.g. using dynamic linking.
Also, differential updates may be desirable to minimize the network traffic [<a href="#bauwens2020over">42</a>, <a href="#rfc8240">46</a>].</p>
<h2 id="sec-lit-review"><a href="#sec-lit-review">Software Update Mechanisms</a></h2>
<p>In this section, we describe the design of several existing software update mechanisms, starting with <a href="#acr-suit">SUIT</a>. We focus primarily on update mechanisms designed for constrained devices.
We specifically examine if and how they meet the requirements described in the previous section.</p>
<h3 id="sec-rw-suit">Software Updates for Internet of Things (SUIT)</h3>
<p>The <a href="#acr-suit">SUIT</a> working group at the <a href="#acr-ietf">IETF</a> aims to standardize a secure software update mechanism for constrained devices with as little as ~10 KiB <a href="#acr-ram">RAM</a> and ~100 KiB flash memory (Class 1 according to RFC 7228 <a href="#rfc7228">[12]</a>).
This would lower development costs for <a href="#acr-iot">IoT</a> device vendors, who would no longer need to design and implement their own update mechanism, and ensure a certain level of quality.
The <a href="#acr-suit">SUIT</a> documents specify a format for update manifests, the update architecture and the update process including the security mechanisms used.
Transport mechanisms, status tracker functionality and discovery mechanisms for status trackers and software repository servers are explicitly not standardized, because they may be implemented in various ways using already existing protocols, e.g. the <a href="#acr-lwm2m">LwM2M</a> protocol for <a href="#acr-iot">IoT</a> device management.
<a href="#acr-suit">SUIT</a> is not limited to full firmware updates. It supports the updating of arbitrary data, including partial software updates, configuration data, or cryptographic keys <a href="#rfc9019">[13, p. 3]</a>.</p>
<p>Although <a href="#acr-suit">SUIT</a> is still a work in progress, there is significant interest in its early support, e.g. from the many researchers using RIOT <a href="#baccelli2018riot">[58]</a>, the open-source <a href="#acr-iot">IoT</a> operating system used in this work.
An implementation of <a href="#acr-suit">SUIT</a> was <a href="https://github.com/RIOT-OS/RIOT/pull/11818">added to the RIOT code base in October 2019</a>.
<a href="#acr-suit">SUIT</a> was chosen for integration over other software update mechanisms because RIOT focuses on providing support for open, standard-based protocols and specifications.</p>
<h4>Update architecture</h4>
<figure id="fig-suit-arch">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="591px" height="229px" viewBox="-0.5 -0.5 591 229"><defs></defs><g><rect x="470" y="80" width="120" height="60" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="529.5" y="115">IoT Device</text></g><rect x="230" y="0" width="120" height="60" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="289.5" y="27">Firmware</text><text x="289.5" y="43">Server</text></g><rect x="230" y="160" width="120" height="60" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="289.5" y="187">Status Tracker</text><text x="289.5" y="203">Server</text></g><rect x="0" y="80" width="120" height="60" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="59.5" y="107">Firmware</text><text x="59.5" y="123">Author</text></g><path d="M 120 110 L 224.85 33.75" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 229.1 30.66 L 225.49 37.61 L 224.85 33.75 L 221.38 31.94 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="rgb(255, 255, 255)" stroke="none" x="140" y="62" width="71" height="48" stroke-width="0"/><text x="174.58" y="73.62">Firmware</text><text x="174.58" y="89.62">manifest</text><text x="174.58" y="105.62">and image</text></g><path d="M 350 188 L 464.7 111.53" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 469.07 108.62 L 465.19 115.42 L 464.7 111.53 L 461.3 109.59 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="#ffffff" stroke="none" x="395" y="113" width="51" height="32" stroke-width="0"/><text x="419.95" y="124.82">Status</text><text x="419.95" y="140.82">queries</text></g><path d="M 470 140 L 355.3 216.47" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 350.93 219.38 L 354.81 212.58 L 355.3 216.47 L 358.7 218.41 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="#ffffff" stroke="none" x="374" y="175" width="54" height="32" stroke-width="0"/><text x="399.61" y="187.2">Status</text><text x="399.61" y="203.2">updates</text></g><path d="M 350 30 L 464.12 77.55" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 468.97 79.57 L 461.16 80.11 L 464.12 77.55 L 463.85 73.65 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="rgb(255, 255, 255)" stroke="none" x="375" y="28" width="71" height="48" stroke-width="0"/><text x="409.19" y="39.54">Firmware</text><text x="409.19" y="55.54">manifest</text><text x="409.19" y="71.54">and image</text></g></g></svg>
<figcaption>The components of <a href="#acr-suit">SUIT</a>'s architecture: Besides the <a href="#acr-iot">IoT</a> device itself, a firmware and a status tracker server are required. The firmware server serves the software and manifests, while the status tracker server triggers and monitors updates.</figcaption>
</figure>
<p>The <a href="#acr-suit">SUIT</a> architecture consists of three components <a href="#rfc9019">[13, pp. 7 f.]</a>. It is shown in <a href="#fig-suit-arch">Figure 5</a>. Firstly, there is the <a href="#acr-iot">IoT</a> device itself. It has one or more microcontrollers with associated bootloaders whose software may be updated. The device's software must implement update functionality which allows it to interact with the tracker and firmware servers, parse and verify the firmware manifest and store the downloaded firmware image.
Secondly, there is the firmware server, which stores and distributes the firmware manifests and images.
Finally, there is the status tracker server. It notifies devices of new firmware versions and receives status information from the devices (e.g. current firmware version, available flash memory). It can trigger a firmware update in a device.
The firmware and the status tracker servers may be co-located on the same machine.</p>
<h4>Update manifest format</h4>
<p><a href="#acr-suit">SUIT</a> manifests contain metadata about an update. Their structure is defined
in the standard draft describing the manifest <a href="#ietf-suit-manifest-12">[14]</a>, while the manifest fields are defined in the information model <a href="#ietf-suit-information-model-11">[15]</a>.
(At the time of writing, version 12 of the manifest standard draft is the most current one, however the RIOT implementation of SUIT is still based on version 9 <a href="#ietf-suit-manifest-09">[59]</a>. The changes to the manifest structure between the two versions are only minor, so that the description here applies equally to both.)
In total, the draft defines 24 manifest fields, seven of which are mandatory to include, such as a sequence number and a storage location.
See <a href="#tab-manifest">Table 1</a> for an example manifest which was generated using the <a href="https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/suit/suit-manifest-generator">manifest generator tool that is included in RIOT</a>.
The <a href="#acr-suit">SUIT</a> manifest also contains command sequences which describe how the receiver should process the manifest.
Commands are either conditions that must be true or directives that must be executed.
They are available for all processing steps usually required by an update process, i.e. signature and digest verification, parameter comparisons, fetching, copying and transformation of data, and code execution.</p>
<p>The manifests are encoded using <a href="#acr-cbor">CBOR</a>, a binary data format specifically designed to generate small messages and require only little code to parse and generate <a href="#rfc7049">[60]</a>, and are authenticated using <a href="#acr-cose">COSE</a> <a href="#rfc8152">[61]</a>.
They are distributed in a container called the “<a href="#acr-suit">SUIT</a> Envelope” alongside an authentication wrapper containing one or more <a href="#acr-cose">COSE</a> signatures or <a href="#acr-mac">MACs</a>.
When using the <a href="https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/suit/suit-manifest-generator/suit_tool">RIOT SUIT tool</a> to generate the signed version of a manifest,
a single <a href="#acr-cose">COSE</a> signature of the hash of the manifest
is added to the authentication wrapper.</p>
<table id="tab-manifest">
<caption>An example <a href="#acr-suit">SUIT</a> manifest.</caption>
<thead>
<tr>
<td style="width: 25%;">Field name</td>
<td style="width: 45%;">Description</td>
<td style="width: 30%;">Example</td>
</tr>
</thead>
<tbody>
<tr>
<td>Manifest Version ID</td>
<td>Version of the manifest format used</td>
<td>1</td>
</tr>
<tr>
<td>Manifest Sequence Number</td>
<td>Monotonically increasing sequence number, e.g. UTC timestamp.
<td>1603813981</td>
</tr>
<tr>
<td>Vendor ID</td>
<td>Unique device vendor ID.</td>
<td><code>riot-os.org</code></td>
</tr>
<tr>
<td>Class ID</td>
<td>Class of devices that can accept the update.</td>
<td><code>nrf52dk</code></td>
</tr>
<tr>
<td>Image Size</td>
<td>Size of the update image in bytes.</td>
<td><code>85488</code></td>
</tr>
<tr>
<td>Offset</td>
<td>Storage offset in bytes.</td>
<td><code>8196</code></td>
</tr>
<tr>
<td>Image Digest</td>
<td>Hash digest of the update image.</td>
<td><code>f5ff..., SHA256</code></td>
</tr>
<tr>
<td><a href="#acr-uri">URI</a></td>
<td>Location from which the update image can be fetched.</td>
<td><code>coap://[2001:db8::1]/fw/nrf52dk/update-slot1.riot.bin</code></td>
</tr>
</table>
<h4 id="sec-suit-process">Update process</h4>
<p>The <a href="#acr-suit">SUIT</a> update process consists of the following steps <a href="#rfc9019">[13, pp. 9–11]</a>:</p>
<ol>
<li>
A new software update is uploaded to the firmware server by an authenticated and authorized source.
The status tracker server is made aware of this.
</li>
<li>
The <a href="#acr-iot">IoT</a> device is notified of the newly available firmware image using a push-based approach, where the status tracker server pushes a notification to the device, or a pull-based approach, where the device periodically polls the status tracker server for available firmware images.
The update manifest and image are transported from the firmware server to the device via an unspecified transport mechanism.
Multicast or broadcast protocols may be used to efficiently distribute them to multiple devices at once.
The device validates the firmware manifest's signature to authenticate the update's source.
The manifest and the image can either be transported separately, or the image can be embedded into the manifest. As described above, the manifest contains the software's <a href="#acr-uri">URI</a> and an associated fetch command.
If they are transported separately, the device can validate the manifest before starting the download of the image, and abort the update process if the manifest fails any check.
The image is stored at the storage location specified in the manifest, e.g. at a certain flash memory offset.</li>
<li>
Once the firmware image is downloaded, the installation may be initiated in one of the following ways:
<ul>
<li>The client immediately proceeds with the installation.</li>
<li>The client delays the update until a certain condition is met (e.g. a certain time of day, battery level or until the device operator acceptst <a href="#ietf-suit-manifest-12">[14, pp. 56–60]</a>.</li>
<li>The client waits for a trigger by the status tracker server.</li>
</ul>
The bootloader then boots from the new firmware image.
</li>
<li>
While the firmware update process is ongoing, the status tracker server tracks its progress, e.g. whether the update is in progress, successfully completed, or failed (and why).
</li>
</ol>
<p>See <a href="#fig-suit-flow-coap">Figure 6</a> for the sequence of messages that are sent when <a href="#acr-coap">CoAP</a> is used as the transport mechanism.
It shows how the current implementation of SUIT in RIOT works.
As can be seen, a <a href="#acr-coap">CoAP</a> <span class="sc">Post</span> request is used by the status tracker server to inform the <a href="#acr-iot">IoT</a> device of the newly available update. The <a href="#acr-uri">URI</a> of the firmware manifest is transmitted within the payload of this request.
The <a href="#acr-iot">IoT</a> device then pulls the manifest and the update itself from the firmware server using block-wise <span class="sc">Get</span> requests.</p>
<figure id="fig-suit-flow-coap">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="-0.5 -0.5 591 351"><defs></defs><g><rect x="0" y="0" width="100" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 50 40 L 50 100" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="49.5" y="17">Firmware</text><text x="49.5" y="33">Author</text></g><rect x="45" y="70" width="10" height="20" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="140" y="0" width="100" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 190 40 L 190 340" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="189.5" y="17">Firmware</text><text x="189.5" y="33">Server</text></g><rect x="185" y="70" width="10" height="260" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 55 70 L 176.88 70" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 183.88 70 L 176.88 73.5 L 176.88 66.5 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="119.5" y="66.5">Upload Manifest</text><text x="119.5" y="82.5">+ Image</text></g><rect x="260" y="0" width="100" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 310 40 L 310 140" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="309.5" y="17">Status Tracker</text><text x="309.5" y="33">Server</text></g><rect x="305" y="70" width="10" height="70" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="420" y="0" width="100" height="40" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 470 40 L 470 350" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="469.5" y="25">IoT Device</text></g><rect x="465" y="70" width="10" height="270" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 195 79.66 L 296.77 79.4" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 303.77 79.38 L 296.78 82.9 L 296.76 75.9 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="249.5" y="74.02">Notify</text></g><path d="M 314.97 90.02 L 456.88 90.14" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 463.88 90.15 L 456.88 93.64 L 456.89 86.64 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><text x="389.46" y="86.58">CoAP POST</text><text x="389.46" y="102.58">/suit/trigger coap://...</text></g><path d="M 465 169.15 L 203.65 169.94" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 196.65 169.96 L 203.64 166.44 L 203.66 173.44 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="#ffffff" stroke="none" x="263" y="151" width="136" height="17" stroke-width="0"/><text x="329.5" y="164.06">CoAP GET /manifest</text></g><path d="M 475.4 235.73 L 500 236 L 500 246 L 483.57 246.08" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 476.57 246.11 L 483.55 242.58 L 483.59 249.58 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="13px"><text x="505.15" y="234.5">Validate</text><text x="505.15" y="250.5">manifest</text></g><path d="M 195 200.02 L 456.88 199.18" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 463.88 199.15 L 456.89 202.68 L 456.87 195.68 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="#ffffff" stroke="none" x="286" y="181" width="88" height="17" stroke-width="0"/><text x="329.5" y="194.09">CoAP ACK ...</text></g><path d="M 475.4 325.73 L 500 326 L 500 336 L 483.57 336.08" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 476.57 336.11 L 483.55 332.58 L 483.59 339.58 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" font-size="13px"><text x="503.14" y="327.5">Proceed with</text><text x="503.14" y="343.5">installation</text></g><path d="M 464.61 130.01 L 322.95 129.85" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 315.95 129.84 L 322.95 126.35 L 322.94 133.35 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="#ffffff" stroke="none" x="355" y="111" width="71" height="17" stroke-width="0"/><text x="389.11" y="124.42">CoAP ACK</text></g><path d="M 465 259.15 L 203.65 259.94" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 196.65 259.96 L 203.64 256.44 L 203.66 263.44 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="#ffffff" stroke="none" x="271" y="241" width="119" height="17" stroke-width="0"/><text x="329.5" y="254.06">CoAP GET /image</text></g><path d="M 195 290.02 L 456.88 289.18" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 463.88 289.15 L 456.89 292.68 L 456.87 285.68 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="#ffffff" stroke="none" x="286" y="271" width="88" height="17" stroke-width="0"/><text x="329.5" y="284.09">CoAP ACK ...</text></g><path d="M 203.12 319.99 L 456.88 319.18" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 196.12 320.02 L 203.11 316.49 L 203.13 323.49 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><path d="M 463.88 319.15 L 456.89 322.68 L 456.87 315.68 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="#ffffff" stroke="none" x="198" y="301" width="265" height="17" stroke-width="0"/><text x="329.5" y="314.09">(Repeat until all blocks are transferred)</text></g><path d="M 203.12 229.99 L 456.88 229.18" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 196.12 230.02 L 203.11 226.49 L 203.13 233.49 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><path d="M 463.88 229.15 L 456.89 232.68 L 456.87 225.68 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><g fill="rgb(0, 0, 0)" font-family="Georgia, serif" text-anchor="middle" font-size="13px"><rect fill="#ffffff" stroke="none" x="198" y="211" width="265" height="17" stroke-width="0"/><text x="329.5" y="224.09">(Repeat until all blocks are transferred)</text></g></g></svg>
<figcaption>Sequence diagram of a software update using <a href="#acr-suit">SUIT</a> with a push notification and <a href="#acr-coap">CoAP</a> as the transport mechanism: The status tracker server pushes an update notification to the device using a <span class="sc">Put</span> request. The device then downloads manifest and image using block-wise <span class="sc">Get</span> requests.</figcaption>
</figure>
<h3>Others</h3>
<p>In this section, we provide an overview over other proposed software update mechanisms, focusing primarily on mechanisms designed for constrained devices.
Finally, we compare them to <a href="#acr-suit">SUIT</a>.</p>
<h4 id="sec-tuf">The Update Framework, Uptane and ASSURED</h4>
<p><a href="#acr-tuf">TUF</a> is a framework for software update retrieval. It authenticates updates using crypographic signatures and was designed to be able to survive the compromise of some of its signing keys using the four principles already described in <a href="#sec-requirements">Section 3.2</a>.
It was first described by Samuel et al <a href="#samuel2010survivable">[49]</a>, and
is now a <a href="https://theupdateframework.io">part of the Linux Foundation's Cloud Native Computing Foundation and in productive use at several companies</a>.
The protocol specification is openly available <a href="#2020tuf">[62]</a>.
<a href="#acr-tuf">TUF</a> uses four different metadata files:
<code>root.txt</code> (keys of root role and roles delegated by root),
<code>release.txt</code> (latest versions, hashes and lengths of all metadata files except <code>timestamp.txt</code>),
<code>timestamp.txt</code> (version, hash and length of latest <code>release.txt</code>),
and <code>targets.txt</code> (available update files including hash digests, file size and optionally, custom information such as version or dependencies).
Each metadata file has at least one associated role with a signing key that is only responsible for signing that file. Multiple signatures may be required.
There can also be multiple hierarchical <code>targets.txt</code> files and keys, e.g. for update files provided from different sources.
All metadata files also have an expiration time.</p>
<p>When downloading an update, the first step of <a href="#acr-tuf">TUF</a> is to get the latest <code>release.txt</code> as specified by <code>timestamp.txt</code> and to check its length and hash.
If <code>release.txt</code> indicates that a new <code>root.txt</code> is available, <a href="#acr-tuf">TUF</a> starts over.
If <code>release.txt</code> indicates that a new <code>targets.txt</code> is available, <a href="#acr-tuf">TUF</a> updates its list of available files using the new version.
When <a href="#acr-tuf">TUF</a> is instructed by an upper software update layer to fetch one of the available files, it does so and checks its hash and length against the ones given by the <code>targets.txt</code> before returning the file.</p>
<p>Thus, the targets, release and timestamp roles share responsibility over the available update files so that all three must be compromised to allow an attacker to get a client to install malicious software.
Freeze attacks are possible once the timestamp key is compromised because it allows an attacker to continually resign a frozen version of <code>timestamp.txt</code>. This prevents the release of a new <code>release.txt</code> and thus also of a new <code>targets.txt</code> or <code>root.txt</code>.
However, the duration of the freeze attack is limited by the earliest expiration date of the other metadata files.
Once the attack is noticed, the timestamp key can be replaced.
Only a compromise of the root key(s) would be completely fatal to the system's security, because the attacker can sign a new <code>root.txt</code> containing his own keys for the other roles.</p>
<p><a href="#acr-tuf">TUF</a> was not designed for constrained devices, and it is not well-suited for them. It requires the updated device to choose which updates to install, to resolve dependencies and to validate multiple cryptographic signatures. Thus, update mechanisms based on <a href="#acr-tuf">TUF</a> have been proposed that outsource these tasks to other components, e.g. ASSURED <a href="#asokan2018assured">[62]</a> and Uptane <a href="#karthik2016uptane">[52]</a>.
ASSURED extends <a href="#acr-tuf">TUF</a> with a “controller” component which communicates with the repository on behalf of the constrained device, and takes on the tasks listed above and then transmits the update to the constrained device over a secure channel. The device only needs to confirm the authenticity of the controller and the constraints given in the update metadata, e.g. device class.
Similarly, Uptane, which was created especially to update electronic control units (ECUs) in automobiles,
adds a “director” role that is responsible for creating and signing a list of softwares to be installed specifically when an automobile requests updates. Due to the heterogeneous levels of constrainedness of the ECUs, one of them is chosen to be the primary who communicates directly with the director and performs the checks, and then distributes the software to all secondaries.
Uptane's design also includes several other changes, such as an external time server which ECUs periodically contact with a nonce. The time server returns the signed current time and nonce.
This is necessary because <a href="#acr-tuf">TUF</a> requires the updated system to have an accurate clock to make use of the expiration timestamps.
Uptane also uses an A/B slot system to ensure that there is always a bootable image available.</p>
<h4>UpKit</h4>
<p>With UpKit, Langiu et al. propose a software update mechanism that is supposed to be lightweight, efficient, open-source, and not dependent on any specific network protocol, hardware platform or <a href="#acr-os">OS</a> <a href="#langiu2019upkit">[53]</a>.
Their goals therefore align quite closely with those of <a href="#acr-suit">SUIT</a>.
Langiu et al. provide <a href="https://github.com/updatekit/upkit">implementations</a> for three different <a href="#acr-os">OSs</a> (RIOT, Contiki-NG, and Zephyr) and multiple hardware platforms.</p>
<p>UpKit's infrastructure consists of a vendor server, update server, and update client in the <a href="#acr-iot">IoT</a> device.
The vendor server pushes new firmware images and signed metadata (the so-called “manifest”) to the update server. The manifest contains the firmware version, size, hash, offset, and application and hardware platform ID.
The update server announces the new version's availability. The update client can then send a request for it, including its device ID and a nonce. The update server appends the nonce to the update metadata, signs it and sends it to the update client.
Using the nonce (if it is sufficiently random <a href="#rfc4086">[64]</a>), the freshness of the information is guaranteed. Unlike <a href="#acr-suit">SUIT</a>, they prefer nonces over timestamps because secure time sources are usually not available to <a href="#acr-iot">IoT</a> devices, and expiry timestamps may be set too far in the future.
Once the update client receives this information, it verifies both signatures and the metadata, such as the firmware version. If all checks are successful, the image is downloaded and its hash is compared. Finally, the image can be booted.
UpKit supports the usage of flexible memory slots for update installation, e.g. A/B slots.</p>
<h4>FiGaRo</h4>
<p>Mottola et al. specify a software reconfiguration process for wireless sensor networks called FiGaRo (FIne Grained SoftwAre RecOnfiguration) <a href="#mottola2008figaro">[43]</a>.
It is implemented on top of the Contiki <a href="#acr-os">OS</a>.
In FiGaRo, the node software is structured into components that have interfaces (i.e. services they provide), dependencies on other components, and a version.
Interfaces are represented as structs containing function pointers which always point to the implementation that is currently used.
A management layer at the node keeps a representation of the current software configuration's dependency tree.
When a new component arrives at the node, it checks whether all dependencies are satisfied. If they are, the component is installed and run if there is either no other component already implementing the same interface or the component that is currently installed has an older version.
Components are replaced using dynamic linking.
The component updates are limited to a subset of nodes using node attributes: First, each node's attributes must be declared (e.g. its hardware). They are piggybacked onto each outgoing message, overheard by all nodes in range, and used to build a mesh routing table that contains node attributes.
Then, the target of the component update can be declared as a boolean function of the attributes (e.g. <code>Board == NUCLEO-F767ZI && Battery >= 75</code>).</p>
<h4>Others</h4>
<p>Frisch et al. present a software update mechanism for ESP8266-based <a href="#acr-iot">IoT</a> devices <a href="#frisch2017ota">[45]</a>. They use an infrastructure consisting of a firmware repository, a home automation controller and several <a href="#acr-iot">IoT</a> devices, which communicate over WiFi and <a href="#acr-mqtt">MQTT</a>.
The repository serves firmware images and metadata files containing version numbers and cryptographic signatures of the images over <a href="#acr-http">HTTP</a>.
There is one metadata file per device type containing the metadata of the most current available firmware version.
The devices use a two-slot system for storing firmware images. They publish state information like currently used firmware version and slot over <a href="#acr-mqtt">MQTT</a> after start-up.
Periodically, they poll the repository for the newest version of the relevant metadata file. A poll can also be triggered by publishing a message on a certain <a href="#acr-mqtt">MQTT</a> topic.
If a different version than the currently running one is returned, the download is started using an <a href="#acr-http">HTTP</a> <span class="sc">Get</span> request.</p>
<p>While many firmware update mechanisms are available, none is yet well-established in the <a href="#acr-iot">IoT</a>. Schmidt et al. believe this is due to their overly complicated nature <a href="#schmidt2019how">[65]</a>. They therefore propose a new “minimal” mechanism.
Their system consists of only a firmware server and the <a href="#acr-iot">IoT</a> devices.
The firmware images sent by the server are encrypted using a pre-shared symmetric key and signed using the server's private key. They are accompanied by metadata (version, file size and IDs of keys to be used) which is also signed. The metadata is transmitted and validated first.
As with <a href="#acr-suit">SUIT</a>, the transport mechanism used by the server is not specified.
They implement a bootloader that is responsible for checking the validity of the signatures and the firmware version.
Their system also uses a two-slot setup of the device's flash memory.</p>
<h3 id="chapter3-5">Comparison</h3>
<p>In this section, we examine if and how <a href="#acr-suit">SUIT</a> and the other reviewed update mechanisms fulfil the requirements described in <a href="#sec-requirements">Section 3.2</a>.</p>
<h4>Confidentiality</h4>
<p>Schmidt et al. use symmetric keys to encrypt the transmitted firmware images, and include an encryption key ID in the update metadata.
<a href="#acr-suit">SUIT</a> supports the optional encryption of the software image, also using symmetric keys. For encrypted software, the manifest includes an “encryption wrapper” that specifies which key should be used to decrypt the image and a list of processing steps necessary to decrypt the image <a href="#ietf-suit-information-model-11">[15, pp. 11 f., 15]</a>.</p>
<p>In any case, traffic may be encrypted using appropriate transport layer security protocols, such as <a href="#acr-dtls">DTLS</a> for <a href="#acr-udp">UDP</a>.</p>
<h4>Integrity of the Image and Metadata</h4>
<p>The mechanisms described by Frisch et al. and Schmidt et al. use signed images.
As described above, <a href="#acr-tuf">TUF</a> and its derivatives Uptane and ASSURED use signed hashes of the software images in their metadata files.
Similarly, UpKit and <a href="#acr-suit">SUIT</a> include the hash of the image in the signed manifest.</p>
<p>When the <a href="#acr-iot">IoT</a> device receives the update metadata, it first validates the signature using the public key of an authorized entity (which must be already known to the device).
During this validation, changes to the manifest by unauthorized entities can be detected.
If the check is successful, the device compares the image digest contained in the metadata to the digest of the received image.
In the case of <a href="#acr-suit">SUIT</a>, this check is part of the command sequence included in the manifest.
During this check, changes to the image can be detected.</p>
<p>In any case, the integrity of the image and metadata can also be protected against man-in-the-middle attacks by transmitting it over a secured channel, as described above.</p>
<h4>Availability of the Updated Device</h4>
<p>Uptane, UpKit and <a href="#acr-suit">SUIT</a> as well as the mechanisms described by Frisch et al. and Schmidt et al. support A/B updates using two memory slots, so that there is a firmware to fall back to if the reboot into the new version fails.</p>
<p>As described above, <a href="#acr-suit">SUIT</a> allows the scheduling of updates using commands that instruct the device to wait until a certain condition is met (e.g. a certain time of day or battery level).
The mechanism described by Frisch et al. allows only rudimentary scheduling using update triggers published over <a href="#acr-mqtt">MQTT</a>.</p>
<p>An automatic rollback when the device cannot reestablish connection to the status tracker server after an update is not part of any of the surveyed mechanisms, but it could be added to the application logic.</p>
<h4>Authentication and Authorization of the Update Source</h4>
<p>The authenticity of the update metadata is generally established through one or more signatures, which must be validated by the device.