Attacking Titan M with Only One Byte
blog.quarkslab.com
blog.quarkslab.com
After something went wrong, a bunch of things went right very quickly. Nice to have good news on a Monday morning.
> … the vulnerable firmware was introduced by Google's Pixel security update of May 2022.
However, further down, in the timeline section, the doc indicates that the issue was reported before May 2022, all the way back in March 2022:
> 2022-03-02: Vulnerability reported. Opened issue 222318108 in Google's Issue Tracker, providing a technical description of the bug and a Proof of Concept (PoC) exploit…
> One of the most interesting consequences of this attack is the ability to retrieve any StrongBox protected key, defeating the highest level of protection of the Android Keystore. Similarly to what happens in TrustZone, these keys can only be used inside Titan M, while they are stored in an encrypted key blob on the device.
I thought the whole point of making a hardware security chip (rather than using a general purpose microcontroller, possibly with crypto acceleration hardware) is that the private keys would be protected by the hardware design. So you could use the private key to e.g. create a digital signature but its impossible to read out the private key itself, outside of potential side-channels.
I was surprised to see that the reward was set at 10k initially. Granted, it was bumped to 75k later, but even that seems on the low side considering the degree of compromise that occurred here.
I may have given up too early during my (fairly brief) research on CVE-2019-9465. I let the lack of firmware source code availability stop me at the time, but in hindsight the presence of "0dd0adde0dd0adde" in the ciphertext likely indicated a crash in Titan M as well. Perhaps there would have been a similarly interesting path to exploitation there.
I wonder why companies still leave the UART pins accessible. Fine they're on the chip, but just remove the trace and slow down attack evolution is worth the cost of a board revision surely...
So long as it doesn't weaken the actual security model, companies should make their products as easy to analyze as possible imo.
Visible and labeled UART pins tell me that you've (hopefully) thought through the consequences of me having access to them. Hidden UART tells me that most likely nobody ever gave that half a thought.
Removing the trace means an extra step which is the whole point. Ffs
No single solution/step is 100% secure, if you think that, throw your devices away now because they're probably already compromised.
Stop with the ego pedaling security stuff and live/work in the real world where small changes have real positive impacts.
It's the same with DRM. It doesn't have to be uncrackable, as long as it keeps the sales for the first x-months it's worked. (Not that I think DRM is acceptable but that's another discussion).
Please stop arguing against a step which could have been taken as part of a valid security model...
I'm not saying this would have magically fixed the chip firmware. I'm not saying this would have magically stopped anyone ever getting into the device. I'm not saying this would stop Google accidentally shipping an unprovisioned unit.
I am saying a small move that strengthens the whole unit should be strongly considered. I'm sorry that backtracking from such a flippant response is so difficult for you.
Frankly it's a custom chip design, they could burn an efuse to cripple UART in production consumer units, that has the same effect for 99.99% of chips that would sell.
I thought I read the whole thing. Did I miss that explanation?
Languages like that aren't going to be suitable for writing a whole web browser or a desktop operating system, but they might well be enough for the Titan chip. This is the sort of work where the compilation is tricky (definitely wouldn't fit on a small ARM core) but the machine code it spits out is much the same except safe.
Even still though, the award Google initially gave was only $10k USD(!). They finally bumped it to $75k USD after complaint and review, but Google's bug bounty program claims up to $1 Million USD.
If fully compromising Google's own security chip to dump all private keys isn't worth the full $1 Million bounty, I honestly don't know what is.
Really, what would, in the mind of those on the internal committee, constitute justification for the $1 Million bounty?
If thr right people don't buy these zero-days, yhe wrong people will.
Somebody sets up a bounty program and defines a framework for deciding how much to pay out. Security is complicated as hell and you cannot possibly devise a framework that accounts for all possible things so this framework is necessarily brittle. For example, you might reasonably decide that the highest payouts require very minimal attacker capabilities (fully remote unauthenticated attacks being the top payouts). This makes sense since those are the easiest attacks to mount.
So now a bounty comes in. It goes to a triage person or, at best, a small group. They refer to the framework. Your bug doesn't really match any of the categories but it kind of looks like this thing over here so it gets bucketed as such. Maybe there is some discussion. Ultimately, the rules say "max payout requires unauthenticated remote attacks" so the payout ends up lower, even if the attack is exciting. Maybe somebody managing the system takes a note to update the framework and policy moving forward. The community then rages about how this bug is actually a big deal and deserves a lot of reward.
In my experience, the people managing these programs get rewarded based on the amount they pay out going up, not down. But you need a payment framework otherwise each bug is paid out on somebody's whim (and trust me, the security researchers will complain to high heaven if they perceive inconsistency in bounty sizes). So you end up with novel bug structures that aren't handled well by the framework and get treated weirdly.
One would imagine that this would have been escalated to some pretty senior security folks at Google before the payout was decided. That would mean that there would be some amount of discretion on Google's end as to the payout, since there would (presumably) be someone senior enough to look at this closely and authorize a higher amount even if there was some rubric that might seem to award a lower amount. Obviously this is ultimately what happened, as they eventually did increase the payout. It's a little strange to me though that this wasn't done sooner.
Bug bounties are routine. "How much do you want to pay out" is way down the list of things that leadership is focused on for these things. "How do we mitigate this" and "how does the researcher get paid" are often questions owned by different people and teams. Directors aren't swooping in to make payout decisions.
This sounds close enough to me, but perhaps there's some subtle nuance between device keys and other keys in the chip.
Thats what im wondering too. particularly this line from mitigations section from the report
>> However, we do want to point out an interesting feature that would have made the StrongBox key blob leak impossible. Indeed, an application can create a key that is authentication-bound, specifying setUserAuthenticationRequired(true) when building it with KeyGenParameterSpec. This way, users need to authenticate before using the key and the key blob is encrypted a second time using a special key derived from the user password that we do not have.
so unless your phone doesnt have a password i dont see how they can retrieve device keys
Probably something that doesn't require physical access to a key for longer time to extract the keys?
--First, Middle, Last Name
--Phone number, email address, social contacts
--Mother's Maiden Name
--First concert you attended
--Name of the street you grew up on
--Name of your best friend
--Name of your first pet
--Make/Model of your first carThese things should probably be more transparent, but I would assume the $1M level would be for exploits that could be deployed on a fresh-from-the-box device with no rooting/mods.
> Google says that if researchers manage to find "a full chain remote code execution exploit with persistence" that also compromises data protected by Titan M, they are willing to pay up to $1 million to the bug hunter who finds it.
So a compromise that doesn't require physical access or root, presumably.
Cue also the inevitable discussion that bug bounties are too low.
Then fixed it in two and a half years, and wrote an article on how complicated bug they just found and how proud and secure they are with their pentesters.
Funny thing. I had to discover this way myself when I lost my phone with Authenticator App. I took my mail client password and discovered that with some header magic I was able to hijack my own account. I couldn't believed it. So I created another account, protected with 2FA and did same thing. Got gaslighted by Google bug bounty team and decided it's not worth it.
> "We are introducing a top prize of $1 million for a full chain remote code execution exploit with persistence which compromises the Titan M secure element on Pixel devices. Additionally, we will be launching a specific program offering a 50% bonus for exploits found on specific developer preview versions of Android, meaning our top prize is now $1.5 million," Jessica Lin of the Android security team said.
> The Titan M bounty applies to the Google phones that have the chip, which include the Pixel 3 and 3 XL, 3a and 3a XL, and 4.
[1] https://duo.com/decipher/hack-the-titan-m-get-usd1-million
> Then, we need a way to access the key blobs on the Android file system, which can be done again by being root, or with some exploit to bypass File Based Encryption or the uid access control.
edit: Thanks for the clarifications. That helps. I'm asking for 2 reasons:
1. Discussing "nukes" openly where I come from would raise some eyebrows.
2. I see acronyms used on HN frequently - sometimes ambiguously even considering the context.The German V2 rocket from World War II has a maximum range of about 320km. So you literally can't fire one from say Berlin to London. They were actually launched from coastal sites in the Netherlands and other occupied countries, and as the Allies took territory after Overlord, the targets changed to cities nearer Germany because the launchers were pulled back.
Don't lose sight of the fact that the purpose of this and other TPM-like devices is to hide secrets from its owner.
It makes sense to use exactly the same technology even if you are "the owner" unless you are somehow only ever running software you wrote on data you obtained, and maybe not even then if other people are able to influence that data.
Most of use a lot of software we didn't write, to process data we got from some third party who may or may not have our best interests in mind.
The whole security landscape seems to have many catch-22's
That's a complete misunderstanding of a TPM's security model. A TPM guards against key theft in a compromised environment by securely storing artifacts and authenticating the platform. The user doesn't enter this threat picture. It is the platform that gets authenticated, not the user.