# Spending bitcoin with non-custodial EMV Abusing the Visa&Mastercard protocol to sign UTXOs with no privkey exposure --- ### [silur@hcpp.cz ~]$ whoami - Hacker @ 0.0.0.0/0 - Cryptographer @ QANPlatform, CasperLabs, MTA Wigner and others - Blockchain architect&consultant - Bug bounty hunter - Malware analyst --- ## Agenda - An ancient problem - credit cards & bitcoin - HW wallets and compatibility - EMV history - EMV Protocol overview - Attack assumptions - Abuse of protocol for BTC --- ## Only 1% of the population own coins - Most end-users are dumb for new tech - UX of btc is **great**, decentralized thinking is the hard part - Backward-compatibility usually helps with tech but not so easy with crypto --- ## Not so clever plays (personal bias alert) - Stablecoins :poop: - App-only banks "supporting" crypto - Spend-fiat, exchange crypto after settlement interval - Real-time fiat exchange in custodial wallets --- ## More clever plays - HW wallets like Trezor, Ledger - But they need separate apps, APIs - (e)Commerce can't keep up with new stuff - Some HW hacks have been introduced recently - Exotic operations are not possible (no monero stealth support) --- ## My favorite hardware for security:  --- ## Why? - I don't know of any recent CC hacks on hardware level - Backward-compatible - Intuitive to most people (2.5 Billion cards out there.. excluding the US!) - Affordable compared to Ledger and friends - Support fun crypto like AES256, SHA256, and EC arithmetics generalized to GFp (support curve25519), stealth addrs, maybe even bulletproofs --- ## Requirements of this talk - Standard, commercially available JCOP card - Private key stays on the card, signs in place - Reader/terminal is unmodified - The tech does not imply fiat in the process (legal part might do) --- ## Equipment?  --- ## Remember Max Butler & Friends? - After CardingForums, Ic3man, Script and other carding gods, EMV came into play - Europay + Mastercard + Visa - Flexible, secure protocol for payment - Channel-agnostic (physical reader or NFC) - Carding came to a halt (or at least slowed down) --- ## TL;DR EMV - important fields - Most fields use ASN.1 BER format - ATC - 16bit counter that the card and the issuer both increment with every TX - AID = RID + PIX app id - PDOL - processing options data list - Issuer certificate & "contact info" in x509 - TVR - 8-bit end result of the transaction --- ## TL;DR EMV - communication - Uses standard T0 APDU format: ```ascii [CLA][INS][P1][P2][P3] | | class instruction ``` --- ## Step 1 - Select app - ... not really useful because 99% of banks issue only one app (that you actually use) - We can make coin/wallet-specific slots here, each with their own files --- ## Step 2 - getProcessingOptions - This is the first operation that increments the ATC so take care when testing - Provides the PDOL to the reader which will determine our processing decision tree later --- ## Step 3 - read app data - Interestingly you cannot specify which files to read, it's all-or-nothing so encrypt well... - Which we thankfully support on the card (AES256, even ECIES) --- ## Step 4 - check 1 - based on the provided app data (expiry, app versions) mask (binary OR) some TRV bits - ODA auth - shortly verify the certificate chain and crypto signature of the card issuer --- ## CA you say?  --- ## Not only banks can self-sign certs - Several airline loyalty cards - https://cards.barclaycardus.com/cards/barclaycard-arrival-plus-world-elite-mastercard.html - Disney - https://creditcards.chase.com/credit-cards/disney-premier - Travel agencies - https://www.citi.com/credit-cards/credit-card-details/citi.action?ID=expedia-rewards - Sports events & programs - https://www.discover.com/credit-cards/cash-back/nhl-card.html --- ## Step 5 - check 2 Cardholder verification either with: - Cryptographic Signature - Offline plaintext PIN - Offline enciphered PIN ( EU ) - Offline plaintext PIN + signature - Offline enciphered PIN + signature --- ## Step 6 risk management - Reader & card must aggree on whether continue online or offline - Reader has more power - only a small number of offline ATC increments can be made - This is the part where ATC mismatch result in card blocks and fraud response --- ## Step 7 - send transaction online - Thankfully the send endpoint is stored on the card as an AFL - we can set up our own backend - Transactions are packed into a so-called ARQC which is basically the description what we pay for and how much - **ARQC has no specified format** - ... so it can be an UTXO! --- ## Step 8 - optional second card action ... basically callbacks with AFL fields to send back to the bank --- ## Step 9 - process scripts - The ARPC (ARQC response) can have arbitrary, encrypted script to be run on the chip card, undreadable to the reader --- ## The attack: Assumptions: - We are signed by a CA (otherwise you are committing CC fraud :) - We have a synced full node - We'll use online auth to support ATMs too - We don't care how the settlement interval is closed (for legal reasons :) --- - Issuer info is stored on the card - Acquirer communicates with this issuer - No technical restriction to make your backend --- - The card stores the xpub + the UTXO list (these cards have 144kb memory) - Meanin spends outside of the card breaks it (just like the standard ATC) - getProcessingOptions should return an Online verification + PIN - the ARQC is formatted as the signed UTXO which the acquirer forwards to the issuer (us) - We validate the signature and the transaction sanity - Forward ARPC trough the acquirer with the new UTXOs as a script - **Whatever the issuer claims here is unquestioned truth** --- - At this point, both the card and the reader/terminal have done it's risk management steps, the issuer have the final say on the TX validity. - Scripts can be arbitrary javacard code, we can store our UTXOs or even replace keys --- ## Settlement? - Usually a 5-7 day interval - .. but banks use legacy software, it's much more chaotic - You don't get a CA signature without due diligence - But self-signing is not that hard (much easier than getting money transmit etc licenses) --- ## An extra assumption IF we modify the reader side we can eliminate the settlement issue with mastercard with a separate app besides the unmodified MC AID. --- ## Thanks Also thanks for Max Hillebrand for pointing out some issues with this attack \o  silur@cryptall.co  @Huohuli