Worst case scenario

[codymanix]

Could it happen that an attacker injects malicious code into the satoshi client? For example that all money of the user's wallet is transferred to the attacker (If the wallet is encrypted, as soon as user enters the password). Then the infected client would have to made available for download on official site bitcoin.org.
Even if the problem is noticed within a few hours, the attacker could have gained lots of money, so such an attack would be very attractive for a criminal hacker.
Additional to the damage done to the users, this could do much damage to bitcoin itself, if not even destroying it.

I can think of a lot possible access points for the attacker:

- An attacker could break directly into the source control where the source code is stored and unnoticed injects his code which is then automatically include in the next version.
  But since bitcoin is open source, the attacker should hide its code in a file where people rarely look into or file which at first glance does not look important but are indeed source files

- An attacker could hack a computer of one of the bitcoin client developers (Either through direct physical access or through some trojan)

- The attacker could threaten one of the bitcoin developers and such force his to do what he wants

- An attacker could break into the website bitcoin.org and place his malicious client for download, or redirect bitcoin.org via some dns attack to his own (same looking) website
  With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?

This are my greatest fears. Please tell me that these scenarios are almost impossible to happen. So the question is, could this be possible?

[gmaxwell]

- An attacker could break directly into the source control where the source code is stored and unnoticed injects his code which is then automatically include in the next version.
  But since bitcoin is open source, the attacker should hide its code in a file where people rarely look into or file which at first glance does not look important but are indeed source files

This won't work. Everyone looks at diffs. Making the change in something that changes all the time would be a better strategy. In GIT it is not possible to make invisible changes either, and rewriting the history will make all git clients refuse to pull until forced.

- An attacker could hack a computer of one of the bitcoin client developers (Either through direct physical access or through some trojan)
- The attacker could threaten one of the bitcoin developers and such force his to do what he wants

If the system is vulnerable to this, then you can remove the third party "attacker" from the equation: One of the developers could just do this if it were possible.  Hopefully, enough people are auditing all changes that this wouldn't be possible.

- An attacker could break into the website bitcoin.org and place his malicious client for download, or redirect bitcoin.org via some dns attack to his own (same looking) website
  With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?

About 1% check. But users update very slowly and we intentionally do not have a forced auto-update. And there are people running automated signature tests who would quickly notice a problem.

This are my greatest fears. Please tell me that these scenarios are almost impossible to happen. So the question is, could this be possible?

Certainly it would be possible, few things are not possible.  It's less clear that there would be a large amount of funds taken this way...

[jl2012]

What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?

[gmaxwell]

What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?

A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message:

"URGENT: Alert key compromised, upgrade required"

[michagogo]

What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?

A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message:

"URGENT: Alert key compromised, upgrade required"

Maybe I'm missing something, but wouldn't the attacker in this case simply set the sequence number and priority to the maximum?

[jl2012]

What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?

A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message:

"URGENT: Alert key compromised, upgrade required"

Maybe I'm missing something, but wouldn't the attacker in this case simply set the sequence number and priority to the maximum?

I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.

[codymanix]

- An attacker could hack a computer of one of the bitcoin client developers (Either through direct physical access or through some trojan)
- The attacker could threaten one of the bitcoin developers and such force his to do what he wants

If the system is vulnerable to this, then you can remove the third party "attacker" from the equation: One of the developers could just do this if it were possible.  Hopefully, enough people are auditing all changes that this wouldn't be possible.

If someone puts a manipulated client on bitcoin.org with his own source, that is without checking in anything?

- An attacker could break into the website bitcoin.org and place his malicious client for download, or redirect bitcoin.org via some dns attack to his own (same looking) website
  With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?

About 1% check. But users update very slowly and we intentionally do not have a forced auto-update. And there are people running automated signature tests who would quickly notice a problem.

If done from a computer of a bitcoin developer, the executable could also be signed valid, so no one will notice the difference.

It would be great some kind of multi key signing would be used, that is, multiple persons have to sign with their private keys to make the signature valid.

[piotr_n]

This is exactly the reason why people shall be using cold wallets, to store their major BTC holdings.

It doesn't even need to be a bug or a backdoor in the actual bitcoin client - more likely it would be a virus/trojan/malware or just a bug/backdoor in the OS.

Keep your bitcoins offline and do not move any signed transaction from your cold storage without double checking whether it does exactly what you intended.
Just use your imagination combined with the already available technology and the worst case scenario would not be a threat to you.

[gmaxwell]

I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.

Correct.

It would be great some kind of multi key signing would be used, that is, multiple persons have to sign with their private keys to make the signature valid.

We have that, thats what gitian is for.

[Cryddit]

Actually, this could be done on a far simpler basis attacking individual users via a MITM attack.  Here is your scenario:

1.  Your ISP hires a dishonest worker.  Let's call him "Mallory".  (I say ISP, but this could happen upstream from the ISP, too, on the backbone).

2.  Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.

3.  Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.

4.  "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
     to a server where Mallory's fiddled version is served.

5.  A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.

6.  These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client.  Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.

7.  Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.

8.  It will be at least two or three months before most of the victims notice. 

[jl2012]

This won't work because people use https, not http

Actually, this could be done on a far simpler basis attacking individual users via a MITM attack.  Here is your scenario:

1.  Your ISP hires a dishonest worker.  Let's call him "Mallory".  (I say ISP, but this could happen upstream from the ISP, too, on the backbone).

2.  Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.

3.  Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.

4.  "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
     to a server where Mallory's fiddled version is served.

5.  A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.

6.  These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client.  Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.

7.  Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.

8.  It will be at least two or three months before most of the victims notice. 

[Shallow]

This is very unlikely i would hope. Pretty sure the source code is thoroughly checked by many paranoid people upon an update.

[michagogo]

I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.

Correct.

Sorry if I'm being slow... Are you saying that the "URGENT: Alert key compromised, upgrade required" message is hard-coded into the client to display when it sees a maximum-sequence alert?

[jl2012]

I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.

Correct.

Sorry if I'm being slow... Are you saying that the "URGENT: Alert key compromised, upgrade required" message is hard-coded into the client to display when it sees a maximum-sequence alert?

Yes.

[cowandtea]

Unlikely, it would happen long before when it is still vulnerable. Right now seems like it has all patched up.

[juhakall]

This won't work because people use https, not http

Actually, this could be done on a far simpler basis attacking individual users via a MITM attack.  Here is your scenario:

1.  Your ISP hires a dishonest worker.  Let's call him "Mallory".  (I say ISP, but this could happen upstream from the ISP, too, on the backbone).

2.  Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.

3.  Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.

4.  "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
     to a server where Mallory's fiddled version is served.

5.  A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.

6.  These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client.  Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.

7.  Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.

8.  It will be at least two or three months before most of the victims notice. 

http://kent.dl.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.8.5/bitcoin-0.8.5-win32-setup.exe

This is what I'm offered to download when clicking through bitcoin.org. No HTTPS there.

[jl2012]

This won't work because people use https, not http

Actually, this could be done on a far simpler basis attacking individual users via a MITM attack.  Here is your scenario:

1.  Your ISP hires a dishonest worker.  Let's call him "Mallory".  (I say ISP, but this could happen upstream from the ISP, too, on the backbone).

2.  Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.

3.  Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.

4.  "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
     to a server where Mallory's fiddled version is served.

5.  A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.

6.  These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client.  Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.

7.  Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.

8.  It will be at least two or three months before most of the victims notice. 

http://kent.dl.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.8.5/bitcoin-0.8.5-win32-setup.exe

This is what I'm offered to download when clicking through bitcoin.org. No HTTPS there.

Oh, that's really bad. Even bitcoin.org is not https enabled. (but at least the package is signed by bitcoin foundation)

[Cryddit]

Well.... yeah, it really is that bad. 

Maybe we should ask sourceforge/github/ any others we can influence, never to serve executable (or, really, even source) using http rather than https? 

https isn't all that secure, for that matter, but it is better than nothing.

Anybody got a better idea?

[gmaxwell]

https isn't all that secure, for that matter, but it is better than nothing.
Anybody got a better idea?

HTTPS is not that secure. Fortunately we have _two_ different signature systems which are better than HTTPS which are in use. GPG signatures by Gavin's signing key, and gitian signatures.

[jl2012]

https isn't all that secure, for that matter, but it is better than nothing.
Anybody got a better idea?

HTTPS is not that secure. Fortunately we have _two_ different signature systems which are better than HTTPS which are in use. GPG signatures by Gavin's signing key, and gitian signatures.

I opened a discussion here: https://bitcointalk.org/index.php?topic=310161.0

So what is your comments for the use of PKI in payment protocol?

For Gavin's key, how do I verify if I do not know him and do not have a web-of-trust?