Certification for ownership of a bank account

ManfredKarrer · June 2, 2018, 5:09pm

I added a proposal for a new security feature:

github.com/bisq-network/proposals

Certification for ownership of a bank account

opened 05:07PM - 02 Jun 18 UTC

closed 10:33AM - 05 Feb 20 UTC

ManfredKarrer

was:stalled

In a discussion with the same friend who set the seed for the account age witnes…s idea we came up with a new idea how to protect Bisq users against stolen bank account chargeback scammers. ## Goal We want to add additional protection to the existing protection from the account age witness to mitigate the risk for cases where a stolen bank account scammer has relative low amounts on the stolen account he wants to cash out as the account age witness method does not provide protection for those cases (e.g. amounts below 0.0625 BTC or about 400 USD with current exchange rate). The limits in the account age witness are also harder to change, so in case of a fast BTC price increase the limit in the fiat currency is getting rather high as well and with that it is lowering the protection provided from the account age witness feature. Our suggested feature for a **"certification for ownership of a bank account"** is optional and provides additional security if a user chooses to select an offer of such a "certified" Bisq trader or that he decides at his own offers to only accepts BTC buyers as taker who have been certified. The feature is only relevant as protection for the BTC seller as the scammer would be in the role of the BTC buyer. ##Assumption: A scammer who is in possession of a stolen bank account has only the online banking access but he does not has the physical ATM card nor can he go to the bank branch to withdraw money from the stolen account as at the bank counter he would need to show his ID for verification. We could use both methods to get a proof that a user is the valid owner of the bank account by requesting the user to withdraw a specific amount to himself using one of those 2 methods. ##Description We add 2 methods how Bisq users can verify the ownership of their bank account. The user can choose any of the 2 methods, whatever is easier and more convenient to him. ### Withdrawal from bank branch The user goes to a local bank branch and withdraws a predefined fractional amount (e.g. 23.45 USD). He keeps the paper receipt and as soon the withdrawal is visible in his online banking statement he requests from the arbitrator a verification (inside Bisq via a new UI feature). The verification will be done via PageSigner. If PageSigner would not work with the users banking webpage other verification methods are used (e.g. video screen sharing). A scan from the paper receipt can be requested from the arbitrator as well. ### Withdrawal from ATM The user goes to a ATM and withdraws a specific amount (multiple of 10 in a range of 20 -100 USD) and takes the ATM paper receipt. As soon he sees that transaction in his online bank statement he requests a verification from the arbitrator as described above. ## Details ### Amounts to withdraw The amounts are derived from the bank ID (IBAN/BIC,...). The result gets mapped to either a fractional value between 20 and 100 USD (e.g. the national currency the account is based on) or a multiple of 10 between 20 and 100 USD. That specific value generates a kind of fingerprint which makes it very unlikely that a scammer by chance could get such an amount displayed in the transaction history from the victim doing a bank withdrawal by themselves. The amount for the ATM amount need to be a multiple of 10 as most ATMs do not support smaller amounts. The min. amount will be 20 EUR as most ATMs have that as minimum (need a bit more research if that is correct). The max. amount is 100 EUR (could maybe also be lower like 50 EUR). #### Mapping function: 1. Convert the bank ID (IBAN/BIC,...) to a SHA256 hash and convert that to a long number. We use the same data fields as in the account age witness to select the identifying account data fields. 2. Make a modulo 8000 of that long number and divide it by 100 so we get a value in the range of 00.00 to 79.99. 3. Add 20 and use the fractional value for the bank branch version. For ATM version we round to a multiple of 10. ### UI There will be a button at the bank account payment method where the user can request a verification. The first step is that he gets the requested amounts for bank branch version and ATM version. He also gets instructions what he need to do. After withdrawal and as soon he sees the statement in his online banking transactions history he goes back to the bank account payment method and clicks another button to contact the arbitrator for requesting a verification. That will open a support ticket similar like a dispute case. There he will provide a PageSiger document to verify the transaction or in case that PageSiger is not working an alternative method decided by the arbitrator will be used. In case the arbitrator does not get convinced he can reject the request. Once the arbitrator has done the verification a signed certificate from the arbitrator will be published to the P2P network and gets matched to his payment account in a similar way we do it for the account age witness. ### Create offer and offer book Any maker of a sell BTC offer can decide to accept only BTC buyers as taker who are certified. For a buy BTC offer it does not make sense to add that option. The restriction option is stored in the preferences and will be remembered and auto-set to the latest selected value when creating another offer. At the offer book a special icon (with tooltip info) will indicate such offers which require a certified BTC buyer. Not certified users cannot take that offer and will get it displayed greyed-out with an popup when clicking on it which displays context information. When a certified user is creating an offer his offer will carry a flag to indicate that he is certified (using an entry in extraDataMap in OfferPayload). The validation will be done as part of the trade protocol (see blow). At the offer book a special icon will indicate such offers where the offer maker is certified. Even the certification is only relevant in case the maker is the BTC buyer we can show it in both cases to avoid confusion to users who don't fully understand the concept. There is no restriction that a maker requiring certified BTC buyers need to be certified by himself. ### Arbitrator verification process The arbitrator will get the requested amounts displayed in the request ticket in a new UI screen similar to the existing disputes list. The request carries the users payment account data so the arbitrators application can calculate and verify the requested amounts and display it to the arbitrator. After verifying with the provided PageSigner doc (or alternative methods) that the withdrawal was done the arbitrator confirms and with that he signs a certificate that the payment account with the specific data has been verified with the withdrawal of the requested amount. The application is publishing that certificate data to the P2P network. The user will see in his payment account that it is now certified. ### Verification and data handling The arbitrator publishes his signed certificate to the P2P network using the hash of the bank ID as key and the arbitrators EC signature of that hash together with the arbitrators index in the pubKey list as value stored in a hashmap. ``` hash = RIPEMD160(Sha256(identifying bank data, e.g. IBAN+BIC)) -> 20 bytes signature = sig(hash, EC key) -> 71-73 bytes index = Index of public Key in hard coded list of arbitrators keys. Index is represented as a single byte. Hashmap: Key: hash Value: index concatenated with signature ``` The data size of the hashmap for 100 000 certificates would result in 9.2-9.4 MB. As that data is stored at all nodes and all users can have multiple certificates we have to be careful to keep the data footprint low. A solution to avoid persisting the signature at all is that the signature check is done at storage time and only valid signatures lead to persisting the hash in a persisted list. That would require only 20 bytes per payment account certificate and also avoids repeated signature checks. With that model we have a data size of 2 MB for 100 000 certificates which seems a pretty low footprint. So the published data from the arbitrator contains both hash and signature but the persisted list only gets filled up with hashes after the signature of the data item has been verified. All Bisq users will receive those certificate data items and they can see if a specific payment account has its hash already in that list. With that model we can support also the cases when an arbitrator has left as the hard coded list of arbitrator pubKeys will not change. Similar as with the account age witness the taker cannot verify a makers certificate before actually taking the offer as only in the trade protocol the peers account data are exchanged. But that is not a problem as a maker who used a fake certificate in his offer would get rejected in the take offer process and loses his maker fee as the offer got taken but has failed. ## Privacy and centralization concerns The arbitrator will play an additional critical role by collecting all the bank account data of the certified Bisq users. The implementation will auto-delete those data after the certification is published but once the arbitration system is fully decentralized we should consider to decouple that role from the arbitrator and leave it to very few operators with high reputation who are trusted to not violate that promise to delete the data (not modified the software). But ultimately that is a critical problem where not good solution is known. ## Using a new role instead of arbitrator It would make sense to separate the role from the arbitrator even if the persons doing it are carrying out both roles. That topic is subject for discussion and will require a bit more analysis to estimate the effort for separating the roles. ## Limitations: - It will not work with all payment methods if those withdrawal methods (bank branch, ATM) are not supported. - Theoretically it could be that an account from a certified Bisq user gets stolen. In such a case the protection will not help. We consider it highly unlikely that this will be the case. BTC users are usually not victims of phishing attacks where most of those accounts get harvested. Though we could use the filter feature where the Bisq founder can publish a message which ignores certain certificates, thus even the certificate is in the data structure it would not get accepted from the application. ## Wording We should find a good term for the feature. Certification or verification might lead to confusion with KYC style verification. Content wise the best description IMO is that it is a "proof of bank account ownership". Any suggestion for a clear in-ambigious term is highly welcome! ## Not intended extensions Basically by proofing account ownership we would use the verification data also as anchor to a real life identity of the user. E.g. in case of a scam committed by that user the payment account data could be used to identify the user and use that for legal steps against him. But that model would have several problems: 1. Legal steps are expensive and most users will probably not go that route anyway 2. The arbitrator would need to store all the payment account data forever, which introduce severe privacy problems. For those reasons it is not intended to extend the suggested feature to such a broader model. **UPDATE:** From the discussions below we found a more privacy protecting model: The account verifier (arbitrator) will only receive the bank name and hash. He will use a screensharing session instead of PageSigner as most banking webpages reveal bank ID and/or name on the transaction history page. In the screensharing session the user is instructed to only reveal the transaction which shows the withdrawal with the requested amount. Furthermore the bank name (address bar) must be visible. The hash will be created from the bank ID + a persisted salt to avoid that the bank could find the hashes of their clients. The verification will be done by the trade peer in the trade protocol where he checks if the hash is correctly derived from the bank ID. Probably we use additional 2 or 3 relevant digits of the bank ID to reduce the chance that a scammer could trick the system in case he has a own bank account at the same bank as his stolen account. So that data would be added in the verification process. We will specify that in more details once the basic idea of the proposal gets accepted. With that modified version the verifier will not learn any identifying data of Bisq users. The only open issue is that the amount (in case of bank counter withdrawal) is kind of a finger print and banks could theoretically spot such clients as potential Bisq users. Though that has a big risk for false positives for them. If they would get the verification data from the verifier they could identify a client to a Bisq user with it's onion address and it's verification hash. Though a Bisq user can change his onion address when starting a new data directory (as well there is an open issue to support that in the UI).

Feedback highly welcome! Best inside of the proposal to have it collected in one place.