Threat Model: Miscellaneous clarifications
Signed-off-by: Janos Follath <janos.follath@arm.com>
diff --git a/SECURITY.md b/SECURITY.md
index 50c8ffd..4ed9d38 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -24,8 +24,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.
+ 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 @@
### 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 @@
#### 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.