HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
Behind the Scenes of iOS Security

Black Hat · Youtube · 10 HN points · 23 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention Black Hat's video "Behind the Scenes of iOS Security".
Youtube Summary
by Ivan Krstic

With over a billion active devices and in-depth security protections spanning every layer from silicon to software, Apple works to advance the state of the art in mobile security with every release of iOS. We will discuss three iOS security mechanisms in unprecedented technical detail, offering the first public discussion of one of them new to iOS 10.

HomeKit, Auto Unlock and iCloud Keychain are three Apple technologies that handle exceptionally sensitive user data – controlling devices (including locks) in the user's home, the ability to unlock a user's Mac from an Apple Watch, and the user's passwords and credit card information, respectively. We will discuss the cryptographic design and implementation of our novel secure synchronization fabric which moves confidential data between devices without exposing it to Apple, while affording the user the ability to recover data in case of device loss.

Data Protection is the cryptographic system protecting user data on all iOS devices. We will discuss the Secure Enclave Processor present in iPhone 5S and later devices and explain how it enabled a new approach to Data Protection key derivation and brute force rate limiting within a small TCB, making no intermediate or derived keys available to the normal Application Processor.

Traditional browser-based vulnerabilities are becoming harder to exploit due to increasingly sophisticated mitigation techniques. We will discuss a unique JIT hardening mechanism in iOS 10 that makes the iOS Safari JIT a more difficult target.
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
Jul 15, 2021 · eddyg on Luxury Surveillance
You may be interested in watching Ivan Krstić’s BlackHat talk[0], in which he details the security of the iCloud infrastructure.

The use of physical one-way hash functions is involved.

[0]https://m.youtube.com/watch?v=BLGFriOKz6U&t=32m31s

I believe this is what OP is talking about: https://youtu.be/BLGFriOKz6U
I tried 1Password but finally resolved to use iCloud keychain after watching this BlackHat 2016 video https://youtu.be/BLGFriOKz6U.

I mean as far as I already trust their OS nothing can really protect me from being spied by them if they are ill intentioned, so as long as they are serious and patch their security flaw on a timely manner I can live with that. Beside it come as a free plan if you don't need more than 5GB of iCloud storage.

I'd figure using an external password manager just add another third party I need to trust and the fact that 1Password offer browser app interface (on top of native) don't reassure me in any way.

Of course if I'd ever need to reassess my threat model because I can't trust Apple anymore, I will quit iCloud service at the same time as their OS and go full FOSS.

The apple security whitepaper is actually a decent place to start https://www.apple.com/business/docs/site/iOS_Security_Guide....

There is also a blackhat talk from Ivan Krstic (one of the top security people at apple) where he goes surprisingly deep https://www.youtube.com/watch?v=BLGFriOKz6U

Worth noting that Apple "gets away" with more in China than most:

- iMessage, one of the only end-to-end encrypted messaging systems widely available in China.

- iCloud Keychain, which they've designed to work securely on "adversarial clouds"[1]

(Of course this may only be because not many people actually use these features versus WeChat...)

[1] https://www.youtube.com/watch?v=BLGFriOKz6U

jhanschoo
I'm of the notion that when doing business in certain illiberal regimes (and China is one of those certain ones), one still does democracy and liberalism a service if one offers, through their services, more empowerment and a less regulated or surveilled experience than what is available in their market.

The primary intuition driving the response that companies should boycott illiberal regimes has three flaws.

First, in a free market of money and information, a sufficiently strong boycott can have severe repercussions for the offender: consumers switch to a known competing service because. There is a problem extending this notion to an (empowering and less surveilling) company boycotting an illiberal regime; from the hypothesis I outline above, a competing service offers less empowerment or more surveillance and regulation, which in effect helps the entity being boycotted, the state; and also because of the hegemonic control of information, the entity being boycotted, the state, is unlikely to see criticism from something so minor as a company not doing business in it.

Second, one argument in favor of boycott is by analogy of economic sanctions. It puts pressure on the sanctioned company. I have to say that this is true to an extent. Companies supplying goods important to national security like oil and arms can exert influence on countries. But one does not think that Apple is critical to the national security of China: everything except for the more empowering and less surveilling services provided by Apple is provided by competing services in China. Perhaps one argues that the more empowering and less surveilling practices makes life more tolerable in the illiberal regime. In that case, I do not see the problem either: many think that Twitter and Facebook do democracy and liberalism a service because they offer empowerment and a less surveilled platform in illiberal regimes.

Finally, there is the question of where the line has to be drawn to be moral. Just as one argues that companies are immoral to participate in the economy of an illiberal regime, one also gets the argument that companies are immoral to participate in the economy of a liberal regime with illiberal elements, countries like the US where monied interests have outsized influence in its politics. It is on the onus of those arguing for boycott to provide a distinction for why doing business in the US in industries heavily shaped by lobbied interests is not immoral but doing business in China is, but thus far the current reasons I have heard being expressed for boycotting illiberal regimes do not work; one, of putting pressure on countries is also an argument for boycotting the US, and likewise for the other, for "refusing to stain one's hands" in participating in illiberal processes. By that dime, it would be immoral to receive federal subsidies for one's business that one thinks does the nation a disservice. For the two reasons I have put before this point, I argue that line drawn is not one between liberal and illiberal regimes, but whether or not a company is providing a more empowering and less surveilled experience to people living under any regime.

Of course, under a sufficiently liberal regime, and in certain contexts, empowerment and surveillance can be tradeoffs: the presence of police surveillance empowers one to go outdoors with less fear of harm being done to themselves, but this is not relevant to the argument at hand.

Unless these flaws are addressed, one is left with the case of Twitter and Facebook in illiberal regimes: they should be appreciated for their empowering and less surveilled services in illiberal regimes, rather than criticized for doing business in those regions.

Thus, if what you say is true, that Apple provides a less surveilled experience, and if my argument is true, then Apple is doing democratic preconditions and liberalism a net benefit in China. I believe the same for Dragonfly by Google, if it provides a much better search experience for Chinese consumers with not significantly more censorship than other search providers in China. Of course, Apple and Google would not be wise to make this argument publicly, for doing so would paint a bright red target on their backs.

cletus
> - iMessage, one of the only end-to-end encrypted messaging systems widely available in China.

And those encryption keys are stored in China because the Chinese government demanded it be so [1].

I believe it's also more subtle than that too. For example, if you (a non-Chinese iMessage user) send a message to a Chinese iMessage user the key to that exchange is now stored in China.

[1] https://www.reuters.com/article/us-china-apple-icloud-insigh...

abalone
That’s inaccurate. iMessage, Keychain and a few other services are end to end encrypted with keys stored only in the secure elements of each iPhone. Apple cannot access this data even under subpoena and neither can anyone who controls their data centers (China). They don’t have those keys.

What the article you cited refers to is more general iCloud data, including backups, which is vulnerable to subpoena/govts. They do have those keys. But it is significant that China permits iMessage to operate even though it is E2EE.

More details here on what is E2EE and what is not: https://support.apple.com/en-us/HT202303

macintux
The keys are only useful if the user enables cloud storage of messages, so the user’s privacy is still achievable. That fact seems to be lost in the noise.
intopieces
But what happens if you send a "sensitive" message over iMessage? On WeChat (or even the messaging system inside Didi!) you get censored. Does it happen on iMessage?
Despegar
What? The point of end-to-end encryption is that Apple doesn't retain the keys.

iMessage and FaceTime are end-to-end encrypted. And after Messages in iCloud, you get the benefit of E2E while everything stays in sync across all your devices [1].

It won't be long until this dumb narrative that ignores Apple's leverage in China goes away. Once there's a trade deal they'll be allowed to own data centers without JVs again [2].

[1] https://www.theverge.com/2018/5/29/17405420/messages-icloud-...

[2] https://www.wsj.com/articles/china-sweetens-its-cloud-offer-...

Sep 17, 2018 · abalone on iOS 12 released
Also several of the iCloud services are E2E encrypted and designed to withstand adversarial clouds. They talked about it at Blackhat.[1]

Doesn't help things like mail or photos, of course, but it is extremely notable in the China context for one big reason: it does E2E encrypt messages. WhatsApp was banned from China when they implemented this. Apple stands out in this way... although they're probably getting away with it because most Chinese don't use Apple Messages.

[1] https://www.youtube.com/watch?v=BLGFriOKz6U

mtgx
Yeah but even if they use e2e, which btw was found to be flawed at the protocol design level by prof. Matthew Greene and his team, they also automatically back-up the messages to iCloud with no way to disable that without disabling the whole of icloud. It would sure be nice if they changed that.
mediocrejoker
Can you elaborate on what you mean by "e2e was found to be flawed"? Is the paper available online?
coolspot
Commenter probably meant this research[0].

[0] - https://blog.cryptographyengineering.com/2016/03/21/attack-o...

threeseed
There is the option in Settings to disable storing Messages and Backups in iCloud.
sneak
...which does not affect the storing of Messages in device backups into iCloud.
djrogers
This is categorically and demonstrably false. Backing up to iCloud is disabled by default, as is Messages in iCloud. Either can be enabled or disabled as desired with no ill effect on your device or the rest of iCloud usage.
sneak
iCloud backup is on by default.
djrogers
No - setting up an iPhone from new doesn’t even require an iCloud account. If you set up iCloud it will enable backups, but even then you can disable them without disabling ‘all of icloud’ as GP claims.
sneak
The fact that iCloud is not required to activate does not change the fact that iCloud is on by default and iCloud backup is also on by default.
teknologist
I suspect that there might be undiscovered software differences between iPhones sold in China and those sold in other markets. The Flag of the Republic of China (Taiwan) is not present on iPhones sold in China. It shows up as a box with a question mark in it.
abalone
If you're implying they secretly disabled iMessage encryption for the China locale: No Friggin Way. That would be discovered and publicized instantly.
teknologist
Not to venture into conspiracy theory territory but the fact that they have the capability in software to modify the phone's behaviour based on which country the device was sold in is concerning enough to me. The Chinese gov. can put pressure on these large multinationals that rely on China's workforce and those companies can't do a great deal about it other than comply.
Take a look at this blackhat talk from Apple's head of security Ivan Krstic, where he explains the mechanism they use to secure credentials stored in the cloud: https://youtu.be/BLGFriOKz6U?t=22m31s
tl;dr Common criminals go with default security settings.

This is about to get even worse for law enforcement. To date, iCloud backup still offers a way for law enforcement to access data with a warrant. However that is about to change. Apple is about to roll out iMessages on iCloud, which sounds innocuous, but actually will premiere a major step forward in security: end-to-end encrypted data in the cloud by default.

This is huuuuuge.

The thing that has been holding back E2EE as the default is that it has sacrificed recoverability. That is, it has required a strong password, which is easy to forget, and if you forget it, no one can help you. So it's something you had to opt into. Not a default.

Now, Apple has created a backup solution that -- get this -- removes the need for a strong password. Sounds crazy, right? All you need to remember is your iPhone passcode. Obviously, this is brute forceable and can't secure your cloud data...

Except yes it can. They've implemented hardware security modules that prevent brute forcing. Then they destroyed the signing key for the HSM firmware. Neat.[1]

So, iMessages are going to transition to this, which probably means they won't be in the iCloud backup, and thus not available to law enforcement. And then it's probably just a matter of time until the whole backup is secured with E2EE.

[1] https://www.youtube.com/watch?v=BLGFriOKz6U

mtgx
I'll believe it when I see it. One simple privacy-focused solution Apple could have implemented since many years ago is keeping iMessages E2EE, instead of backing them all up to the cloud automatically and not allowing the users to disable the backups for iMessages unless they disable the whole iCloud backup (which is enabled by default).
abalone
> One simple privacy-focused solution Apple could have implemented since many years ago is keeping iMessages E2EE, instead of backing them all up to the cloud automatically

Which means they would not be recoverable or even restorable to a new iPhone. Not a good default for a consumer device.

Apple made the right choice, letting you opt into stronger security at the sacrifice of recoverability. And now they're working on the best of both worlds.

That’s not the apple talk. Apple gave a talk specifically about hardware security in the iPhone.

Edit: this one. https://youtu.be/BLGFriOKz6U

Edit 2: the question was asked at 47:20

https://www.youtube.com/watch?v=BLGFriOKz6U&feature=youtu.be...

They take security for these things seriously. You can store data safely even in adversarial clouds.

Passwords are backed up but they are end to end encrypted. Check out Cloud Key Vault, it’s a pretty cool solution for keychain (password) backups designed for adversarial clouds.

Unfortunately does not apply to regular iCloud backups or most other data. But a major step forward.

https://www.youtube.com/watch?v=BLGFriOKz6U&feature=youtu.be...

dogma1138
end to end encrypted doesn’t mean much when your decryption key is the Apple account/iCloud password.

AFAIK I never had to define an encryption password for an iCloud backup only for local backups with iTunes which means that the device only needs my Apple account credentials to retrieve and decrypt a backup from iCloud as such China and for that matter any entity which gains lawful or unlawful access to your Apple account gets to have the keys to the kingdom.

abalone
You didn’t watch the video did you. That’s not how it works. The key is your device passcode.
dogma1138
The key for the backups can’t be the device passcode because the device passcode protects the key stored in the Secure Enclave on the device that is the local encryption key also 6 digits isn’t nearly enough entropy for any key derivation algorithm.

I can download a backup from iCloud and unpack it in any device or use a 3rd party application to view to content of the backup and the only thing I need is the Apple account password used for iCloud.

abalone
"We have a feature called iCloud Keychain Backup, and here's what we do. We have a new credential, the iCloud Security Code, and most often this is the device passcode."

- Apple security architect, in the aforelinked video, which you still didn't watch

> Where Apple provides overwhelming detail about their best security systems (file encryption, iOS, iMessage), they provide distressingly little technical detail about the weaker links like iCloud encryption.

Sounds like the author missed Apple's BlackHat 2016 talk. It goes into lots of technical detail on Cloud Key Vault.[1] Well worth watching -- and a very cool implementation of a secure backup system designed for "adversarial clouds".

It's pretty cool how it retains end-to-end encryption of your keychain while also backing it up to untrusted clouds. Basically it employs Hardware Security Modules that limit recovery attempts to 10 tries before destroying the data, thus protecting against backend brute forcing and allowing you to use your relatively weak device passcode to encrypt the backup. And here's the kicker -- they put the HSM firmware signing keys in a blender so even an adversarial government can't force them to modify them.

Update: I guess he did watch the video (he previously wrote a whole post on it). So I'm not sure what he thinks is missing, or maybe I misunderstood and he's only complaining about non-keychain data encryption.

[1] https://www.youtube.com/watch?v=BLGFriOKz6U&feature=youtu.be...

JoachimSchipper
The author, in fact, has specifically written an article on the talk you mention: https://blog.cryptographyengineering.com/2016/08/13/is-apple....

Matthew Green is a capable cryptographer who engages with the wider security community and practical encryption a lot (e.g. https://blog.cryptographyengineering.com/2016/03/21/attack-o... if you're interested in this kind of thing, I'd recommend following him more closely (e.g. on Twitter.)

ec109685
Apple still could release a software update that would update the HSM firmware to remove the limit of ten tries before the keys are lost.

Mentioned here: https://9to5mac.com/2016/02/25/apple-working-on-stronger-icl...

eridius
You're confusing the behavior of the device with the behavior of the HSM modules used for iCloud storage.
ec109685
The attack is that you force Apple to update the OS for a person’s device w/ evil firmware. Then you crack the device by guessing the pin in a brute force manner. Then you unlock the data from the HSM with that guessed pin.
niij
The conversation is about recovery of data stored off-device e.g.: on Apple's servers. There wasn't a discussion about recovery of information when the physical device is present.

HSM is a term used exclusively for server hardware, I believe. I know Apple devices (and some Android) use secure enclaves, but I don't believe they are referred to as "HSM"s.

ec109685
I know. I conflated HSM and Secure Enclave incorrectly.

I agree Apple does well in the security arena, but they should do more to prevent software updates without erasing the device if the security key is not available.

ec109685
Also, the article stated this: “In short: Apple has designed a key vault that even they can’t be forced to open. Only customers can get their own keys.”

That was the part I was arguing with. Apple can get the keys if they were compelled to.

eridius
But they can't be compelled to.

If Apple has access to the data, the government can compel them to turn it over. The whole point of this setup is that Apple doesn't have access to the data, because they can't get the keys, and they can't reconfigure the HSM to give it to them.

Now yes, they could in theory change iOS and push out an update to everyone that breaks the security model. But the government¹ can't compel them to do that. The government cannot compel them to materially change their product and break one of the major advertised features of the device.

¹I'm assuming US government here. The rules would be different in China, but I guess China knows that even they can't compel Apple to break the security model of the device in this way, Apple would rather leave China than do it.

abalone
eridius is right. Apple cannot update the firmware of the backend HSM clusters without data loss. (If you believe what they say.) They literally throw the signing keys into a blender. The article refers to device firmware not the iCloud backend.
ec109685
Yeah, I got confused by HSM and Secure Enclave. I still think it is crackable given it is all secured by a user’s pin which can be verified on device by software Apple controls.
abalone
Of course Apple controls the software. Apple or any manufacturer could push an update overnight that disables all encryption and transmits your data to Donald Trump or whoever they want the next time you enter your passcode. There’s exactly zero “security researcher insight” in observing that.

The question is, if you trust that iOS and iCloud work the way Apple says they do (under oath), how vulnerable are they to an adversarial cloud. They have designed a system to keep your keychain safe under these conditions.

ec109685
Agree they aren’t vulnerable to a rogue cloud for keychain data.
Buge
This is covered in the blog post:

>With one major exception — iCloud Keychain, which I’ll discuss below — iCloud fails the mud puddle test. That’s because most Apple files are not end-to-end encrypted.

The blog post is saying that iCloud backups are not protect from Apple, except keychain backups. So your files, messages, etc are not protected from Apple. And the video you posted seems to only be about keychain backups.

kodablah
I think the author is looking for written documentation and reference material, not a presentation that may be outdated and not apply to this situation. I concur with the author, this should be available in clear unambiguous docs. Instead, many are unfortunately forced to point to old videos and depositions as reference material.
abalone
August 2016 is not that old, it clearly applies to this situation (“adversarial clouds”), and also the salient points are documented in the iOS security white paper which is updated annually: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
sandworm101
And why should we assume that every cloud is the same? The china cloud might be different in tiny but important ways.

Or all the clouds might have 'evolved' a few minutes ago to comort with some new apple policy. This is all about trusting a corporation. I still prefer to handle my own encryption, keeping my keys how and where i like.

abalone
Nobody is assuming that. The whole point is it can store secrets on adversarial clouds. The key stays with the client.
Apple doesn't even have the encryption keys for iCloud Keychain. They've taken a very hardcore secure approach to this that is explicitly designed for "adversarial clouds". This isn't true for all iCloud data, but the most sensitive stuff like keychain and health data use end-to-end encryption.[1]

What's impressive is they've implemented a backup solution for this that still retains end-to-end encryption. They use HSMs to encrypt a keychain "escrow" backup using your device passcode. The HSMs protect against brute forcing and Apple has no way to bypass -- they literally put the firmware administration keys in a blender.[2] It's pretty cool.

[1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf

[2] https://www.youtube.com/watch?v=BLGFriOKz6U&feature=youtu.be...

None
None
The Black Hat talk was really great: https://youtu.be/BLGFriOKz6U?t=6m55s (link is to SEP and on-device encryption, 22:30 is iCloud stuff)

> I know they said they could have accessed that San Bernardino terrorist’s iCloud backup if only they had one. Not sure if they’ve change the security architecture since then.

I actually think they have, the shooting was in 2015 and iOS 10 was released in 2016 and was first to have some of the features he talks about in the video.

comstock
Apple, very clearly states that only the following data is end-to-end encrypted:

iCloud Keychain Payment information Wi-Fi network information Home data Siri information

So everything else, pictures, notes etc. etc. part of the iCloud backup, are not. Please not spread misinformation about this.

https://support.apple.com/en-us/HT202303

abalone
Chill. You’re extrapolating incorrectly from that brief support document. It doesn’t say that Apple can read the other encrypted stuff. The security whitepaper notes that things like iCloud backups are encrypted with keys that are stuffed into the keychain, which is then transmitted end to end encrypted.
comstock
Would you care to link to the section of the security white paper that says that? There’s a small subset of data that is encrypted end-to-end. Your photos, notes, most and most other information is not include in that.

It’s pretty obvious really, they need to know the key for encrypted at rest data in order to be able to reset your password if you desire. They absolutely do don’t currently offset end-to-end encryption on the majority of data in iCloud backups.

abalone
Not obvious. p55: “changing the iCloud password won’t invalidate existing backups.“

But you’re right, the paper doesn’t say they do encrypted iCloud backups yet. The infrastructure is there to store encrypted backup keys in the keychain and escrow them so they’re recoverable yet Apple never has access. It’s probably the same foundation for iMessages in iCloud which they are just rolling out. That lets them store your very sensitive messages in the cloud and restore them to new devices and reset your password, all without them ever having access to your keys.

See the section on keychain escrow and recovery for more detail. It’s a game changer and makes storing data in adversarial clouds feasible.

garmaine
If that were the case you wouldn’t be able to restore from an iCloud backup to a fresh new device. But you can.
abalone
In a simpler system yes. But they’ve developed a sophisticated system for syncing secrets called iCloud Keychain. Apple never knows your keychain. Once a new device joins your keychain circle it would in theory be able to sync backup keys and then restore, all without Apple ever knowing. They’re about to roll this out for iMessages which are also not readable by Apple. Backups are probably in the pipeline if they’re not doing it already.
comstock
Only if you have multiple devices... it would be nice if they supported this optionally (it would be nice if they supported any kind of end-to-end backup optionally).
comstock
Yes, they obviously have the infrastructure to do it. However, they don’t even optionally.

Part of the reason is that people sometimes forget their passwords and that would lock them out of their backups. So they want to allow email/other methods of resetting the password and giving access to data.

But it would be nice to have it as an option. It’s worrying though that even technical people seem to believe it is end-to-end encrypted. When it very obviously isn’t.

abalone
No, Apple doesn’t need to know your backup key to reset your password and retain backups. I explained why in my previous comment. If they’re not stuffing it in iCloud Keychain (yet) it’s not because the infrastructure can’t support it in principle. See: iCloud Keychain recovery. It’s probably just a matter of maturity; they still haven’t rolled out iMessages in iCloud which is a similar case.
comstock
I think they want to support the scenario of lost device, lost password, but still allow restoring data to a new device.
They do all sorts of device key exchange, if you haven't watched the talk at Black Hat I'd highly recommend it: https://youtu.be/BLGFriOKz6U?t=6m55s (link goes to beginning of Secure Enclave content, and later on in the talk he discusses iCloud which uses the SEP keys)
bluejekyll
Excellent. I’ll take a look at that, thanks for the post.
There's a video of a presentation by Ivan Krstic (head of security engineering, Apple) at Black Hat from 2016 about iOS security: https://www.youtube.com/watch?v=BLGFriOKz6U
Sep 17, 2017 · Shank on Our Approach to Privacy
It all boils down to what you see in the public. The FBI was trying to get Apple to create an iOS variant to extract data from a device, to the point where Tim Cook wrote a letter refusing to do so and was willing to fight it in court. In a similar fashion, Apple has given talks and white papers on iOS security. In tandem with these well documented white papers and talks discussing the internal functions of iOS, we haven't seen any well known or trivial exploits appear to surface that demonstrate flaws in them.

In the case of the FBI fiasco, for example, we know that the FBI later paid Cellebrite for an exploit that allowed them to unlock the device. We don't know the details of how that happened, but the FBI had to reach out to an independent company and exploit an older device to do it.

To be clear: if they were lying about the lengths they go to with encryption, on device security, and user trust, this story would have been different. The FBI would have already had a backdoor or been able to trivially break the device, or they would have complied and created an iOS variant to break in. All we know is what they stood their ground on, and the effort that was required for the FBI to get in.

iOS 10 security white paper: https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Talk about iOS security at Black Hat: https://www.youtube.com/watch?v=BLGFriOKz6U

forapurpose
Perhaps both the FBI and Apple had a chance at good PR for their causes, and the FBI had a chance to set legal precedent, so neither admitted that the FBI could break in if needed.

The idea that iPhones were inaccessible to highly-resourced attackers like the U.S. government seems unbelievable. Everything has security holes, even if they are expensive to discover or exploit; the U.S. government's resources are immense and the payoff - access to iPhones when needed - is clearly worthwhile. And in the end, when the PR debate had run its course, the FBI found a way in.

lern_too_spel
We know that they lied to customers claiming they couldn't help law enforcement get data off customers' devices.

"Unlike our competitors, Apple cannot bypass your passcode and therefore cannot access this data. So it's not technically feasible for us to respond to government warrants for the extraction of this data from devices in their possession running iOS 8."[1]

After it became clear that it is technically feasible for Apple to assist with those data requests, they quietly removed that claim from their website.[2]

[1] https://arstechnica.com/gadgets/2014/09/apple-expands-data-e...

[2] https://www.apple.com/privacy/government-information-request...

millstone
By "technically feasible" are you referring to Apple's ability to build a software update that allows for quicker brute-forcing of the passcode?
lern_too_spel
Yes. Brute forcing pin codes can be done very quickly. Apple realized it was technically feasible too, which is why they no longer make that claim. That they didn't apologize to their users and offer refunds demonstrates the disdain they have for their customers.
Given the way iCloud security works I'm not sure iCloud was breached at all [1]. Other reports seem to indicate that it was employees at Apple stores and third party resellers who had access to names, phone numbers and Apple IDs [2]. Presumably they would try to phish them later on.

[1] https://youtu.be/BLGFriOKz6U?t=32m35s

[2] http://www.foxbusiness.com/features/2017/06/07/chinas-new-cy...

eddyg
It's almost as if people commenting here haven't even watched Ivan Krstić's Black Hat video...
sitharus
Given that with 2FA enabled Apple can't even reset your password (which has caught the tech press out before https://thenextweb.com/apple/2014/12/08/lost-apple-id-learnt...) I agree that iCloud itself is unlikely the source.

It's probably a marketing or support database that contains basic data. Annoying but not a serious breach.

Apple at least has done as much as possible: https://www.youtube.com/watch?v=BLGFriOKz6U

tl;dw the process includes a blender.

For a really in-depth dive about the iOS class keys system he mentions I recommend this 2016 blackhat talk by Ivan Krstic (head of security at Apple): https://www.youtube.com/watch?v=BLGFriOKz6U (relevant portion starts at 6:56)
Sep 07, 2016 · tedmiston on iPhone 7
I found the talk (though I don't pretend to understand it all), video & slides are online if others are interested.

Behind the Scenes with iOS Security

Abstract - https://www.blackhat.com/us-16/briefings.html#behind-the-sce...

Slides - https://www.blackhat.com/docs/us-16/materials/us-16-Krstic.p...

Video - https://www.youtube.com/watch?v=BLGFriOKz6U

Sep 03, 2016 · 2 points, 0 comments · submitted by doener
Aug 18, 2016 · 2 points, 0 comments · submitted by antr
Aug 17, 2016 · 1 points, 0 comments · submitted by robin_reala
Aug 17, 2016 · 1 points, 0 comments · submitted by ivank
Aug 16, 2016 · 4 points, 0 comments · submitted by subnaught
HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.