Hacker News Reader

Comment by stirlo | Hacker News Reader

In the second half of the post he suggests remotely determining an iDevice passcode was possible with his rate limit bypass. Essentially a salted version of the devices passcode is uploaded to the apple server which he could then bypass the rate limit to brute force it.

Isn't this a backdoor that would enable passcode bypass like was requested for the San Bernardino and Pensacola shooters phones?

This vulnerability is a massive deal. With the passcode determined there's nothing stopping bad actors surreptitiously access your data.

After all this a $2,180,000,000,000 market cap company offers a reward of $18,000. What a disgrace!

View on HN

He is assuming that, because all the other endpoints had buggy rate-limits, this one would too, and they also fixed it.

This is a bad assumption to make, because the device passcode recovery flow is going through an iCloud Keychain HSM cluster, which is a completely different implementation from everything else (which are just web services). In fact, it is well-documented that Apple cannot update the underlying code of their HSM clusters, as they destroy the management cards after initial provisioning. So they can't have actually fixed this bug if it existed prior to his report. That code was surely audited much more carefully, and depends on a much smaller technology stack, than all the web service stuff, and certainly handles rate-limiting within the HSM itself.

So I have no reason to believe that this flow was vulnerable to the rate limit bypass race condition like the others.

However, we have a different problem now.

I called it the iCloud Keychain HSM cluster because, as documented, that whole thing is used for iCloud Keychain escrow (i.e. password store in the cloud). That's an opt-in feature. More info here:

https://support.apple.com/guide/security/escrow-security-for...

I did not know this, but apparently if your account has 2FA, the code used for this is indeed your device passcode, which smells dodgy to me:

https://support.apple.com/en-am/guide/security/secdeb202947/...

But still, the context is iCloud Keychain.

But now Apple are claiming this flow, which does not have the problem OP discovered, is used for all Apple accounts that have logged in from a passcode-protected iOS device. This implies that they are re-using this system, originally designed for the very narrow use case of (and trade-offs that necessarily come with) iCloud Keychain, as a general account recovery mechanism for all Apple accounts. That does, in fact, mean that they have (the ability to brute-force) the device passcode of everyone who has ever logged in their device.

That's bad. The HSM cluster stuff makes this hard, but it is a huge change in attack surface. It means that your device data security now not only depends on on-device software and hardware design (and Apple are famously good at this), but also the security of an HSM cluster at Apple HQ. It means that if you manage to break into a given HSM cluster, you can then brute force the passcodes for all users managed by it. And it means that if the HSMs have a vulnerability, that is a massive liability. The HSMs are third-party, and I honestly trust HSM manufacturers much less than Apple themselves when it comes to building secure systems.

So I would very much like to know what's going on here, whether that flow really does work on all accounts regardless of whether you use iCloud Keychain or not, and why none of this is documented in the Platform Security Guide. Does the hard 10-attempt limit used for iCloud Keychain escrow recovery also apply here, or can you continue trying PIN codes forever subject only to rate-limiting? Is this the same codebase or a different one? There are many questions here, and Apple's vague answers and lack of documentation for this make it sound like something very fishy is going on here.

Out of interest, what’s your reasoning for trusting HSM manufacturers less than Apple?

HSM manufacturers are essentially selling security, so any security issue could destroy their business, whereas Apple would likely survive.

I have seen pentests being done on an HSM and the steps they go to are quite impressive. Far further than I would ever have expected.

I don't know for sure that HSMs can't be trusted, but:

1. They're all closed-source, super-expensive devices that security researchers don't look at in any numbers.

2. We know getting security right is extremely difficult; products from big, sophisticated, motivated companies have security problems revealed by careful public scrutiny. A product that hasn't received such scrutiny seems unlikely to be better than that.

3. The first and biggest customer for obscure security hardware like TPMs and Smart Cards is the government/military. In my country, government/military tech efforts have a reputation for being delivered late and over budget; often ending in failure; and not being particularly secure. Are we to believe defence contractors managed to do a competent IT project when they couldn't do that before or after?

4. We know, from examples like Dual EC DRBG and Crypto AG, that governments will happily put in a backdoor when given the chance. If a giant defence contractor like Thales was asked by their number 1 customer to put in a backdoor, do you think they'd say no?

This, and also:

- Infineon and ROCA. We know the code audits the industry does are superficial and do not catch the worst bugs. That code would've been a big red flag for real cryptographers, and it would've been quickly found had it been open source.

- Government requirements. Stuff like FIPS certification decreases security by increasing bureaucracy and complexity. See vulnerabilities affecting only the YubiKey FIPS for an example. These certifications hold the industry back by mandating compliance with large suites of algorithms, forbidding newer, better cryptography, and stuff like that.

- The general culture of that industry. They sell security, and they are all about audits. Those audits are about ticking boxes. They do not measure good design, overall defense in depth, or anything like that. They are bullet point lists of security features and specific attack models. Interesting attacks use novel approaches, and those audits are completely worthless at determining whether a system is likely to be designed in a way to be robust against new attacks or not.

I think HSMs are selling security (rather than security being an additional feature) and therefore you may be surprised at the amount of testing and scrutiny being done.

As I mentioned, I saw a pentest happening, that included physical, network, software, pretty much anything that could be done over months.

Issues like the Debian OpenSSL issues show that something being open source does not mean it's getting the scrutiny it needs, and while open source software is easier to apply that scrutiny to, I think the relationship is far more complicated than that.

If a defence contractor like Thales was asked to put a backdoor in, do you think that wouldn't be found if their device was tested for months on end by external testers paid to, and motivated by, finding vulnerabilities.

I'm not saying it doesn't happen, but I do think they deserve a little more credit than you may be giving them.

> If a defence contractor like Thales was asked to put a backdoor in, do you think that wouldn't be found [..] by external testers

There are many ways to design a back door that would pass such security audits, yes.

One option is to simply give the auditors a device without the back door - or a firmware listing without it.

You can also create bugs that are undetectable by black box testing - such as generating keys with insufficient entropy.

Another is to copy subtle bugs from other products, that sat in plain sight for years.

And of course the testers will all be under NDA so if they do find your back door, they’ve already promised to take part in your cover-up.

I agree with your first point and disagree with the second. :)

I think it's highly likely that Apple was being honest and that the HSM service was not vulnerable to this attack. That's consistent (as you say) with this being a separate, highly-audited implementation, and frankly consistent with what Apple said--and to save, what, $200k, they have no real reason to lie to a researcher here.

To your second point, while this is indeed a big change in attack surface, I am not sure it's as problematic as you say. Doesn't the iCloud backup basically contain (for most users) all of the device contents--photos, messages, etc--that an attacker would want? Conversely, users want to be able to restore their iCloud backups from a new i-device if they lose their existing one, ideally without having to know more than the lockscreen PIN.

Given that, the two systems--the cloud system and the i-device--are storing mostly-identical data, offering mostly the same security guarantees (hardware-backed key derivation from a weak PIN, rate limiting), and the only issue is that this is just a second hardware security module that's separate from the one in the i-device.

For users who have turned off cloud backup, this might be a bad tradeoff. (Maybe turning off cloud backup turns off the HSM/PIN syncing?) But for most users, the gain in usability seems likely to far outweigh the hypothetical additional risk.

iCloud backups aren't a requirement. You can have an iPhone with iCloud on disabled, and privacy-conscious users might choose that approach; additionally, those backups don't necessarily contain all device data.

But if you want to download apps at all from the App Store you need to sign in, and if that alone gives Apple the ability to verify your device PIN even without iCloud, that's a problem.

Hmm. I think for such users this may be surprising. At the same time, you don’t really have any reason to trust the cloud HSM more or less than the Secure Enclave, right?

Certainly it does increase attack surface, but if Apple said “now I-devices ship with 2 HSMs”, we’d be like, ok, shrug. No?

The fact that this is “remote” is sort of immaterial, I think. You’re trusting Apple’s (bespoke or acquired) stack the same either way, and as far as we can tell the security properties of both local and remote HSMs are the same.

The issue is that if you break one HSM, you get the ability to bruteforce thousands (millions?) of users' PINs, without their knowledge. You could bruteforce someone's PIN ahead of time, then acquire their phone knowing you can get at the data with zero risk. Getting the phone first then figuring out how to break into it is a lot trickier.

I do in fact trust the SEP more than I trust cloud HSM, because the SEP is an Apple design, and the HSMs they use, as far as I know, are third-party.

That's fair. I think I agree with that characterization.

I think if this excluded users who turned off iCloud sync, I'd have no qualms about it, however; the tradeoffs seem ideal for giving users a secure recovery mechanism. But users who have turned off iCloud may not want this functionality, I agree.

Yeah, the “Your password is encrypted and cannot be read by Apple” is a bold faced lie. This can definitely be used to crack a passcode. Log out of iCloud if possible.

I made a mini series on self hosting my cloud services here: https://www.naut.ca/blog/tag/shs/

I'm not sure it's really fair to say it's a bold faced lie. It's been awhile since I looked at SRP, but it looks like server side only require storage of Username, Salt, Verifier in it's database according to http://srp.stanford.edu/design.html

Unless I'm missing something this is really an artifact of allowing a user to use a short pin on the device, but also because this short pin is allowed to be used somehow as part of the password recovery flow which as such requires properties to prevent brute force.

Unless I'm missing something, choosing an alphanumeric pin of sufficient length would avoid this and be difficult to brute force. So it would seem the guarentee's are weaker than expected due to this, but I doubt it's a bold faced lie.

Unless I'm missing something of course.

The point is SRP is no different, in this context, from storing a standard password hash. You can brute force the passcode if you have access to the verification material on the server.

Apple's device security model relies on rate- and attempt-limiting unlock attempts, so that people can in fact use short numeric passcodes. Their on-device model is carefully designed to make it very hard to bypass this.

The problem is now they have extended that model and attack surface to their HSM clusters. That's 1) not Apple hardware (I trust Apple hardware more than I trust the third-party HSMs they use), 2) not (only) Apple code (again I have less trust in HSM frameworks than Apple's), 3) shared for many users, so break one HSM cluster and you get to bruteforce a lot of passcodes, 4) strangely not documented in Apple's Platform Security Guide, which is very suspicious.

I was expecting iPhones to generate public/private key pair and upload public part to the cloud during provisioning. That way you can securely prove you own the device but there’s no need to send password or anything derived from it to Apple.

Yea, I think this missed expectation is valid, I certainly wouldn't have expected the pin code to be used as an authenticator on an internet facing API.

I wish they allowed more technically proficient users to disable password recovery and manage iCloud backups off cloud.

Reply on news.ycombinator.com