Topic: Worst case scenario (Read 2064 times)
The worst case scenario is Government take down the whole Bitcoin by forcing us to download a anti Bitcoin program, if we don't do it we are jailed and confiscate all our Bitcoin.
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.Anybody got a better idea?
I opened a discussion here: https://bitcointalksearch.org/topic/bitcoinorg-and-sourceforgenet-are-not-running-on-https-310161
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?
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.Anybody got a better idea?
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?
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?
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.
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)
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.
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.
Unlikely, it would happen long before when it is still vulnerable. Right now seems like it has all patched up.
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.
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?
This is very unlikely i would hope. Pretty sure the source code is thoroughly checked by many paranoid people upon an update.
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.
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.
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.
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.
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. 
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.
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.
Quote
- 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.- The attacker could threaten one of the bitcoin developers and such force his to do what he wants
Quote
- 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.With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?
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.
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.
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?
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"
What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?
- 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
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.
Quote
- 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.- The attacker could threaten one of the bitcoin developers and such force his to do what he wants
Quote
- 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?
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.
Quote
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...
Jump to: