PIN is not as secure as you think

DeletedUser43

The Google Pixels claim to fame is its TPM chip called Titan M, which - besides a couple of iPhones - is considered the only one which can reliably throttle brute force attempts, allowing users to securely use relatively easy PINs. For some time now I've been wondering how is this possible, and I'm here to call bull****.

This topic has been driving me crazy for some time, so I'm writing this in an overconfident manner not because I found the exact answer, but because I hope to provoke someone to proof me wrong.

Titan-M does absolutely anything special about throttling. Because Titan-M has exact throttling progression defined with exact seconds, then to do this it needs to count passage of time, and to do that it needs power. If Titan-M doesn't have its own battery (which should be able to run for 10+ years) and clock, then it's relying on external signal to count the time. So all you need to do, is to move it over to a special board and speed up time after every failed PIN attempt. It might be even as simple as changing the time value on the board, if Titan-M doesn't count it by itself using signal frequency.

TLDR: I'm here to claim, the PIN throttling is based on either:

external time value
is counted based on experienced frequency.
Both of which can be easily manipulated.

BTW. It gets worse. While researching this topic, I've found a research paper about Titan-M [1]. It claims Titan-M firmware can be updated, and this process is secured by user password, so just PIN.

Why then we didn't hear about bypassing PIN on GrapheneOS? I think it's because GrapheneOS is such a small niche, it will just happen when required (or even already happened), but there's just no reason for perpetrators to talk about it. For standard Pixels it's not necessary, Google can just bypass anything over Google Play Services on court order.

So what to do? Consider your threat model. GrapheneOS was always encouraging strong password as the safest solution. I'm just here to claim, bypassing PIN throttling is most likely a lot easier to defeat than it is commonly believed.

Appendix: can it be done better? Yes. Yubikeys don't allow firmware updates at all. They don't throttle PIN attempts, then count them and clear the PK when the limit is reached. This has a side effect: it's easy for a bad actor to reset the device. Someone could just take the phone, reach the limit to wipe it - pretty annoying.

[1] https://i.blackhat.com/EU-21/Wednesday/EU-21-Rossi-Bellom-2021_A_Titan_M_Odyssey-wp.pdf

DeletedUser217

The Titan M2, despite its name as a follow-up to the Titan M, is in fact a complete redesign based on the RISC-V CPU architecture. Therefore, its security characteristics have significantly changed and improved from the Titan M. This is demonstrated by its continued resilience against brute-force attacks (source) despite the best efforts of mobile forensics companies.

DeletedUser43 Why then we didn't hear about bypassing PIN on GrapheneOS? I think it's because GrapheneOS is such a small niche, it will just happen when required (or even already happened), but there's just no reason for perpetrators to talk about it. For standard Pixels it's not necessary, Google can just bypass anything over Google Play Services on court order.

You are making multiple assumptions which are incorrect. In fact Google has gone out of its way to implement strong Insider Attack Resistance requiring the users credentials be provided before any software or firmware updates are possible. Moreover, it’s well understood that nothing is perfectly secure and there will always be vulnerabilities in both software and hardware. Therefore, security patching is in fact one of the best ways to ensure security. Recently, there was a vulnerability in many previous Yubikeys which must now be replaced since Yubico markets non-upgradeable firmware as a selling point and refuses to offer updates. If they really cared they could offer two models, one with upgradeable firmware, but of course that wouldn’t make them as much money.

DeletedUser43 We don't care what time it is, we care how much time passed

This is correct. Although it is not the Titan M2, the OpenTitan project is somewhat related and implements a hardware timer.

DeletedUser26

I think you’re misunderstanding something, it’s not that they can’t bypass the rate limiting just on GrapheneOS, they also can’t bypass it on PixelOS in BFU mode. These chips are designed so that they shut down if improper voltage is applied and they are hardened against all kinds of physical attacks. What I assume you’re referring to when you say the firmware updates are protected by user password is Insider Attack Resistance, which requires a password to update the phone. This is designed to prevent the OEM from installing a malicious update on the phone, since it’s already not possible to install firmware unless it’s signed by Google. If it was really so easy to bypass the Titan chips then we would see these forensics firms with massive funding easily bypass them. That’s not what we see however.

DeletedUser43

DeletedUser26 The linked paper claims the firmware's signature is not checked, only user password is required to approve it. But you're most likely right, it can't be that simple. Just another thing to figure out and understand, as it's not documented fully anywhere.

DeletedUser87

To answer all your questions, here's an article: https://blog.google/products/android-enterprise/how-pixel-2s-security-module-delivers-enterprise-grade-security/

Tl;dr: you most likely can't outsmart it and I'm pretty sure you're not the first guy who had that idea."Just run on a board", okay, how are you gonna get the Titan desoldered and onto that board without it clearing it's own RAM?

DeletedUser43

DeletedUser87 Please look at https://i.blackhat.com/EU-21/Wednesday/EU-21-Rossi-Bellom-2021_A_Titan_M_Odyssey-wp.pdf
Pages 17-19 - they plug it over to Rapsberry Pie - not rocket science.

Nothing important is kept in RAM AFAIK.

But, the blog entry you linked, provides a very interesting claim: "The hardware is also resilient against many physical fault injection techniques including attempts to run outside normal operating conditions, [...] wrong clock speed [...]".

Preventing manipulating clock speed is the key then, but how? If Titan-M doesn't measure time by itself, how it could know the clock speed is out of bound?

Here's an idea: on one side the process is purposefully slow (it requires a lot of clock cycles) to process single PIN attempt, so manipulating the clock down is counterproductive. On the top side, the hardware purposefully "bad" like very old CPUs, so it looses signal integrity quickly if the frequency is raised to high? Overall it would not prevent manipulation, but let's say it'd allow only to speed up the process 100-1000x times, which is not good enough?

DeletedUser87

DeletedUser43 okay, read the paper. Read some updated information regarding Titan M2 (in use since Pixel 6). It seems that with the introduction of in-house designed Tensor SoCs, Google has actually offloaded some of the functionality to the Tensor Security Core. Source: XDA

Besides the upgraded Titan M2 chip, there's also the Google Tensor security core. The Tensor security core has its own dedicated CPU, ROM, one-time-programmable (OTP) memory, crypto engine (no, not cryptocurrency), internal SRAM, and protected DRAM. Its main purpose in the Pixel 6 is to protect user data keys and maintain Secure Boot

From what I've seen in the paper, the researchers never tried to retrieve any user data by transferring the Titan to the custom PCB. To exploit the vulnerabilities of the Titan you would also need root access, if that is to happen anywhere on a software level.
To address your claims about how the Titan counts time, there could be some possibilities. One of them not being a battery, but a capacitor (or a series of caps) storing charge in case the battery runs out completely or is disconnected. It could of course also retrieve time externally, but I kind of doubt that.
Not to mention, all of this research only applies to the first gen Titan. We don't know the full capabilities of the M2 but I'd be surprised if it didn't have any substantial improvements over the first one.
As I've said before, companies like Cellebrite would have all the incentive to exploit such vulnerabilities if they existed, especially if they were "extremely easy" as you've said.

areaman

I don't know about Titan specifically, but I see no reason the chip couldn't have an internal CMOS oscillator. It might not have the same long-term accuracy as a crystal or MEMS oscillator, but we don't care about loosing seconds over a few days. Just do an internal oscillator and have tamper circuitry that detects over/under voltage and over/under temperature (also doable on-chip) so you know the clock is within reasonable bounds. Chips can have internal voltage regulation as well with a bandgap reference, so you can have a clean voltage without depending on anything off-chip. I am an electrical engineer, it's not my specialty but I know the basics of analog/digital IC design.

DeletedUser43

areaman This makes total sense. I was assuming to count time, you need power. That's true, but not counting time when there's no power just stops the clock, making the throttling worse. And here is no need to follow time, all what's required is to count proper amount of oscillations and save then in persistent memory.

But it may even be simpler than that - without CMOS. Why not just count the base clock ticks? If you expect the phone's board to have stable frequency, let's say 100MHz, and the chip reliably crashes on lets say 3,5GHz, you can set a static multiplier to 30, so the chip always runs on 3GHz, then you can assume 3 "giga-clock-ticks" equals 1s passed. Then if someone underclocks, then the throttling would get worse, and if someone overclocks, the chip will fail way before any meaningful speed up could be achieved.

BTW. Let this topic again show, on the Internet it's best to start a discussion with a wrong solution. When I was just asking if someone knows how it works, I got nothing.

GuyN916

Meh, not everyone knows how to do this or has the equipment. Plus, you would need to have something on your phone to waste this much time cracking it...

DeletedUser43

DeletedUser87 I was only using this research to understand better how it works, because there is no proper documentation. I know it's about previous version.

Please take a look at "areaman" message and my response to it. I think it's either a built-in oscillator, or it's relying on a board's base clock and running the chip on frequency close to the maximum, so it fails if it's raised too much.

Either way, my original message doesn't make sense.

DeletedUser87

DeletedUser43 okay, but how does it matter? I haven't tested this on Pixel devices, but I know this from iPhones: Let's say your phone is blocked for one hour due to too many attempts. The timer counts down, 30 minutes remaining. You reboot the phone (or kill the power) and the timer resets to one hour. I would need to test this first (if this applies to Titan as well) but what would prevent Titan from storing a failed attempts count in memory and setting the timer based on that? It wouldn't really matter what the clock does as long as the chip knows how to set the clock based on hard data.

DeletedUser43

DeletedUser87 We don't care what time it is, we care how much time passed. In the case you described, the chip on iPhone probably just stores the amount of failed attempts in persistent memory, and counts to 60 minutes in RAM. After restart, it knows - lets say - it was 10 failed attempts, so it needs to count 60 minutes penalty, and it starts the count over. Cutting the power can only make the penalty worse.

If it has internal oscillator, you can't change the speed, you can only reset the count by cutting power.
If it counts the base clock and runs close to silicon's limit, if you try to speed it up too much, it will crash, reseting the count.