> Apple will publish a Knowledge Base article containing a root hash of the encrypted CSAM hash database included with each version of every Apple operating system that supports the feature. Additionally, users will be able to inspect the root hash of the en- crypted database present on their device, and compare it to the expected root hash in the Knowledge Base article. This is just security theater, they already si…
> And there is no way to audit that the database is what they claim it is, doesn't contain multiple databases that can be activated under certain conditions, etc. Although this is true, the same argument already applies to "your phone might be scanning all your photos and stealthily uploading them" -- Apple having announced this program doesn't seem to have changed the odds of that. At some point you have to trust yo…
Security Threat Model Review of the Apple Child Safety Features [pdf]
51–60 of 393 posts
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#52Earlier quoted context omitted.
Your phone threat model should already include "the OS author has full access to do whatever they want to whatever data is on my phone, and can change what they do any time they push out an update." I don't think anyone's necessarily being too upset or paranoid about THIS, but maybe everyone should also be a little less trusting of every closed OS - macOS, Windows, Android as provided by Google - that has root access…
Sure, but that doesn't change the fact that the vulnerabilities with local scanning remain a significant superset of cloud scanning's. Apple has built iOS off user trust & goodwill, unlike most other OSes.
Where does that fit in your set intersection?
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#53Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#54What is the process to make sure the next management will honor these promises?
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#55Earlier quoted context omitted.
> And there is no way to audit that the database is what they claim it is, doesn't contain multiple databases that can be activated under certain conditions, etc. Although this is true, the same argument already applies to "your phone might be scanning all your photos and stealthily uploading them" -- Apple having announced this program doesn't seem to have changed the odds of that. At some point you have to trust yo…
Which is why I am confused by a lot of this backlash. Apple already controls the hardware, software, and services. I don't see why it really matters where in that chain the scanning is done when they control the entire system. If Apple can't be trusted with this control today, why did people trust them with this control a week ago?
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#56Earlier quoted context omitted.
If you're uploading to the cloud, you have to trust a lot more than just your OS vendor (well, in the default case, your OS vendor often == your cloud vendor, but the access is a lot greater once the data is on the cloud). And if your phone has the capability to upload to the cloud, then you have to trust your OS vendor to respect your wish if you disable it, etc. It's curious that this is the particular breaking poi…
Yeah, it's weird. Speaking purely personally, whether the scanning happens immediately-before-upload on my phone or immediately-after-upload in the cloud doesn't really make a difference to me. But this is clearly not a universal opinion. The most-optimistic take on this I can see is that this program could be the prelude to needing to trust less people. If Apple can turn on e2e encryption for photos, using this prog…
What I find interesting is that so many people find it worse to do it on device, because of the risk that they do it to photos you don't intend to upload. This is clearly where Apple got caught off-guard, because to them, on-device = private.
It seems like the issue is really the mixing of on-device and off. People seem to be fine with on-device data that stays on-device, and relatively fine with the idea that Apple gets your content if you upload it to them. But when they analyze the data on-device, and then upload the results to the cloud, that really gets people.
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#57Two things that stuck out to me:
1) The CSAM hash database is encrypted on-device
2) The device doesn't know the results of hash comparisons
These suggest to me that the hash comparison is going to happen inside the Secure Enclave - give it the encrypted database and the NeuralHash of an image, it gives you back a Security Voucher to upload.
I don't quite get how the hash database can stay secret though - the decryption key has to come from somewhere. AFAIK the hash database has never been made publicly available before, which probably makes it quite a high value target for security researchers and curious parties.
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#58Earlier quoted context omitted.
If you're uploading to the cloud, you have to trust a lot more than just your OS vendor (well, in the default case, your OS vendor often == your cloud vendor, but the access is a lot greater once the data is on the cloud). And if your phone has the capability to upload to the cloud, then you have to trust your OS vendor to respect your wish if you disable it, etc. It's curious that this is the particular breaking poi…
No, the threat model differs entirely. Local scanning introduces a whole host of single points of failure, including the 'independent auditor' & involuntary scans, that risk the privacy & security of all local files on a device. Cloud scanning largely precludes these potential vulnerabilities.
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#59Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#60This seems like a pretty helpful document, and really shows how carefully the CSAM system has been designed. Two things that stuck out to me: 1) The CSAM hash database is encrypted on-device 2) The device doesn't know the results of hash comparisons These suggest to me that the hash comparison is going to happen inside the Secure Enclave - give it the encrypted database and the NeuralHash of an image, it gives you ba…