Mailing List Archive

"Mark H. Wood via Gnupg-users" <gnupg-users@gnupg.org> writes:

> I didn't know where else to turn, for folks who might be able to point
> me at standards for or discussion of embedding crypto signatures in
> image formats, to detect tampering with the image.

While you can technically embed some kind of signature in pretty much
any image format's XMP or EXIF metadata (and some cameras do), the only
graphic format with a reasonably well-defined and supported signature
scheme is probably PDF.

Unfortunately PDF's complex structure makes correct implementation
difficult and most vendors (including Adobe) have had numerous issues:
https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1B-4_24117_paper.pdf

You may be interested in the Adobe et al. Content Authenticity
Initiative, though that scheme's compatibility with open-source software
seems dubious.

-Valtteri

On 2021-09-08 4:53 p.m., Mark H. Wood via Gnupg-users -
gnupg-users@gnupg.org wrote:
> I didn't know where else to turn, for folks who might be able to point
> me at standards for or discussion of embedding crypto signatures in
> image formats, to detect tampering with the image.

There are no standards that I have ever heard about that would
be specific to ~image~ files; so I would ask this:

Which particular image file type are you interested in (.jpg,
.tiff, .png, .bmp, .psd...) are you interested in, and why is it
not appropriate to simply consider such file as another binary
file that someone needs to digitally sign?


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Thu, Sep 09, 2021 at 10:43:05AM +0000, Oli Kon via Gnupg-users wrote:
> On 2021-09-08 4:53 p.m., Mark H. Wood via Gnupg-users -
> gnupg-users@gnupg.org wrote:
> > I didn't know where else to turn, for folks who might be able to point
> > me at standards for or discussion of embedding crypto signatures in
> > image formats, to detect tampering with the image.
>
> There are no standards that I have ever heard about that would
> be specific to ~image~ files; so I would ask this:
>
> Which particular image file type are you interested in (.jpg,
> .tiff, .png, .bmp, .psd...) are you interested in, and why is it
> not appropriate to simply consider such file as another binary
> file that someone needs to digitally sign?

Formats: first of all .jpg, but really any image format that can bear
signature data.

Why are image files special? They aren't. For every type of
structured file, one must consider the structure of the file type in
order to insert a signature without disrupting the other content, to
identify the content which should be covered by the signature, and to
locate the signature data.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

Years ago, I think Canon offered some kind of in-camera file format that supposedly could prove that the file had not been tampered with. Eventually exploits were found that rendered it unreliable. https://hk.canon/en/support/to-users-of-the-original-data-security-kit-osk-e3-original-data-verification-kit-dvk-e1-or-dvk-e2-accessories-for-digital-slr-cameras/notice I suppose if you were going to engineer a spec like that today you'd have each camera have it's own key that it used (maybe alongside a baked-in manufacturer key) to sign the relevant guts of RAW files of each shot it took. But this would really only be useful in a true forensics type situation, as most photographers end up editing and altering photos with programs like Lightroom before they call them "done".


As it is, most of the time people look for image tampering not through signatures but rather by looking for telltale signs of the artifacts left behind by common forms of tampering. https://belkasoft.com/forgery-detection

-Ryan McGinnis

ryan@digicana.com

http://bigstormpicture.com

5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD

??????? Original Message ???????

On Thursday, September 9th, 2021 at 5:43 AM, Oli Kon via Gnupg-users <gnupg-users@gnupg.org> wrote:

> On 2021-09-08 4:53 p.m., Mark H. Wood via Gnupg-users -
>

> gnupg-users@gnupg.org wrote:
>

> > I didn't know where else to turn, for folks who might be able to point
> >

> > me at standards for or discussion of embedding crypto signatures in
> >

> > image formats, to detect tampering with the image.
>

> There are no standards that I have ever heard about that would
>

> be specific to ~image~ files; so I would ask this:
>

> Which particular image file type are you interested in (.jpg,
>

> .tiff, .png, .bmp, .psd...) are you interested in, and why is it
>

> not appropriate to simply consider such file as another binary
>

> file that someone needs to digitally sign?
>

> Gnupg-users mailing list
>

> Gnupg-users@gnupg.org
>

> http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 2021-09-10 8:00 p.m., Ryan McGinnis via Gnupg-users -
gnupg-users@gnupg.org wrote:
> Years ago, I think Canon offered some kind of in-camera file format
> that supposedly could prove that the file had not been tampered with.

We appear to be talking about two different things here. Both Nikon
and Canon had developed a system which, purportedly, guaranteed that
an image file represented "a reality, as the camera has seen it".
This is no more possible than constructing a ~perpetum mobile~, for
no matter what the in-camera software and hardware did, the lens
could be simply pointed to a synthetic image that is a faked reality,
and camera would be none the wiser. By that naive logic, we could
point the lens at the Botticelli's painting and camera would produce
a cryptgraphically signed file that guaranteed that the photographer
was present when Venus was born. Both Nikon and Canon quickly
realized the error of their ways and quietly dropped the whole idea.

Is is a completely different thing for an owner of a private
cryptographic key to sign a file, and clearly state what it is that
he or she guarantees. That is a trivial process but it requires
three things: a clear statement of what is it that the file signer
guarantees, a secure conveyance of matching public key into the hands
of the image user and a detached or "baked-into-file" signature.

Since all three things are required, I see no significant advantage
of an in-file (as opposed to a detached) signature.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Mark H. Wood wrote:

> I didn't know where else to turn, for folks who might be able to point
> me at standards for or discussion of embedding crypto signatures in
> image formats, to detect tampering with the image.

I do not know any, but like to add my POV. Let's say GnuPG could
digitally sign a .png image, i.e. inserting the signature
steganographically
in the image and later a user could verify the steganographically
embedbed
signature. What happens if Eve uses Photoshop and does a slightly image
correcting and re-saves the image? It would IMHO give a user then
an invalid signature or none.

Sending images over the Internet, say from an authorized photostudio
(passport photos etc.) can only be savely transmitted (openly) IMHO if
the photostudio would embedd the image in an, for example, digitally
signed .pdf, containing an eIDAS[1] signature, guaranteeing globally
that the image in the .pdf was signed by an authorized photosudio and
not manipulated by a middleman, while in transfer.

[1] eIDAS is the Digital Signature Standard in the EU for .pdf
documents,
which can be verified with the free Adobe Reader.

Regards
Stefan




_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

No, I think what Canon and Nikon attempted to implement was something that, when paired with a validation software, would say with certainty "this is exactly what the camera wrote to the card". It wasn't saying anything about whether what was being photographed was real or faked, merely that after the image file was written it wasn't tampered with. It's a chain of custody thing. Sorta like signing software -- the signature doesn't mean the software isn't a Trojan, it just means that the software has been signed by whatever key it was signed by, and you decide what that signature means to you.

Unfortunately they never really got the standard down, which is kinda funny since it's the kind of thing that can almost certainly be done. I guess there just wasn't much of a market for it. (Probably because altering photos undetectably is very hard to do -- you don't need digital signatures to see that the DA used the clone tool to put the gun in the killer's hand)

-Ryan McGinnis

ryan@digicana.com

http://bigstormpicture.com

5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD

??????? Original Message ???????

On Saturday, September 11th, 2021 at 2:53 PM, Oli Kon via Gnupg-users <gnupg-users@gnupg.org> wrote:

> On 2021-09-10 8:00 p.m., Ryan McGinnis via Gnupg-users -
>

> gnupg-users@gnupg.org wrote:
>

> > Years ago, I think Canon offered some kind of in-camera file format
> >

> > that supposedly could prove that the file had not been tampered with.
>

> We appear to be talking about two different things here. Both Nikon
>

> and Canon had developed a system which, purportedly, guaranteed that
>

> an image file represented "a reality, as the camera has seen it".
>

> This is no more possible than constructing a ~perpetum mobile~, for
>

> no matter what the in-camera software and hardware did, the lens
>

> could be simply pointed to a synthetic image that is a faked reality,
>

> and camera would be none the wiser. By that naive logic, we could
>

> point the lens at the Botticelli's painting and camera would produce
>

> a cryptgraphically signed file that guaranteed that the photographer
>

> was present when Venus was born. Both Nikon and Canon quickly
>

> realized the error of their ways and quietly dropped the whole idea.
>

> Is is a completely different thing for an owner of a private
>

> cryptographic key to sign a file, and clearly state what it is that
>

> he or she guarantees. That is a trivial process but it requires
>

> three things: a clear statement of what is it that the file signer
>

> guarantees, a secure conveyance of matching public key into the hands
>

> of the image user and a detached or "baked-into-file" signature.
>

> Since all three things are required, I see no significant advantage
>

> of an in-file (as opposed to a detached) signature.
>

> Gnupg-users mailing list
>

> Gnupg-users@gnupg.org
>

> http://lists.gnupg.org/mailman/listinfo/gnupg-users