aboutsummaryrefslogtreecommitdiff
path: root/docs/threat_model/threat_model.rst
blob: 9cee10415133d60ee69707fc053896c7b0e8f7f2 (plain)
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
*****************
Introduction
*****************
Threat modeling is an important part of Secure Development Lifecycle (SDL)
that helps us identify potential threats and mitigations affecting a system.

This document provides a generic threat model for TF-A firmware. In the
next sections, we first give a description of the target of evaluation
using a data flow diagram. Then we provide a list of threats we have
identified based on the data flow diagram and potential threat mitigations.

************************
Target of Evaluation
************************
In this threat model, the target of evaluation is the Trusted
Firmware for A-class Processors (TF-A). This includes the boot ROM (BL1),
the trusted boot firmware (BL2) and the runtime EL3 firmware (BL31) as
shown on Figure 1. Everything else on Figure 1 is outside of the scope of
the evaluation.

TF-A can be configured in various ways. In this threat model we consider
only the most basic configuration. To that end we make the following
assumptions:

- All TF-A images are run from either ROM or on-chip trusted SRAM. This means
  TF-A is not vulnerable to an attacker that can probe or tamper with off-chip
  memory.
- Trusted boot is enabled. This means an attacker can't boot arbitrary images
  that are not approved by platform providers.
- There is no Secure-EL2. We don't consider threats that may come with
  Secure-EL2 software.

Data Flow Diagram
======================
Figure 1 shows a high-level data flow diagram for TF-A. The diagram
shows a model of the different components of a TF-A-based system and
their interactions with TF-A. A description of each diagram element
is given on Table 1. On the diagram, the red broken lines indicate
trust boundaries. Components outside of the broken lines
are considered untrusted by TF-A.

.. uml:: ../resources/diagrams/plantuml/tfa_dfd.puml
  :caption: Figure 1: TF-A Data Flow Diagram

.. table:: Table 1: TF-A Data Flow Diagram Description

  +-----------------+--------------------------------------------------------+
  | Diagram Element | Description                                            |
  +=================+========================================================+
  |       ``DF1``   | | At boot time, images are loaded from non-volatile    |
  |                 |   memory and verified by TF-A boot firmware. These     |
  |                 |   images include TF-A BL2 and BL31 images, as well as  |
  |                 |   other secure and non-secure images.                  |
  +-----------------+--------------------------------------------------------+
  |       ``DF2``   | | TF-A log system framework outputs debug messages     |
  |                 |   over a UART interface.                               |
  +-----------------+--------------------------------------------------------+
  |       ``DF3``   | | Debug and trace IP on a platform can allow access    |
  |                 |   to registers and memory of TF-A.                     |
  +-----------------+--------------------------------------------------------+
  |       ``DF4``   | | Secure world software (e.g. trusted OS) interact     |
  |                 |   with TF-A through SMC call interface and/or shared   |
  |                 |   memory.                                              |
  +-----------------+--------------------------------------------------------+
  |       ``DF5``   | | Non-secure world software (e.g. rich OS) interact    |
  |                 |   with TF-A through SMC call interface and/or shared   |
  |                 |   memory.                                              |
  +-----------------+--------------------------------------------------------+
  |       ``DF6``   | | This path represents the interaction between TF-A and|
  |                 |   various hardware IPs such as TrustZone controller    |
  |                 |   and GIC. At boot time TF-A configures/initializes the|
  |                 |   IPs and interacts with them at runtime through       |
  |                 |   interrupts and registers.                            |
  +-----------------+--------------------------------------------------------+


*********************
Threat Analysis
*********************
In this section we identify and provide assessment of potential threats to TF-A
firmware. The threats are identified for each diagram element on the
data flow diagram above.

For each threat, we identify the *asset* that is under threat, the
*threat agent* and the *threat type*. Each threat is given a *risk rating*
that represents the impact and likelihood of that threat. We also discuss
potential mitigations.

Assets
==================
We have identified the following assets for TF-A:

.. table:: Table 2: TF-A Assets

  +--------------------+---------------------------------------------------+
  | Asset              | Description                                       |
  +====================+===================================================+
  | ``Sensitive Data`` | | These include sensitive data that an attacker   |
  |                    |   must not be able to tamper with (e.g. the Root  |
  |                    |   of Trust Public Key) or see (e.g. secure logs,  |
  |                    |   debugging information such as crash reports).   |
  +--------------------+---------------------------------------------------+
  | ``Code Execution`` | | This represents the requirement that the        |
  |                    |   platform should run only TF-A code approved by  |
  |                    |   the platform provider.                          |
  +--------------------+---------------------------------------------------+
  | ``Availability``   | | This represents the requirement that TF-A       |
  |                    |   services should always be available for use.    |
  +--------------------+---------------------------------------------------+

Threat Agents
=====================
To understand the attack surface, it is important to identify potential
attackers, i.e. attack entry points. The following threat agents are
in scope of this threat model.

.. table:: Table 3: Threat Agents

  +-------------------+-------------------------------------------------------+
  | Threat Agent      | Description                                           |
  +===================+=======================================================+
  |   ``NSCode``      | | Malicious or faulty code running in the Non-secure  |
  |                   |   world, including NS-EL0 NS-EL1 and NS-EL2 levels    |
  +-------------------+-------------------------------------------------------+
  |   ``SecCode``     | | Malicious or faulty code running in the secure      |
  |                   |   world, including S-EL0 and S-EL1 levels             |
  +-------------------+-------------------------------------------------------+
  |   ``AppDebug``    | | Physical attacker using  debug signals to access    |
  |                   |   TF-A resources                                      |
  +-------------------+-------------------------------------------------------+
  | ``PhysicalAccess``| | Physical attacker having access to external device  |
  |                   |   communication bus and to external flash             |
  |                   |   communication bus using common hardware             |
  +-------------------+-------------------------------------------------------+

.. note::

  In this threat model an advanced physical attacker that has the capability
  to tamper with a hardware (e.g. "rewiring" a chip using a focused
  ion beam (FIB) workstation or decapsulate the chip using chemicals) is
  considered out-of-scope.

Threat Types
========================
In this threat model we categorize threats using the `STRIDE threat
analysis technique`_. In this technique a threat is categorized as one
or more of these types: ``Spoofing``, ``Tampering``, ``Repudiation``,
``Information disclosure``, ``Denial of service`` or
``Elevation of privilege``.

Threat Risk Ratings
========================
For each threat identified, a risk rating that ranges
from *informational* to *critical* is given based on the likelihood of the
threat occuring if a mitigation is not in place, and the impact of the
threat (i.e. how severe the consequences could be). Table 4 explains each
rating in terms of score, impact and likelihood.

.. table:: Table 4: Rating and score as applied to impact and likelihood

  +-----------------------+-------------------------+---------------------------+
  | **Rating (Score)**    | **Impact**              | **Likelihood**            |
  +=======================+=========================+===========================+
  | ``Critical (5)``      | | Extreme impact to     | | Threat is almost        |
  |                       |   entire organization   |   certain to be exploited.|
  |                       |   if exploited.         |                           |
  |                       |                         | | Knowledge of the threat |
  |                       |                         |   and how to exploit it   |
  |                       |                         |   are in the public       |
  |                       |                         |   domain.                 |
  +-----------------------+-------------------------+---------------------------+
  | ``High (4)``          | | Major impact to entire| | Threat is relatively    |
  |                       |   organization or single|   easy to detect and      |
  |                       |   line of business if   |   exploit by an attacker  |
  |                       |   exploited             |   with little skill.      |
  +-----------------------+-------------------------+---------------------------+
  | ``Medium (3)``        | | Noticeable impact to  | | A knowledgeable insider |
  |                       |   line of business if   |   or expert attacker could|
  |                       |   exploited.            |   exploit the threat      |
  |                       |                         |   without much difficulty.|
  +-----------------------+-------------------------+---------------------------+
  | ``Low (2)``           | | Minor damage if       | | Exploiting the threat   |
  |                       |   exploited or could    |   would require           |
  |                       |   be used in conjunction|   considerable expertise  |
  |                       |   with other            |   and resources           |
  |                       |   vulnerabilities to    |                           |
  |                       |   perform a more serious|                           |
  |                       |   attack                |                           |
  +-----------------------+-------------------------+---------------------------+
  | ``Informational (1)`` | | Poor programming      | | Threat is not likely    |
  |                       |   practice or poor      |   to be exploited on its  |
  |                       |   design decision that  |   own, but may be used to |
  |                       |   may not represent an  |   gain information for    |
  |                       |   immediate risk on its |   launching another       |
  |                       |   own, but may have     |   attack                  |
  |                       |   security implications |                           |
  |                       |   if multiplied and/or  |                           |
  |                       |   combined with other   |                           |
  |                       |   threats.              |                           |
  +-----------------------+-------------------------+---------------------------+

Aggregate risk scores are assigned to identified threats;
specifically, the impact score multiplied by the likelihood score.
For example, a threat with high likelihood and low impact would have an
aggregate risk score of eight (8); that is, four (4) for high likelihood
multiplied by two (2) for low impact. The aggregate risk score determines
the finding's overall risk level, as shown in the following table.

.. table:: Table 5: Overall risk levels and corresponding aggregate scores

  +---------------------+-----------------------------------+
  | Overall Risk Level  | Aggregate Risk Score              |
  |                     | (Impact multiplied by Likelihood) |
  +=====================+===================================+
  | Critical            | 20–25                             |
  +---------------------+-----------------------------------+
  | High                | 12–19                             |
  +---------------------+-----------------------------------+
  | Medium              | 6–11                              |
  +---------------------+-----------------------------------+
  | Low                 | 2–5                               |
  +---------------------+-----------------------------------+
  | Informational       | 1                                 |
  +---------------------+-----------------------------------+

The likelihood and impact of a threat depends on the
target environment in which TF-A is running. For example, attacks
that require physical access are unlikely in server environments while
they are more common in Internet of Things(IoT) environments.
In this threat model we consider three target environments:
``Internet of Things(IoT)``, ``Mobile`` and ``Server``.

Threat Assessment
============================
The following threats were identified by applying STRIDE analysis on
each diagram element of the data flow diagram.

+------------------------+----------------------------------------------------+
| ID                     | 01                                                 |
+========================+====================================================+
| ``Threat``             | | **An attacker can mangle firmware images to      |
|                        |   execute arbitrary code**                         |
|                        |                                                    |
|                        | | Some TF-A images are loaded from external        |
|                        |   storage. It is possible for an attacker to access|
|                        |   the external flash memory and change its contents|
|                        |   physically, through the Rich OS, or using the    |
|                        |   updating mechanism to modify the non-volatile    |
|                        |   images to execute arbitrary code.                |
+------------------------+----------------------------------------------------+
| ``Diagram Elements``   | DF1, DF4, DF5                                      |
+------------------------+----------------------------------------------------+
| ``Affected TF-A        | BL2, BL31                                          |
| Components``           |                                                    |
+------------------------+----------------------------------------------------+
| ``Assets``             | Code Execution                                     |
+------------------------+----------------------------------------------------+
| ``Threat Agent``       | PhysicalAccess, NSCode, SecCode                    |
+------------------------+----------------------------------------------------+
| ``Threat Type``        | Tampering, Elevation of Privilege                  |
+------------------------+------------------+-----------------+---------------+
| ``Application``        | ``Server``       | ``IoT``         | ``Mobile``    |
+------------------------+------------------+-----------------+---------------+
| ``Impact``             | Critical (5)     | Critical (5)    | Critical (5)  |
+------------------------+------------------+-----------------+---------------+
| ``Likelihood``         | Critical (5)     | Critical (5)    | Critical (5)  |
+------------------------+------------------+-----------------+---------------+
| ``Total Risk Rating``  | Critical (25)    | Critical (25)   | Critical (25) |
+------------------------+------------------+-----------------+---------------+
| ``Mitigations``        | | TF-A implements the `Trusted Board Boot (TBB)`_  |
|                        |   feature which prevents malicious firmware from   |
|                        |   running on the platform by authenticating all    |
|                        |   firmware images. In addition to this, the TF-A   |
|                        |   boot firmware performs extra checks on           |
|                        |   unauthenticated data, such as FIP metadata, prior|
|                        |   to use.                                          |
+------------------------+----------------------------------------------------+

+------------------------+----------------------------------------------------+
| ID                     | 02                                                 |
+========================+====================================================+
| ``Threat``             | | **An attacker may attempt to boot outdated,      |
|                        |   potentially vulnerable firmware image**          |
|                        |                                                    |
|                        | | When updating firmware, an attacker may attempt  |
|                        |   to rollback to an older version that has unfixed |
|                        |   vulnerabilities.                                 |
+------------------------+----------------------------------------------------+
| ``Diagram Elements``   | DF1, DF4, DF5                                      |
+------------------------+----------------------------------------------------+
| ``Affected TF-A        | BL2, BL31                                          |
| Components``           |                                                    |
+------------------------+----------------------------------------------------+
| ``Assets``             | Code Execution                                     |
+------------------------+----------------------------------------------------+
| ``Threat Agent``       | PhysicalAccess, NSCode, SecCode                    |
+------------------------+----------------------------------------------------+
| ``Threat Type``        | Tampering                                          |
+------------------------+------------------+-----------------+---------------+
| ``Application``        | ``Server``       | ``IoT``         | ``Mobile``    |
+------------------------+------------------+-----------------+---------------+
| ``Impact``             | Critical (5)     | Critical (5)    | Critical (5)  |
+------------------------+------------------+-----------------+---------------+
| ``Likelihood``         | Critical (5)     | Critical (5)    | Critical (5)  |
+------------------------+------------------+-----------------+---------------+
| ``Total Risk Rating``  | Critical (25)    | Critical (25)   | Critical (25) |
+------------------------+------------------+-----------------+---------------+
| ``Mitigations``        | | TF-A supports anti-rollback protection using     |
|                        |   non-volatile counters (NV counters) as required  |
|                        |   by `TBBR-Client specification`_. After a firmware|
|                        |   image is validated, the image revision number    |
|                        |   taken from a certificate extension field is      |
|                        |   compared with the corresponding NV counter stored|
|                        |   in hardware to make sure the new counter value is|
|                        |   larger or equal to the current counter value.    |
|                        |   Platforms must implement this protection using   |
|                        |   platform specific hardware NV counters.          |
+------------------------+----------------------------------------------------+

+------------------------+-------------------------------------------------------+
| ID                     | 03                                                    |
+========================+=======================================================+
| ``Threat``             | |  **An attacker can use Time-of-Check-Time-of-Use    |
|                        |   (TOCTOU) attack to bypass image authentication      |
|                        |   during the boot process**                           |
|                        |                                                       |
|                        | | Time-of-Check-Time-of-Use (TOCTOU) threats occur    |
|                        |   when the security check is produced before the time |
|                        |   the resource is accessed. If an attacker is sitting |
|                        |   in the middle of the off-chip images, they could    |
|                        |   change the binary containing executable code right  |
|                        |   after the integrity and authentication check has    |
|                        |   been performed.                                     |
+------------------------+-------------------------------------------------------+
| ``Diagram Elements``   | DF1                                                   |
+------------------------+-------------------------------------------------------+
| ``Affected TF-A        | BL1, BL2                                              |
| Components``           |                                                       |
+------------------------+-------------------------------------------------------+
| ``Assets``             | Code Execution, Sensitive Data                        |
+------------------------+-------------------------------------------------------+
| ``Threat Agent``       | PhysicalAccess                                        |
+------------------------+-------------------------------------------------------+
| ``Threat Type``        | Elevation of Privilege                                |
+------------------------+---------------------+-----------------+---------------+
| ``Application``        | ``Server``          | ``IoT``         | ``Mobile``    |
+------------------------+---------------------+-----------------+---------------+
| ``Impact``             | N/A                 | Critical (5)    | Critical (5)  |
+------------------------+---------------------+-----------------+---------------+
| ``Likelihood``         | N/A                 | Medium (3)      | Medium (3)    |
+------------------------+---------------------+-----------------+---------------+
| ``Total Risk Rating``  | N/A                 | High (15)       | High (15)     |
+------------------------+---------------------+-----------------+---------------+
| ``Mitigations``        | | TF-A boot firmware copies image to on-chip          |
|                        |   memory before authenticating an image.              |
+------------------------+-------------------------------------------------------+

+------------------------+-------------------------------------------------------+
| ID                     | 04                                                    |
+========================+=======================================================+
| ``Threat``             | | **An attacker with physical access can execute      |
|                        |   arbitrary image by bypassing the signature          |
|                        |   verification stage using glitching techniques**     |
|                        |                                                       |
|                        | | Glitching (Fault injection) attacks attempt to put  |
|                        |   a hardware into a undefined state by manipulating an|
|                        |   environmental variable such as power supply.        |
|                        |                                                       |
|                        | | TF-A relies on a chain of trust that starts with the|
|                        |   ROTPK, which is the key stored inside the chip and  |
|                        |   the root of all validation processes. If an attacker|
|                        |   can break this chain of trust, they could execute   |
|                        |   arbitrary code on the device. This could be         |
|                        |   achieved with physical access to the device by      |
|                        |   attacking the normal execution flow of the          |
|                        |   process using glitching techniques that target      |
|                        |   points where the image is validated against the     |
|                        |   signature.                                          |
+------------------------+-------------------------------------------------------+
| ``Diagram Elements``   | DF1                                                   |
+------------------------+-------------------------------------------------------+
| ``Affected TF-A        | BL1, BL2                                              |
| Components``           |                                                       |
+------------------------+-------------------------------------------------------+
| ``Assets``             | Code Execution                                        |
+------------------------+-------------------------------------------------------+
| ``Threat Agent``       | PhysicalAccess                                        |
+------------------------+-------------------------------------------------------+
| ``Threat Type``        | Tampering, Elevation of Privilege                     |
+------------------------+---------------------+-----------------+---------------+
| ``Application``        | ``Server``          | ``IoT``         | ``Mobile``    |
+------------------------+---------------------+-----------------+---------------+
| ``Impact``             | N/A                 | Critical (5)    | Critical (5)  |
+------------------------+---------------------+-----------------+---------------+
| ``Likelihood``         | N/A                 | Medium (3)      | Medium (3)    |
+------------------------+---------------------+-----------------+---------------+
| ``Total Risk Rating``  | N/A                 | High (15)       | High (15)     |
+------------------------+---------------------+-----------------+---------------+
| ``Mitigations``        | | The most effective mitigation is adding glitching   |
|                        |   detection and mitigation circuit at the hardware    |
|                        |   level. However, software techniques,                |
|                        |   such as adding redundant checks when performing     |
|                        |   conditional branches that are security sensitive,   |
|                        |   can be used to harden TF-A against such attacks.    |
|                        |   **At the moment TF-A doesn't implement such         |
|                        |   mitigations.**                                      |
+------------------------+-------------------------------------------------------+

+------------------------+---------------------------------------------------+
| ID                     | 05                                                |
+========================+===================================================+
| ``Threat``             | | **Information leak via UART logs such as        |
|                        |   crashes**                                       |
|                        |                                                   |
|                        | | During the development stages of software it is |
|                        |   common to include crash reports with detailed   |
|                        |   information of the CPU state including current  |
|                        |   values of the registers, privilege level and    |
|                        |   stack dumps. This information is useful when    |
|                        |   debugging problems before releasing the         |
|                        |   production version, but it could be used by an  |
|                        |   attacker to develop a working exploit if left   |
|                        |   in the production version.                      |
+------------------------+---------------------------------------------------+
| ``Diagram Elements``   | DF2                                               |
+------------------------+---------------------------------------------------+
| ``Affected TF-A        | BL1, BL2, BL31                                    |
| Components``           |                                                   |
+------------------------+---------------------------------------------------+
| ``Assets``             | Sensitive Data                                    |
+------------------------+---------------------------------------------------+
| ``Threat Agent``       | AppDebug                                          |
+------------------------+---------------------------------------------------+
| ``Threat Type``        | Information Disclosure                            |
+------------------------+------------------+----------------+---------------+
| ``Application``        | ``Server``       | ``IoT``        | ``Mobile``    |
+------------------------+------------------+----------------+---------------+
| ``Impact``             | N/A              | Low (2)        | Low (2)       |
+------------------------+------------------+----------------+---------------+
| ``Likelihood``         | N/A              | High (4)       | High (4)      |
+------------------------+------------------+----------------+---------------+
| ``Total Risk Rating``  | N/A              | Medium (8)     | Medium (8)    |
+------------------------+------------------+----------------+---------------+
| ``Mitigations``        | | In TF-A, crash reporting is only enabled for    |
|                        |   debug builds by default. Alternatively, the log |
|                        |   level can be tuned at build time (from verbose  |
|                        |   to no output at all), independently of the      |
|                        |   build type.                                     |
+------------------------+---------------------------------------------------+

+------------------------+----------------------------------------------------+
| ID                     | 06                                                 |
+========================+====================================================+
| ``Threat``             | | **An attacker can read sensitive data and        |
|                        |   execute arbitrary code through the external      |
|                        |   debug and trace interface**                      |
|                        |                                                    |
|                        | | Arm processors include hardware-assisted debug   |
|                        |   and trace features that can be controlled without|
|                        |   the need for software operating on the platform. |
|                        |   If left enabled without authentication, this     |
|                        |   feature can be used by an attacker to inspect and|
|                        |   modify TF-A registers and memory allowing the    |
|                        |   attacker to read sensitive data and execute      |
|                        |   arbitrary code.                                  |
+------------------------+----------------------------------------------------+
| ``Diagram Elements``   | DF3                                                |
+------------------------+----------------------------------------------------+
| ``Affected TF-A        | BL1, BL2, BL31                                     |
| Components``           |                                                    |
+------------------------+----------------------------------------------------+
| ``Assets``             | Code Execution, Sensitive Data                     |
+------------------------+----------------------------------------------------+
| ``Threat Agent``       | AppDebug                                           |
+------------------------+----------------------------------------------------+
| ``Threat Type``        | Tampering, Information Disclosure,                 |
|                        | Elevation of privilege                             |
+------------------------+------------------+---------------+-----------------+
| ``Application``        | ``Server``       | ``IoT``       | ``Mobile``      |
+------------------------+------------------+---------------+-----------------+
| ``Impact``             | N/A              | High (4)      | High (4)        |
+------------------------+------------------+---------------+-----------------+
| ``Likelihood``         | N/A              | Critical (5)  | Critical (5)    |
+------------------------+------------------+---------------+-----------------+
| ``Total Risk Rating``  | N/A              | Critical (20) | Critical (20)   |
+------------------------+------------------+---------------+-----------------+
| ``Mitigations``        | | Configuration of debug and trace capabilities is |
|                        |   platform specific. Therefore, platforms must     |
|                        |   disable the debug and trace capability for       |
|                        |   production releases or enable proper debug       |
|                        |   authentication as recommended by [`DEN0034`_].   |
+------------------------+----------------------------------------------------+

+------------------------+------------------------------------------------------+
| ID                     | 07                                                   |
+========================+======================================================+
| ``Threat``             | | **An attacker can perform a denial-of-service      |
|                        |   attack by using a broken SMC call that causes the  |
|                        |   system to reboot or enter into unknown state.**    |
|                        |                                                      |
|                        | | Secure and non-secure clients access TF-A services |
|                        |   through SMC calls. Malicious code can attempt to   |
|                        |   place the TF-A runtime into an inconsistent state  |
|                        |   by calling unimplemented SMC call or by passing    |
|                        |   invalid arguments.                                 |
+------------------------+------------------------------------------------------+
| ``Diagram Elements``   | DF4, DF5                                             |
+------------------------+------------------------------------------------------+
| ``Affected TF-A        | BL31                                                 |
| Components``           |                                                      |
+------------------------+------------------------------------------------------+
| ``Assets``             | Availability                                         |
+------------------------+------------------------------------------------------+
| ``Threat Agent``       | NSCode, SecCode                                      |
+------------------------+------------------------------------------------------+
| ``Threat Type``        | Denial of Service                                    |
+------------------------+-------------------+----------------+-----------------+
| ``Application``        | ``Server``        | ``IoT``        | ``Mobile``      |
+------------------------+-------------------+----------------+-----------------+
| ``Impact``             | Medium (3)        | Medium (3)     | Medium (3)      |
+------------------------+-------------------+----------------+-----------------+
| ``Likelihood``         | High (4)          | High (4)       | High (4)        |
+------------------------+-------------------+----------------+-----------------+
| ``Total Risk Rating``  | High (12)         | High (12)      | High (12)       |
+------------------------+-------------------+----------------+-----------------+
| ``Mitigations``        | | The generic TF-A code validates SMC function ids   |
|                        |   and arguments before using them.                   |
|                        |   Platforms that implement SiP services must also    |
|                        |   validate SMC call arguments.                       |
+------------------------+------------------------------------------------------+

+------------------------+------------------------------------------------------+
| ID                     | 08                                                   |
+========================+======================================================+
| ``Threat``             | | **Memory corruption due to memory overflows and    |
|                        |   lack of boundary checking when accessing resources |
|                        |   could allow an attacker to execute arbitrary code, |
|                        |   modify some state variable to change the normal    |
|                        |   flow of the program, or leak sensitive             |
|                        |   information**                                      |
|                        |                                                      |
|                        | | Like in other software, the Trusted Firmware has   |
|                        |   multiple points where memory corruption security   |
|                        |   errors can arise. Memory corruption is a dangerous |
|                        |   security issue since it could allow an attacker    |
|                        |   to execute arbitrary code, modify some state       |
|                        |   variable to change the normal flow of the program, |
|                        |   or leak sensitive information.                     |
|                        |                                                      |
|                        | | Some of the errors include integer overflow,       |
|                        |   buffer overflow, incorrect array boundary checks,  |
|                        |   and incorrect error management.                    |
|                        |   Improper use of asserts instead of proper input    |
|                        |   validations might also result in these kinds of    |
|                        |   errors in release builds.                          |
+------------------------+------------------------------------------------------+
| ``Diagram Elements``   | DF4, DF5                                             |
+------------------------+------------------------------------------------------+
| ``Affected TF-A        | BL1, BL2, BL31                                       |
| Components``           |                                                      |
+------------------------+------------------------------------------------------+
| ``Assets``             | Code Execution, Sensitive Data                       |
+------------------------+------------------------------------------------------+
| ``Threat Agent``       | NSCode, SecCode                                      |
+------------------------+------------------------------------------------------+
| ``Threat Type``        | Tampering, Information Disclosure,                   |
|                        | Elevation of Privilege                               |
+------------------------+-------------------+-----------------+----------------+
| ``Application``        | ``Server``        | ``IoT``         | ``Mobile``     |
+------------------------+-------------------+-----------------+----------------+
| ``Impact``             | Critical (5)      | Critical (5)    | Critical (5)   |
+------------------------+-------------------+-----------------+----------------+
| ``Likelihood``         | Medium (3         | Medium (3)      | Medium (3)     |
+------------------------+-------------------+-----------------+----------------+
| ``Total Risk Rating``  | High (15)         | High (15)       | High (15)      |
+------------------------+-------------------+-----------------+----------------+
| ``Mitigations``        | | TF-A uses a combination of manual code reviews and |
|                        |   automated program analysis and testing to detect   |
|                        |   and fix memory corruption bugs. All TF-A code      |
|                        |   including platform code go through manual code     |
|                        |   reviews. Additionally, static code analysis is     |
|                        |   performed using Coverity Scan on all TF-A code.    |
|                        |   The code is also tested  with                      |
|                        |   `Trusted Firmware-A Tests`_ on Juno and FVP        |
|                        |   platforms.                                         |
|                        |                                                      |
|                        | | Data received from normal world, such as addresses |
|                        |   and sizes identifying memory regions, are          |
|                        |   sanitized before being used. These security checks |
|                        |   make sure that the normal world software does not  |
|                        |   access memory beyond its limit.                    |
|                        |                                                      |
|                        | | By default *asserts* are only used to check for    |
|                        |   programming errors in debug builds. Other types of |
|                        |   errors are handled through condition checks that   |
|                        |   remain enabled in release builds. See              |
|                        |   `TF-A error handling policy`_. TF-A provides an    |
|                        |   option to use *asserts* in release builds, however |
|                        |   we recommend using proper runtime checks instead   |
|                        |   of relying on asserts in release builds.           |
+------------------------+------------------------------------------------------+

+------------------------+------------------------------------------------------+
| ID                     | 09                                                   |
+========================+======================================================+
| ``Threat``             | | **Improperly handled SMC calls can leak register   |
|                        |   contents**                                         |
|                        |                                                      |
|                        | | When switching between secure and non-secure       |
|                        |   states, register contents of Secure world or       |
|                        |   register contents of other normal world clients    |
|                        |   can be leaked.                                     |
+------------------------+------------------------------------------------------+
| ``Diagram Elements``   | DF5                                                  |
+------------------------+------------------------------------------------------+
| ``Affected TF-A        | BL31                                                 |
| Components``           |                                                      |
+------------------------+------------------------------------------------------+
| ``Assets``             | Sensitive Data                                       |
+------------------------+------------------------------------------------------+
| ``Threat Agent``       | NSCode                                               |
+------------------------+------------------------------------------------------+
| ``Threat Type``        | Information Disclosure                               |
+------------------------+-------------------+----------------+-----------------+
| ``Application``        | ``Server``        | ``IoT``        | ``Mobile``      |
+------------------------+-------------------+----------------+-----------------+
| ``Impact``             | Medium (3)        | Medium (3)     | Medium (3)      |
+------------------------+-------------------+----------------+-----------------+
| ``Likelihood``         | High (4)          | High (4)       | High (4)        |
+------------------------+-------------------+----------------+-----------------+
| ``Total Risk Rating``  | High (12)         | High (12)      | High (12)       |
+------------------------+-------------------+----------------+-----------------+
| ``Mitigations``        | | TF-A saves and restores registers                  |
|                        |   by default when switching contexts. Build options  |
|                        |   are also provided to save/restore additional       |
|                        |   registers such as floating-point registers.        |
+------------------------+------------------------------------------------------+

+------------------------+-----------------------------------------------------+
| ID                     | 10                                                  |
+========================+=====================================================+
| ``Threat``             | | **SMC calls can leak sensitive information from   |
|                        |   TF-A memory via microarchitectural side channels**|
|                        |                                                     |
|                        | | Microarchitectural side-channel attacks such as   |
|                        |   `Spectre`_ can be used to leak data across        |
|                        |   security boundaries. An attacker might attempt to |
|                        |   use this kind of attack to leak sensitive         |
|                        |   data from TF-A memory.                            |
+------------------------+-----------------------------------------------------+
| ``Diagram Elements``   | DF4, DF5                                            |
+------------------------+-----------------------------------------------------+
| ``Affected TF-A        | BL31                                                |
| Components``           |                                                     |
+------------------------+-----------------------------------------------------+
| ``Assets``             | Sensitive Data                                      |
+------------------------+-----------------------------------------------------+
| ``Threat Agent``       | SecCode, NSCode                                     |
+------------------------+-----------------------------------------------------+
| ``Threat Type``        | Information Disclosure                              |
+------------------------+-------------------+----------------+----------------+
| ``Application``        | ``Server``        | ``IoT``        | ``Mobile``     |
+------------------------+-------------------+----------------+----------------+
| ``Impact``             | Medium (3)        | Medium (3)     | Medium (3)     |
+------------------------+-------------------+----------------+----------------+
| ``Likelihood``         | Medium (3)        | Medium (3)     | Medium (3)     |
+------------------------+-------------------+----------------+----------------+
| ``Total Risk Rating``  | Medium (9)        | Medium (9)     | Medium (9)     |
+------------------------+-------------------+----------------+----------------+
| ``Mitigations``        | | TF-A implements software mitigations for Spectre  |
|                        |   type attacks as recommended by `Cache Speculation |
|                        |   Side-channels`_ for the generic code. SiPs should |
|                        |   implement similar mitigations for code that is    |
|                        |   deemed to be vulnerable to such attacks.          |
+------------------------+-----------------------------------------------------+

+------------------------+----------------------------------------------------+
| ID                     | 11                                                 |
+========================+====================================================+
| ``Threat``             | | **Misconfiguration of the Memory Management Unit |
|                        |   (MMU) may allow a normal world software to       |
|                        |   access sensitive data or execute arbitrary       |
|                        |   code**                                           |
|                        |                                                    |
|                        | | A misconfiguration of the MMU could              |
|                        |   lead to an open door for software running in the |
|                        |   normal world to access sensitive data or even    |
|                        |   execute code if the proper security mechanisms   |
|                        |   are not in place.                                |
+------------------------+----------------------------------------------------+
| ``Diagram Elements``   | DF5, DF6                                           |
+------------------------+----------------------------------------------------+
| ``Affected TF-A        | BL1, BL2, BL31                                     |
| Components``           |                                                    |
+------------------------+----------------------------------------------------+
| ``Assets``             | Sensitive Data, Code execution                     |
+------------------------+----------------------------------------------------+
| ``Threat Agent``       | NSCode                                             |
+------------------------+----------------------------------------------------+
| ``Threat Type``        | Information Disclosure, Elevation of Privilege     |
+------------------------+-----------------+-----------------+----------------+
| ``Application``        | ``Server``      | ``IoT``         | ``Mobile``     |
+------------------------+-----------------+-----------------+----------------+
| ``Impact``             | Critical (5)    | Critical (5)    | Critical (5)   |
+------------------------+-----------------+-----------------+----------------+
| ``Likelihood``         | High (4)        | High (4)        | High (4)       |
+------------------------+-----------------+-----------------+----------------+
| ``Total Risk Rating``  | Critical (20)   | Critical (20)   | Critical (20)  |
+------------------------+-----------------+-----------------+----------------+
| ``Mitigations``        | | In TF-A, configuration of the MMU is done        |
|                        |   through a translation tables library. The        |
|                        |   library provides APIs to define memory regions   |
|                        |   and assign attributes including memory types and |
|                        |   access permissions. Memory configurations are    |
|                        |   platform specific, therefore platforms need make |
|                        |   sure the correct attributes are assigned to      |
|                        |   memory regions. When assigning access            |
|                        |   permissions, principle of least privilege ought  |
|                        |   to be enforced, i.e. we should not grant more    |
|                        |   privileges than strictly needed, e.g. code       |
|                        |   should be read-only executable, RO data should   |
|                        |   be read-only XN, and so on.                      |
+------------------------+----------------------------------------------------+

+------------------------+-----------------------------------------------------+
| ID                     | 12                                                  |
+========================+=====================================================+
| ``Threat``             | | **Incorrect configuration of Performance Monitor  |
|                        |   Unit (PMU) counters can allow an attacker to      |
|                        |   mount side-channel attacks using information      |
|                        |   exposed by the counters**                         |
|                        |                                                     |
|                        | | Non-secure software can configure PMU registers   |
|                        |   to count events at any exception level and in     |
|                        |   both Secure and Non-secure states. This allows    |
|                        |   a Non-secure software (or a lower-level Secure    |
|                        |   software) to potentially  carry out               |
|                        |   side-channel timing attacks against TF-A.         |
+------------------------+-----------------------------------------------------+
| ``Diagram Elements``   | DF5, DF6                                            |
+------------------------+-----------------------------------------------------+
| ``Affected TF-A        | BL31                                                |
| Components``           |                                                     |
+------------------------+-----------------------------------------------------+
| ``Assets``             | Sensitive Data                                      |
+------------------------+-----------------------------------------------------+
| ``Threat Agent``       | NSCode                                              |
+------------------------+-----------------------------------------------------+
| ``Threat Type``        | Information Disclosure                              |
+------------------------+-------------------+----------------+----------------+
| ``Impact``             | Medium (3)        | Medium (3)     | Medium (3)     |
+------------------------+-------------------+----------------+----------------+
| ``Likelihood``         | Low (2)           | Low (2)        | Low (2)        |
+------------------------+-------------------+----------------+----------------+
| ``Total Risk Rating``  | Medium (6)        | Medium (6)     | Medium (6)     |
+------------------------+-------------------+----------------+----------------+
| ``Mitigations``        | | TF-A follows mitigation strategies as described   |
|                        |   in `Secure Development Guidelines`_. General      |
|                        |   events and cycle counting in the Secure world is  |
|                        |   prohibited by default when applicable. However,   |
|                        |   on some implementations (e.g. PMUv3) Secure world |
|                        |   event counting depends on external debug interface|
|                        |   signals, i.e. Secure world event counting is      |
|                        |   enabled if external debug is enabled.             |
|                        |   Configuration of debug signals is platform        |
|                        |   specific, therefore platforms need to make sure   |
|                        |   that external debug is disabled in production or  |
|                        |   proper debug authentication is in place.          |
+------------------------+-----------------------------------------------------+

--------------

*Copyright (c) 2021, Arm Limited. All rights reserved.*


.. _STRIDE threat analysis technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model
.. _DEN0034: https://developer.arm.com/documentation/den0034/latest
.. _Cache Speculation Side-channels: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
.. _Spectre: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
.. _TBBR-Client specification: https://developer.arm.com/documentation/den0006/d/
.. _Trusted Board Boot (TBB): https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot.html
.. _TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines.html#error-handling-and-robustness
.. _Secure Development Guidelines: https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardening.html#secure-development-guidelines
.. _Trusted Firmware-A Tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/