GPG signatures do not authenticate filenames

Phabricator Tickets
1

Information

ID: 61
PHID: PHID-TASK-b56lq6ev3nvmsutu64ct
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

Issue:

When using gpg --armor --detach-sign some-file-version-c a file some-file-version-c.asc will be created.

But an adversary position to arbitrarily change file names on a mirror or so could rename it to some-file-version-d and some-file-version-d.asc.

That could trick the verifier into believing having received a more recent version than expected. The adversary could use this to mount rollback [1] (downgrade) or indefinite freeze [2] attacks.

Research:

The Tor Project (TPO) similar track ticket - GPG signatures do not authenticate filenames:

asked on gnupg-users mailing list - How to sign the name of the name as well, not just the file?
http://lists.gnupg.org/pipermail/gnupg-users/2015-January/052185.html

Possible solution: OpenPGP notations

We could use OpenPGP notations as I asked on the gnupg-users mailing list:
http://lists.gnupg.org/pipermail/gnupg-users/2015-January/052191.html

Try this:

echo "test" > x
gpg --armor --set-notation file@name="x" --detach-sign x
gpg --armor --verify-options show-notations --verify x.asc

Example output:

~ $ echo "test" > x
~ $ gpg --armor --set-notation file@name="x" --detach-sign x

You need a passphrase to unlock the secret key for
user: "Patrick Schleizer <adrelanos@riseup.net>"
4096-bit RSA key, ID 77BB3C48, created 2014-01-16 (main key ID 2EEACCDA)

~ $ gpg --armor --verify-options show-notations --verify x.asc
gpg: Signature made Mon 12 Jan 2015 11:13:19 PM UTC using RSA key ID 77BB3C48
gpg: Good signature from "Patrick Schleizer <adrelanos@riseup.net>" [ultimate]
gpg: Signature notation: issuer-fpr@notations.openpgp.fifthhorseman.net=6E979B28A6F37C43BE30AFA1CB8D50BB77BB3C48
gpg: Signature notation: file@name=x
~ $

The first gpg command could be added to the sign_images Whonix maintainer script to easily add this notation:
https://github.com/Whonix/whonix-developer-meta-files/blob/master/release/sign_images

Then we could tell users in documentation to use --verify-options show-notations and therefore check the file name has not been tampered with.

Other possible solutions:

  • creating a sha512sums file and signing that one - more cumbersome to download and verify
  • using tar and a versioned sub folder - cumbersome for .ova images - folder name easily overlooked

Comments

Patrick

2015-01-12 23:37:35 UTC

Patrick

2015-02-04 02:18:25 UTC