Published on: 2018-02-01T01:14:45+00:00
A new public key has been generated for Bitcoin Core releases starting with 0.16.0rc1 due to an error in the previously published key that was created for iPhone OS instead of macOS. The purpose of the new key is to sign future macOS releases, and it can be verified using openssl smime -verify -noverify -in msg.pem. This announcement apologizes for the confusion caused by the noise, and the previous email contains the original pubkey that is no longer valid.Meanwhile, Bitcoin Core developer Peter Todd discussed how OpenTimestamps (OTS) provided little proof when verifying an important certificate in the Bitcoin software. While OTS extracted a timestamped proof of existence for the BitcoinFoundation_Apple_Cert.pem file within the repo, it failed to prove who had put it there. Todd explained that if someone could create a collision between the real certificate and one for which they had the private key, they could switch them at a later date. Furthermore, Todd found a security hole related to clearsigned PGP recently. He suggests using a detached signature or piping gpg --verify -o - to grep instead of separating verification from use of data.In another post on the bitcoin-dev mailing list, Todd described how to use the `-signer` option in OpenSSL to write the signer's certificate to a file, which can then be compared to the one from the repository. He also noted that OpenTimestamps has git integration, allowing the extraction of an OTS proof generated as of Oct 13, 2016 for the certificate from the repo. However, he questioned if the proof generated by those three commands are crypto snakeoil that proved little since there was no proof of who put it there. Additionally, with the breaking of SHA-1, there may be scenarios involving two different PEMs with the same hash but different public keys. Todd discussed potential solutions using PGP, such as not using clearsigning, using a detached signature, or having shell scripts written by someone knowledgeable about security.The email conversation on the bitcoin-dev mailing list suggested using openssl smime to verify the certificate used to sign Bitcoin Core binaries. The -ignore_critical flag is required to ignore Apple specific critical extensions that OpenSSL doesn't understand, and the -purpose any allows skipping the purpose == smimesign check since the certificate is only authorized to sign code, not arbitrary messages. However, it is noted that the signature will fail to validate as the certificate has expired. If openssl doesn't have the Apple Certificate Authority in its CA list, -noverify needs to be added. To compare the signer's certificate to the one from the repo, the -signer option can be used to write the signer's certificate to a file. OpenTimestamps has git integration, which allows the extraction of an OTS proof from 2016 for that certificate from the repo. The signed message was timestamped on the Bitcoin blockchain using OpenTimestamps. The 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. Bitcoin Core's contrib/verifybinaries/verify.sh isn't vulnerable to this mistake.Bitcoin Core's macOS code signing certificate has expired, and a new threshold signing scheme is being established to handle code signing without any single point of failure. Until then, releases will be signed as before, just with a new certificate. The old code-signing key/certificate was used to sign a message containing the pubkey that matches the new key/certificate for record purposes. The attached pkcs7 format contains the current signing certificate to make verification easier. Verification can be done using openssl smime -verify -in sig.pkcs7 -inform pem -ignore_critical -purpose any command. The signature will probably fail to validate now because the certificate has expired. To timestamp the signed message on the Bitcoin blockchain, OpenTimestamps was used. An ots file containing the timestamp proof is attached.The context also includes a PKCS7 encoded file with the encryption key MCVVMCCCdK9a7psn2QMAkGBSsOAwIaBQCggbEw and a signature in OpenDocument format named expire.txt.sig.ots. However, the URL for the attachment is not provided in the context.
Updated on: 2023-08-01T22:27:54.667619+00:00