* [bitcoin-dev] New Bitcoin Core macOS signing key
@ 2018-01-12 5:04 Cory Fields
2018-01-12 8:54 ` Peter Todd
0 siblings, 1 reply; 4+ messages in thread
From: Cory Fields @ 2018-01-12 5:04 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5659 bytes --]
Hi all
As discussed in a few of the last weekly meetings, Bitcoin Core's
macOS code signing certificate expired today.
We are (Greg is ;) in the process of establishing a new threshold
signing scheme that will allow us to handle code signing without any
single point of failure. But until then, releases will be signed as
before, just with a new certificate.
As a matter of record, I used the old code-signing key/certificate to
sign a message containing the pubkey that matches the new
key/certificate. It's attached at the end of this message.
The pkcs7 format is rather clunky, but I wanted to include the current
signing certificate to make verification easier. I'll leave it to the
reader to extract the certificate from a previous release in order to
make sure that they match. It was also in the Core git repo until it
was removed recently.
To verify, you can use something like:
openssl smime -verify -in sig.pkcs7 -inform pem -ignore_critical -purpose any
- "ignore_critical" setting tells openssl to ignore the Apple-specific
critical extensions that it doesn't understand.
- "-purpose any" allows the "purpose == smimesign" check to be
skipped. This would otherwise fail because this certificate is only
authorized to sign code, not arbitrary messages.
By now, the signature will probably fail to validate because the
certificate has expired.
The signed message below is timestamped on the Bitcoin blockchain
using OpenTimestamps. See the attached ots file containing the
timestamp proof. If the attachment gets scrubbed and doesn't make it
to the list, don't be afraid to nag Peter Todd about a mail-friendly
format for these proofs :)
Regards,
Cory
expire.txt.sig:
-----BEGIN PKCS7-----
MIILTwYJKoZIhvcNAQcCoIILQDCCCzwCAQExCzAJBgUrDgMCGgUAMIIDNAYJKoZI
hvcNAQcBoIIDJQSCAyFUaGUgY3VycmVudCBCaXRjb2luIENvcmUgbWFjT1MgY29k
ZSBzaWduaW5nIGNlcnRpZmljYXRlIGV4cGlyZXMNCmxhdGVyIHRvZGF5LCBKYW51
YXJ5IDExLCAyMDE4Lg0KDQpJbiB0aGUgZnV0dXJlLCBhIHRocmVzaG9sZCBzaWdu
YXR1cmUgd2lsbCBiZSB1c2VkIHRvIHNpZ24gbWFjT1MNCnJlbGVhc2VzLCBidXQg
c2luY2UgdGhpcyB3YXMgbm90IHJlYWR5IGluIHRpbWUsIGEgdGVtcG9yYXJ5DQpj
ZXJ0aWZpY2F0ZSB3aWxsIGxpa2VseSBiZSB1c2VkIGZvciB0aGUgMC4xNiByZWxl
YXNlLg0KDQpUaGUgcHVibGljIGtleSB0byBiZSB1c2VkIHdpdGggdGhpcyBuZXcg
Y2VydGlmaWNhdGUgaXM6DQoNCi0tLS0tQkVHSU4gUFVCTElDIEtFWS0tLS0tDQpN
SUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXF4aWJE
Z2pBT09WVXBTY3pVMnBqDQp0UEVpQ0lZeXl2V21EN2VidGhQbzI5WG9xMUJqYWJG
NDlCZ3diNkZFaU1haFN5UTY4ZklMSUhDanJ5SUo4RUN1DQpROFJWbVF3cGdhKzV0
OTZiMEM5emN5WTFhcSsrRzIyMVNqNmFpUmVveXZwcHIrZ2poNmNPbktEc1B0Z2pU
cGdiDQovOUhuMmtwYzFmZ000ZkRFMlQ2VXZHVHMwd3d5dWNvL21ya0s1LzEySCtq
ZUE3QXVNcjBLQTBVSktSS1VOenFhDQo4QjlLalFFektaRGVVVHRYak9vSmIyNkRQ
U3hCbXBGd25zWSs2aHBjeFZSSmphNG1FYzRFYnIyb2gxSmVORU5uDQp4WXR3MHRW
VWczTUwvWlI2WU9qQVpMY0V0cW5IR2ZOZXVRazJXVm1pYy9JY3d4VEM0cUk4MnFR
OGgxQnFpY3pRDQo4UUlEQVFBQg0KLS0tLS1FTkQgUFVCTElDIEtFWS0tLS0tDQqg
ggWLMIIFhzCCBG+gAwIBAgIIJ0r1rumyfZAwDQYJKoZIhvcNAQELBQAweTEtMCsG
A1UEAwwkRGV2ZWxvcGVyIElEIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYwJAYD
VQQLDB1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTETMBEGA1UECgwKQXBw
bGUgSW5jLjELMAkGA1UEBhMCVVMwHhcNMTMwMTEwMjIzOTAxWhcNMTgwMTExMjIz
OTAxWjCBqDEaMBgGCgmSJomT8ixkAQEMClBCVjRHTFM5SjQxQDA+BgNVBAMMN0Rl
dmVsb3BlciBJRCBBcHBsaWNhdGlvbjogQklUQ09JTiBGT1VOREFUSU9OLCBJTkMu
LCBUSEUxEzARBgNVBAsMClBCVjRHTFM5SjQxJjAkBgNVBAoMHUJJVENPSU4gRk9V
TkRBVElPTiwgSU5DLiwgVEhFMQswCQYDVQQGEwJVUzCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBALTd5zURuZVoJviusr119aktXksenb9IN9vq6kBbq38v
xEk79wkKMES2XfBRh0HxcEizGzhMNy5OCXuTLMaNMihYdfwYSoBoR2foEU+6kjPU
nyJ4dQBFLJZJr5/QeQmALmYHEgZ6lwXFD2lU8t92340zeJ4y5LZw5pcEHtH9Iumm
YDutOGCkCGXDcjL+5nHhNScJiXHhswM+62o6XXsQiP6EWbM1CsgrGTNLtaa0U/Uv
VDwE79YKklSC5Bog2LD0jBcTuveI66mFzqu++L9X9u+ZArtebwCl7BPNQ+uboYy5
uV2dzf8lpNNZLfXCFjoLe9bLICKfZ7ub9V5aC8+GhckCAwEAAaOCAeEwggHdMD4G
CCsGAQUFBwEBBDIwMDAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuYXBwbGUuY29t
L29jc3AtZGV2aWQwMTAdBgNVHQ4EFgQUa5xsqKVzcHDiV6NJ2GL7l8elXV4wDAYD
VR0TAQH/BAIwADAfBgNVHSMEGDAWgBRXF+2iz9x8mKEQ4Py+hy0s8uMXVDCCAQ4G
A1UdIASCAQUwggEBMIH+BgkqhkiG92NkBQEwgfAwKAYIKwYBBQUHAgEWHGh0dHA6
Ly93d3cuYXBwbGUuY29tL2FwcGxlY2EwgcMGCCsGAQUFBwICMIG2DIGzUmVsaWFu
Y2Ugb24gdGhpcyBjZXJ0aWZpY2F0ZSBieSBhbnkgcGFydHkgYXNzdW1lcyBhY2Nl
cHRhbmNlIG9mIHRoZSB0aGVuIGFwcGxpY2FibGUgc3RhbmRhcmQgdGVybXMgYW5k
IGNvbmRpdGlvbnMgb2YgdXNlLCBjZXJ0aWZpY2F0ZSBwb2xpY3kgYW5kIGNlcnRp
ZmljYXRpb24gcHJhY3RpY2Ugc3RhdGVtZW50cy4wDgYDVR0PAQH/BAQDAgeAMBYG
A1UdJQEB/wQMMAoGCCsGAQUFBwMDMBMGCiqGSIb3Y2QGAQ0BAf8EAgUAMA0GCSqG
SIb3DQEBCwUAA4IBAQAfJ0BjID/1dS2aEeVyhAzPzCBjG8vm0gDf+/qfwRn3+yWe
L9vSnMdbilwM48IyQWTagjGGcojbsAd/vE4N7NhQyHInoCllNoeor1I5xx+blTaG
RBK+dDhJbbdlGCjsLnH/BczGZi5fyEJds9lUIrp1hJidRcUKO76qb/9gc6qNZpl1
vH5klDUuJYt7YhAs+L6rTXDyqcK9maeQr0gaOPsRRAQLLwiQCorPeMTUNsbVMdMw
ZYJsR+PxiAnk+nyi7rfiFvPoASAYUuI6OzYL/Fa6QU4/gYyPgic944QYVkaQBnc0
vEP1nXq6LGKwgVGcqJnkr/E2kui5gJoV5C3qll3eMYICYTCCAl0CAQEwgYUweTEt
MCsGA1UEAwwkRGV2ZWxvcGVyIElEIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYw
JAYDVQQLDB1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTETMBEGA1UECgwK
QXBwbGUgSW5jLjELMAkGA1UEBhMCVVMCCCdK9a7psn2QMAkGBSsOAwIaBQCggbEw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMTEx
MTgxMDUwWjAjBgkqhkiG9w0BCQQxFgQUvqCmkSFwZTLWSNhIddUfdxBPQSswUgYJ
KoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAE
ggEAQadtQ5qePkjvB3xqLeSvN3e6SpoGQGn6Oo57IiUs/9zP3LAziS2pLbOxSlrS
WWJ5byt7qHdxg9Hi+8IRK5ppps3TxX49ZtN9xHR0BQECspHhbad++JnLuCVjoW88
tgX6NylWb16xekpKA9D1xsLOaVlxFJry4S9k3wz53ajg7J83jlA5K1j9rcS8dVhZ
WjIl12I2AalQ//PXVyu1soF7ieKgyFKeOefGaAOT3ybji1ibYoPfsS/IdnBz7hbn
EmHUHDdl2R+TWDf0ADXMqV3qjMuG5osFRUJbeWm5CUne1/w2BdcIkmkvfmzU+Bmh
jixGT1Xg83O4e3LL4Bww0rRY6w==
-----END PKCS7-----
[-- Attachment #2: expire.txt.sig.ots --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet-template, Size: 1740 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] New Bitcoin Core macOS signing key
2018-01-12 5:04 [bitcoin-dev] New Bitcoin Core macOS signing key Cory Fields
@ 2018-01-12 8:54 ` Peter Todd
2018-01-12 10:14 ` nullius
0 siblings, 1 reply; 4+ messages in thread
From: Peter Todd @ 2018-01-12 8:54 UTC (permalink / raw)
To: Cory Fields, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6286 bytes --]
On Fri, Jan 12, 2018 at 12:04:44AM -0500, Cory Fields via bitcoin-dev wrote:
> To verify, you can use something like:
> openssl smime -verify -in sig.pkcs7 -inform pem -ignore_critical -purpose any
>
> - "ignore_critical" setting tells openssl to ignore the Apple-specific
> critical extensions that it doesn't understand.
> - "-purpose any" allows the "purpose == smimesign" check to be
> skipped. This would otherwise fail because this certificate is only
> authorized to sign code, not arbitrary messages.
>
> By now, the signature will probably fail to validate because the
> certificate has expired.
Note that you may need to add -noverify as well if your openssl doesn't have
the Apple Certificate Authority in the CA list.
While a clunky way to do it, you can use the `-signer` option to tell OpenSSL
to write the signer's certificate to a file. That certificate can then be
compared to the one from the repo, which was still in the repo as of the
(signed!) v0.15.1 tag.
Fun fact: OpenTimestamps has git integration, which means you can extract a OTS
proof from 2016 for that certificate from the repo:
$ git checkout v0.15.1
$ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem share/certs/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b8236775e4
$ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots
Assuming target filename is 'share/certs/BitcoinFoundation_Apple_Cert.pem'
Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016 EDT
Homework problem: write a paragraph explaining how the proof generated by the
above three commands are crypto snakeoil that proved little. :)
> The signed message below is timestamped on the Bitcoin blockchain
> using OpenTimestamps. See the attached ots file containing the
> timestamp proof. If the attachment gets scrubbed and doesn't make it
> to the list, don't be afraid to nag Peter Todd about a mail-friendly
> format for these proofs :)
Ha! Fortunately even the mailing list archives at lists.linuxfoundation.org
seem to contain the attachment just fine.
But anyway, I'd suggest using base64:
AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/ieLohOiSlAEITeD8FWBXd613LkHPt3JyrZBKamczrmmf
NLwSJohkYfDwEB35DezwYGb4KePty9TSWRcI//AQjTiBNRdo5I7oIeLjkGhQuAjxBFpXqSbwCN+N
8xIdwxQG/wCD3+MNLvkMji4taHR0cHM6Ly9hbGljZS5idGMuY2FsZW5kYXIub3BlbnRpbWVzdGFt
cHMub3JnCPEgijKAmyu82BuY9WL4Ags9TuzOph/XJBC6zUYZNW2Kv14I8SDyd3rD94qsLgkTPUlF
nA3SbabHilzJcHkrlGbYL+MaBgjxINCDuse4CSogHVUKQ9WaRrYkExs8PMx8O11OoVhj5ydJCPAg
y3ZstDNn/6b32WO12ZprF9zhb6VfGUl9spxU5k5eirgI8SBwa20AdPHR6oLcSdnogmPmUpWEd+n1
ky2dhWKvqZwJ/AjwIBYprQWyepSdvr1Ber0DD1eP66d4l1+138SZw7/fIflPCPAgTXOIKaeMbmNj
oO6Q/6SoX7ksCKOjkt284KYyI/ELaVgI8VkBAAAAAc1gOrgz+6mCizItuiE8bQ4foKYwCz0sB9lG
7gj/kK9fAAAAAAD9////Ag9aLAAAAAAAFgAU4gDd5F6wUprr6G4WBg+5sQkAi1YAAAAAAAAAACJq
IPAEuq8HAAgI8SAQbNEWckYQhxlLHC1aYxnyzHgxatOXQCOkQGgXe7CV7wgI8SDvEAaFSJ6unpLU
CvJzUpe2ISKMquT7kvQlvOam3SbgdggI8SBKKOTuNlh0TqP0wxy+BvCN8HgXFj/CQvJm/r9061dC
XggI8CBjdeDoADpZAb6CHjryDthP/BPcKVcMNiu+KAHIfgdDfAgI8CBuq4+F9RGpuGjFp7YU0WyH
mohtNWCv1oiDAvm6TAZeXAgI8CCI0tiLN7YMP2HtPKIm72bDi6OoFduzG0TQ1n7hEjEvvQgI8CBm
oIe62AVnwyFp6mZ37TuP0JsBHuazibGEgBKgB2xSTAgI8CDbi0srCkqentfGfk+HgBPLllDWN/mU
p4HsOQBoiDB3HwgI8SBpOitFwKhqpvNNL2SzSAxmCDIRpIpq+Kp5x774ovXexggI8SAtBMNMgP/r
L2MztJ9H43LYDRM3jGt8mbbG4Ji2+5z1rQgI8CAoVuz4NodKzCGU5c0hdBWon6T7TuMN5lA1IIOB
UF+5+QgIAAWIlg1z1xkBA7vfHvAQ5vjVlfmkli0Jsy9r6Zl5EAjxBFpXqSXwCGWEIRA/ovvQ/wCD
3+MNLvkMjiwraHR0cHM6Ly9ib2IuYnRjLmNhbGVuZGFyLm9wZW50aW1lc3RhbXBzLm9yZwjxIPEX
gnzr8J36EGTnlaF/N3bvWi0cmhlkt1b/TVIBZuCHCPEgKqjwAWBXRj1MC6oVZK6P7MBuaB5VnC+S
CpN4pfoQNJcI8CB166rXsYFaNJvQD0b6PvcK02KauHQ0G6h3dyO5NoLE1QjwIOXfM7LRnV2CFLYU
AC6uWB3K28jnM7chsxQiPXQvOmE/CPEgWmgM4iyrpd8Ip/Vs0bPeC1mdH/fgEOO+fLCR0Ae8OH0I
8CAebOJrI00jNjqWLJNxFLZaO4tY69kEKHx6AvrjoQqNzgjxWQEAAAABqY/4nDzgexnxwERsA6RG
QKS4pzagJAciBvkAbejv8mwAAAAAAP3///8CGrg4AAAAAAAWABQNuE08uA4/5oWDRYPWIW0HNrwS
ZgAAAAAAAAAAImog8AS2rwcACAjwIGQuGBXXZjCZPN527NmlDPNE7DY5jznNp8UauCoSRe3UCAjx
IPnKxEUG7HPVIm2RehYqhROpmLrZuPtr4MuMKoX+xTT1CAjwID9qxx7kHhzJrzDeZPXsvaCdQCX3
mVqkyBzlIG/Rz0TPCAjxIFHQruGgLpotZScpYu9Ou9EUmeqmizOmW77hqP04oN5/CAjwIKqKpmbK
V3weRNXWLDAWVcr0bXZndaq6th6b8dy5mjoeCAjwIA2RHHGChLN8t1f7rJJRowlLp1F3XLGD2kqK
k5M3K4c3CAjxIBwP3futX+WjxgkAS0d2TGxiyUoKMFT6bmG2o4zwmz/4CAjwIJmhwnqv64SuTiSQ
atRL1udPduUsJ6qevzrJiiuYaRuSCAjxINEU34ZeVioiqA4bBJJU8HMVlWdyYYXFnZRZ0lsKCJvc
CAjxIPjnINA1faJ/WYxuV0KSUceoHWd4EltavqltfDjTjQhcCAjwIOJixScSNRwwkg68C4HSMeRM
K5YKNh1phfaY3Du/0i68CAgABYiWDXPXGQEDt98e
On Linux, the `base64 -d` command will decode the above just fine.
The _real_ issue is that asking the user to cut-n-paste that PKCS7-encoded
message is problematic, as differences in whitespace and line endings will make
the verification fail. Works fine on Linux, but would probably have failed on
Windows.
What's nice about OpenPGP's "clearsigned" format is how it ignores whitespace;
a replica of that might be a nice thing for OTS to be able to do too. Though
that's on low priority, as there's some tricky design choices(1) to be made about
how to nicely nest clearsigned PGP within OTS.
1) For example, I recently found a security hole related to clearsigned PGP
recently. Basically the issue was that gpg --verify will return true on a file
that looks like the following:
1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a foo-v2.0.tar.gz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 foo-v1.0.tar.gz
-----BEGIN PGP SIGNATURE-----
<snip pgp stuff>
-----END PGP SIGNATURE-----
The system I was auditing then did something like this to verify that the file
was signed:
set -e # exit immediately on error
gpg --verify SHA256SUMS.asc
cat SHA256SUMS.asc | grep foo-v2.0.tar.gz
<do installation>
While it makes it a bit less user friendly, the fact that PKCS7's encoding made
it impossible to see the message you signed until it's been properly verified
is a good thing re: security.
And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh isn't
vulnerable to this mistake. :)
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] New Bitcoin Core macOS signing key
2018-01-12 8:54 ` Peter Todd
@ 2018-01-12 10:14 ` nullius
2018-02-01 1:14 ` Cory Fields
0 siblings, 1 reply; 4+ messages in thread
From: nullius @ 2018-01-12 10:14 UTC (permalink / raw)
To: Peter Todd, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5216 bytes --]
On 2018-01-12 at 08:54:12 +0000, Peter Todd <pete@petertodd•org> wrote:
>While a clunky way to do it, you can use the `-signer` option to tell
>OpenSSL to write the signer's certificate to a file. That certificate
>can then be compared to the one from the repo, which was still in the
>repo as of the (signed!) v0.15.1 tag.
>
>
>Fun fact: OpenTimestamps has git integration, which means you can
>extract a OTS proof from 2016 for that certificate from the repo:
>
> $ git checkout v0.15.1
> $ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem share/certs/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b8236775e4
> $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots
> Assuming target filename is 'share/certs/BitcoinFoundation_Apple_Cert.pem'
> Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016 EDT
>
>Homework problem: write a paragraph explaining how the proof generated
>by the above three commands are crypto snakeoil that proved little. :)
It says, “Bitcoin attests data existed”. Within the scope of those
three commands, I don’t see any proof of who put it there. Does OTS
check the PGP signatures on *commits* when it does that `git-extract`?
The signature on the v0.15.1 tag is irrelevant to that question; and
FWIW, I don’t see *that* signature being verified here, either.
Second paragraph: Moreover, with the breaking of SHA-1, it *may* be
feasible for some scenario to play out involving two different PEMs with
the same hash, but different public keys (and thus different
corresponding private keys). I don’t know off the top of my head if
somewhere could be found to stash the magic bits; and the overall
scenario would need to be a bit convoluted. I think a malicious
committer who lacked access to the signing key *may* be able to create a
collision between the real certificate, and a certificate as for which
he has the private key—then switch them, later. Maybe. I would not
discount the possibility off-hand. OTS would prove nothing, if he had
the foresight to obtain timestamps proving that both certificates
existed at the appropriate time (which they would need to anyway; it is
not a post facto preimage attack).
>[...]
>
>What's nice about OpenPGP's "clearsigned" format is how it ignores
>whitespace; a replica of that might be a nice thing for OTS to be able
>to do too. Though that's on low priority, as there's some tricky design
>choices(1) to be made about how to nicely nest clearsigned PGP within
>OTS.
>
>
>1) For example, I recently found a security hole related to clearsigned
>PGP recently. Basically the issue was that gpg --verify will return
>true on a file that looks like the following:
>
> 1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a foo-v2.0.tar.gz
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 foo-v1.0.tar.gz
> -----BEGIN PGP SIGNATURE-----
>
> <snip pgp stuff>
> -----END PGP SIGNATURE-----
>
>The system I was auditing then did something like this to verify that
>the file was signed:
>
> set -e # exit immediately on error
> gpg --verify SHA256SUMS.asc
> cat SHA256SUMS.asc | grep foo-v2.0.tar.gz
> <do installation>
>
>While it makes it a bit less user friendly, the fact that PKCS7's
>encoding made it impossible to see the message you signed until it's
>been properly verified is a good thing re: security.
Potential solutions using PGP:
0. Don’t use clearsigning.
1. Use a detached signature.
2. Use `gpg --verify -o -` and pipe that to `grep`, rather than
illogically separating verification from use of data. (By the way,
where is the *hash* verified? Was `grep` piped to `sha256sum -c`?)
3. Have shell scripts written by somebody who knows how to think about
security, and/or who knows how to RTFM; quoting gpg(1):
>Note: When verifying a cleartext signature, gpg verifies only what
>makes up the cleartext signed data and not any extra data outside of
>the cleartext signature or the header lines directly following the dash
>marker line. The option --output may be used to write out the actual
>signed data, but there are other pitfalls with this format as well. It
>is suggested to avoid cleartext signatures in favor of detached
>signatures.
4. Obtain an audit from Peter Todd.
>And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh
>isn't vulnerable to this mistake. :)
P.S., oh my! *Unsigned data:*
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists•linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
nullius@nym•zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] New Bitcoin Core macOS signing key
2018-01-12 10:14 ` nullius
@ 2018-02-01 1:14 ` Cory Fields
0 siblings, 0 replies; 4+ messages in thread
From: Cory Fields @ 2018-02-01 1:14 UTC (permalink / raw)
To: nullius, Bitcoin Protocol Discussion
A public key was published recently for future macOS releases. Sadly,
that key was created the wrong way (iPhone OS instead of macOS), so
another had to be generated.
The new, working pubkey for Bitcoin Core releases starting with
0.16.0rc1 is included in the message below. That message is signed
with the key mentioned in the previous mail.
It can be verified with: openssl smime -verify -noverify -in msg.pem
Sorry for the noise.
-----BEGIN PKCS7-----
MIIPbQYJKoZIhvcNAQcCoIIPXjCCD1oCAQExCzAJBgUrDgMCGgUAMIIC5gYJKoZI
hvcNAQcBoIIC1wSCAtNBIHB1YmxpYyBrZXkgd2FzIHB1Ymxpc2hlZCByZWNlbnRs
eSBmb3IgZnV0dXJlIG1hY09TIHJlbGVhc2VzLg0KDQpTYWRseSwgdGhlIHB1Ymxp
c2hlZCBrZXkgd2FzIGNyZWF0ZWQgdGhlIHdyb25nIHdheSAoaVBob25lIE9TIGlu
c3RlYWQgb2YgbWFjT1MpLCBzbyBhbm90aGVyIGhhZCB0byBiZSByZXF1ZXN0ZWQu
DQoNClRoZSBuZXcsIHdvcmtpbmcgcHVia2V5IGZvciBCaXRjb2luIENvcmUgcmVs
ZWFzZXMgc3RhcnRpbmcgd2l0aCAwLjE2LjByYzEgaXM6DQoNCi0tLS0tQkVHSU4g
UFVCTElDIEtFWS0tLS0tDQpNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4
QU1JSUJDZ0tDQVFFQXF4aWJEZ2pBT09WVXBTY3pVMnBqDQp0UEVpQ0lZeXl2V21E
N2VidGhQbzI5WG9xMUJqYWJGNDlCZ3diNkZFaU1haFN5UTY4ZklMSUhDanJ5SUo4
RUN1DQpROFJWbVF3cGdhKzV0OTZiMEM5emN5WTFhcSsrRzIyMVNqNmFpUmVveXZw
cHIrZ2poNmNPbktEc1B0Z2pUcGdiDQovOUhuMmtwYzFmZ000ZkRFMlQ2VXZHVHMw
d3d5dWNvL21ya0s1LzEySCtqZUE3QXVNcjBLQTBVSktSS1VOenFhDQo4QjlLalFF
ektaRGVVVHRYak9vSmIyNkRQU3hCbXBGd25zWSs2aHBjeFZSSmphNG1FYzRFYnIy
b2gxSmVORU5uDQp4WXR3MHRWVWczTUwvWlI2WU9qQVpMY0V0cW5IR2ZOZXVRazJX
Vm1pYy9JY3d4VEM0cUk4MnFROGgxQnFpY3pRDQo4UUlEQVFBQg0KLS0tLS1FTkQg
UFVCTElDIEtFWS0tLS0tDQqgggnZMIIFzTCCBLWgAwIBAgIId5kUM+xSbWMwDQYJ
KoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMu
MSwwKgYDVQQLDCNBcHBsZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFE
MEIGA1UEAww7QXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgwMTEwMjAyNTA1WhcNMTkwMTEwMjAy
NTA1WjCBwDEaMBgGCgmSJomT8ixkAQEMCllaQzdXSDNNUlUxUDBOBgNVBAMMR2lQ
aG9uZSBEaXN0cmlidXRpb246IEJpdGNvaW4gQ29yZSBDb2RlIFNpZ25pbmcgQXNz
b2NpYXRpb24gKFlaQzdXSDNNUlUpMRMwEQYDVQQLDApZWkM3V0gzTVJVMS4wLAYD
VQQKDCVCaXRjb2luIENvcmUgQ29kZSBTaWduaW5nIEFzc29jaWF0aW9uMQswCQYD
VQQGEwJVUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsYmw4IwDjl
VKUnM1NqY7TxIgiGMsr1pg+3m7YT6NvV6KtQY2mxePQYMG+hRIjGoUskOvHyCyBw
o68iCfBArkPEVZkMKYGvubfem9Avc3MmNWqvvhtttUo+mokXqMr6aa/oI4enDpyg
7D7YI06YG//R59pKXNX4DOHwxNk+lLxk7NMMMrnKP5q5Cuf9dh/o3gOwLjK9CgNF
CSkSlDc6mvAfSo0BMymQ3lE7V4zqCW9ugz0sQZqRcJ7GPuoaXMVUSY2uJhHOBG69
qIdSXjRDZ8WLcNLVVINzC/2UemDowGS3BLapxxnzXrkJNllZonPyHMMUwuKiPNqk
PIdQaonM0PECAwEAAaOCAfEwggHtMD8GCCsGAQUFBwEBBDMwMTAvBggrBgEFBQcw
AYYjaHR0cDovL29jc3AuYXBwbGUuY29tL29jc3AwMy13d2RyMTEwHQYDVR0OBBYE
FNOBKRRpuWarZwT6owhUtiOP6lbSMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU
iCcXCam2GGCL7Ou69kdZxVJUo7cwggEdBgNVHSAEggEUMIIBEDCCAQwGCSqGSIb3
Y2QFATCB/jCBwwYIKwYBBQUHAgIwgbYMgbNSZWxpYW5jZSBvbiB0aGlzIGNlcnRp
ZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVzIGFjY2VwdGFuY2Ugb2YgdGhlIHRo
ZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJtcyBhbmQgY29uZGl0aW9ucyBvZiB1
c2UsIGNlcnRpZmljYXRlIHBvbGljeSBhbmQgY2VydGlmaWNhdGlvbiBwcmFjdGlj
ZSBzdGF0ZW1lbnRzLjA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5hcHBsZS5jb20v
Y2VydGlmaWNhdGVhdXRob3JpdHkvMA4GA1UdDwEB/wQEAwIHgDAWBgNVHSUBAf8E
DDAKBggrBgEFBQcDAzATBgoqhkiG92NkBgEEAQH/BAIFADANBgkqhkiG9w0BAQsF
AAOCAQEARvNgy5mhFqZsI5JGgn6HSR/eQIXjuoGyOivOa6+uCb5qcrSjSR+PSj7D
K/SBxrz+sVgKvwQ3buhv3BJnURmbYtEmqRr60G+yZE6xNpDMEyZyEM7aT6R9zBMX
++5mwqq5Ip57Mq8yB+pGTzSCBUAat6qiMBUkJBa+F/fk+vXZxgKAfKGMEfALLR5j
Rnwadg2CoTng47Mt4gzuGqjRSJH2vlB44GzRiFoJjXJOJGZ0hdagXl1ARTKul1NF
QukGMeJa1xlXzEk2K1sT7inGHEHTO5KD4RyyVFaDTnhWtvDfmDZt5R/Ipfc7KMmc
dObDKqWe/TGoKM5noj3dvafhNFZ9mDCCBAQwggLsoAMCAQICCBh6qajCliEMMA0G
CSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpBcHBsZSBJbmMu
MSYwJAYDVQQLEx1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEWMBQGA1UE
AxMNQXBwbGUgUm9vdCBDQTAeFw0xMjAyMDEyMjEyMTVaFw0yNzAyMDEyMjEyMTVa
MHkxLTArBgNVBAMMJERldmVsb3BlciBJRCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEmMCQGA1UECwwdQXBwbGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxEzARBgNV
BAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAiXZPBluaQe6lIysCo1/Xcz/ANbCLhAo/BiR/p5U/608Ok6+0
DtDIPuVtGLMf6IlHv9cJCOT/VpgpFeeUnbk1owrNtMDh4mD0yuwpeEVpaWBrX4qS
/J4j5jrCIrMxTxy68rY0WULusKkCAxiRBLazeC4zH4BFDUVvuw5aW38659gI1wsO
Mm37hjbkbKvEEYpwhCaqn0TR8bjGe5QXm0j3C1gWuiPFnxU5fspdwzJfD+BSf0Dq
vqwIZJVbyRqc5YDKH2pEHGw+xLAmHx3se69eoGo9R6lYEjE/IHYobR0csMJOEWkm
i8vW0BGCyU4P8VZ00NkIS2Z4oqusp+LSTIdZyQIDAQABo4GmMIGjMB0GA1UdDgQW
BBRXF+2iz9x8mKEQ4Py+hy0s8uMXVDAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQY
MBaAFCvQaUeUdgn+9GuNLkCm90dNfwheMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6
Ly9jcmwuYXBwbGUuY29tL3Jvb3QuY3JsMA4GA1UdDwEB/wQEAwIBhjAQBgoqhkiG
92NkBgIGBAIFADANBgkqhkiG9w0BAQsFAAOCAQEAQjl0a6HcxqSPNyqMsx0KRLyV
LH+8WbisYfsHkJIyudS/O8FQOWpEdKLsWx9w5ardS2wcI3EtX9HFk77um4pwZYKd
FuMaEBeJLajN/Qx4WEkMKH8z7gB6G7R2rLa1u0/fqBudyBmXSgtWZy/CPrazxIM6
8HdtdMQuI1HumqUDb2D0pUinBsK7WuIfH0ZFfuSX9ScQtyAicm9y2sZQdcU9JY9d
owDpnzaMSDmPszvqkIAulZpg9HjO9A4KUz6i+k/YHq6ElY0yvFZNiel4GOCsmkK6
ekYbhKKJzhToiNFYi/auVsQsBSpFrwvZS6kCDzSsiMdhVYlEySdzB+6C5U71cDGC
An8wggJ7AgEBMIGjMIGWMQswCQYDVQQGEwJVUzETMBEGA1UECgwKQXBwbGUgSW5j
LjEsMCoGA1UECwwjQXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMx
RDBCBgNVBAMMO0FwcGxlIFdvcmxkd2lkZSBEZXZlbG9wZXIgUmVsYXRpb25zIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5Agh3mRQz7FJtYzAJBgUrDgMCGgUAoIGxMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDIwMTAx
MTExNFowIwYJKoZIhvcNAQkEMRYEFNKi/xYPqnN6zp/RogVZBZ3ICGOBMFIGCSqG
SIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3
DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIB
AJQtrcrRd/3PLS9rhey0RyU1ZRnuB4Ib+y/wAan3k+fRNpA70F9kaxxcme78eqho
HH5rvizY4InvrG1wjtpYeickMHp+s0E51j1AbVxOgZ/UiEgjLRq9Dv5OCPgKoLaB
lsyCj41baXvlqzXZ8RaP7Li2SPLpdksqLE5yegiN+yMIiEPfNAtmaRLN3CNnbbMf
X1bF4ifgyhy3P1VGPPk+WTiQyu0VqySrlhz0Ux9+acB/TFUrymFEKxJ/7bM//4nL
UpEQVlnj9rl3OYzhYgDsQgz0kGU+6UG7Iw6gB9xFAMeE/1Y5Xrs2UdjBVC9hkSy8
r1+2rPF1yixiWjiORNk4kyU=
-----END PKCS7-----
Regards,
Cory
On Fri, Jan 12, 2018 at 5:14 AM, nullius via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 2018-01-12 at 08:54:12 +0000, Peter Todd <pete@petertodd•org> wrote:
>>
>> While a clunky way to do it, you can use the `-signer` option to tell
>> OpenSSL to write the signer's certificate to a file. That certificate can
>> then be compared to the one from the repo, which was still in the repo as of
>> the (signed!) v0.15.1 tag.
>>
>>
>> Fun fact: OpenTimestamps has git integration, which means you can extract
>> a OTS proof from 2016 for that certificate from the repo:
>>
>> $ git checkout v0.15.1
>> $ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem
>> share/certs/BitcoinFoundation_Apple_Cert.pem.ots
>> 36f60a5d5b1bc9a12b87d6475e3245b8236775e4
>> $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots
>> Assuming target filename is
>> 'share/certs/BitcoinFoundation_Apple_Cert.pem'
>> Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016
>> EDT
>>
>> Homework problem: write a paragraph explaining how the proof generated by
>> the above three commands are crypto snakeoil that proved little. :)
>
>
> It says, “Bitcoin attests data existed”. Within the scope of those three
> commands, I don’t see any proof of who put it there. Does OTS check the PGP
> signatures on *commits* when it does that `git-extract`? The signature on
> the v0.15.1 tag is irrelevant to that question; and FWIW, I don’t see *that*
> signature being verified here, either.
> Second paragraph: Moreover, with the breaking of SHA-1, it *may* be
> feasible for some scenario to play out involving two different PEMs with the
> same hash, but different public keys (and thus different corresponding
> private keys). I don’t know off the top of my head if somewhere could be
> found to stash the magic bits; and the overall scenario would need to be a
> bit convoluted. I think a malicious committer who lacked access to the
> signing key *may* be able to create a collision between the real
> certificate, and a certificate as for which he has the private key—then
> switch them, later. Maybe. I would not discount the possibility off-hand.
> OTS would prove nothing, if he had the foresight to obtain timestamps
> proving that both certificates existed at the appropriate time (which they
> would need to anyway; it is not a post facto preimage attack).
>
>> [...]
>>
>> What's nice about OpenPGP's "clearsigned" format is how it ignores
>> whitespace; a replica of that might be a nice thing for OTS to be able to do
>> too. Though that's on low priority, as there's some tricky design choices(1)
>> to be made about how to nicely nest clearsigned PGP within OTS.
>>
>>
>> 1) For example, I recently found a security hole related to clearsigned
>> PGP recently. Basically the issue was that gpg --verify will return true on
>> a file that looks like the following:
>>
>> 1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a
>> foo-v2.0.tar.gz
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
>> foo-v1.0.tar.gz
>> -----BEGIN PGP SIGNATURE-----
>>
>> <snip pgp stuff>
>> -----END PGP SIGNATURE-----
>>
>> The system I was auditing then did something like this to verify that the
>> file was signed:
>>
>> set -e # exit immediately on error
>> gpg --verify SHA256SUMS.asc
>> cat SHA256SUMS.asc | grep foo-v2.0.tar.gz
>> <do installation>
>>
>> While it makes it a bit less user friendly, the fact that PKCS7's encoding
>> made it impossible to see the message you signed until it's been properly
>> verified is a good thing re: security.
>
>
> Potential solutions using PGP:
>
> 0. Don’t use clearsigning.
>
> 1. Use a detached signature.
>
> 2. Use `gpg --verify -o -` and pipe that to `grep`, rather than illogically
> separating verification from use of data. (By the way, where is the *hash*
> verified? Was `grep` piped to `sha256sum -c`?)
>
> 3. Have shell scripts written by somebody who knows how to think about
> security, and/or who knows how to RTFM; quoting gpg(1):
>
>> Note: When verifying a cleartext signature, gpg verifies only what makes
>> up the cleartext signed data and not any extra data outside of the cleartext
>> signature or the header lines directly following the dash marker line. The
>> option --output may be used to write out the actual signed data, but there
>> are other pitfalls with this format as well. It is suggested to avoid
>> cleartext signatures in favor of detached signatures.
>
>
> 4. Obtain an audit from Peter Todd.
>
>> And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh isn't
>> vulnerable to this mistake. :)
>
>
> P.S., oh my! *Unsigned data:*
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> --
> nullius@nym•zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
> “‘If you’re not doing anything wrong, you have nothing to hide.’
> No! Because I do nothing wrong, I have nothing to show.” — nullius
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-02-01 1:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-12 5:04 [bitcoin-dev] New Bitcoin Core macOS signing key Cory Fields
2018-01-12 8:54 ` Peter Todd
2018-01-12 10:14 ` nullius
2018-02-01 1:14 ` Cory Fields
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox