Samsung Shattered Encryption On 100 Million Phones (threatpost.com) 20
Samsung shipped an estimated 100 million smartphones with botched encryption, including models ranging from the 2017 Galaxy S8 on up to last year's Galaxy S21. Threatpost reports: Researchers at Tel Aviv University found what they called "severe" cryptographic design flaws that could have let attackers siphon the devices' hardware-based cryptographic keys: keys that unlock the treasure trove of security-critical data that's found in smartphones. What's more, cyber attackers could even exploit Samsung's cryptographic missteps -- since addressed in multiple CVEs -- to downgrade a device's security protocols. That would set up a phone to be vulnerable to future attacks: a practice known as IV (initialization vector) reuse attacks. IV reuse attacks screw with the encryption randomization that ensures that even if multiple messages with identical plaintext are encrypted, the generated corresponding ciphertexts will each be distinct.
The design flaws primarily affect devices that use ARM's TrustZone technology: the hardware support provided by ARM-based Android smartphones (which are the majority) for a Trusted Execution Environment (TEE) to implement security-sensitive functions. TrustZone splits a phone into two portions, known as the Normal world (for running regular tasks, such as the Android OS) and the Secure world, which handles the security subsystem and where all sensitive resources reside. The Secure world is only accessible to trusted applications used for security-sensitive functions, including encryption.
Matthew Green, associate professor of computer science at the Johns Hopkins Information Security Institute, explained on Twitter that Samsung incorporated "serious flaws" in the way its phones encrypt key material in TrustZone, calling it "embarrassingly bad." "They used a single key and allowed IV re-use," Green said. "So they could have derived a different key-wrapping key for each key they protect," he continued. "But instead Samsung basically doesn't. Then they allow the app-layer code to pick encryption IVs." The design decision allows for "trivial decryption," he said.
Samsung responded to the academics' disclosure by issuing a patch for affected devices that addressed CVE-2021-25444: an IV reuse vulnerability in the Keymaster Trusted Application (TA) that runs in the TrustZone. Keymaster TA carries out cryptographic operations in the Secure world via hardware, including a cryptographic engine. The Keymaster TA uses blobs, which are keys "wrapped" (encrypted) via AES-GCM. The vulnerability allowed for decryption of custom key blobs. Then, in July 2021, the researchers revealed a downgrade attack -- one that lets attacker trigger IV reuse vulnerability with privileged process. Samsung issued another patch -- to address CVE-2021-25490 -- that remoged the legacy blob implementation from devices including Samsung's Galaxy S10, S20 and S21 phones.
The design flaws primarily affect devices that use ARM's TrustZone technology: the hardware support provided by ARM-based Android smartphones (which are the majority) for a Trusted Execution Environment (TEE) to implement security-sensitive functions. TrustZone splits a phone into two portions, known as the Normal world (for running regular tasks, such as the Android OS) and the Secure world, which handles the security subsystem and where all sensitive resources reside. The Secure world is only accessible to trusted applications used for security-sensitive functions, including encryption.
Matthew Green, associate professor of computer science at the Johns Hopkins Information Security Institute, explained on Twitter that Samsung incorporated "serious flaws" in the way its phones encrypt key material in TrustZone, calling it "embarrassingly bad." "They used a single key and allowed IV re-use," Green said. "So they could have derived a different key-wrapping key for each key they protect," he continued. "But instead Samsung basically doesn't. Then they allow the app-layer code to pick encryption IVs." The design decision allows for "trivial decryption," he said.
Samsung responded to the academics' disclosure by issuing a patch for affected devices that addressed CVE-2021-25444: an IV reuse vulnerability in the Keymaster Trusted Application (TA) that runs in the TrustZone. Keymaster TA carries out cryptographic operations in the Secure world via hardware, including a cryptographic engine. The Keymaster TA uses blobs, which are keys "wrapped" (encrypted) via AES-GCM. The vulnerability allowed for decryption of custom key blobs. Then, in July 2021, the researchers revealed a downgrade attack -- one that lets attacker trigger IV reuse vulnerability with privileged process. Samsung issued another patch -- to address CVE-2021-25490 -- that remoged the legacy blob implementation from devices including Samsung's Galaxy S10, S20 and S21 phones.
No, it's a Samsung feature (Score:2)
Re:No, it's a Samsung feature (Score:5, Informative)
It wasn't a flaw, Samsung left it there on purpose. How else can they force a round of hardware upgrades when restricting Android OS upgrades wasn't working as well as it used to /s
This flaw wouldn't be useful for that. It can be fixed via over-the-air update, and the normal Android Keystore key blob upgrade process will cause all of the key blobs to be replaced with properly-encrypted ones. In fact, Samsung did that months ago, after being notified by the researchers.
Obviously, if an attacker knew about this before the fix was pushed, and found a way to compromise your phone (the attack requires breaking through the layers of internal firewalling in Android to get access to the TrustZone APIs needed to exploit this), and already decrypted and extracted your keys, you're hosed. Though, actually, if an attacker found a way to compromise your phone that deeply you're probably hosed even without this bug, since although the attacker wouldn't have had access to the key material, they would have had the ability to tell Keymaster to use the keys in whatever ways was allowed by the key configurations. Plus the attacker would have access to all of the data on your phone (roughly, there are some caveats and limitations here, but they're beyond the scope of this post).
(Context: I'm the Tech Lead for the Android hardware-backed security team. I designed Keymaster, specified the requirements and wrote the reference implementation and the tests, at least initially, though many others have contributed. Sadly, I never envisioned that some implementer of the Keymaster interface would allow the non-secure world to specify the blob encryption nonces, or I would have written a test for that. One of the engineers on my team is closing that barn door now. My reference implementation does it correctly, of course, as do the half dozen other implementations out there.)
Re: (Score:3)
Sadly, I never envisioned that some implementer of the Keymaster interface would allow the non-secure world to specify the blob encryption nonces, or I would have written a test for that.
Really? I mean nothing surprises me anymore. I've lost track of how many bits of code I've seen over the years that were written just for a quick test and then were forgotten about or never replaced because "it works".
It isn't the perfect that is the enemy of the good that I worry about, it is the "good enough".
Re: (Score:2)
Re: (Score:2)
It can be corrected - or is that word 'Might'. Might other defects be found, when the same dummy coder botched other brands. My telco is NOT rolling out patches for obsolete phone models. After Heartbleed, professionals should have been all over this. Now only if there is a warning added, when some joker tries the same trick again.
Obaolete models? The earliest affected model was from 2017, FFS!
That would be the equivalent of Apple not updating an iPhone X. Instead, Apple just issued a Security Update in September, 2021 that patches iOS 12, covering models clear back to lhe iPhone 5s:
https://support.apple.com/en-u... [apple.com]
Samsung sucks eggs.
Re: (Score:2)
Re: (Score:3)
It can be corrected - or is that word 'Might'. Might other defects be found, when the same dummy coder botched other brands.
The relevant code is only used on Exynos.
Re: (Score:2)
Let me guess, unsafe-at-any-speed GCM? As soon as I saw the summary I thought "I bet it's GCM".
And it was...
Re: (Score:3)
Let me guess, unsafe-at-any-speed GCM? As soon as I saw the summary I thought "I bet it's GCM".
GCM isn't great, but it's not that bad. I think it's unfortunate that GCM has become the world's default AEAD mode, but it's really not that hard to use correctly, as evidenced by the fact that it's by far the most widely-used AEAD mode and we don't see many problems of this sort, relative to the vast amount of usage. You just need to make sure either key or nonce is random per usage, and that your CPRNG is good and properly seeded (which you almost certainly need to do in any case). Obviously SIV is bette
I took a basic Crypto course... (Score:3)
...when Udacity was getting started. Dave Evans (UVA) taught it.
He made is all promise never to implement our own crypto systems.
This. Is. Why.
Re: (Score:3)
Re: I took a basic Crypto course... (Score:2)
Even with rock-solid crypto primatives, cryptography is hard. Hard like "Peace in the Middle East" hard.
Sure, IV trouble is a crypto 101 problem for those who've studied, but a brand new challenge, and probably a bit opaque to developers who've never thought about it before. A simple checklist item if you don't understand the significance, and what has to happen. 'One more thing to do to make my code work. OK, it lets it compile now'
Dear editors (Score:3)
When I "shatter" something it implies I came in and broke violently something which was at one point in a better condition. As these devices shipped broken Samsung didn't "shatter" anything.
Please leave clickbait headline bullshit to the Daily Express, they are far better at it than you.
Re: (Score:2)
When I "shatter" something it implies I came in and broke violently something which was at one point in a better condition. As these devices shipped broken Samsung didn't "shatter" anything.
Please leave clickbait headline bullshit to the Daily Express, they are far better at it than you.
Howabout the fact that Samsung Shattered their Users' Expectations that their communications were actually Secure?
That is using "Shatter" in a relevant sentence.
Re: (Score:2)
You're making a lot of assumptions about user's expectations ;-)
Re: (Score:2)
You're making a lot of assumptions about user's expectations ;-)
No more than you ;-)
Par for the course for Samsung (Score:2)
Sooooo, WEP "security"? (Score:2)
"They used a single key and allowed IV re-use," Green said. "So they could have derived a different key-wrapping key for each key they protect," he continued. "But instead Samsung basically doesn't. Then they allow the app-layer code to pick encryption IVs." The design decision allows for "trivial decryption," he said
This sounds a lot like what made the old Wired Equivalent Privacy garbage protection
Re: (Score:3)
Then they allow the app-layer code to pick encryption IVs
Not app layer code, highly-privileged system code.
However, given that that threat model for Keymaster assumes that none of the system is trustworthy, not even the Linux kernel, this was still the wrong choice (note that the Android system is actually quite secure, but the way you do defense in depth is to start by assuming the attacker controls all of the previous layers). The right way to do it is to have the secure world app randomly generate the nonces. This means it's crucial to have a good random n