Pages:

Author

Topic: tlsnotary - cryptographic proof of fiat transfer for p2p exchanges - page 9. (Read 42802 times)

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: nomailing on May 29, 2013, 10:27:48 AM

Quote from: dansmith on May 27, 2013, 06:19:29 AM

Weaknesses:
1. the bank may frown upon the payer logging into his bank from random IPs. But we discussed this earlier and it seems not to be a serious weakness.
2. The payer can flood the p2p pool from which the gateway users get selected by his accomplices. If the payer and gateway user are in cahoots, they can spoof the whole SSL session.
3. To mitigate #2, the gateway user should be the beneficiary of the payment. (The beneficiary has no interest to defraud himself), which leads to ...
4. If the beneficiary is the gateway user and over time has a lot of those who pay him, the bank will flag the beneficiary's IP because there will be many users of that bank logging into their accounts from the same IP.

I agree that the 4th party is an extra level of architectural complexity that is worth avoiding if it doesn't really bring a benefit.

Quote

To make sure that all 4 parties (seller,buyer,escrow,gateway) are really different persons, it would even make more sense to link p2p-accounts to real-world-bank-accounts. This would reduce the risk that someone could flood the p2p pool, because nobody has arbitrary many bank accounts.

The only risk left once we move to the model I describe in post 61 is the collusion between the escrow and either the buyer or the seller. This is mitigated by (a)random choice, possibly more than once and (b) prevention of Sybil attack by cost of identity creation.
Would you not agree that this has all been covered in posts 65 and 67-71?

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: nomailing on May 29, 2013, 10:03:10 AM

Quote from: waxwing on May 29, 2013, 04:35:56 AM

I have a new suggestion, melding together several of the ideas already mentioned:
...snip...

A problem with the approach to always have the proxy on the machine of the BTC-seller is that they might not be online at the same time. How could they agree to a specific online time? Should they specify this in their trade? In principle the BTC-buyer could just say that he couldn't do the transfer because the BTC-seller was always offline when he wanted to do it.

Although it's clearly not ideal to have this synchronization, this seems to be a less important issue. Counterparties displayed would be restricted to those who are active on the network at the time you are looking to trade. Both sides have to agree to a price as well as certain other settings possibly, and then the proxy-ed session to the bank can take place. Importantly, the BTC seller (acting as proxy) doesn't actually have to DO anything during the proxy session (doesn't have to sit at their computer), just has to be online. I think realistically they would want to stay around though and get a confirmation message that the encrypted data from the session was stored correctly.

If the BTC seller fails to store that encrypted data, they have forfeited the right to their (escrowed) BTC in case of a dispute. That works both ways; if the BTC buyer (the one who used internet banking to make a transfer) loses the SSL session key which decrypts the data, they also would forfeit their right to the BTC in case of a dispute.

nomailing

full member

Activity: 126

Merit: 100

Quote from: dansmith on May 27, 2013, 06:19:29 AM

Enters the scheme where the user doesn't have to expose his bank credentials and doesn't have to use SSL re-negotiation.
(But what I'm proposing below adds an extra level of complexity).

A randomly selected gateway user comes into play. The payer who has possesion of the SSL key does his banking session by channeling traffic to the bank through/from the gateway user. When the payer in finished, what happens is:
1. The gateway user submits to the e.agent only those packets which the payer has designated. (Packets which don't contain sensitive info)
2. The payer submits to the e.agent his SSL key, so that the e.agent could decrypt packets which gateway user gave him

I would add SSL-renegotiation (as optional for the payer) to increase security. How could you really be 100% sure that the gateway and the escrow do not exchange more of your session-dump or your session-key? This doesn't look 100% secure, maybe just 99% secure without SSL-renegotiation. So it's better for the payer to use SSL-renegotiation if his bank supports it. And many important websites seem to support renegotiation (e.g. paypal and large banks).

Probably the only reason why renegotiation is disabled on some websites is the security vulnerability (CVE-2009-3555). That many banks have it disabled is overkill, because there is a patch for OpenSSL to close this vulnerability. Maybe over time many websites will anyway update to the newer openSSL version and will enable SSL-renegotiation again.

Quote from: dansmith on May 27, 2013, 06:19:29 AM

The problem which you describe in #2 applies also to the selection of the escrow agent. How would you make sure that the escrow agent is really a third party and not in cahoots with either the seller or buyer? Probably by some mechanism to randomly choose the escrow. So if it works there, why not use the same mechanism for the gateway? So I would say your point #3 doesn't make sense, especially if you think about the problem that they both have to be online at the same time it is better to select a random user from the pool?

To make sure that all 4 parties (seller,buyer,escrow,gateway) are really different persons, it would even make more sense to link p2p-accounts to real-world-bank-accounts. This would reduce the risk that someone could flood the p2p pool, because nobody has arbitrary many bank accounts.

nomailing

full member

Activity: 126

Merit: 100

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: TimJBenham on May 29, 2013, 08:02:48 AM

This is a specific example of the rule that says if other people have tried hard to solve a problem and failed, then it probably isn't easy to solve. People (Polipay) with real money to spend on programmers etc have already attacked one of the OP's sub-problems (proving that a bank transfer has been made) and the solution they came up with (letting their java app control your internet banking) sucks.

However, they want to do it in real time, whereas your proposal (if I understand correctly), doesn't. The escrow still waits for Betty to confirm that the bank transfer has been received before releasing the BTC. That would typically take a day or more. In this use case POLi sort of forcibly does the transfer for Adam, then sends a message to Betty (presumably via Polipay's servers) that the transfer has been initiated, and Betty is expected to trust that and supply the goods immediately. It is assumed that Betty is trustworthy because she is a business (and pays Polipay's fees).

Good luck with your idea, but I don't think it solves a problem that is holding Bitcoin back much.

OK, so now I understand what you mean - but it's an apples and oranges comparison.

We are only trying to create a way to "record" the internet banking session, but we are trying to do it in a technically transparent way so that the bank doesn't even know about it. (To my mind there is nothing morally wrong with it because the SSL session remains intact - nobody can eavesdrop on Adam's banking activities. Only when Adam *voluntarily* gives the session key to the escrow in case of a dispute would anybody see any part of his internet banking, and only the parts that he specifically chooses them to see.)

Poli on the other hand are actually doing your internet banking for you underneath their app (I won't comment on the technicals because I don't know what they're doing under the hood - could be calling bank APIs in the same style as OFX or could be actually generating normal internet banking sessions - the latter more likely but also a lot more work for them in terms of coding). That's a much harder thing to do than just passive recording of encrypted data. And of course no surprise, they are only doing it for a specific set of banks.

As to your last point, thanks for the good wishes and I'll politely disagree but that would definitely be better for another thread

TimJBenham

sr. member

Activity: 280

Merit: 250

Quote from: waxwing on May 29, 2013, 05:53:41 AM

Quote from: TimJBenham on May 29, 2013, 04:38:14 AM

Quote from: waxwing on May 28, 2013, 06:12:47 AM

Quote from: TimJBenham on May 28, 2013, 05:00:09 AM

Quote from: dansmith on April 11, 2013, 06:32:11 AM

Goal: a payer needs to prove that he made a money transfer into the account of the seller (of BTC). This proof is only needed to be presented to an escrow agent in case a dispute arises. This proof aka SSL dump should not disclose payer's online bank login credential

POLi does something similar. It uses a java applet that drives your internet banking interface for you (you just get to type your password and click Confirm), so they could steal your password (but promise not to).

Thanks Tim, interesting example.

The fact they do it in that way suggests the OP's way wont work, but maybe he is a better designer.

Not sure I understand you there.

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: nomailing on May 29, 2013, 07:09:59 AM

Indeed reputation should be in the system too. something like the OTC rating system. this would help to minimize disputes.

Whilst I'm not denying that reputation is a useful idea, I think it's dangerous to rely on it, because it can easily lead to quasi-centralization, e.g. everyone uses the Bitcoin seller with rating 1000. I know that can be offset with a price mechanism, but still. Better to have the system so that you don't really need to trust the counterparty. Centralization is death for this system.
At a higher level, it's something like: democratise decisions that need to be made (reputation is a kind of democracy), but even better is not to make a decision (i.e. instead of letting trusted parties do X, redesign X so that whoever does it, it's not really dangerous).

Quote from: waxwing on May 29, 2013, 06:45:32 AM

Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.

Could you elaborate why this wouldn't help?

No, I can't elaborate. It seems to be nonsense. I think I just got confused about something

oakpacific

hero member

Activity: 784

Merit: 1000

Quote from: waxwing on May 29, 2013, 06:45:32 AM

Quote from: oakpacific on May 29, 2013, 06:24:27 AM

Another problem is the Sybil attack, if the escrower is an informant, he can gather a lot of buyers' information this way.

Really good point. Thanks.

First I would say that buyer information will only be exposed at the level of account number, bank and possibly name (all this info is already semi-public as we've discussed). This will only arise in the case of dispute. And for a lot of people (I can't say most, I just don't know), even in that rare dispute case, they will not even have to display their account balance, let alone other sensitive info.

(Other comments are for P2P exchange generally, I am thinking here more of my own plan as in https://bitcointalksearch.org/topic/m.2210078):
But the general point of the Sybil attack applies to the role of escrow here. It's another good reason not to overemphasize reputation. Identities will be cheap to acquire here because they will be linked to bitcoin addresses. I wouldn't want to somehow make them artificially expensive. Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.

Off the cuff thought: we could retain the ability to create cheap addresses, and thus use the network to buy bitcoins for the first time, but limit escrow agency to members with non-zero bitcoin addresses (balance above X). This would prevent swamping the network. Then the escrow agent for any transaction would be chosen randomly from those slightly-higher-status users. And also, we could keep the option of a "second opinion" if an arbitration goes against you (but that's really off the top of my head, so if you don't like it, ignore it).

Something else that can be done is to require anyone who wants to be an escrower putting a specific amount of bitcoins in custody within an address that's multisigned by a number of randomly chosen escrowers(which rational people would be inclined to do for escrowing fees income), so as long as the majority of the escrowers are not informants, each government action against a bitcoin buyer will cost them a fortune. This should be combined with some rating system to use.

False reporting of government crackdown from buyers/sellers can also be suppressed by requirng them to work with randomly chosen escrowers.

nomailing

full member

Activity: 126

Merit: 100

Quote from: waxwing on May 29, 2013, 06:45:32 AM

(Other comments are for P2P exchange generally, I am thinking here more of my own plan as in https://bitcointalksearch.org/topic/m.2210078):
But the general point of the Sybil attack applies to the role of escrow here. It's another good reason not to overemphasize reputation. Identities will be cheap to acquire here because they will be linked to bitcoin addresses. I wouldn't want to somehow make them artificially expensive. Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.

Off the cuff thought: we could retain the ability to create cheap addresses, and thus use the network to buy bitcoins for the first time, but limit escrow agency to members with non-zero bitcoin addresses (balance above X). This would prevent swamping the network. Then the escrow agent for any transaction would be chosen randomly from those slightly-higher-status users. And also, we could keep the option of a "second opinion" if an arbitration goes against you (but that's really off the top of my head, so if you don't like it, ignore it).

Indeed reputation should be in the system too. something like the OTC rating system. this would help to minimize disputes.
Why not link the p2p accounts (and the corresponding reputations) to the supplied real-world bank accounts? It would further minimize the number of disputes because nobody wants to risk that he can never use his bank account anymore in the p2p exchange. Is it possible to link p2p-account-reputations to real-world-bank-accounts without disclosing the bank-account-number to everyone? Maybe one could create a hash of the account-number, which then serves as the user-id in the p2p exchange?

Quote from: waxwing on May 29, 2013, 06:45:32 AM

Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.

Could you elaborate why this wouldn't help? I think if a user always trades using his paypal account, then he could build a good reputation by always using this exact paypal account. Consider he has a good reputation after some time, then he wouldn't want to fraud with this account? If you go further, a user might be able to link his paypal and bank-account and p2p-account all together to even get a higher reputation. And when he once linked them, then it's not possible to delink them anymore because everyone knows that these accounts belong to the same real-world person...

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: oakpacific on May 29, 2013, 06:24:27 AM

Another problem is the Sybil attack, if the escrower is an informant, he can gather a lot of buyers' information this way.

Really good point. Thanks.

First I would say that buyer information will only be exposed at the level of account number, bank and possibly name (all this info is already semi-public as we've discussed). This will only arise in the case of dispute. And for a lot of people (I can't say most, I just don't know), even in that rare dispute case, they will not even have to display their account balance, let alone other sensitive info.

(Other comments are for P2P exchange generally, I am thinking here more of my own plan as in https://bitcointalksearch.org/topic/m.2210078):
But the general point of the Sybil attack applies to the role of escrow here. It's another good reason not to overemphasize reputation. Identities will be cheap to acquire here because they will be linked to bitcoin addresses. I wouldn't want to somehow make them artificially expensive. Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.(EDIT: Ignore that last sentence, doesn't make sense (see below)).

Off the cuff thought: we could retain the ability to create cheap addresses, and thus use the network to buy bitcoins for the first time, but limit escrow agency to members with non-zero bitcoin addresses (balance above X). This would prevent swamping the network. Then the escrow agent for any transaction would be chosen randomly from those slightly-higher-status users. And also, we could keep the option of a "second opinion" if an arbitration goes against you (but that's really off the top of my head, so if you don't like it, ignore it).

oakpacific

hero member

Activity: 784

Merit: 1000

Quote from: waxwing on May 29, 2013, 06:01:54 AM

Quote from: oakpacific on May 29, 2013, 05:05:26 AM

Hmmm, maybe we can form a Tor-like network with multiple non-colluding escrowers participated, each of them only keeps some of the packages transmitted, so none of them can recover your password and identity information, yet when required, can put all pieces together to verify if the proof of transfer from the buyer is real?

Tor had crossed my mind too, but I rejected it as (a) users will be put off by it and (b) it will make the networking side even more difficult to figure out. Certainly, the anonymity is important, and we should use as much encryption as possible, but there will still be occasions (not often) when someone else on the network sees your bank account number.

As for splitting the banking session records amongst many users, it seems very complicated.
First, to emphasise, we don't need to expose login details at all. (e.g. in the last version of the design I posted a few posts back).
But more importantly, I actually think we do need human intervention for the escrow action, in order to correctly parse the banking session record. So that would need one person to make the decision. The trick is that the USD seller would only show those pages he wanted to show.

My thought was always that the escrow would be chosen randomly from a large network thus making collusion between escrow and bitcoin seller either impractical or impossible.

Another problem is the Sybil attack, if the escrower is an informant, he can gather a lot of buyers' information this way.

waxwing

sr. member

Activity: 469

Merit: 253

Following up on the proxy architecture, I found this re: HTTP CONNECT at http://muffin.doit.org/docs/rfc/tunneling_ssl.html

Quote

CONNECT is really a lower-level function than the rest of the HTTP methods, kind of an escape mechanism for saying that the proxy should not interfere with the transaction, but merely forward the data. This is because the proxy should not need to know the entire URI that is being accessed (privacy, security), only the information that it explicitly needs (hostname and port number). Due to this fact, the proxy cannot verify that the protocol being spoken is really SSL, and so the proxy configuration should explicitly limit allowed connections to well-known SSL ports (such as 443 for HTTPS, 563 for SNEWS, as assigned by the Internet Assigned Numbers Authority).

If that's right, the only caveat is that I'm not sure whether the proxy can easily record all the encrypted traffic going back and forth. Presumably we can just sniff the network traffic, although that would be a bit ugly. Much easier if the proxy server just logs it to file.

Or maybe I'm totally misinterpreting it.
For someone who actually knows networking this is probably all child's play

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: oakpacific on May 29, 2013, 05:05:26 AM

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: TimJBenham on May 29, 2013, 04:38:14 AM

Quote from: waxwing on May 28, 2013, 06:12:47 AM

Quote from: TimJBenham on May 28, 2013, 05:00:09 AM

Quote from: dansmith on April 11, 2013, 06:32:11 AM

Thanks Tim, interesting example.

The fact they do it in that way suggests the OP's way wont work, but maybe he is a better designer.

Not sure I understand you there.

Quote from: waxwing on May 28, 2013, 06:12:47 AM

Meanwhile comment: today's news on OKPay is yet another example of the urgent need for decentralizing the fiat-in part of cryptocurrencies..

Maybe we all need to get on localbitcoins. It is a lot easier to shut down an exchange or processor taking $1M a month than to shut down a 1000 randoms doing a $1000 a month.

That's the purpose of what I'm doing in this thread - if this piece of the puzzle can be worked out, we can build an online and completely decentralized version of localbitcoins. See https://bitcointalksearch.org/topic/m.2210078 for details.

oakpacific

hero member

Activity: 784

Merit: 1000

TimJBenham

sr. member

Activity: 280

Merit: 250

Quote from: waxwing on May 28, 2013, 06:12:47 AM

Quote from: TimJBenham on May 28, 2013, 05:00:09 AM

Quote from: dansmith on April 11, 2013, 06:32:11 AM

Thanks Tim, interesting example.

The fact they do it in that way suggests the OP's way wont work, but maybe he is a better designer.

Quote from: waxwing on May 28, 2013, 06:12:47 AM

Meanwhile comment: today's news on OKPay is yet another example of the urgent need for decentralizing the fiat-in part of cryptocurrencies..

Maybe we all need to get on localbitcoins. It is a lot easier to shut down an exchange or processor taking $1M a month than to shut down a 1000 randoms doing a $1000 a month.

waxwing

sr. member

Activity: 469

Merit: 253

I have a new suggestion, melding together several of the ideas already mentioned:

Adam is going to pay Betty USD in return for Bitcoins.

1. Betty puts Bitcoins into escrow
2. The software starts a proxy server on Betty's machine for Adam
3. Adam connects to his internet banking via the proxy.

The proxy acts purely as a forwarding mechanism.
I am basing this on the description:

Quote

If you want to connect to an HTTPS website via an HTTP proxy, you need to use the CONNECT HTTP verb (because that's how a proxy works for HTTPS). In this case, the proxy server simply connects to the target server and relays whatever is sent by the server back to the client's socket (and vice versa). There's no caching involved in this case (but you might be able to log the hosts you're connecting to).

here: http://stackoverflow.com/questions/3118602/convert-http-proxy-to-https-proxy-in-twisted/3186044#3186044
(the first answer)
I would *really* appreciate input from someone with good technical knowledge of SSLs and proxys to comment on feasibility of this.

4. Betty's proxy server logs the entire banking session in ENCRYPTED form. Also, Adam's software logs the whole session too, in unencrypted form.
5. If the wire transfer is successful, everyone is happy, no need to do more. If Betty disputes that the wire is received, then:
6. Escrow agent is called in. Escrow agent requests Adam to identify from his logs which pages he would like to provide to agent as proof that he did carry out the wire transfer.
7. Escrow agent requests those specific pages (which remember are still encrypted) from Betty.
8. Escrow agent requests master secret key from Adam
9. Escrow agent can decrypt the specific intended pages and verify that the wire was sent.

Plus points about this approach:
*As long as both sides have the necessary software installed, then if the transaction goes through normally, no one has to do actually *do* anything to ensure trust.
*Adam (the USD sender) has control over which HTML pages he sends to escrow in case of an audit. Normally it will be the last one or two pages of the banking session, and it may well be possible that he doesn't have to reveal any other transaction, or his balance.
*By using the counterparty as the "gateway", we remove the incentive for collusion. This is a brilliant idea and full credit to dansmith for it.

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: TimJBenham on May 28, 2013, 05:00:09 AM

Quote from: dansmith on April 11, 2013, 06:32:11 AM

Thanks Tim, interesting example.

Meanwhile comment: today's news on OKPay is yet another example of the urgent need for decentralizing the fiat-in part of cryptocurrencies..

TimJBenham

sr. member

Activity: 280

Merit: 250

Quote from: dansmith on April 11, 2013, 06:32:11 AM

waxwing

sr. member

Activity: 469

Merit: 253

Just did a little experiment. Looked at a wire transfer that I made some time ago, last August, on my statement, and saw that it only shows some kind of transaction ID, not the actual information (the receiving account number or name or bank), so that would actually be quite useless. I would have to rely on the internal messaging thing as I mentioned above, but this message is deleted by the bank after 30 days.

There will be lots and lots of little quirks like this.