Verifying repository data
I have downloaded the repository data from pkg.pfsense.org but am unable to verify the validity of the signature using openssl.
I have tried openssl sha256 -verify digests.pub -signature digests.sig digests
I get the error Verification Failed
I also tried openssl rsautl -pubin -inkey digests.pub -verify -in digests.sig -asn1parse
I get an output of a signed sha256 hash but the hash doesn't match the output of sha256sum digests
Should I be using a different tool for verification? How are the signatures actually generated? There is very little documentation on how signing works when using an external signing server as pfsense does. I found this
It says the command to sign repository data is "ssh email@example.com sudo ./sign.sh" Unfortunately the source code for "sign.sh" doesn't seem to be available.
This should be all for 'sign.sh': https://github.com/freebsd/pkg/blob/master/scripts/sign.sh
#!/bin/sh # Example signing script. See pkg-repo(8) for more information. set -e read -t 2 sum [ -z "$sum" ] && exit 1 echo SIGNATURE echo -n "$sum" | /usr/bin/openssl dgst -sign repo.key -sha256 -binary echo echo CERT cat repo.pub echo END
If openssl is used to make a sha256 digest then it should also work to verify the same. I can't think of a good reason why it should have given a verification error other than the checksum failed. Am I overlooking something? Maybe I should bring this to the attention of the security team. Can you check to see if verification fails for you also?
The command "openssl sha256 -verify digests.pub -signature digests.sig digests" should be identical to
"openssl dgst -verify digests.pub -sha256 -signature digests.sig digests"
Looks good to me.
: egrep '(signature|fingerprints)' /usr/local/etc/pkg/repos/pfSense.conf | sort | uniq fingerprints: "/usr/local/share/pfSense/keys/pkg", signature_type: "fingerprints", : ls -l /usr/local/share/pfSense/keys/pkg total 1 drwxr-xr-x 2 root wheel 2 Sep 6 09:35 revoked drwxr-xr-x 2 root wheel 4 Sep 6 09:35 trusted : ls -l /usr/local/share/pfSense/keys/pkg/trusted total 9 -rw-r--r-- 1 root wheel 95 Aug 23 09:38 beta.pfsense.org.20151223 -rw-r--r-- 1 root wheel 95 Aug 23 09:38 pkg.pfsense.org.20160406 : cat /usr/local/share/pfSense/keys/pkg/trusted/pkg.pfsense.org.20160406 function: sha256 fingerprint: 30be9cc2e7b2b3ba1ff3b2be1795f3f0719ab9a65322695703dc7b8f004035a8 : fetch https://files00.netgate.com/pfSense_v2_4_0_amd64-core/digests.txz digests.txz 100% of 1516 B 11 MBps 00m00s : tar xvzf digests.txz x digests.sig x digests.pub x digests : openssl sha256 digests.pub SHA256(digests.pub)= 30be9cc2e7b2b3ba1ff3b2be1795f3f0719ab9a65322695703dc7b8f004035a8
That's for CE, factory has a different URL/digest/fingerprint.
Yeah, verifying the sha256 sum of the public key is an important step but so is verifying the sha256 sum and signature of the actual signed data.
My understanding of the chain of trust is that the "fingerprint" ie sha256 sum of the public key used for signing is included in the distribution. That's step 1.
Step 2 is using the public key to verify the signature, digests.sig. That's what the command
"openssl rsautl -pubin -inkey digests.pub -verify -in digests.sig -asn1parse"
did. The fact that it returned an asn1 encoded sha256 hash tells me the signature was valid. The problem arises with step 3.
Step 3 is verifying the asn1 encoded hash matches the sha256 sum of the actual digests file. That's where the mismatch occurs.
See this link.