SECURITY.md (7333B)
1 ## Reporting Vulnerabilities 2 3 If you think you have found an Mbed TLS security vulnerability, then please 4 send an email to the security team at 5 <mbed-tls-security@lists.trustedfirmware.org>. 6 7 ## Security Incident Handling Process 8 9 Our security process is detailed in our 10 [security 11 center](https://developer.trustedfirmware.org/w/mbed-tls/security-center/). 12 13 Its primary goal is to ensure fixes are ready to be deployed when the issue 14 goes public. 15 16 ## Maintained branches 17 18 Only the maintained branches, as listed in [`BRANCHES.md`](BRANCHES.md), 19 get security fixes. 20 Users are urged to always use the latest version of a maintained branch. 21 22 ## Threat model 23 24 We classify attacks based on the capabilities of the attacker. 25 26 ### Remote attacks 27 28 In this section, we consider an attacker who can observe and modify data sent 29 over the network. This includes observing the content and timing of individual 30 packets, as well as suppressing or delaying legitimate messages, and injecting 31 messages. 32 33 Mbed TLS aims to fully protect against remote attacks and to enable the user 34 application in providing full protection against remote attacks. Said 35 protection is limited to providing security guarantees offered by the protocol 36 being implemented. (For example Mbed TLS alone won't guarantee that the 37 messages will arrive without delay, as the TLS protocol doesn't guarantee that 38 either.) 39 40 **Warning!** Block ciphers do not yet achieve full protection against attackers 41 who can measure the timing of packets with sufficient precision. For details 42 and workarounds see the [Block Ciphers](#block-ciphers) section. 43 44 ### Local attacks 45 46 In this section, we consider an attacker who can run software on the same 47 machine. The attacker has insufficient privileges to directly access Mbed TLS 48 assets such as memory and files. 49 50 #### Timing attacks 51 52 The attacker is able to observe the timing of instructions executed by Mbed TLS 53 by leveraging shared hardware that both Mbed TLS and the attacker have access 54 to. Typical attack vectors include cache timings, memory bus contention and 55 branch prediction. 56 57 Mbed TLS provides limited protection against timing attacks. The cost of 58 protecting against timing attacks widely varies depending on the granularity of 59 the measurements and the noise present. Therefore the protection in Mbed TLS is 60 limited. We are only aiming to provide protection against **publicly 61 documented attack techniques**. 62 63 As attacks keep improving, so does Mbed TLS's protection. Mbed TLS is moving 64 towards a model of fully timing-invariant code, but has not reached this point 65 yet. 66 67 **Remark:** Timing information can be observed over the network or through 68 physical side channels as well. Remote and physical timing attacks are covered 69 in the [Remote attacks](remote-attacks) and [Physical 70 attacks](physical-attacks) sections respectively. 71 72 **Warning!** Block ciphers do not yet achieve full protection. For 73 details and workarounds see the [Block Ciphers](#block-ciphers) section. 74 75 #### Local non-timing side channels 76 77 The attacker code running on the platform has access to some sensor capable of 78 picking up information on the physical state of the hardware while Mbed TLS is 79 running. This could for example be an analogue-to-digital converter on the 80 platform that is located unfortunately enough to pick up the CPU noise. 81 82 Mbed TLS doesn't make any security guarantees against local non-timing-based 83 side channel attacks. If local non-timing attacks are present in a use case or 84 a user application's threat model, they need to be mitigated by the platform. 85 86 #### Local fault injection attacks 87 88 Software running on the same hardware can affect the physical state of the 89 device and introduce faults. 90 91 Mbed TLS doesn't make any security guarantees against local fault injection 92 attacks. If local fault injection attacks are present in a use case or a user 93 application's threat model, they need to be mitigated by the platform. 94 95 ### Physical attacks 96 97 In this section, we consider an attacker who has access to physical information 98 about the hardware Mbed TLS is running on and/or can alter the physical state 99 of the hardware (e.g. power analysis, radio emissions or fault injection). 100 101 Mbed TLS doesn't make any security guarantees against physical attacks. If 102 physical attacks are present in a use case or a user application's threat 103 model, they need to be mitigated by physical countermeasures. 104 105 ### Caveats 106 107 #### Out-of-scope countermeasures 108 109 Mbed TLS has evolved organically and a well defined threat model hasn't always 110 been present. Therefore, Mbed TLS might have countermeasures against attacks 111 outside the above defined threat model. 112 113 The presence of such countermeasures don't mean that Mbed TLS provides 114 protection against a class of attacks outside of the above described threat 115 model. Neither does it mean that the failure of such a countermeasure is 116 considered a vulnerability. 117 118 #### Block ciphers 119 120 Currently there are four block ciphers in Mbed TLS: AES, CAMELLIA, ARIA and 121 DES. The pure software implementation in Mbed TLS implementation uses lookup 122 tables, which are vulnerable to timing attacks. 123 124 These timing attacks can be physical, local or depending on network latency 125 even a remote. The attacks can result in key recovery. 126 127 **Workarounds:** 128 129 - Turn on hardware acceleration for AES. This is supported only on selected 130 architectures and currently only available for AES. See configuration options 131 `MBEDTLS_AESCE_C`, `MBEDTLS_AESNI_C` and `MBEDTLS_PADLOCK_C` for details. 132 - Add a secure alternative implementation (typically hardware acceleration) for 133 the vulnerable cipher. See the [Alternative Implementations 134 Guide](docs/architecture/alternative-implementations.md) for more information. 135 - Use cryptographic mechanisms that are not based on block ciphers. In 136 particular, for authenticated encryption, use ChaCha20/Poly1305 instead of 137 block cipher modes. For random generation, use HMAC\_DRBG instead of CTR\_DRBG. 138 139 #### Everest 140 141 The HACL* implementation of X25519 taken from the Everest project only protects 142 against remote timing attacks. (See their [Security 143 Policy](https://github.com/hacl-star/hacl-star/blob/main/SECURITY.md).) 144 145 The Everest variant is only used when `MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED` 146 configuration option is defined. This option is off by default. 147 148 #### Formatting of X.509 certificates and certificate signing requests 149 150 When parsing X.509 certificates and certificate signing requests (CSRs), 151 Mbed TLS does not check that they are strictly compliant with X.509 and other 152 relevant standards. In the case of signed certificates, the signing party is 153 assumed to have performed this validation (and the certificate is trusted to 154 be correctly formatted as long as the signature is correct). 155 Similarly, CSRs are implicitly trusted by Mbed TLS to be standards-compliant. 156 157 **Warning!** Mbed TLS must not be used to sign untrusted CSRs unless extra 158 validation is performed separately to ensure that they are compliant to the 159 relevant specifications. This makes Mbed TLS on its own unsuitable for use in 160 a Certificate Authority (CA). 161 162 However, Mbed TLS aims to protect against memory corruption and other 163 undefined behavior when parsing certificates and CSRs. If a CSR or signed 164 certificate causes undefined behavior when it is parsed by Mbed TLS, that 165 is considered a security vulnerability.