1.. _sensor-threat:
2
3Sensor Device Threat Model
4##########################
5
6This document describes a threat model for an IoT sensor device.
7Spelling out a threat model helps direct development effort, and can
8be used to help prioritize these efforts as well.
9
10This device contains a sensor of some type (for example temperature, or a
11pressure in a pipe), which sends this data to an SoC running a
12microcontroller. This microcontroller connects to a cloud service, and
13relays this sensor data to this service. The cloud service is also able
14to send configuration data to the device, as well as software update
15images. A general diagram can be seen in Figure 1:
16
17.. figure:: media/sensor-model.svg
18
19   Figure 1. Sensor General Diagram
20
21In this sensor device, the sensor connects with the SoC via an SPI bus,
22and the SoC has a network interface that it uses to communicate with the
23cloud service. The particulars of these interfaces can impact the threat
24model in unexpected ways, and variants on this will need to be
25considered (for example, using a separate network interface SoC
26connected via some type of bus).
27
28This model also focuses on communicating via the MQTT-over-TLS protocol,
29as this seems to be in wide use [1]_.
30
31Assets
32======
33
34One aspect of the threat model to consider are assets involved in the
35operation of the device. The following list enumerates the assets
36included in this model:
37
381. **The bootloader**. This is a small code/data image contained in
39   on-device flash that is the first code to run. In order to establish
40   a root of trust, this image must be immutable. This model assumes
41   that the SoC provides a mechanism to protect a region of the flash
42   from future writes, and that this will be done after this image is
43   programmed into the device, early in production [th-imboot]_.
44
452. **The application firmware image**. This asset consists of the
46   remainder of the firmware run by the microcontroller. The distinction
47   is made because this part of the image will need to be updated
48   periodically as security vulnerabilities are discovered. Requirements
49   for updates to this image are:
50
51   a. The image shall only be replaced with an authorized image
52      [th-authrepl]_.
53
54   b. When an authorized replacement image is available, the update
55      shall be done in a timely manner [th-timely-update]_.
56
57   c. The image update shall be seen as atomic, meaning that when the
58      image is run, the flash shall contain either the update image in
59      its entirety, or the old image in its entirety
60      [th-atomic-update]_.
61
623. **Root certificate list**. In order to authenticate the cloud service
63   (server), the IoT device must have a list of root certificates that
64   are allowed to sign the certificate on the server. For cloud-provider
65   based services, this list will generally be provided by the service
66   provider. Because the root certificates can expire, and possibly be
67   revoked, this list will need to be periodically updated
68   [th-root-certs]_, [th-root-check]_.
69
704. **Client secrets**. To authenticate the client to the service, the
71   client must possess some kind of secret. This is generally a private
72   key, usually either an RSA key or an EC private key. When
73   establishing communication with the server, the device will use
74   this secret either as part of the TLS establishment, or to sign a
75   message used in the communication.
76
77   This secret is generally generated by the service provider, or by
78   software running elsewhere, and must be securely installed on the
79   device. Policy may dictate that this secret be replaced
80   periodically, which will require a way to update the client secret.
81   Typically, the service will allow two or three active keys to allow
82   this update to proceed while the old key is used.
83
84   These secrets must be protected from read, and the smallest amount
85   of code necessary shall have access to them. [th-secret-storage]_
86
875. **Current date/time**. TLS certificate verification requires
88   knowledge of the current date and time in order to determine if the
89   current time falls within the certificate's current validity time.
90   Also, token based client authentication will generally require the
91   client to sign a message containing a time window that the token is
92   valid. Certificate validation requires the device's notion of date and
93   time to be accurate within a day or so. Token generation generally
94   requires the time to be accurate within 5-10 minutes.
95
96   It may be possible to approximate secure time by querying an
97   external time server.  Secure NTP is possibly beyond the
98   capabilities of an IoT device.  The main risks of having incorrect
99   time are denial of service (the device rejects valid certificates),
100   and the generation of tokens with invalid times.  It could be
101   possible to trick the device into generating tokens that are valid in
102   the future, but the attacker would also have to spoof the server's
103   certificate to be able to intercept this. [th-time]_
104
1056. **Sensor data**. The data received from the sensor itself, and
106   delivered to the service shall be delivered without modification or
107   tampering.
108
1097. **Device configuration**. Various configuration data, such as the
110   hostname of the service to connect to, the address of a time server,
111   frequency and parameters of when sensor data is sent to the service,
112   and other need to be kept by the device. This configuration data will
113   need to be updated periodically as the configuration changes. Updates
114   should be allowed only from authorized parties. [th-conf]_
115
1168. **Logs**. In order to assist with analysis of security issues, the
117   device shall log information about security-pertinent events. IoT
118   devices generally have limited storage, and as such, these logs need
119   to be carefully selected. It may also be possible to send these log
120   events to the cloud service where they can be stored in a more
121   resource-available environment. Types of events that should be logged
122   include:
123
124   a. **Firmware image updates**. The system should log the download of
125      new images, and when an image is successfully updated.
126
127   b. **Client secret changes**. Changes and new client secrets should be
128      logged.
129
130   c. **Changes to the device configuration**.
131
132   [th-logs]_
133
134Communication
135=============
136
137In addition to assets, the threat model also considers the locations
138where data or assets are communicated between entities of the system.
139
1401. **Flash contents**. The flash device contains several regions. The
141   contents of flash can be modified programmatically by the SoC's CPU.
142
143   a. **The bootloader**. As described in the Assets section, the
144      bootloader is a small section of the flash device containing the
145      code initially run. This section shall be written early in the
146      lifecycle of the device, and the flash device then configured to
147      permanently disallow modification of this section. This
148      configuration should also prevent modification via external
149      interfaces, such as JTAG or SWD debuggers.
150
151      The bootloader is responsible for verifying the signature of the
152      application image as well as updating the application image from
153      the update image when an update is needed.
154
155      The bootloader shall verify the signature of the update image
156      before installing it.
157
158      The bootloader shall only accept an update image with a newer
159      version number than the current image.
160
161   b. **The application image**. The application image contains the code
162      executed during normal operation of the device. Before running
163      this image, the bootloader shall verify a digital signature of the
164      image, to avoid running an image that has been tampered with. The
165      flash/system shall be configured such that after the bootloader
166      has completed, the CPU will be unable to write to the application
167      image.
168
169   c. **The update image**. This is an area of flash that holds a new
170      version of the application image. This image will be downloaded
171      and stored by the application during normal operation. When this
172      has completed, the application can trigger a reboot, and the
173      bootloader can install the new image.
174
175   d. **Secret storage**. An area of the flash will be used to store
176      client secrets. This area is written and read by a subset of the
177      application image. The application shall be configured to
178      protect this area from both reads and writes by code that does
179      not need to have access to it, giving consideration to possible
180      exploits found within a majority of the application code.
181      Revealing the contents of the secrets would allow the attacker
182      to spoof this device.
183
184      Initial secrets shall be placed in the device during a
185      provisioning activity, distinct from normal operation of the
186      device. Later updates can be made under the direction of
187      communication received over a secured channel to the service.
188
189   e. **Configuration storage**. There shall be an area to store other
190      configuration information. On resource-constrained devices, it is
191      allowed for this to be stored in the same region as the secret
192      storage, however, this adds additional code that has access to the
193      secret storage area, and as such, more code that must be
194      scrutinized.
195
196   f. **Log storage**. The device may have an area of flash where log
197      events can be written.
198
1992. **Sensor/Actuator interface**. In this design, the sensor or actuator
200   communicates with the SoC via a bus, such as SPI. The hardware design
201   shall be made to make intercepting this bus difficult for an attack.
202   Required techniques depend on the sensitivity and use of the sensor
203   data, and can range from having the sensor mounted on the same PCB as
204   the MCU to epoxy potting the entire device.
205
2063. **Communication with cloud service**. Communication between the
207   device, and the cloud service will be done over the general
208   internet. As such, it shall be assumed that an attacker can
209   arbitrarily intercept this channel and, for example, return spoofed
210   DNS results or attempt man-in-the-middle attacks
211   against communication with cloud services.
212
213   The device shall use TLS for all communication with the cloud
214   service [th-all-tls]_. The TLS stack shall be configured to use only cipher suites
215   that are generally considered secure [2]_, including forward
216   secrecy. The communication shall be secured by the following:
217
218   a. **Cipher suite selection**. The device shall only allow
219      communication with generally agreed secure cipher suites
220      [th-tls-ciphers]_.
221
222   b. **Server certificate verification**. The server presented by the
223      server shall be verified [th-root-check]_.
224
225      i.   **Naming**. The certificate shall name the host and service
226           the cloud service server is providing.
227           `RFC6125 <https://tools.ietf.org/html/rfc6125>`__ describes
228           best practices for this. It is permissible for the device to
229           require the certificate to be more restrictive than as
230           described in this RFC, provided the service can use a
231           certificate that can comply.
232
233      ii.  **Path validation**. The device shall verify that the
234           certificate chain has a valid signature path from a root
235           certificate contained within the device, to the certificate
236           presented by the service.
237           `RFC4158 <https://tools.ietf.org/html/rfc4158>`__ describes
238           this is general. The device is permitted to require a more
239           restricted path, provided the server certificate used
240           complies with this restriction.
241
242      iii. **Validity period**. The validity period of all presented
243           certificates shall be checked against the device's best
244           notion of the current time.
245
246   c. **Client authentication**. The client shall authenticate itself to
247      the service using a secret known only to that particular device.
248      There are several options, and the technique used is generally
249      mandated by the particular service provider being used
250      [th-tls-client-auth]_.
251
252      i.  **TLS client certificates**. The TLS protocol allows the
253          client to present a certificate, and assert its knowledge of
254          the secret described by that certificate. Generally, these
255          certificates will be stored within the service provider. These
256          certificates can be self-signed, or signed by a CA. Since the
257          service provider maintains a list of valid certificates
258          (mapping them to a device identity), having these certificates
259          signed by a CA does not add any additional security, but may
260          be useful in the management of these certificates.
261
262      ii. **Token-based authentication**. It is also possible for the
263          client to authenticate itself using the *password* field of
264          the MQTT CONNECT packet. However, the secret itself must not
265          be transmitted in this packet. Instead, a token-based
266          protocol, such as
267          `RFC7519 <https://tools.ietf.org/html/rfc7519>`__\ 's JSON Web
268          Token (JWT) can be used. These tokens will generally have a
269          small validity period (e.g. 1 hour), to prevent them from
270          being reused if they are intercepted. The token shall not be
271          sent until the device has verified the identity of the server.
272
273   d. **Random/Entropy source**. Cryptographic communication requires the
274      generation of secure pseudorandom numbers. The device shall use a
275      modern, accepted cryptographic random-bit generator to generate
276      these random numbers. It shall use either a Non-Deterministic
277      Random Bit Generator (True RBG) implemented in hardware within the
278      SoC, or a Deterministic Random Bit Generator (Pseudo RBG) seeded
279      by an entropy source within the SoC.  Please see NIST SP 800-90A
280      for information on approved RBGs and NIST SP 800-90B for
281      information on testing a device's entropy source [th-entropy]_.
282
2834. **Communication with the time service**. Ideally, the device shall
284   contain hardware that maintains a secure time. However, most SoCs in
285   use do not have support for this, and it will be necessary to consult
286   an external time service.
287   `RFC4330 <https://tools.ietf.org/html/rfc4330>`__ and referenced RFCs
288   describe the Simple Network Time Protocol that can be used to query
289   the current time from a network time server.
290
2915. **Device lifecycle**. An IoT device will have a lifecycle from
292   production to destruction and disposal of the device. Aspects of this
293   lifecycle that impact security include initial provisioning, normal
294   operation, re-provisioning, and destruction.
295
296   a. **Initial provisioning**. During the initial provisioning stage,
297      it is necessary to program the bootloader, an initial application
298      image, a device secret, and initial configuration data
299      [th-initial-provision]_. In
300      addition, the bootloader flash protection shall be installed. Of
301      this information, only the device secret needs to differ per
302      device. This secret shall be securely maintained, and destroyed in
303      all locations outside of the device once it has been programmed
304      [th-initial-secret]_.
305
306   b. **Normal operation**. Normal operation includes the behavior
307      described by the rest of this document.
308
309   c. **Re-provisioning**. Sometimes it is necessary to re-provision a
310      device, such as for a different application. One way to do this is
311      to keep the same device secret, and replace the configuration
312      data, as well as the cloud service data associated with the
313      device. It is also possible to program a new device secret, but if
314      this is done it shall be done securely, and the new secret
315      destroyed externally once programmed into the device
316      [th-reprovision]_.
317
318   d. **Destruction**. To prevent the device secret from being used to
319      spoof the device, upon decommissioning, the secret for a
320      particular device shall be rendered ineffective
321      [th-destruction]_. Possibilities include:
322
323      i.    Hardware destruction of the device.
324
325      ii.   Securely wiping the flash area containing the
326            secret [3]_.
327
328      iii.  Removing the device identity and certificate from the
329            service.
330
331Other Considerations
332====================
333
334In addition to the above, network connected devices generally will need
335a way to configure them to connect to the network environment they are
336placed in. There are numerous ways of doing this, and it is important
337for these configuration methods to not circumvent the security
338requirements described above.
339
340Threats
341=======
342
343.. [th-imboot] Must boot with an immutable bootloader.
344
345.. [th-authrepl] Application image shall only be replaced with an
346   authorized image.
347
348.. [th-timely-update]
349   Application updates shall be done in a timely manner.
350
351.. [th-atomic-update]
352   Application updates shall be atomic.
353
354.. [th-root-certs]
355   TLS must have a list of trusted root certificates.
356
357.. [th-root-check]
358   TLS must verify root certificate from server is valid.
359
360.. [th-secret-storage]
361   There must be a mechanism to securely store client secrets.  The
362   least amount of code necessary shall have access to these secrets.
363
364.. [th-time]
365   System must have moderately accurate notion of the current
366   date/time.
367
368.. [th-conf]
369   The system must receive, and keep configuration data.
370
371.. [th-logs]
372   The system must log security-related events, and either store them
373   locally, or send to a service.
374
375.. [th-all-tls]
376   All communications with the cloud service shall use TLS.
377
378.. [th-tls-ciphers]
379   TLS shall be configured to allow only generally agreed cipher
380   suites (including forward secrecy).
381
382.. [th-tls-client-auth]
383   The device shall authenticate itself with the cloud provider using
384   one of the methods described.
385
386.. [th-entropy]
387   The TLS layer shall use a modern, accepted cryptographic random-bit
388   generator seeded by an entropy source within the SoC.
389
390.. [th-initial-provision]
391   The device shall have a per-device secret loaded before deployment.
392
393.. [th-initial-secret]
394   The initial secret shall be securely maintained, and destroyed in
395   any external location as soon as the device is provisioned.
396
397.. [th-reprovision]
398   Reprovisioning a device shall be done securely.
399
400.. [th-destruction]
401   Upon decommissioning, the device secret shall be rendered
402   ineffective.
403
404Notes
405=====
406
407.. [1]
408   See https://www.slideshare.net/kartben/iot-developer-survey-2018. As
409   of this writing, the three major cloud IoT service providers, AWS
410   IoT, Google Cloud IoT, and Microsoft Azure IoT all provide MQTT over
411   TLS. Some feedback has suggested that some find difficulty with UDP
412   protocols and routing issues on various networks.
413
414.. [2]
415   As new exploits are discovered, what is considered secure can
416   change.
417   Organizations such as https://www.ssllabs.com/ provide information on
418   current ideas of how TLS must be configured to be secure.
419
420.. [3]
421   Note that merely erasing this flash area is unlikely to be
422   sufficient.
423