6

Let's say you have person A who wants to pay person B.

A common way for B to communicate his/her address to A is by QR code or email or some such non secure method either of which could be substituted for another address in a man-in-the-middle attack, by person C. In other words C contrives a situation where they can replace B's address with their own, thereby making A pay C instead of B.

This would be even harder to prevent if A and B were continents apart. Not only would A not be able to see B or perhaps even talk to them, but they would also have some difficulty carrying out even basic checking.

Is there a way to stop a man-in-the-middle attack when communicating addresses in this sort of circumstance?

| improve this question | |
  • 1
    Your question is ill-defined. You say "who wants to pay person B" but what does that mean? In order to "want to pay person B", there must be something you know that identifies person B, and the answer to this question 100% depends on what that something is. For example, if you know you want to pay "Jeffrey Smith, who currently resides at 112 Buckingham Lane" that's totally different from "Amazon, the merchant who owns amazon.com" or "the guy who just sent me this email". – David Schwartz Feb 24 '14 at 20:03
  • It means that you want to pay another person. It is a pre-amble to a payment, but for the sake of clarity, it is not A who should know anything about B, but the other way round. If B is requesting a payment, they must already know something about A, and from that a secure and authenticated shared secret can be agreed. – T9b Feb 25 '14 at 13:25
  • 1
    You want to "pay another person", but what does that mean? How do you know which person is the person you want to pay? Do you know their name? Address? National identification number? You can't answer the question without understanding what it is that uniquely identifies who you want to pay. Otherwise, there's no way to know whether you've paid the right person or not. And you can't assure something you don't even understand. – David Schwartz Feb 27 '14 at 21:46
4

No. That is impossible if A and B have never communicated through a secure channel to exchange keys before, unless you are willing to trust another user, for example a user, D, you know and have safely exchanged keys before, that says it trust users B address, creating a web of trust or less preferable a certificate authority. This is a known and significant issue in public key exchange.

| improve this answer | |
  • Nothing is "impossible". It might be impractical, but that is different. After posting I discovered the Diffie-Hellman key exchange, which seems to contradict what you state. – T9b Feb 24 '14 at 15:07
  • 4
    You might want to check again what Diffie-Hellman key exchange is meant for. D-H guarantees secrecy of communication without prior key exchange, but not authentication of the third party. So you might be securely exchanging keys with a man in the middle! – dendini Feb 24 '14 at 16:04
  • Exactly dendini. You cannot know if the key belongs to the person you think it belongs to, unless you use something like a web of trust, but that has its issues too. – Jori Feb 24 '14 at 16:12
  • I beleive that Authenticated or Unified DH (aka DH2) does get around this problem - but I am open to this kind of advice. – T9b Feb 25 '14 at 13:21
  • 1
    I highly doubt that. There is no solution, as there is no way to identify the person at the other end of the network, without having a secure channel before (just once is enough). – Jori Feb 25 '14 at 16:58
0

Email is a very bad way to exchange address information unless the email is digitally signed. If it was A would still need to know which key to use to validate the signature on the email.

A typical secure scenario would be if B is an ecommerse site and wants to tell A where to send the Bitcoins they would do so on a secure webpage over SSL. The identity of B is therefore validated by there SSL certificate. If C tried a man in the middle attack then an error would appear in A's browser.

That does rely on C not being able to corrupt the SSL certificate issuing process. That's a fairly safe assumption if C is a criminal gang. If C is a well financed government agency may be not.

| improve this answer | |
  • There is a flaw in that we tend to blindly trust certificates, just because there is a cert that has a chain of trust to a recognized CA does not mean it belongs to who you think it does. So, one is careful ad looks at the cert, looks at the Common Name, is that the correct name? You want to connect with company you know as "ABC". Should you trust a cert with the Common Name "ABC Inc.", "ABC", "ABC LLC"? And, really how many people even look at a cert. There is a difference between "validating" a cert and validation an identity. Secure apps use SSL pining but you need the cert in the app. – zaph Feb 26 '14 at 13:24
  • To be fair with the EV certs (the ones that make the address bar go green) they are fairly well validated. Theres a standard the issuing authority is supposed to follow to validate you. Its pretty rigours. Of course it relies on the issuer playing by the rules, which they generally do. But I am sure a really well financed attacker could find a way. – Charlie M May 27 '14 at 18:02
  • I agree with your comment. There are a few issuers however who are not rigorous, I know my wife deletes some CAs from her computer that she does not trust (she is professionally paranoid). – zaph May 27 '14 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.