Imagine Being on Trial. With Exonerating Evidence Trapped on Your Phone.
> Public defenders lack access to gadgets and software that could keep their clients out of jail.
> This tech gap has two basic forms. First, law enforcement agencies can use warrants and court orders to compel companies to turn over emails, photos and other communications, but defense lawyers have no such power. And second, the government has access to forensic technology that makes digital investigations easier. Over the last two decades, the machines and software designed to extract data from computers and smartphones were primarily made for and sold to law enforcement.
> To successfully defend its clients, the Legal Aid Society, New York City’s largest public defender office, realized in 2013 that it needed to buy the same tools the police had: forensic devices and software from companies including Cellebrite, Magnet Forensics and Guidance Software. Not only does the expensive technology unearth digital evidence that is otherwise hard or impossible to find, it captures it in a format that can hold up in court, as opposed to evidence that could have been tampered with or forged.
TPM—Fail TPM meets Timing and Lattice Attacks
> We discovered timing leakage on Intel firmware-based TPM (fTPM) as well as in STMicroelectronics’ TPM chip. Both exhibit secret-dependent execution times during cryptographic signature generation. While the key should remain safely inside the TPM hardware, we show how this information allows an attacker to recover 256-bit private keys from digital signature schemes based on elliptic curves.
> This research shows that even rigorous testing as required by Common Criteria certification is not flawless and may miss attacks that have explicitly been checked for. The STMicroelectronics TPM chip is Common Criteria certified at EAL4+ for the TPM protection profiles and FIPS 140-2 certified at level 2, while the Intel TPM is certified according to FIPS 140-2. However, the certification has failed to protect the product against an attack that is considered by the protection profile.
> Rolling forward 15 years, isogeny-based cryptography is another area with many technical subtleties, but is moving into the mainstream of cryptography. Once again, not everything that can be done with discrete logarithms can necessarily be done with isogenies. It is therefore not surprising to find papers that have issues with their security.
> It is probably time for an Isogenies for Cryptographers paper, but I don’t have time to write it. Instead, in this blog post I will mention several recent examples of incorrect papers. My hope is that these examples are instructional and will help prevent future mistakes. My intention is not to bring shame upon the authors.
Real-world measurements of structured-lattices and supersingular isogenies in TLS
> This is the third in a series of posts about running experiments on post-quantum confidentiality in TLS. The first detailed experiments that measured the estimated network overhead of three families of post-quantum key exchanges. The second detailed the choices behind a specific structured-lattice scheme. This one gives details of a full, end-to-end measurement of that scheme and a supersingular isogeny scheme, SIKE/p434. This was done in collaboration with Cloudflare, who integrated Microsoft’s SIKE code into BoringSSL for the tests, and ran the server-side of the experiment.
> Because optimised assembly implementations are labour-intensive to write, they were only available/written for AArch64 and x86-64. Because SIKE is computationally expensive, it wasn’t feasible to enable it without an assembly implementation, thus only AArch64 and x86-64 clients were included in the experiment and ARMv7 and x86 clients did not contribute to the results even if they were assigned to one of the experiment groups.
How Google Changed the Secretive Market for the Most Dangerous Hacks in the World
> For five years, Google has funded Project Zero, a team of hackers with the sole mission of finding bugs in whatever software they wanted to research, be it Google’s or somebody else’s. Are they making the internet safer?
A fair bit of fluff, but one solid point.
> For one, Project Zero has normalized something that years ago was more controversial: a strict 90-day deadline for companies that receive its bug reports to patch the vulnerabilities. If they don’t patch in that time frame, Google drops the bugs itself. Microsoft, in particular, was not a fan of this policy at the beginning. Today, most companies that interact with Project Zero respect that 90-day deadline as an industry standard, a tidal change in the always controversial debate on the so-called “responsible disclosure”—the idea that security researchers who find vulnerabilities should first disclose them to the affected company, so that it can fix them before the bugs are exploited by hackers. According to its own tally, around 95 percent of bugs reported by Project Zero get patched within that deadline.
Looking back at the Snowden revelations
> It’s no coincidence that this is a cryptography blog, which means that I’m not concerned with the same things as the general public. That is, I’m not terribly interested in debating the value of whistleblower laws (for some of that, see this excellent Twitter thread by Jake Williams). Instead, when it comes to Snowden’s leaks, I think the question we should be asking ourselves is very different. Namely:
> What did the Snowden leaks tell us about modern surveillance capabilities? And what did we learn about our ability to defend against them?
Chromebook U2F ECDSA vulnerability
> We discovered a vulnerability in the H1 security chip firmware concerning ECDSA signature generation. The firmware code used incompatible transfer instructions when passing a critical secret value to the cryptographic hardware block, resulting in generating secret values of a specific structure and having a significant loss of entropy in the secret value (64 bits instead of 256 bits). We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the the underlying ECC private key to be obtained. Thus, attackers that have a single pair of signature and signed data can effectively compute the private key, breaking any functionality or protocols that use the key pair in question.
Experimental feature, with an annoying fix. If it had been for real, quite messy.
> We present an attack on the encryption key negotiation protocol of Bluetooth BR/EDR. The attack allows a third party, without knowledge of any secret material (such as link and encryption keys), to make two (or more) victims agree on an encryption key with only 1 byte (8 bits) of entropy. Such low entropy enables the attacker to easily brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages (in real-time). The attack is stealthy because the encryption key negotiation is transparent to the Bluetooth users. The attack is standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. As a result, the attacker completely breaks Bluetooth BR/EDR security without being detected. We call our attack Key Negotiation Of Bluetooth (KNOB) attack.
The scramble to secure America’s voting machines
> Paperless voting devices are a gaping weakness in the patchwork U.S. election system, security experts say. But among these 14 states and their counties, efforts to replace these machines are slow and uneven, a POLITICO survey reveals.
Very annoying scroll interaction at the top, but eventually some content appears.
Four reasons why cryptography is so hard to get right and four solutions
> Before proceeding, I want to stress that everything I refer to here relates to mistakes made when using (good) cryptographic libraries. The challenge of implementing the low-level cryptographic primitives themselves (like AES, RSA, ECC and so on) is a very different one, requiring high cryptographic engineering experience and knowledge. As such, this should be avoided whenever possible. In contrast, many software engineers need to just use cryptography in their work, and this cannot be avoided. Unfortunately, even this turns out to be far more problematic than expected.
This rings very true. The recommended solution, use a better library instead of lower level pieces, is also good, but should probably give some names. libsodium for example.
Jackson CVE-2019-12384: anatomy of a vulnerability class
> During one of our engagements, we analyzed an application which used the Jackson library for deserializing JSONs. In that context, we have identified a deserialization vulnerability where we could control the class to be deserialized. In this article, we want to show how an attacker may leverage this deserialization vulnerability to trigger attacks such as Server-Side Request Forgery (SSRF) and remote code execution.
Investigating sources of PII used in Facebook’s targeted advertising
> We develop a novel technique that uses Facebook’s advertiser interface to check whether a given piece of PII can be used to target some Facebook user, and use this technique to study how Facebook’s advertising service obtains users’ PII. We investigate a range of potential sources of PII, finding that phone numbers and email addresses added as profile attributes, those provided for security purposes such as two-factor authentication, those provided to the Facebook Messenger app for the purpose of messaging, and those included in friends’ uploaded contact databases are all used by Facebook to allow advertisers to target users. These findings hold despite all the relevant privacy controls on our test accounts being set to their most private settings.
Natural Adversarial Examples
> We introduce natural adversarial examples -- real-world, unmodified, and naturally occurring examples that cause classifier accuracy to significantly degrade. We curate 7,500 natural adversarial examples and release them in an ImageNet classifier test set that we call ImageNet-A. This dataset serves as a new way to measure classifier robustness. Like l_p adversarial examples, ImageNet-A examples successfully transfer to unseen or black-box classifiers. For example, on ImageNet-A a DenseNet-121 obtains around 2% accuracy, an accuracy drop of approximately 90%. Recovering this accuracy is not simple because ImageNet-A examples exploit deep flaws in current classifiers including their over-reliance on color, texture, and background cues. We observe that popular training techniques for improving robustness have little effect, but we show that some architectural changes can enhance robustness to natural adversarial examples. Future research is required to enable robust generalization to this hard ImageNet test set.
How Ledger Hacked an HSM
> At the moment very few details are available in English about how this attack by researchers from Ledger was carried out, but fortunately for Francophones, this work was presented in detail earlier this week at the annual French security conference SSTIC. French speakers can watch the video or read the paper in the proceedings.
> For the not-so-Francophone, the bilingual team at Cryptosense have translated a brief summary of what the Ledger researchers Gabriel Campana and Jean-Baptiste Bédrune did. There were plenty of technical challenges to solve along the way, in what was clearly a thorough and professional piece of vulnerability research:
How does Apple (privately) find your offline devices?
> A big caveat: much of this could be totally wrong. I’ll update it relentlessly when Apple tells us more.
> Since this is a security system, the first question you should ask is: who’s the bad guy? The answer in this setting is unfortunate: everyone is potentially a bad guy. That’s what makes this problem so exciting.
RowHammer: A Retrospective
> In this article, we comprehensively survey the scientific literature on RowHammer-based attacks as well as mitigation techniques to prevent RowHammer. We also discuss what other related vulnerabilities may be lurking in DRAM and other types of memories, e.g., NAND flash memory or Phase Change Memory, that can potentially threaten the foundations of secure systems, as the memory technologies scale to higher densities. We conclude by describing and advocating a principled approach to memory reliability and security research that can enable us to better anticipate and prevent such vulnerabilities.
Analysis of CVE-2019-0708 (BlueKeep)
> As always, I started with a BinDiff of the binaries modified by the patch (in this case there is only one: TermDD.sys). Below we can see the results.
0day "In the Wild"
> Project Zero’s team mission is to “make zero-day hard”, i.e. to make it more costly to discover and exploit security vulnerabilities. We primarily achieve this by performing our own security research, but at times we also study external instances of zero-day exploits that were discovered “in the wild”. These cases provide an interesting glimpse into real-world attacker behavior and capabilities, in a way that nicely augments the insights we gain from our own research.
> Today, we’re sharing our tracking spreadsheet for publicly known cases of detected zero-day exploits, in the hope that this can be a useful community resource:
Reverse-engineering Broadcom wireless chipsets
> In this blogpost I provided an account of various activities during my 6 months as an intern at Quarkslab, my project involved understanding the Linux kernel drivers, analyzing Broadcom firmware, reproducing publicly known vulnerabilities, working on an emulator to run portions of firmware, fuzzing and finding 5 vulnerabilities (CVE-2019-8564, CVE-2019-9500, CVE-2019-9501, CVE-2019-9502, CVE-2019-9503). Two of those vulnerabilities are present both in the Linux kernel and firmware of affected Broadcom chips. The most common exploitation scenario leads to a remote denial of service. Although it is technically challenging to achieve, exploitation for remote code execution should not be discarded as the worst case scenario.
Don’t miss the disclosure timeline at the end.