I attended the briefings at Black Hat 2019. All the presentations I attended were engaging. Nevertheless, here is the feedback on my preferred
ones. The link gives access to the
corresponding slid decks.
One
of the mitigations to Bleichenbacher’s attack is that the exponent d should be
large. Unfortunately, in some standards d is still small, typically 3. But even with larger exponents, forgery is possible
due to vulnerable software.
Forgery
uses the fact that many verifiers do not check garbage, parameter lengths, and
padding.
He
provides a list of vulnerable libraries (that are now fixed).
Lessons:
- Check everything.
No corner cutting.
- Parsing in security
should be bulletproof. The complexity of
the structures and syntax may become an issue.
Complexity is the enemy of security.
Jean
Philippe is a Kudelski Security expert.
He
provides a view of most deployed mistakes.
Most are well known. A few ones
that I liked:
- Weak key derivation
from a password. Use a real derivation function.
- Avoid using panic
if the error is not unrecoverable, else it may become a potential DoS.
- No way to erase
securely sensitive memory with garbage collection (for Instance, go)
His
preferred language for crypto is Rust.
The
slide deck is an excellent refresher of what not to do. Practitioners should have a look.
Breaking
Encrypted Databases: Generic Attacks on Range Queries (Marie-Sarah Lacharite)
She
presented how to use access pattern leakage and volume attack leakage to guess
the content of the database even if encrypted.
Independently
of the provided attacks, the researcher reminded that if using a common
encryption key (and same IV) with server-side encryption, it is still possible
to perform a range query because the same cleartext generates the same
ciphertext. This may be a PII
issue.
There
are some partial solutions to this problem:
- Order preserving
encryption solves the issue
- Order revealing
encryption is even better
Pattern
leakages measure the number of returned records per request. She used PQ trees
to rebuild the order of the observed answer of access pattern. For N values in
the database, N log N queries were needed.
Volume
leakage is easier because the attacker may just monitor the communication. For
N values in the database, N2 log N of observed queries are needed.
Some
possible mitigations:
- Restricting query
types
- Dummy records
- Dummy values
The two last
solutions may introduce some accuracy issues if not filtered out.
The studied the actual security of Hardware Security Modules
(HSM). HSMs are rarely studied because
they are expensive and if attacked they will erase secret.
They used the PKCS11 API.
The targeted HSM used an old version of LINUX (10-year-old). Furthermore,
every process runs as root, and there was NO secure boot. Attackers used fuzzing to find 14
vulnerabilities. Exploiting a few of
them, they could get access to the private root key!
Lesson:
Hardware Tamper Resistance and controlled API are not enough. The software should assume that the enclave
has been breached and be protected correspondingly.
Samsung’s Trustzone works only on Samsung chip Exonis and not Qualcomm’s
Snapdragon
The secure OS is Kinibi by Trustonics.
Once more, adversaries used a fuzzier (AFL-based)
Currently, the trustlet has no ASLR and PIE (Position Independent
Executable). They used buffer overflow on the trustlet and a trusted vulnerable
driver to go inside the Trustzone. From there,
they attacked mmap for accessing Kinibi.
They were able to read and write memory arbitrarily. For instance,
they accessed the master key both from EL3 and from EL1. With the master key, the attacker has access
to all the secrets in the Trustzone.
Lesson:
Once more, protect code within the secure enclave. Defense in depth is critical.