Bitcoin Forum
July 29, 2021, 05:06:09 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 »  All
  Print  
Author Topic: tlsnotary - cryptographic proof of fiat transfer for p2p exchanges  (Read 42677 times)
waxwing
Sr. Member
****
Offline Offline

Activity: 469
Merit: 250


View Profile
December 10, 2013, 11:06:52 AM
 #181

Here are a few slides I put together last week. Rough notes actually, intended to be combined with verbal descriptions. Not sure if it's useful as if you've been following the project you'll already know most of it, otherwise you probably won't understand it. However, there is a diagram in there which might be helpful.

https://github.com/AdamISZ/multisig_lspnr/raw/master/Paysty.pdf


PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1627578369
Hero Member
*
Offline Offline

Posts: 1627578369

View Profile Personal Message (Offline)

Ignore
1627578369
Reply with quote  #2

1627578369
Report to moderator
1627578369
Hero Member
*
Offline Offline

Posts: 1627578369

View Profile Personal Message (Offline)

Ignore
1627578369
Reply with quote  #2

1627578369
Report to moderator
waxwing
Sr. Member
****
Offline Offline

Activity: 469
Merit: 250


View Profile
December 17, 2013, 01:19:56 PM
 #182

Here is a much more detailed suggested architecture, not dependent on oracles and not dependent on buyer/seller reputation or identity persistence (intra-transaction) (formats pdf and libre office):
https://drive.google.com/folderview?id=0B-fjs8k25mNAemdxWkpmRFJmNm8&usp=sharing

The trust is in a pool of escrows, which must have some recognizable identity. The slightly complicated set up of a transaction, and escrow choice is all designed to make it both costly and infeasible to achieve collusion between escrow and one party, to cheat the other.

Criticisms more than welcome!

PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3626
Merit: 1852



View Profile
December 17, 2013, 08:18:36 PM
 #183

Here is a much more detailed suggested architecture, not dependent on oracles and not dependent on buyer/seller reputation or identity persistence (intra-transaction) (formats pdf and libre office):
https://drive.google.com/folderview?id=0B-fjs8k25mNAemdxWkpmRFJmNm8&usp=sharing

The trust is in a pool of escrows, which must have some recognizable identity. The slightly complicated set up of a transaction, and escrow choice is all designed to make it both costly and infeasible to achieve collusion between escrow and one party, to cheat the other.

Criticisms more than welcome!

Escrow pool .... interesting.

waxwing
Sr. Member
****
Offline Offline

Activity: 469
Merit: 250


View Profile
December 18, 2013, 07:06:20 PM
Last edit: December 18, 2013, 07:24:39 PM by waxwing
 #184

Here's an updated version with the following change: sharing numbers to create a random number is not a good idea on the CNE (I will spare the details for those who want to discuss it); instead we use only publically verifiable information, initial suggestion the last few bytes of the next blockchain hash after the funding of deposits.

Additionally, a "proxy service agreement" for the seller will be necessary since costless abort is no longer possible when on the RE.

More to the point, I added two slides at the end to show the map of transaction states through the protocol.
 
https://docs.google.com/file/d/0B-fjs8k25mNAcEltbzNtWjJXdEU/edit

As before, criticisms welcome, especially attacks.

(Edit: here is an interesting public source of randomness: https://beacon.nist.gov/home)

PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
dansmith
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
February 07, 2014, 03:24:35 PM
Last edit: February 07, 2014, 09:06:52 PM by dansmith
 #185

I'd like to bring you up to speed on what I've been doing over the last 2 months or so.
I came up with a much more efficient method of proving the ownership of HTTPS pages which I dubbed "tlsnotary".

Here's why tlsnotary is better that the current working solution a.k.a paysty:

- tlsnotary does not require the use of Amazon EC2 oracle instances
- in tlsnotary the traffic from the auditee flows directly to the bank, as opposed to via the oracle instance in paysty.
- it does not require the escrow agent at all, i.e. can be used p2p between the buyer and the seller of the BTC.

Here's the simplified explanation:

During a TLS connection, the bank's server uses a symmetric encryption key to encrypt the HTML page and also uses a MAC key to "sign" the HTML. It is sufficient for the auditee to only know the server's encryption key in order to decrypt the HTML, the MAC signature check only ensures that the TLS data from the bank was not modified in transit.
Thus we can delegate it to the auditor to calculate the encryption key and the MAC key. The auditor then hands the encryption key to the auditee but keeps the MAC key. Having the server encryption key, the auditee can now decrypt data from the bank. Because all messages are "signed" by the bank using the MAC key and only the bank and the auditor know the MAC key, a correct MAC signature can serve as proof that certain messages came from the bank and were not spoofed by the auditee.

Here's the in-depth explanation of the TLS workflow: with references to RFC2246

   The auditee connects to the bank's server and starts a TLS handshake.
   The auditee gives the auditor the bank's public key, client_random and server_random.
   The auditor generates pre-master secret(PMS) and encrypts it with the bank's public key, calls it A) encrypted PMS. (see 7.4.7.1. RSA encrypted premaster secret message)
   Using PMS, client_random, and server_random, the auditor derives master secret (MS) - an intermediate step. (see 8.1. Computing the master secret & 5. HMAC and the pseudorandom function)
   Then using MS, client_random, and server_random, the auditor derives B) server encryption key, C) client encryption key, D) server MAC and E) client MAC. (6.3. Key calculation & 5. HMAC and the pseudorandom function)
   The auditor forwards A), B), C), E) to the auditee. Keeps the server MAC.
   TLS requires that the handshake be verified. For that the auditee submits to the auditor md5 and sha hashes of all the handshake messages. The auditor then uses MS, md5 hash and sha hash to calculate the verify_data which gets sent back to the auditee. (see 7.4.9. Finished & 5. HMAC and the pseudorandom function)
   The auditee finishes the TLS hahdshake and continues with the data exchange OMITTING the MAC check. (because the auditee must not know the server MAC key for the scheme to work.)
   When finished, the auditee presents the auditor with a network trace file containing the encrypted HTML in question. The auditor checks the TLS record against the server MAC key to ascertain that it originated from the server.

How this will be implemented:
   I already implemented this and know that it works for TLS 1.0&1.1 with RSA-AES128&256 ciphers, I just need to package the tools in an end-user-consumable way.
   I made a small patch to the NSS library, the one which Firefox relies on for TLS crypto.
   I need to setup a gitian environment to build the NSS library. This way multiple people can replicate the build process and confirm the hashes of the builds. This will allow me to distribute the patched NSS libs in binary form.
   The Auditee will be requires to use Firefox with a patched NSS library.
   Auditee-to-auditor communication will be happening on an IRC channel.


Questions are welcomed.

https://tlsnotary.org
Transferable webpage content notarization.
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1025


View Profile
February 07, 2014, 10:28:09 PM
 #186

That's beautiful! Congratulations! I wondered throughout this entire thread if there was a way to do some creative hack or abuse of the protocol to get the needed effect, but I never knew enough about TLS to come up with one.

The only issue I see, which I'm sure you already thought about, is that by stripping the server MAC it may become possible to do some kind of content injection MITM attack on the live connection. However, as you can snapshot just a single page and the user already knows what content to expect anyway, I suspect that's not a big deal in practice especially if the HTML is not rendered (as otherwise various kinds of cookie stealing attack might be possible). I mean, I suspect it's rather hard to usefully inject data into the middle of a TLS stream even without the server MAC, but it's obviously there for a reason.

Is there a risk of k-lining or attacks if using IRC for rendezvous? IRC is typically unauthenticated. I wonder if direct ip to ip with STUN would be feasible.

edit: By the way, I'd suggest running your scheme past Adam Langley and see what he thinks. He is a TLS expert who works for Google and has designed a bunch of recent TLS extensions.
waxwing
Sr. Member
****
Offline Offline

Activity: 469
Merit: 250


View Profile
February 07, 2014, 10:53:10 PM
 #187

So Dansmith and I discussed this in December. I have yet to be convinced that this idea is safe. My issue is not so much the stripping of the server mac (I agree that needs to be assessed, maybe it already has), but that the auditor possesses the master secret. Whilst attacks may be practically difficult, it seems to me that this isn't safe. I would love to be convinced otherwise, as it's a powerful idea and full credit to dan for managing to modify NSS to allow it to work.

Edit: to clarify, the issue is that in this architecture the auditor possesses the master secret in real time, ie. the MS of the live connection, whereas in previous architectures the master secret was only passed to the auditor after the connection was torn down (long after).

PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
dansmith
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
February 08, 2014, 08:50:03 AM
 #188

Thank you for good comments.
The only issue I see, which I'm sure you already thought about, is that by stripping the server MAC it may become possible to do some kind of content injection MITM attack on the live connection...
Edit: to clarify, the issue is that in this architecture the auditor possesses the master secret in real time, ie. the MS of the live connection...
Yes, this is THE weakness of tlsnotary for which there is no mitigation. If the attacker is the auditor (or the attacker has compromised the auditor's machine) AND the attacker is controlling the auditee's home router, then It's a full-on MITM attack. The attacker can channel modified or unmodified traffic to-from the bank and on top of that he can inject any kind of HTML. Even after the auditee stops the "recording" and logs out, the attacker can spoof the logout page and  still have a functioning connection to the auditee's bank and can do whatever he wants.


Is there a risk of k-lining or attacks if using IRC for rendezvous? IRC is typically unauthenticated. I wonder if direct ip to ip with STUN would be feasible.

Ideally of course, the auditor and the auditee should exchange their public keys via some alternative channel and only then meet on IRC. Each message between them must be digitally signed. Then the possibility of an attack is mitigated.
STUN is possible, but someone must be running the STUN server and get paid for that. That's why IRC was my first choice. Besides, I also thought that having an independent third-party logging the IRC channel may serve as an extra safeguard if one of the counterparties breaks the protocol. This way even if the auditor and the auditee don't trust each other to even follow the protocol, they still can meet on IRC and invite an arbiter to monitor the channel.

https://tlsnotary.org
Transferable webpage content notarization.
nomailing
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
February 10, 2014, 07:43:11 PM
 #189

This looks promising.

Yes, this is THE weakness of tlsnotary for which there is no mitigation. If the attacker is the auditor (or the attacker has compromised the auditor's machine) AND the attacker is controlling the auditee's home router, then It's a full-on MITM attack. The attacker can channel modified or unmodified traffic to-from the bank and on top of that he can inject any kind of HTML. Even after the auditee stops the "recording" and logs out, the attacker can spoof the logout page and  still have a functioning connection to the auditee's bank and can do whatever he wants.

I think it is anyway standard to have 2 factor authentication enabled. At least all banks in Germany that I know ask for a unique TAN before every new action or money wire.

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
waxwing
Sr. Member
****
Offline Offline

Activity: 469
Merit: 250


View Profile
February 11, 2014, 04:27:17 AM
 #190

I think it is anyway standard to have 2 factor authentication enabled. At least all banks in Germany that I know ask for a unique TAN before every new action or money wire.

It doesn't remove all the risk, and it will be very bank dependent, but - you make a good point.

PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1025


View Profile
February 12, 2014, 04:58:37 PM
 #191

Yes, use of 2FA for wire transfers is standard these days at least for European banks.
waxwing
Sr. Member
****
Offline Offline

Activity: 469
Merit: 250


View Profile
February 23, 2014, 08:33:36 AM
 #192

Further concerns/questions about the tlsnotary model. All of this is obviously modulated by how difficult the attack is, but all the same.

1. Since the purpose of the ssl logging is to provide objective proof to some other party that the payment was made, the possible attacks are not restricted to redirecting a payment to a new bank account. Any tampering with the data that invalidates the record allows the btc seller to give "objective evidence" that the wire transfer did not take place, when actually it did, and thus defraud the buyer.


2. The nightmare scenario might still allow direct stealing, even with 2FA:
The black hat auditor has inserted himself as MITM between you and the bank. You request a wire transfer to account X (00001234), the MITM modifies it to send a request to transfer to account Y(00005678) to the bank. The bank sends back the challenge for the 2FA device, expecting the user to enter the last four digits of account Y to get the correct response. The MITM modifies this web page so it says "enter the digits 5678" instead of "enter the last four digits of the account number". Thus, the MITM receives the correct response from the client and forwards that to the bank, enabling the fraudulent transfer.

You may very reasonably say that most users are not so stupid to follow such instructions, but there are plenty of limitations on that: systems can't rely on users not being stupid, users tend very strongly to trust (and even obey!) their bank if they are convinced that they're actually talking to their bank (principally through the "padlock thingy" in their browser, combined with their own passwords), and last but not least, the MITM's ability to modify the html contents allows them to exercise their creativity in phrasing the instructions to make users trust it. Here's an example of such creativity: "enter the account number here - ... - now the system will now generate a one-time code to be entered into your 2FA device ... hourglass ... here it is: 5678". It is not that difficult to bamboozle people, at least the less intelligent 50% of people.

3. As I opined before to dansmith, security experts will not sign off on this kind of thing, I'm pretty sure. It violates the essential principle of ssl. Banks, moreover, will be within their rights to attack us as we would genuinely be weakening their security model. Users are already very distrustful of even logging the encrypted ssl session (even though any node on the internet could do that). How much more so here.

PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1025


View Profile
February 23, 2014, 05:25:59 PM
 #193

One thing that wasn't clear to me - the auditor doesn't seem to create local randomness at any point. If the auditee has both client and server random, then what stops it repeating the exact same process?
dansmith
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
February 23, 2014, 06:27:42 PM
 #194

@Mike Hearn
The auditor generates a 48-byte random Pre-master secret
The auditor then encrypts the PMS with the bank's key and gives the encrypted PMS to the auditee.
Thus, the auditee never knows the PMS.

https://tlsnotary.org
Transferable webpage content notarization.
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1025


View Profile
February 23, 2014, 06:56:54 PM
 #195

Ah, got it. I didn't realise the PMS was random. Great.

waxwing
Sr. Member
****
Offline Offline

Activity: 469
Merit: 250


View Profile
February 24, 2014, 09:55:35 AM
 #196

Here's an updated version with the following change: sharing numbers to create a random number is not a good idea on the CNE (I will spare the details for those who want to discuss it); instead we use only publically verifiable information, initial suggestion the last few bytes of the next blockchain hash after the funding of deposits.

Additionally, a "proxy service agreement" for the seller will be necessary since costless abort is no longer possible when on the RE.

More to the point, I added two slides at the end to show the map of transaction states through the protocol.
 
https://docs.google.com/file/d/0B-fjs8k25mNAcEltbzNtWjJXdEU/edit

As before, criticisms welcome, especially attacks.

(Edit: here is an interesting public source of randomness: https://beacon.nist.gov/home)

An update - it seems it this proposal might be a bit easier to understand if explained in a bit more detail, so I wrote a semi-detailed description here:
https://github.com/AdamISZ/stegabank/blob/master/protocol.md

It's a fairly big wall of text of course, but maybe it's helpful.

As you can see I've made a new repo with the name 'stegabank', you can see the rest of the code in there if it's of interest.

PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1025


View Profile
March 22, 2014, 06:56:40 PM
 #197

I noticed today that my bank (UBS) can be told to generate digitally signed PDFs for wire transfers. No SSL tricks necessary, just load it into Adobe Reader and you get a document signed by the bank attesting to _only_ that transfer. This is pretty sweet: exactly what we need.

It makes me wonder how many other banks have a similar feature. Seems like this project can really be split into several pieces: ability to meet counterparties like on localbitcoins, ability to make a dispute mediated trade, and ability to extract a proof from lame banks that don't provide any kind of crypto proof of transfer.
oakpacific
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
April 10, 2014, 05:59:29 PM
Last edit: April 13, 2014, 12:25:23 PM by oakpacific
 #198

A short update of the project status: we have managed to tackle the MITM problem by splitting the MS/keyblock generation process between the auditor and the auditee, as it turns out, the RFC 2246 TLS standard effectively allows the splitting in the definition of the MS generation function:

PRF(secret, label, seed) = P_MD5(S2, label + seed) XOR P_SHA-1(S1, label + seed),

where S1 and S2 are the first and second half of the 48 bytes PMS, respectively.



The basic procedure is a modification from that posted by dansmith: https://bitcointalk.org/index.php?topic=173220.msg4998488#msg4998488.

1. The auditee connects to the bank's server and starts a TLS handshake.
  
2. The auditee gives the auditor the bank's public key, client_random and server_random.

3. Both auditee and auditor independently generate 24 bytes of random data, called S1 and S2 respectively per the definition of the RFC2246 standard.

4. Both parties then cooperate to generate the encrypted PMS with the bank's public key, using the homomorphic property of RSA encryption:


RSA(2^(k_p)*P+2^(k_1)*S1+1)*RSA(2^(k_2)*S2+1) mod n=RSA(2^(k_p+k_2)*P*S2 + 2^(k_p)*P+2^(k_1+k_2)*S1*S2+2^(k_1)*S1+2^(k_2)*S2+1),

where P is a factor used in construction of the PKCS RSA padding. As can be seen from the result of the above equation, the cleartext PMS that is to be used by the bank can be splitted clearly into parts which can be generated separately by an auditor/auditee, as long as k_1 > k_2+k_s, where k_s is the number of digits of S2.

5. The auditee calculates P_SHA-1(S1, label+seed), generating 48 bytes - H_1 = H_11||H_12, where H_11 and H_12 are of equal length of 24 bytes.

6. The auditor calculates P_MD5(S2, label+seed), generating 48 bytes - H_2 = H_21||H_22, where H_21 and H_22 are of equal length of 24 bytes.

7. The auditor gives to the auditee H_21.

8. The auditee gives to the auditor H_12.

9. The auditee constructs M_1 = H_21 XOR H_11 (the first half of the master secret).

10. The auditor constructs M_2 = H_12 XOR H_22 (the second half of the master secret).

11. The auditee now calculates X=P_SHA-1(M_1, label+seed).

12. The auditor now calculates Y=P_MD5(M_2, label+seed).

13.The auditor and auditee share those bytes of each of X,Y which allow the other party (using XOR again) to generate the required secret data: for the auditor, the server mac secret, and for the auditee, the client and server encryption keys. During the whole process, neither the auditor nor the aduitee has access to the full PMS/MS/keyblock, which prevents both the MITM attack from being carried out, and the forgery on auditee's part. The finished handshake message can be generated similarly as it uses the same PRF function.

Known problems:

Padding the secret is a bit tricky, as it needs to meet certain specified format, however we are already able to generate valid PMS at a high probability(about 90% of the time).

The entropies of both S1 and S2 are a bit too small, with that of S2 being as small as 10 bytes, however any brute-force attack can only be conducted in real-time as the PMS will not be reused, so even 2^80 possibilities pose a formidable challenge to any known potential attacker.

The above procedure will only work for TLS 1.0/1.1, as the TLS 1.2 changes the PRF to use a single SHA-256 function, yet given the slow pace of IT infrastructure upgrade it would take many years before the TLS 1.0/1.1 are phased out.

Implementation:

All of the modifications are already implemented, live trials have been conducted successfully as well, right now dansmith is working on polishing the NSS patch.

As always, questions are welcomed, especially attacks against the security.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1025


View Profile
April 10, 2014, 08:56:32 PM
 #199

Amazing work once again. I don't have the time/energy to check the maths unfortunately, but it sounds plausible.
bitcool
Legendary
*
Offline Offline

Activity: 1441
Merit: 1000

Live and enjoy experiments


View Profile
June 05, 2014, 12:58:04 AM
 #200

Looking forward to using the actual service.
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!