0

I plan to issue software updates to offline machines via USB sticks.
Machies will be dispatched, and on site for potentially many years,
During that time, new developers will be hired and fired.

I plan to use GnuPG to check the updates on the USB stick before installing them.

There will be a master key, and each developer will be given their own developer key.

The developer keys will be signed by the master key. The deployed machines will trust fully the master key. However, the deployed machines will not have all of the developer keys.

How can I make the deployed machines understand that they can trust packages signed with unknown keys, If those unknown keys are signed by the fully-trusted master key??

In my tests, gpg --verify package.tar.gz.sig fails because the public key is NOT known.

In order to get gpg --verify to accept the key, I must first gpg --import developer_123.key.

But that does not check that the new key was signed by the trusted master!

I can create a new rogue_developer key, not signed by the trusted master, import that, then gpg --verify will authenticate the package.

I think im am misunderstanding a fundamental understanding of how this process should work?

Should I...
1) Allow all developers to sign with the master key ( bad idea, the key will be leaked, and i will not be able to revoke it without re-caling deployed machines!)
2) Bundle the exported developer key with the USB update.
But then how do i check that it was signed by the master before importing it ?
3) If there a way of validating that the package was signed by a key that was signed by my trusted master without having to import that key?
4) Something else I'be not thought of ?

Im sure I am mis-understanding something... As T thought that making master trusted fully was supposed to mean that we also validate keys that were signed by that trusted key?
But how does that process work ?

Thanks for any pointers!

Chris.

EDIT:
I have created for testing, a real developer ( DVKey ) and a rogue attacker ( ROKey ).
DVKey is signed by the master key, which is trusted fully. ROKey is NOT signed by the master key. When verifying a package signed by the DVKey, i get

[cds@notebook ~]$ gpg --homedir FMHOME --verify ArchLinuxARM-rpi-2-latest.tar.gz.sig
gpg: assuming signed data in 'ArchLinuxARM-rpi-2-latest.tar.gz'
gpg: Signature made Wed 18 Nov 2015 21:15:55 GMT using RSA key ID B90C2061
gpg: Good signature from "DVKey " [full]
[cds@notebook ~]$ echo $?
0

Note that gpg returned '0', success.

When I verify the rogue package, I get

[cds@notebook ~]$ gpg --homedir FMHOME --verify Untitled.log.sig
gpg: assuming signed data in 'Untitled.log'
gpg: Signature made Wed 18 Nov 2015 21:23:03 GMT using RSA key ID EEF5033E
gpg: Good signature from "ROKey " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C00D C1EE 4670 2FE9 4B8D D03E 4DC6 8D9C EEF5 033E
[cds@notebook ~]$ echo $?
0

Note that i got a warning! but gpg still returned '0', success. I need the lack of a trusted signature to be a FAILURE to verify.

Again, THANKS.

0

Answering my own question.

I could not find a good way of determining the trust level with gpg alone.

I wrote a small c program. I'll link it here if anyone is interested.
https://github.com/chris-stones/gpg-verify-trust

compile with gcc "src/gpg-verify-trust.c -lgpgme -o verify_trust".
depends on the gpgme headers / libraries.

returns 0 for no trust
returns 1 for marginal trust
returns 2 for full trust
returns 3 for ultimate trust
any other return value indicates error.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.