Topic: Bitcoin Signed Binaries - page 2. (Read 5411 times)

Well OK.  I meant you actually *read* the code before building it.

Not a guarantee

Bitcoin is an open-source project.  Build the client yourself from source to guarantee you don't run a compromised executable.

That's the whole point of open source.

Agree with Mike, just one quibble - the main usage of PE signatures today is so anti-virus systems can automatically learn reputation. Having a binary signed by a "good" organization that has lots of installs and few/no reports of being a virus means even if the executable/DLL is brand new, it'll be left alone. It also helps AV engines detect modified system libraries. For this reason it's really helpful to let Bitcoin develop a good reputation - it'll reduce AV FPs.

A tool to strip the signatures from EXEs is probably already in existence, if not it'd be easy to write (for either windows or linux, though don't we already depend on Wine?).

Problem is that someone who modifies a binary to be malicious will just as easily modify the self-test to falsely report success.

The only self-testing that's really sensible is for the currently installed version to acquire and verify the next version you're about to install to replace it.  The way I see it, this would actually be a strong defense against a whole lot of potential fake-client attack avenues.

One additional idea for thrustworthyness, could we compute the hash in the binary (a hash of itself during startup) and compare that agains the reference-hash, which resides on the download server or is stored where it can't be manipulated (no master plan for this though) and warn the user or block program usage, when the hashes don't match? I have to admit I never checked the hash of bitcoin-qt.exe btw. ^^ and I would love if I could easily ensure I have a valid and official binary.

Dia

Sounds like it's relatively easy to add/remove such a signature from a binary, so it could be done after the gitian building step, and still be verifiable. I'm all in favor of signing released binaries if it helps making Bitcoin trustworthy. I'm totally oblivious about the process to achieve that for Windows binaries, though.

This is a build process that can be changed as needs arise, right?

Simply eliminate the bytes belonging to the signature field from comparison.  Adding a signature, according to a cursory Google search, simply fills in a pre-allocated signature field inside the executable in a location that can be found deterministically from the executable file headers.  When Microsoft hashes the file for the purpose of signature validation, this field is located and excluded from the hash calculation by design, so a signed binary will hash the same as an unsigned one for their signing purposes.  The build process could do the same.  Then it could automatically confirm that the same binary (minus the signature) was signed by everyone, and then you'd have great security.

I think you missed a key point, pun intended.  The build process demands that multiple people all produce exactly the same binary file, bit for bit.  The only way to do this is to have multiple people with the same private signing key, which is bad security, and had certainly better be grounds for revocation of the signing certificate.

You are somewhat right about the technical control / legal control aspect, but it turns out that whatever the intention was, lots of things treat binaries differently based on the validity of the signature.

If the objective is to sign the binaries in a Windows-favored style just so that it's signed for the sake of shutting up the OS about untrusted software, just one person doing the signature will accomplish the objective.  That person can just as well sign with a personal (rather than organizational) signature.  Until Windows makes any distinction between once-signed and multiply-signed binaries, the practical difference is moot.  Mac OS X likely falls under the same umbrella.  Multiple PGP signatures can and ought to be checked by those able to do so.

I might point out that someone downloading an update is far more in a position to be scammed than someone downloading the client for the first time, since the updater is far more likely to own coins.  Therefore, I would submit including an automated update mechanism in the client with authentication built in would be the most effective mechanism to bring secure client downloads to bitcoin users.

I believe that Windows binary signing is meant to make sure that code can be connected with a real person or organization.  It wasn't designed to be a technical based control against all rogue code, it's meant to be a legal/social one (where someone who signs something harmful can be identified and held accountable - as well as the certificate revoked - and therefore has an incentive not to abuse it).

Matt hit it.  (And Maged beat me to it, but I think I explain more.)


Bitcoin-qt isn't built in Windows, it is cross-compiled from a Linux.  Even worse, the build process is totally scripted inside a Linux virtual machine.  There are several people that build the binaries in this way, and then they compute hashes on the outputs.  The official releases only get posted after a bunch of people have all built exactly the same files, as verified by the hashes.

To get signed Windows binaries, we would need to distribute the signing key to everyone that builds the releases, which would be bad.  Also, I'm guessing here, but I bet that Microsoft's policies for accepting CA certs for code signing require that the CA have policies that prevent distribution of the keys they hand out.

Phew, I managed to get all of the way through a PKI post without going off onto a tangent about how the current CA scheme used by SSL and everything else is absolutely and totally fucked and broken.  Er, almost.

As Matt said...
As you can see, that's a pretty big downside.

It's been over a year since this thread was touched. I was just looking at my system with Process Explorer and out of the 62 processes, only 3 are not signed. One of them is Bitcoin-qt. Is there any downside to signing? I always verify with Gavin's signature and I trust that keychain more than I would one issued by a centralized authority... We all know what has happened to SSL CAs. Is this the argument?

They're different kinds of risk. If the auto-update has a vulnerability, somebody could steal the private keys of tens of thousands of users in a matter of minutes. If the client software has some other vulnerability, then depending on the nature of it, it will be more or less dangerous than what I just mentioned. Probably less.

The compiler should use ProPolice or /GS in case of M$

May I suggest another thread for the auto-update debate?

I did? You can make updating secure such that other risks are higher than the update risk.

You missed the point. 

Wouldn't it be more risky NOT having an auto-update? As long as the process of getting the binaries is secure. I'm thinking from the point of view that there could be exploits in the network or old versions where you want people to update to protect themselves. People are notorious for not upgrading and what if we need them too to prevent an attack on the network? Newer web browsers seem to do it to enhance security so why wouldn't that be the case for bitcoin?

Obviously we aren't going to blindly auto-update, there will be a user-prompt.  Also, the binaries are signed by multiple developers meaning you would have to compromise the pgp private keys of several developers.  If you think an attacker will try to compromise the download script, well how is that any different from compromising the current downloads?  You would have to compromise sourceforge, so it wouldn't make a difference.  If you think the script itself might be trickable into downloading without having enough signatures, then I ask you to look it over yourself https://github.com/devrandom/gitian-builder/blob/updater/share/gitian-updater