5 ms·

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, becau

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-icloud-keychain-sec3e341e75d/web 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/1/web/1 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.

danpalmer 5y ago
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.
- michaelt 5y ago
  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?
  - marcan_42 5y ago
    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.

danpalmer 5y ago

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.

michaelt 5y ago
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?
- marcan_42 5y ago
  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.