C2PA from the Attacker's Perspective(hackerfactor.com)
hackerfactor.com
C2PA from the Attacker's Perspective
https://www.hackerfactor.com/blog/index.php?/archives/1031-C2PA-from-the-Attackers-Perspective.html
2 comments
>Now, change this string to something within the date range. For the demo, I backdated it by two months, to March 11: "20240311143900Z". Save the file and upload Gorilla-edit.jpeg to Content Credentials. Poof! The authoritative cryptographic signature says it was created two months earlier. C2PA says there is no indication of tampering.
wtf? It looks like either the date itself isn't signed, or that the validation service doesn't bother validating the date is signed? Later on it says
>This isn't a code problem, this is a standards definition issue.
But it's not clear why the timestamp can't be validated. The timestamping infrastructure used for Windows authenticode signatures seem to work fine. Why can't the C2PA get their timestamping scheme to work?
wtf? It looks like either the date itself isn't signed, or that the validation service doesn't bother validating the date is signed? Later on it says
>This isn't a code problem, this is a standards definition issue.
But it's not clear why the timestamp can't be validated. The timestamping infrastructure used for Windows authenticode signatures seem to work fine. Why can't the C2PA get their timestamping scheme to work?
BTW I guess 'watermarks' can be easily scrambled; add noise, filters, &/or recompress into another image format (eg JPEG -> AVIF).