1## Reporting Vulnerabilities 2 3If you think you have found an Mbed TLS security vulnerability, then please 4send an email to the security team at 5<mbed-tls-security@lists.trustedfirmware.org>. 6 7## Security Incident Handling Process 8 9Our security process is detailed in our 10[security 11center](https://developer.trustedfirmware.org/w/mbed-tls/security-center/). 12 13Its primary goal is to ensure fixes are ready to be deployed when the issue 14goes public. 15 16## Maintained branches 17 18Only the maintained branches, as listed in [`BRANCHES.md`](BRANCHES.md), 19get security fixes. 20Users are urged to always use the latest version of a maintained branch. 21 22## Threat model 23 24We classify attacks based on the capabilities of the attacker. 25 26### Remote attacks 27 28In this section, we consider an attacker who can observe and modify data sent 29over the network. This includes observing the content and timing of individual 30packets, as well as suppressing or delaying legitimate messages, and injecting 31messages. 32 33Mbed TLS aims to fully protect against remote attacks and to enable the user 34application in providing full protection against remote attacks. Said 35protection is limited to providing security guarantees offered by the protocol 36being implemented. (For example Mbed TLS alone won't guarantee that the 37messages will arrive without delay, as the TLS protocol doesn't guarantee that 38either.) 39 40**Warning!** Block ciphers do not yet achieve full protection against attackers 41who can measure the timing of packets with sufficient precision. For details 42and workarounds see the [Block Ciphers](#block-ciphers) section. 43 44### Local attacks 45 46In this section, we consider an attacker who can run software on the same 47machine. The attacker has insufficient privileges to directly access Mbed TLS 48assets such as memory and files. 49 50#### Timing attacks 51 52The attacker is able to observe the timing of instructions executed by Mbed TLS 53by leveraging shared hardware that both Mbed TLS and the attacker have access 54to. Typical attack vectors include cache timings, memory bus contention and 55branch prediction. 56 57Mbed TLS provides limited protection against timing attacks. The cost of 58protecting against timing attacks widely varies depending on the granularity of 59the measurements and the noise present. Therefore the protection in Mbed TLS is 60limited. We are only aiming to provide protection against **publicly 61documented attack techniques**. 62 63As attacks keep improving, so does Mbed TLS's protection. Mbed TLS is moving 64towards a model of fully timing-invariant code, but has not reached this point 65yet. 66 67**Remark:** Timing information can be observed over the network or through 68physical side channels as well. Remote and physical timing attacks are covered 69in the [Remote attacks](remote-attacks) and [Physical 70attacks](physical-attacks) sections respectively. 71 72**Warning!** Block ciphers do not yet achieve full protection. For 73details and workarounds see the [Block Ciphers](#block-ciphers) section. 74 75#### Local non-timing side channels 76 77The attacker code running on the platform has access to some sensor capable of 78picking up information on the physical state of the hardware while Mbed TLS is 79running. This could for example be an analogue-to-digital converter on the 80platform that is located unfortunately enough to pick up the CPU noise. 81 82Mbed TLS doesn't make any security guarantees against local non-timing-based 83side channel attacks. If local non-timing attacks are present in a use case or 84a user application's threat model, they need to be mitigated by the platform. 85 86#### Local fault injection attacks 87 88Software running on the same hardware can affect the physical state of the 89device and introduce faults. 90 91Mbed TLS doesn't make any security guarantees against local fault injection 92attacks. If local fault injection attacks are present in a use case or a user 93application's threat model, they need to be mitigated by the platform. 94 95### Physical attacks 96 97In this section, we consider an attacker who has access to physical information 98about the hardware Mbed TLS is running on and/or can alter the physical state 99of the hardware (e.g. power analysis, radio emissions or fault injection). 100 101Mbed TLS doesn't make any security guarantees against physical attacks. If 102physical attacks are present in a use case or a user application's threat 103model, they need to be mitigated by physical countermeasures. 104 105### Caveats 106 107#### Out-of-scope countermeasures 108 109Mbed TLS has evolved organically and a well defined threat model hasn't always 110been present. Therefore, Mbed TLS might have countermeasures against attacks 111outside the above defined threat model. 112 113The presence of such countermeasures don't mean that Mbed TLS provides 114protection against a class of attacks outside of the above described threat 115model. Neither does it mean that the failure of such a countermeasure is 116considered a vulnerability. 117 118#### Block ciphers 119 120Currently there are four block ciphers in Mbed TLS: AES, CAMELLIA, ARIA and 121DES. The pure software implementation in Mbed TLS implementation uses lookup 122tables, which are vulnerable to timing attacks. 123 124These timing attacks can be physical, local or depending on network latency 125even 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 134Guide](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 141The HACL* implementation of X25519 taken from the Everest project only protects 142against remote timing attacks. (See their [Security 143Policy](https://github.com/hacl-star/hacl-star/blob/main/SECURITY.md).) 144 145The Everest variant is only used when `MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED` 146configuration option is defined. This option is off by default. 147
