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).
- 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.
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!
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.
Once more, protect code within the secure enclave. Defense in depth is critical.