From ce2985b22cc33537e376d896e16409e595f9fc31 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Fri, 24 Feb 2023 16:00:21 +0000 Subject: [PATCH 01/15] Add Threat Model Summary Signed-off-by: Janos Follath --- SECURITY.md | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index 33bbc2ff30..ae37dab778 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -18,3 +18,63 @@ goes public. Only the maintained branches, as listed in [`BRANCHES.md`](BRANCHES.md), get security fixes. Users are urged to always use the latest version of a maintained branch. + +## Threat model + +We use the following classification of attacks: + +- **Remote Attacks:** The attacker can observe and modify data sent over the + network. This includes observing timing of individual packets and potentially + delaying legitimate messages. +- **Timing Attacks:** The attacker can gain information about the time certain + sets of instructions in Mbed TLS operations take. +- **Physical Attacks:** The attacker has access to physical information about + the hardware Mbed TLS is running on and/or can alter the physical state of + the hardware. + +### Remote attacks + +Mbed TLS aims to fully protect against remote attacks. Mbed Crypto aims to +enable the user application in providing full protection against remote +attacks. Said protection is limited to providing security guarantees offered by +the protocol in question. (For example Mbed TLS alone won't guarantee that the +messages will arrive without delay, as the TLS protocol doesn't guarantee that +either.) + +### Timing attacks + +Mbed TLS and Mbed Crypto provide limited protection against timing attacks. The +cost of protecting against timing attacks widely varies depending on the +granularity of the measurements and the noise present. Therefore the protection +in Mbed TLS and Mbed Crypto is limited. We are only aiming to provide protection +against publicly documented attacks. + +**Warning!** Block ciphers constitute an exception from this protection. For +details and workarounds see the section below. + +#### Block Ciphers + +Currently there are 4 block ciphers in Mbed TLS: AES, CAMELLIA, ARIA and DES. +The Mbed TLS implementation uses lookup tables, which are vulnerable to timing +attacks. + +**Workarounds:** + +- Turn on hardware acceleration for AES. This is supported only on selected + architectures and currently only available for AES. See configuration options + `MBEDTLS_AESCE_C`, `MBEDTLS_AESNI_C` and `MBEDTLS_PADLOCK_C` for details. +- Add a secure alternative implementation (typically bitslice implementation or + hardware acceleration) for the vulnerable cipher. See the [Alternative +Implementations Guide](docs/architecture/alternative-implementations.md) for + more information. +- Instead of a block cipher, use ChaCha20/Poly1305 for encryption and data + origin authentication. + +### Physical attacks + +Physical attacks are out of scope. Any attack using information about or +influencing the physical state of the hardware is considered physical, +independently of the attack vector. (For example Row Hammer and Screaming +Channels are considered physical attacks.) If physical attacks are present in a +use case or a user application's threat model, it needs to be mitigated by +physical countermeasures. From 661c88f2ba1ccbb0d95c81743d63c67c897cbe54 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Fri, 3 Mar 2023 14:16:12 +0000 Subject: [PATCH 02/15] Threat Model: Improve wording Signed-off-by: Janos Follath Co-authored-by: Dave Rodgman --- SECURITY.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index ae37dab778..50c8ffd980 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -26,8 +26,8 @@ We use the following classification of attacks: - **Remote Attacks:** The attacker can observe and modify data sent over the network. This includes observing timing of individual packets and potentially delaying legitimate messages. -- **Timing Attacks:** The attacker can gain information about the time certain - sets of instructions in Mbed TLS operations take. +- **Timing Attacks:** The attacker can gain information about the time taken + by certain sets of instructions in Mbed TLS operations. - **Physical Attacks:** The attacker has access to physical information about the hardware Mbed TLS is running on and/or can alter the physical state of the hardware. @@ -47,14 +47,14 @@ Mbed TLS and Mbed Crypto provide limited protection against timing attacks. The cost of protecting against timing attacks widely varies depending on the granularity of the measurements and the noise present. Therefore the protection in Mbed TLS and Mbed Crypto is limited. We are only aiming to provide protection -against publicly documented attacks. +against publicly documented attacks, and this protection is not currently complete. -**Warning!** Block ciphers constitute an exception from this protection. For +**Warning!** Block ciphers do not yet achieve full protection. For details and workarounds see the section below. #### Block Ciphers -Currently there are 4 block ciphers in Mbed TLS: AES, CAMELLIA, ARIA and DES. +Currently there are four block ciphers in Mbed TLS: AES, CAMELLIA, ARIA and DES. The Mbed TLS implementation uses lookup tables, which are vulnerable to timing attacks. @@ -63,7 +63,7 @@ attacks. - Turn on hardware acceleration for AES. This is supported only on selected architectures and currently only available for AES. See configuration options `MBEDTLS_AESCE_C`, `MBEDTLS_AESNI_C` and `MBEDTLS_PADLOCK_C` for details. -- Add a secure alternative implementation (typically bitslice implementation or +- Add a secure alternative implementation (typically a bitsliced implementation or hardware acceleration) for the vulnerable cipher. See the [Alternative Implementations Guide](docs/architecture/alternative-implementations.md) for more information. From e57ed98f9e4d3049519cb46aa8ab887877e07d32 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Fri, 3 Mar 2023 14:56:38 +0000 Subject: [PATCH 03/15] Threat Model: Miscellaneous clarifications Signed-off-by: Janos Follath --- SECURITY.md | 53 ++++++++++++++++++++++++++--------------------------- 1 file changed, 26 insertions(+), 27 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 50c8ffd980..4ed9d3807c 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -24,8 +24,8 @@ Users are urged to always use the latest version of a maintained branch. We use the following classification of attacks: - **Remote Attacks:** The attacker can observe and modify data sent over the - network. This includes observing timing of individual packets and potentially - delaying legitimate messages. + network. This includes observing the content and timing of individual packets, + as well as suppressing or delaying legitimate messages, and injecting messages. - **Timing Attacks:** The attacker can gain information about the time taken by certain sets of instructions in Mbed TLS operations. - **Physical Attacks:** The attacker has access to physical information about @@ -34,20 +34,19 @@ We use the following classification of attacks: ### Remote attacks -Mbed TLS aims to fully protect against remote attacks. Mbed Crypto aims to -enable the user application in providing full protection against remote -attacks. Said protection is limited to providing security guarantees offered by -the protocol in question. (For example Mbed TLS alone won't guarantee that the -messages will arrive without delay, as the TLS protocol doesn't guarantee that -either.) +Mbed TLS aims to fully protect against remote attacks and to enable the user +application in providing full protection against remote attacks. Said +protection is limited to providing security guarantees offered by the protocol +in question. (For example Mbed TLS alone won't guarantee that the messages will +arrive without delay, as the TLS protocol doesn't guarantee that either.) ### Timing attacks -Mbed TLS and Mbed Crypto provide limited protection against timing attacks. The -cost of protecting against timing attacks widely varies depending on the -granularity of the measurements and the noise present. Therefore the protection -in Mbed TLS and Mbed Crypto is limited. We are only aiming to provide protection -against publicly documented attacks, and this protection is not currently complete. +Mbed TLS provides limited protection against timing attacks. The cost of +protecting against timing attacks widely varies depending on the granularity of +the measurements and the noise present. Therefore the protection in Mbed TLS is +limited. We are only aiming to provide protection against publicly documented +attacks, and this protection is not currently complete. **Warning!** Block ciphers do not yet achieve full protection. For details and workarounds see the section below. @@ -55,26 +54,26 @@ details and workarounds see the section below. #### Block Ciphers Currently there are four block ciphers in Mbed TLS: AES, CAMELLIA, ARIA and DES. -The Mbed TLS implementation uses lookup tables, which are vulnerable to timing -attacks. +The pure software implementation in Mbed TLS implementation uses lookup tables, +which are vulnerable to timing attacks. **Workarounds:** - Turn on hardware acceleration for AES. This is supported only on selected architectures and currently only available for AES. See configuration options `MBEDTLS_AESCE_C`, `MBEDTLS_AESNI_C` and `MBEDTLS_PADLOCK_C` for details. -- Add a secure alternative implementation (typically a bitsliced implementation or - hardware acceleration) for the vulnerable cipher. See the [Alternative -Implementations Guide](docs/architecture/alternative-implementations.md) for - more information. -- Instead of a block cipher, use ChaCha20/Poly1305 for encryption and data - origin authentication. +- Add a secure alternative implementation (typically hardware acceleration) for + the vulnerable cipher. See the [Alternative Implementations +Guide](docs/architecture/alternative-implementations.md) for more information. +- Use cryptographic mechanisms that are not based on block ciphers. In + particular, for authenticated encryption, use ChaCha20/Poly1305 instead of + block cipher modes. For random generation, use HMAC\_DRBG instead of CTR\_DRBG. ### Physical attacks -Physical attacks are out of scope. Any attack using information about or -influencing the physical state of the hardware is considered physical, -independently of the attack vector. (For example Row Hammer and Screaming -Channels are considered physical attacks.) If physical attacks are present in a -use case or a user application's threat model, it needs to be mitigated by -physical countermeasures. +Physical attacks are out of scope (eg. power analysis or radio emissions). Any +attack using information about or influencing the physical state of the +hardware is considered physical, independently of the attack vector. (For +example Row Hammer and Screaming Channels are considered physical attacks.) If +physical attacks are present in a use case or a user application's threat +model, it needs to be mitigated by physical countermeasures. From 5adb2c2328acb5d8280e2bd666860caa3d4ec174 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Mon, 6 Mar 2023 14:54:59 +0000 Subject: [PATCH 04/15] Threat Model: reorganise threat definitions Simplify organisation by placing threat definitions in their respective sections. Signed-off-by: Janos Follath --- SECURITY.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 4ed9d3807c..7981a44b64 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -23,17 +23,12 @@ Users are urged to always use the latest version of a maintained branch. We use the following classification of attacks: -- **Remote Attacks:** The attacker can observe and modify data sent over the - network. This includes observing the content and timing of individual packets, - as well as suppressing or delaying legitimate messages, and injecting messages. -- **Timing Attacks:** The attacker can gain information about the time taken - by certain sets of instructions in Mbed TLS operations. -- **Physical Attacks:** The attacker has access to physical information about - the hardware Mbed TLS is running on and/or can alter the physical state of - the hardware. - ### Remote attacks +The attacker can observe and modify data sent over the network. This includes +observing the content and timing of individual packets, as well as suppressing +or delaying legitimate messages, and injecting messages. + Mbed TLS aims to fully protect against remote attacks and to enable the user application in providing full protection against remote attacks. Said protection is limited to providing security guarantees offered by the protocol @@ -42,6 +37,9 @@ arrive without delay, as the TLS protocol doesn't guarantee that either.) ### Timing attacks +The attacker can gain information about the time taken by certain sets of +instructions in Mbed TLS operations. + Mbed TLS provides limited protection against timing attacks. The cost of protecting against timing attacks widely varies depending on the granularity of the measurements and the noise present. Therefore the protection in Mbed TLS is @@ -71,6 +69,9 @@ Guide](docs/architecture/alternative-implementations.md) for more information. ### Physical attacks +The attacker has access to physical information about the hardware Mbed TLS is +running on and/or can alter the physical state of the hardware. + Physical attacks are out of scope (eg. power analysis or radio emissions). Any attack using information about or influencing the physical state of the hardware is considered physical, independently of the attack vector. (For From adc8a0bceff7bb2fb9d8b4dc0cdcc956e5d74a0d Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Wed, 8 Mar 2023 16:10:39 +0000 Subject: [PATCH 05/15] Threat Model: increase classification detail Originally for the sake of simplicity there was a single category for software based attacks, namely timing side channel attacks. Be more precise and categorise attacks as software based whether or not they rely on physical information. Signed-off-by: Janos Follath --- SECURITY.md | 54 ++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 43 insertions(+), 11 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 7981a44b64..c6345d65c8 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -35,22 +35,33 @@ protection is limited to providing security guarantees offered by the protocol in question. (For example Mbed TLS alone won't guarantee that the messages will arrive without delay, as the TLS protocol doesn't guarantee that either.) -### Timing attacks +### Local attacks + +The attacker is capable of running code on the same hardware as Mbed TLS, but +there is still a security boundary between them (ie. the attacker can't for +example read secrets from Mbed TLS' memory directly). + +#### Timing attacks The attacker can gain information about the time taken by certain sets of -instructions in Mbed TLS operations. +instructions in Mbed TLS operations. (See for example the [Flush+Reload +paper](https://eprint.iacr.org/2013/448.pdf).) + +(Technically, timing information can be observed over the network or through +physical side channels as well. Network timing attacks are less powerful than +local and countermeasures protecting against local attacks prevent network +attacks as well. If the timing information is gained through physical side +channels, we consider them physical attacks and as such they are out of scope.) Mbed TLS provides limited protection against timing attacks. The cost of protecting against timing attacks widely varies depending on the granularity of the measurements and the noise present. Therefore the protection in Mbed TLS is -limited. We are only aiming to provide protection against publicly documented -attacks, and this protection is not currently complete. +limited. We are only aiming to provide protection against **publicly +documented** attacks, and this protection is not currently complete. **Warning!** Block ciphers do not yet achieve full protection. For details and workarounds see the section below. -#### Block Ciphers - Currently there are four block ciphers in Mbed TLS: AES, CAMELLIA, ARIA and DES. The pure software implementation in Mbed TLS implementation uses lookup tables, which are vulnerable to timing attacks. @@ -67,14 +78,35 @@ Guide](docs/architecture/alternative-implementations.md) for more information. particular, for authenticated encryption, use ChaCha20/Poly1305 instead of block cipher modes. For random generation, use HMAC\_DRBG instead of CTR\_DRBG. +#### Local non-timing side channels + +The attacker code running on the platform has access to some sensor capable of +picking up information on the physical state of the hardware while Mbed TLS is +running. This can for example be any analogue to digital converter on the +platform that is located unfortunately enough to pick up the CPU noise. (See +for example the [Leaky Noise +paper](https://tches.iacr.org/index.php/TCHES/article/view/8297).) + +Mbed TLS doesn't offer any security guarantees against local non-timing based +side channel attacks. If local non-timing attacks are present in a use case or +a user application's threat model, it needs to be mitigated by the platform. + +#### Local fault injection attacks + +Software running on the same hardware can affect the physical state of the +device and introduce faults. (See for example the [Row Hammer +paper](https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf).) + +Mbed TLS doesn't offer any security guarantees against local fault injection +attacks. If local fault injection attacks are present in a use case or a user +application's threat model, it needs to be mitigated by the platform. + ### Physical attacks The attacker has access to physical information about the hardware Mbed TLS is -running on and/or can alter the physical state of the hardware. +running on and/or can alter the physical state of the hardware (eg. power +analysis, radio emissions or fault injection). -Physical attacks are out of scope (eg. power analysis or radio emissions). Any -attack using information about or influencing the physical state of the -hardware is considered physical, independently of the attack vector. (For -example Row Hammer and Screaming Channels are considered physical attacks.) If +Mbed TLS doesn't offer any security guarantees against physical attacks. If physical attacks are present in a use case or a user application's threat model, it needs to be mitigated by physical countermeasures. From 389cdf43ab0404741e9433d68b8658ea011d29d6 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Wed, 8 Mar 2023 16:38:07 +0000 Subject: [PATCH 06/15] Threat model: explain dangling countermeasures Signed-off-by: Janos Follath --- SECURITY.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index c6345d65c8..95e549f44e 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -110,3 +110,16 @@ analysis, radio emissions or fault injection). Mbed TLS doesn't offer any security guarantees against physical attacks. If physical attacks are present in a use case or a user application's threat model, it needs to be mitigated by physical countermeasures. + +### Caveats + +#### Out of scope countermeasures + +Mbed TLS has evolved organically and a well defined threat model hasn't always +been present. Therefore, Mbed TLS might have countermeasures against attacks +outside the above defined threat model. + +The presence of such countermeasures don't mean that Mbed TLS provides +protection against a class of attacks outside of the above described threat +model. Neither does it mean that the failure of such a countermeasure is +considered a vulnerability. From 5e68d3b05f299f9de9a56678a044f06396580419 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Wed, 8 Mar 2023 16:53:50 +0000 Subject: [PATCH 07/15] Threat Model: move the block cipher section The block cipher exception affects both remote and local timing attacks. Move them to the Caveats section and reference it from both the local and the remote attack section. Signed-off-by: Janos Follath --- SECURITY.md | 44 +++++++++++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 17 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 95e549f44e..677e68555d 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -35,6 +35,11 @@ protection is limited to providing security guarantees offered by the protocol in question. (For example Mbed TLS alone won't guarantee that the messages will arrive without delay, as the TLS protocol doesn't guarantee that either.) +**Warning!** Depending on network latency, the timing of messages might be +enough to launch some timing attacks. Block ciphers do not yet achieve full +protection against these. For details and workarounds see the [Block +Ciphers](#block-ciphers) section. + ### Local attacks The attacker is capable of running code on the same hardware as Mbed TLS, but @@ -60,23 +65,7 @@ limited. We are only aiming to provide protection against **publicly documented** attacks, and this protection is not currently complete. **Warning!** Block ciphers do not yet achieve full protection. For -details and workarounds see the section below. - -Currently there are four block ciphers in Mbed TLS: AES, CAMELLIA, ARIA and DES. -The pure software implementation in Mbed TLS implementation uses lookup tables, -which are vulnerable to timing attacks. - -**Workarounds:** - -- Turn on hardware acceleration for AES. This is supported only on selected - architectures and currently only available for AES. See configuration options - `MBEDTLS_AESCE_C`, `MBEDTLS_AESNI_C` and `MBEDTLS_PADLOCK_C` for details. -- Add a secure alternative implementation (typically hardware acceleration) for - the vulnerable cipher. See the [Alternative Implementations -Guide](docs/architecture/alternative-implementations.md) for more information. -- Use cryptographic mechanisms that are not based on block ciphers. In - particular, for authenticated encryption, use ChaCha20/Poly1305 instead of - block cipher modes. For random generation, use HMAC\_DRBG instead of CTR\_DRBG. +details and workarounds see the [Block Ciphers](#block-ciphers) section. #### Local non-timing side channels @@ -123,3 +112,24 @@ The presence of such countermeasures don't mean that Mbed TLS provides protection against a class of attacks outside of the above described threat model. Neither does it mean that the failure of such a countermeasure is considered a vulnerability. + +#### Block ciphers + +Currently there are four block ciphers in Mbed TLS: AES, CAMELLIA, ARIA and +DES. The pure software implementation in Mbed TLS implementation uses lookup +tables, which are vulnerable to timing attacks. + +These timing attacks can be physical, local or depending on network latency +even a remote. The attacks can result in key recovery. + +**Workarounds:** + +- Turn on hardware acceleration for AES. This is supported only on selected + architectures and currently only available for AES. See configuration options + `MBEDTLS_AESCE_C`, `MBEDTLS_AESNI_C` and `MBEDTLS_PADLOCK_C` for details. +- Add a secure alternative implementation (typically hardware acceleration) for + the vulnerable cipher. See the [Alternative Implementations +Guide](docs/architecture/alternative-implementations.md) for more information. +- Use cryptographic mechanisms that are not based on block ciphers. In + particular, for authenticated encryption, use ChaCha20/Poly1305 instead of + block cipher modes. For random generation, use HMAC\_DRBG instead of CTR\_DRBG. From 18ffba6100c8a12380debe128b24ccb649482495 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Wed, 8 Mar 2023 19:58:29 +0000 Subject: [PATCH 08/15] Threat Model: improve wording Signed-off-by: Janos Follath --- SECURITY.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 677e68555d..d0281ace93 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -42,14 +42,14 @@ Ciphers](#block-ciphers) section. ### Local attacks -The attacker is capable of running code on the same hardware as Mbed TLS, but -there is still a security boundary between them (ie. the attacker can't for -example read secrets from Mbed TLS' memory directly). +The attacker can run software on the same machine. The attacker has +insufficient privileges to directly access Mbed TLS assets such as memory and +files. #### Timing attacks -The attacker can gain information about the time taken by certain sets of -instructions in Mbed TLS operations. (See for example the [Flush+Reload +The attacker is able to observe the timing of instructions executed by Mbed +TLS.(See for example the [Flush+Reload paper](https://eprint.iacr.org/2013/448.pdf).) (Technically, timing information can be observed over the network or through From 8257d8aa000a51e9e7064ecf891459db0c115652 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Wed, 8 Mar 2023 20:07:59 +0000 Subject: [PATCH 09/15] Threat Model: clarify attack vectors Timing attacks can be launched by any of the main 3 attackers. Clarify exactly how these are covered. Signed-off-by: Janos Follath --- SECURITY.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index d0281ace93..387221e61f 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -52,17 +52,16 @@ The attacker is able to observe the timing of instructions executed by Mbed TLS.(See for example the [Flush+Reload paper](https://eprint.iacr.org/2013/448.pdf).) -(Technically, timing information can be observed over the network or through -physical side channels as well. Network timing attacks are less powerful than -local and countermeasures protecting against local attacks prevent network -attacks as well. If the timing information is gained through physical side -channels, we consider them physical attacks and as such they are out of scope.) - Mbed TLS provides limited protection against timing attacks. The cost of protecting against timing attacks widely varies depending on the granularity of the measurements and the noise present. Therefore the protection in Mbed TLS is limited. We are only aiming to provide protection against **publicly -documented** attacks, and this protection is not currently complete. +documented** attacks. + +**Remark:** Timing information can be observed over the network or through +physical side channels as well. Remote and physical timing attacks are covered +in the [Remote attacks](remote-attacks) and [Physical +attacks](physical-attacks) sections respectively. **Warning!** Block ciphers do not yet achieve full protection. For details and workarounds see the [Block Ciphers](#block-ciphers) section. From 6ce259d287b48e0420caf6a9a89aaaf8fb710c2e Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Tue, 14 Mar 2023 12:47:27 +0000 Subject: [PATCH 10/15] Threat Model: improve wording and grammar Signed-off-by: Janos Follath --- SECURITY.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 387221e61f..dcffa1d9be 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -21,7 +21,7 @@ Users are urged to always use the latest version of a maintained branch. ## Threat model -We use the following classification of attacks: +We classify attacks based on the capabilities of the attacker. ### Remote attacks @@ -32,13 +32,13 @@ or delaying legitimate messages, and injecting messages. Mbed TLS aims to fully protect against remote attacks and to enable the user application in providing full protection against remote attacks. Said protection is limited to providing security guarantees offered by the protocol -in question. (For example Mbed TLS alone won't guarantee that the messages will -arrive without delay, as the TLS protocol doesn't guarantee that either.) +being implemented. (For example Mbed TLS alone won't guarantee that the +messages will arrive without delay, as the TLS protocol doesn't guarantee that +either.) -**Warning!** Depending on network latency, the timing of messages might be -enough to launch some timing attacks. Block ciphers do not yet achieve full -protection against these. For details and workarounds see the [Block -Ciphers](#block-ciphers) section. +**Warning!** Block ciphers do not yet achieve full protection against attackers +who can measure the timing of packets with sufficient precision. For details +and workarounds see the [Block Ciphers](#block-ciphers) section. ### Local attacks @@ -70,14 +70,14 @@ details and workarounds see the [Block Ciphers](#block-ciphers) section. The attacker code running on the platform has access to some sensor capable of picking up information on the physical state of the hardware while Mbed TLS is -running. This can for example be any analogue to digital converter on the +running. This could for example be an analogue-to-digital converter on the platform that is located unfortunately enough to pick up the CPU noise. (See for example the [Leaky Noise paper](https://tches.iacr.org/index.php/TCHES/article/view/8297).) -Mbed TLS doesn't offer any security guarantees against local non-timing based +Mbed TLS doesn't make any security guarantees against local non-timing-based side channel attacks. If local non-timing attacks are present in a use case or -a user application's threat model, it needs to be mitigated by the platform. +a user application's threat model, they need to be mitigated by the platform. #### Local fault injection attacks @@ -85,23 +85,23 @@ Software running on the same hardware can affect the physical state of the device and introduce faults. (See for example the [Row Hammer paper](https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf).) -Mbed TLS doesn't offer any security guarantees against local fault injection +Mbed TLS doesn't make any security guarantees against local fault injection attacks. If local fault injection attacks are present in a use case or a user -application's threat model, it needs to be mitigated by the platform. +application's threat model, they need to be mitigated by the platform. ### Physical attacks The attacker has access to physical information about the hardware Mbed TLS is -running on and/or can alter the physical state of the hardware (eg. power +running on and/or can alter the physical state of the hardware (e.g. power analysis, radio emissions or fault injection). -Mbed TLS doesn't offer any security guarantees against physical attacks. If +Mbed TLS doesn't make any security guarantees against physical attacks. If physical attacks are present in a use case or a user application's threat -model, it needs to be mitigated by physical countermeasures. +model, they need to be mitigated by physical countermeasures. ### Caveats -#### Out of scope countermeasures +#### Out-of-scope countermeasures Mbed TLS has evolved organically and a well defined threat model hasn't always been present. Therefore, Mbed TLS might have countermeasures against attacks From 08094b831382066eb8111adbe5545ffb2a0a07f7 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Tue, 14 Mar 2023 14:49:34 +0000 Subject: [PATCH 11/15] Threat Model: clarify stance on timing attacks Signed-off-by: Janos Follath --- SECURITY.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index dcffa1d9be..97fe0e7475 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -48,15 +48,20 @@ files. #### Timing attacks -The attacker is able to observe the timing of instructions executed by Mbed -TLS.(See for example the [Flush+Reload -paper](https://eprint.iacr.org/2013/448.pdf).) +The attacker is able to observe the timing of instructions executed by Mbed TLS +by leveraging shared hardware that both Mbed TLS and the attacker have access +to. Typical attack vectors include cache timings, memory bus contention and +branch prediction. Mbed TLS provides limited protection against timing attacks. The cost of protecting against timing attacks widely varies depending on the granularity of the measurements and the noise present. Therefore the protection in Mbed TLS is limited. We are only aiming to provide protection against **publicly -documented** attacks. +documented attack techniques**. + +As attacks keep improving, so does Mbed TLS's protection. Mbed TLS is moving +towards a model of fully timing-invariant code, but has not reached this point +yet. **Remark:** Timing information can be observed over the network or through physical side channels as well. Remote and physical timing attacks are covered From e3d677c6aa2b246c16ae8b2bf824f61e110d9a26 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Tue, 14 Mar 2023 14:54:44 +0000 Subject: [PATCH 12/15] Threat Model: remove references Remove references to scientific papers as they are too specific and might be misleading. Signed-off-by: Janos Follath --- SECURITY.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 97fe0e7475..8d2337111c 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -76,9 +76,7 @@ details and workarounds see the [Block Ciphers](#block-ciphers) section. The attacker code running on the platform has access to some sensor capable of picking up information on the physical state of the hardware while Mbed TLS is running. This could for example be an analogue-to-digital converter on the -platform that is located unfortunately enough to pick up the CPU noise. (See -for example the [Leaky Noise -paper](https://tches.iacr.org/index.php/TCHES/article/view/8297).) +platform that is located unfortunately enough to pick up the CPU noise. Mbed TLS doesn't make any security guarantees against local non-timing-based side channel attacks. If local non-timing attacks are present in a use case or @@ -87,8 +85,7 @@ a user application's threat model, they need to be mitigated by the platform. #### Local fault injection attacks Software running on the same hardware can affect the physical state of the -device and introduce faults. (See for example the [Row Hammer -paper](https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf).) +device and introduce faults. Mbed TLS doesn't make any security guarantees against local fault injection attacks. If local fault injection attacks are present in a use case or a user From 6cd045905fa83de7e4c450774d260ba663094e97 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Tue, 14 Mar 2023 15:43:24 +0000 Subject: [PATCH 13/15] Threat Model: adjust modality Signed-off-by: Janos Follath --- SECURITY.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 8d2337111c..8d3678a5ee 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -25,9 +25,10 @@ We classify attacks based on the capabilities of the attacker. ### Remote attacks -The attacker can observe and modify data sent over the network. This includes -observing the content and timing of individual packets, as well as suppressing -or delaying legitimate messages, and injecting messages. +In this section, we consider an attacker who can observe and modify data sent +over the network. This includes observing the content and timing of individual +packets, as well as suppressing or delaying legitimate messages, and injecting +messages. Mbed TLS aims to fully protect against remote attacks and to enable the user application in providing full protection against remote attacks. Said @@ -42,9 +43,9 @@ and workarounds see the [Block Ciphers](#block-ciphers) section. ### Local attacks -The attacker can run software on the same machine. The attacker has -insufficient privileges to directly access Mbed TLS assets such as memory and -files. +In this section, we consider an attacker who can run software on the same +machine. The attacker has insufficient privileges to directly access Mbed TLS +assets such as memory and files. #### Timing attacks @@ -93,9 +94,10 @@ application's threat model, they need to be mitigated by the platform. ### Physical attacks -The attacker has access to physical information about the hardware Mbed TLS is -running on and/or can alter the physical state of the hardware (e.g. power -analysis, radio emissions or fault injection). +In this section, we consider an attacker who can attacker has access to +physical information about the hardware Mbed TLS is running on and/or can alter +the physical state of the hardware (e.g. power analysis, radio emissions or +fault injection). Mbed TLS doesn't make any security guarantees against physical attacks. If physical attacks are present in a use case or a user application's threat From 35f5ef01f21da18111ce9e59a7e194e1bf55b149 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Wed, 15 Mar 2023 15:43:08 +0000 Subject: [PATCH 14/15] Threat Model: adjust to 2.28 MBEDTLS_AESCE_C is not available in 2.28., remove it from workarounds. Signed-off-by: Janos Follath --- SECURITY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index 8d3678a5ee..e25601bcd5 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -129,7 +129,7 @@ even a remote. The attacks can result in key recovery. - Turn on hardware acceleration for AES. This is supported only on selected architectures and currently only available for AES. See configuration options - `MBEDTLS_AESCE_C`, `MBEDTLS_AESNI_C` and `MBEDTLS_PADLOCK_C` for details. + `MBEDTLS_AESNI_C` and `MBEDTLS_PADLOCK_C` for details. - Add a secure alternative implementation (typically hardware acceleration) for the vulnerable cipher. See the [Alternative Implementations Guide](docs/architecture/alternative-implementations.md) for more information. From 83050519a7bf27078f3421bf1e6abc6d8e2c7376 Mon Sep 17 00:00:00 2001 From: Janos Follath Date: Thu, 16 Mar 2023 15:00:03 +0000 Subject: [PATCH 15/15] Threat Model: fix copy paste Signed-off-by: Janos Follath --- SECURITY.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index e25601bcd5..732335b233 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -94,10 +94,9 @@ application's threat model, they need to be mitigated by the platform. ### Physical attacks -In this section, we consider an attacker who can attacker has access to -physical information about the hardware Mbed TLS is running on and/or can alter -the physical state of the hardware (e.g. power analysis, radio emissions or -fault injection). +In this section, we consider an attacker who has access to physical information +about the hardware Mbed TLS is running on and/or can alter the physical state +of the hardware (e.g. power analysis, radio emissions or fault injection). Mbed TLS doesn't make any security guarantees against physical attacks. If physical attacks are present in a use case or a user application's threat