Any timing variance dependant on the output of this function enables a
Bleichenbacher attack. It is extremely difficult to use safely.
In the Marvin attack paper
(https://people.redhat.com/~hkario/marvin/marvin-attack-paper.pdf) the
author suggests that implementations of PKCS 1.5 decryption that don't
include a countermeasure should be considered inherently dangerous.
They suggest that all libraries implement the same countermeasure, as
implementing different countermeasures across libraries enables the
Bleichenbacher attack as well.
This is extremely fragile and therefore we don't implement it. The use
of PKCS 1.5 in Mbed TLS implements the countermeasures recommended in
the TLS standard (7.4.7.1 of RFC 5246) and is not vulnerable.
Add a warning to PKCS 1.5 decryption to warn users about this.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Automatic testing of our testing is not essential, as our testing
framework may be manually tested. Having automated tests to test our
tests may be left to future work.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Describe the approach of platform-specific code and draw a comparison
with the constant-time module.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
These cover the fact that we need to test our test framework to make
sure it really detects incorrect accesses.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
* Rename config options to have MBEDTLS_TEST_ prefix
* Clarify that these config options should not exist in mbedtls_config.h
Signed-off-by: David Horstmann <david.horstmann@arm.com>
This is already covered in the design exploration and since the other
approach was chose, we do not need to discuss it in the detailed design
section.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
New tests are needed (rather than existing ones) because the complexity
of setting up careful-access tests would make it difficult to build atop
existing tests.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
This consists in outlining the prototyping and evaluation of different
possible testing approaches.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Add lengths to structs in the convenience functions to allocate and copy
input and output buffers. It seems better to ensure we always store a
buffer with its length.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
And clarify our potential use of it as a starting point for writing
memory poisoning tests from scratch.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
In light of choosing Valgrind/ASan over mprotect()-based poisoning,
update the detailed design of copy validation.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Main changes:
* New tests are easier to write than first stated
* Use of existing tests is ledd beneficial
* But using existing tests is a benefit if it can be done transparently
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Consider MSan, ASan and Valgrind as options for implementing memory
poisoning tests. Come to the altered conclusion that Valgrind is the
best option.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
* Remove references to the platform - this is unlikely to affect whether
copies are optimized.
* Note that the evaluation should test extreme optimisation settings.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
