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.
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.
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.