* [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