5 ms·

I have seen it suggested that everyone should flood the system with flagged images to overwhelm it in protest to this move by apple. Sounds pretty stupid to me

I have seen it suggested that everyone should flood the system with flagged images to overwhelm it in protest to this move by apple. Sounds pretty stupid to me to fill your phone with kiddie porn in protest, but you do you internet people.

mannerheim 5y ago
You don't need to do that, just use images that collide with the hashes.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- robertoandred 5y ago
  How will you know something collides?
  - falcolas 5y ago
    Because the algorithm and list will be on your phone, and can (has, per TFA) be extracted.
    - robertoandred 5y ago
      You cannot extract or reverse the CSAM hashes. They've been encrypted and blinded using server-side-only keys. If TFA said that, it's lying.
      - falcolas 5y ago
        One does not need to reverse the CSAM hashes to find a collision with a hash. If the evaluation is being done on the phone, including identifying a hash match, the hashes must also be on the phone.
        mannerheim 5y ago
        I believe the hash comparisons are made on Apple's end. Then the only way to get hashes will be a data breach on Apple's end (unlikely but not impossible) or generating it from known CSAM material.
        falcolas 5y ago
        That's not what Apple's plans state. The comparisons are done on phone, and are only escalated to Apple if there are more than N hash matches, at which point they are supposedly reviewed by Apple employees/contractors. Otherwise, they'd just keep doing it on the material that's actually uploaded.
        mannerheim 5y ago
        Ah, never mind, you're right: > Apple’s method of detecting known CSAM is designed with user privacy in mind. Instead of scanning images in the cloud, the system performs on-device matching using a database of known CSAM image hashes provided by NCMEC and other child-safety organizations. Apple further transforms this database into an unreadable set of hashes, which is securely stored on users’ devices. https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni...
        cyanite 5y ago
        He is not right, though. The system used will not reveal matches to the device, only to the server and only if the threshold is reached.
        cyanite 5y ago
        > That's not what Apple's plans state. The comparisons are done on phone Yes but as stated in the technical description, this match is against a blinded table, so the device doesn’t learn if it’s a match or not.
        robertoandred 5y ago
      - lifthrasiir 5y ago
        After more reading of the whitepaper I think you are right. As I understand it, given the image hash H0 and CSAM hashes H[1]...H[n] (some might be duplicates in disguise) the algorithm proceeds like this: - The device generates a secret X and divides it into X[1]...X[m] with the secret sharing algorithm. m is some large number and any k (but no less) copies out of X[i] are enough to reconstruct X. - The device stores blinded hashes f(H[1])...f(H[n]). The function f itself is not known to the client. - The image hash H0 is compressed with another function g to the range between 1 and n. - The downscaled image data (for the human check) is encrypted with X and appended with (probably) random X[i]. - The result is then encrypted again with a key derived from f(H0) and sent to the server with an associated data g(H0). - The server tries to decrypt it with a key derived from f(H[g(H0)]). This is only possible when H[g(H0)] = H0, i.e. H0 represents some known CSAM. - You can only decrypt the second layer with at least k copies of X[i] then. At this stage Apple can still learn the number of CSAM images less than k. The fix is described in an overly technical document and I can't exactly follow, but supposedly the client can inject an appropriate amount of synthetic data where only the first layer can be always decrypted and the second layer is bogus (including the presumed X[i]). --- Assuming this scheme is correctly implemented, the only attack I can imagine is the timing attack. As I understand a malicious client can choose not to send false data. This will affect the number of items that pass the first layer of encryption, so the client can possibly learn the number of actual matches by adjusting the number of synthetic data since the server can only proceed to the next step with at least k such items. This attack seems technically possible, but is probably infeasible to perform (remember that we already need 2^95 oracle operations, which is only vaguely possible even in the local device). Maybe the technical report actually has a solution for this, but for now I can only guess.
        falcolas 5y ago
        That synopsis disagrees with Apple's own descriptions - or rather it goes into the secondary checks, which confuses the issue that the initial hash checks are indeed performed on-device: > Apple’s method of detecting known CSAM is designed with user privacy in mind. Instead of scanning images in the cloud, the system performs on-device matching using a database of known CSAM image hashes provided by NCMEC and other child-safety organizations. Apple further transforms this database into an unreadable set of hashes, which is securely stored on users’ devices. https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni...
  - mannerheim 5y ago
    > Apple’s method of detecting known CSAM is designed with user privacy in mind. Instead of scanning images in the cloud, the system performs on-device matching using a database of known CSAM image hashes provided by NCMEC and other child-safety organizations. Apple further transforms this database into an unreadable set of hashes, which is securely stored on users’ devices. https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni...
    - robertoandred 5y ago
      Yeah, so how would you know something would collide with the hash?
      - mannerheim 5y ago
        Because the hashes are stored on the user's device?
        robertoandred 5y ago
        No, encrypted and blinded hashes are stored. You can’t extract them.
        cyanite 5y ago
        This also means that the device doesn’t know if a given image is a match.
        robertoandred 5y ago
        Correct, only the server does.
        fastball 5y ago
        Right, but your device is checking against the hashes, no? So at some point you generate an image which triggers a subroutine and you know that image collides.
  - HALtheWise 5y ago
    Presumably, someone on the internet will download a dump _actual_ CP and run it through NeuralHash, then post the resulting hashes to GitHub. Doing so will be illegal for them because they are downloading CP, but it should be perfectly legal for you to then download the hashes they posted, randomly select one, and generate an innocuous image that matches it. The fact that Apple isn't posting hashes doesn't actually make it all that hard to get your hands on them.
floatingatoll 5y ago
It’s incredibly stupid because your Apple ID will get terminated for abusing Apple services.
- falcolas 5y ago
  There are applications which automatically save images sent to you to your camera roll (such as Whatsapp, IIRC). How can Apple prove you put them there intentionally? Granted, they most likely won't care, but it's a legitimate attack vector.
  - floatingatoll 5y ago
    You’re right that it’s a valid attack upon the people Apple pays to review matched images before invoking law enforcement, but no harm comes to the recipient in that model, unless they receive real legitimate CSAM and don’t report it to the authorities themselves. Attempted entrapment and abuse of computing systems, which is an uncomfortable way to phrase the WhatsApp scenario, would be quite sufficient cause for a discovery warrant to have WhatsApp reveal the sender’s identity to Apple. Doesn’t mean they’d be found guilty, but WhatsApp will fold a lot sooner than Apple, especially if the warrant is sealed by the court to prevent the sender from deleting any CSAM in their possession. A hacker would say that’s all contrived nonsense and anyways it’s just SWATting, that’s no big deal. A judge would say that’s a reasonable balance of protecting the sender from being dragged through the mud in the press before being indicted and permitting the abused party (Apple) to pursue a conviction and damages. I am not your lawyer, this is not legal advice, etc.

mannerheim 5y ago

You don't need to do that, just use images that collide with the hashes.

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
robertoandred 5y ago
How will you know something collides?
- falcolas 5y ago
  Because the algorithm and list will be on your phone, and can (has, per TFA) be extracted.
  - robertoandred 5y ago
    You cannot extract or reverse the CSAM hashes. They've been encrypted and blinded using server-side-only keys. If TFA said that, it's lying.
    - falcolas 5y ago
      One does not need to reverse the CSAM hashes to find a collision with a hash. If the evaluation is being done on the phone, including identifying a hash match, the hashes must also be on the phone.
      - mannerheim 5y ago
        I believe the hash comparisons are made on Apple's end. Then the only way to get hashes will be a data breach on Apple's end (unlikely but not impossible) or generating it from known CSAM material.
        falcolas 5y ago
        That's not what Apple's plans state. The comparisons are done on phone, and are only escalated to Apple if there are more than N hash matches, at which point they are supposedly reviewed by Apple employees/contractors. Otherwise, they'd just keep doing it on the material that's actually uploaded.
        mannerheim 5y ago
        Ah, never mind, you're right: > Apple’s method of detecting known CSAM is designed with user privacy in mind. Instead of scanning images in the cloud, the system performs on-device matching using a database of known CSAM image hashes provided by NCMEC and other child-safety organizations. Apple further transforms this database into an unreadable set of hashes, which is securely stored on users’ devices. https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni...
        cyanite 5y ago
        He is not right, though. The system used will not reveal matches to the device, only to the server and only if the threshold is reached.
        cyanite 5y ago
        > That's not what Apple's plans state. The comparisons are done on phone Yes but as stated in the technical description, this match is against a blinded table, so the device doesn’t learn if it’s a match or not.
      - robertoandred 5y ago
    - lifthrasiir 5y ago
      After more reading of the whitepaper I think you are right. As I understand it, given the image hash H0 and CSAM hashes H[1]...H[n] (some might be duplicates in disguise) the algorithm proceeds like this: - The device generates a secret X and divides it into X[1]...X[m] with the secret sharing algorithm. m is some large number and any k (but no less) copies out of X[i] are enough to reconstruct X. - The device stores blinded hashes f(H[1])...f(H[n]). The function f itself is not known to the client. - The image hash H0 is compressed with another function g to the range between 1 and n. - The downscaled image data (for the human check) is encrypted with X and appended with (probably) random X[i]. - The result is then encrypted again with a key derived from f(H0) and sent to the server with an associated data g(H0). - The server tries to decrypt it with a key derived from f(H[g(H0)]). This is only possible when H[g(H0)] = H0, i.e. H0 represents some known CSAM. - You can only decrypt the second layer with at least k copies of X[i] then. At this stage Apple can still learn the number of CSAM images less than k. The fix is described in an overly technical document and I can't exactly follow, but supposedly the client can inject an appropriate amount of synthetic data where only the first layer can be always decrypted and the second layer is bogus (including the presumed X[i]). --- Assuming this scheme is correctly implemented, the only attack I can imagine is the timing attack. As I understand a malicious client can choose not to send false data. This will affect the number of items that pass the first layer of encryption, so the client can possibly learn the number of actual matches by adjusting the number of synthetic data since the server can only proceed to the next step with at least k such items. This attack seems technically possible, but is probably infeasible to perform (remember that we already need 2^95 oracle operations, which is only vaguely possible even in the local device). Maybe the technical report actually has a solution for this, but for now I can only guess.
      - falcolas 5y ago
        That synopsis disagrees with Apple's own descriptions - or rather it goes into the secondary checks, which confuses the issue that the initial hash checks are indeed performed on-device: > Apple’s method of detecting known CSAM is designed with user privacy in mind. Instead of scanning images in the cloud, the system performs on-device matching using a database of known CSAM image hashes provided by NCMEC and other child-safety organizations. Apple further transforms this database into an unreadable set of hashes, which is securely stored on users’ devices. https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni...
- mannerheim 5y ago
  > Apple’s method of detecting known CSAM is designed with user privacy in mind. Instead of scanning images in the cloud, the system performs on-device matching using a database of known CSAM image hashes provided by NCMEC and other child-safety organizations. Apple further transforms this database into an unreadable set of hashes, which is securely stored on users’ devices. https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni...
  - robertoandred 5y ago
    Yeah, so how would you know something would collide with the hash?
    - mannerheim 5y ago
      Because the hashes are stored on the user's device?
      - robertoandred 5y ago
        No, encrypted and blinded hashes are stored. You can’t extract them.
        cyanite 5y ago
        This also means that the device doesn’t know if a given image is a match.
        robertoandred 5y ago
        Correct, only the server does.
        fastball 5y ago
        Right, but your device is checking against the hashes, no? So at some point you generate an image which triggers a subroutine and you know that image collides.
- HALtheWise 5y ago
  Presumably, someone on the internet will download a dump _actual_ CP and run it through NeuralHash, then post the resulting hashes to GitHub. Doing so will be illegal for them because they are downloading CP, but it should be perfectly legal for you to then download the hashes they posted, randomly select one, and generate an innocuous image that matches it. The fact that Apple isn't posting hashes doesn't actually make it all that hard to get your hands on them.

floatingatoll 5y ago

It’s incredibly stupid because your Apple ID will get terminated for abusing Apple services.

falcolas 5y ago
There are applications which automatically save images sent to you to your camera roll (such as Whatsapp, IIRC). How can Apple prove you put them there intentionally? Granted, they most likely won't care, but it's a legitimate attack vector.
- floatingatoll 5y ago
  You’re right that it’s a valid attack upon the people Apple pays to review matched images before invoking law enforcement, but no harm comes to the recipient in that model, unless they receive real legitimate CSAM and don’t report it to the authorities themselves. Attempted entrapment and abuse of computing systems, which is an uncomfortable way to phrase the WhatsApp scenario, would be quite sufficient cause for a discovery warrant to have WhatsApp reveal the sender’s identity to Apple. Doesn’t mean they’d be found guilty, but WhatsApp will fold a lot sooner than Apple, especially if the warrant is sealed by the court to prevent the sender from deleting any CSAM in their possession. A hacker would say that’s all contrived nonsense and anyways it’s just SWATting, that’s no big deal. A judge would say that’s a reasonable balance of protecting the sender from being dragged through the mud in the press before being indicted and permitting the abused party (Apple) to pursue a conviction and damages. I am not your lawyer, this is not legal advice, etc.