Lines Matching full:the
13 relays this sensor data to this service. The cloud service is also able
14 to send configuration data to the device, as well as software update
21 In this sensor device, the sensor connects with the SoC via an SPI bus,
22 and the SoC has a network interface that it uses to communicate with the
23 cloud service. The particulars of these interfaces can impact the threat
28 This model also focuses on communicating via the MQTT-over-TLS protocol,
34 One aspect of the threat model to consider are assets involved in the
35 operation of the device. The following list enumerates the assets
38 1. **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
41 that the SoC provides a mechanism to protect a region of the flash
43 programmed into the device, early in production [th-imboot]_.
45 2. **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
51 a. The image shall only be replaced with an authorized image
54 b. When an authorized replacement image is available, the update
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
62 3. **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
70 4. **Client secrets**. To authenticate the client to the service, the
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.
77 This secret is generally generated by the service provider, or by
78 software running elsewhere, and must be securely installed on the
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.
84 These secrets must be protected from read, and the smallest amount
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
94 requires the time to be accurate within 5-10 minutes.
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
105 6. **Sensor data**. The data received from the sensor itself, and
106 delivered to the service shall be delivered without modification or
109 7. **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
116 8. **Logs**. In order to assist with analysis of security issues, the
120 events to the cloud service where they can be stored in a more
124 a. **Firmware image updates**. The system should log the download of
130 c. **Changes to the device configuration**.
137 In addition to assets, the threat model also considers the locations
138 where data or assets are communicated between entities of the system.
140 1. **Flash contents**. The flash device contains several regions. The
141 contents of flash can be modified programmatically by the SoC's CPU.
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
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.
155 The bootloader shall verify the signature of the update image
158 The bootloader shall only accept an update image with a newer
159 version number than the current image.
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
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.
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
180 exploits found within a majority of the application code.
181 Revealing the contents of the secrets would allow the attacker
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.
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
196 f. **Log storage**. The device may have an area of flash where log
199 2. **Sensor/Actuator interface**. In this design, the sensor or actuator
200 communicates with the SoC via a bus, such as SPI. The hardware design
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.
206 3. **Communication with cloud service**. Communication between the
207 device, and the cloud service will be done over the general
210 DNS results or attempt man-in-the-middle attacks
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
216 secrecy. The communication shall be secured by the following:
218 a. **Cipher suite selection**. The device shall only allow
222 b. **Server certificate verification**. The server presented by the
225 i. **Naming**. The certificate shall name the host and service
226 the cloud service server is providing.
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
233 ii. **Path validation**. The device shall verify that the
235 certificate contained within the device, to the certificate
236 presented by the service.
238 this is general. The device is permitted to require a more
239 restricted path, provided the server certificate used
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.
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
252 i. **TLS client certificates**. The TLS protocol allows the
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
260 be useful in the management of these certificates.
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
270 being reused if they are intercepted. The token shall not be
271 sent until the device has verified the identity of the server.
273 d. **Random/Entropy source**. Cryptographic communication requires the
274 generation of secure pseudorandom numbers. The device shall use a
277 Random Bit Generator (True RBG) implemented in hardware within the
279 by an entropy source within the SoC. Please see NIST SP 800-90A
283 4. **Communication with the time service**. Ideally, the device shall
288 describe the Simple Network Time Protocol that can be used to query
289 the current time from a network time server.
292 production to destruction and disposal of the device. Aspects of this
296 a. **Initial provisioning**. During the initial provisioning stage,
297 it is necessary to program the bootloader, an initial application
300 addition, the bootloader flash protection shall be installed. Of
301 this information, only the device secret needs to differ per
303 all locations outside of the device once it has been programmed
306 b. **Normal operation**. Normal operation includes the behavior
307 described by the rest of this document.
311 to keep the same device secret, and replace the configuration
312 data, as well as the cloud service data associated with the
314 this is done it shall be done securely, and the new secret
315 destroyed externally once programmed into the device
318 d. **Destruction**. To prevent the device secret from being used to
319 spoof the device, upon decommissioning, the secret for a
323 i. Hardware destruction of the device.
325 ii. Securely wiping the flash area containing the
328 iii. Removing the device identity and certificate from the
334 In addition to the above, network connected devices generally will need
335 a way to configure them to connect to the network environment they are
337 for these configuration methods to not circumvent the security
361 There must be a mechanism to securely store client secrets. The
365 System must have moderately accurate notion of the current
369 The system must receive, and keep configuration data.
372 The system must log security-related events, and either store them
376 All communications with the cloud service shall use TLS.
383 The device shall authenticate itself with the cloud provider using
384 one of the methods described.
387 The TLS layer shall use a modern, accepted cryptographic random-bit
388 generator seeded by an entropy source within the SoC.
391 The device shall have a per-device secret loaded before deployment.
394 The initial secret shall be securely maintained, and destroyed in
395 any external location as soon as the device is provisioned.
401 Upon decommissioning, the device secret shall be rendered
409 of this writing, the three major cloud IoT service providers, AWS