Verifying repository data

bigguy_

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
https://github.com/pfsense/pfsense/blob/master/tools/builder_defaults.sh

It says the command to sign repository data is "ssh sign@codesigner.netgate.com sudo ./sign.sh" Unfortunately the source code for "sign.sh" doesn't seem to be available.

PiBa

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

bigguy_

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"

jimp

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.

bigguy_

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.
https://lists.freebsd.org/pipermail/freebsd-ports/2014-February/089751.html