Research: Can Privacy and Traceability Exist Together: Tracing Keys and Jurisdictions?

Blog: https://medium.com/asecuritysite-when-bob-met-alice/can-privacy-and-traceability-exist-together-tracing-keys-and-jurisdictions-bfc395d502a Introduction Privacy and traceability are two sides of the same coin, and where the coin will never land on its side. If you want privacy in a transaction, you have to hide the payer and payee and the transaction value. All that needs to happen is that there is proof that the payer has enough currency to pay the payee. We can do this with a range proof — so that Bob can show that the sum of his previous transactions minus the current one is greater than zero. But, this stops any traceability and stops investigators from investigating the trail of an illegal transaction. It’s a dilemma that can keep cybersecurity professionals awake at night and where a few bad apples can spoil the whole bunch. But, if we add traceability — such as in Bitcoin — we remove the privacy aspect, and if someone links your Bitcoin address to you and the others you trade with, they will be able to see all your transactions. “Ah, I see”, they might say, “That Bill has just bought a ticket for a bus journey in Edinburgh at 10:03 am”. Along with this, we have different requirements in different jurisdictions and where we might want to limit the investigator power in one jurisdiction to others. For this, John Gilmore — one of the original Cipher Punks — wrote: “We are literally in a race between our ability to build and deploy technology, and their ability to build and deploy laws and treaties. Neither side is likely to back down or wise up until it has definitively lost the race” And, so, the tension between strong cryptography, which protects privacy, and the ability to monitor and investigate remains as open as ever. In the UK, the Online Safety Act could aim to insert backdoors in cryptography in order to monitor communications. So, is it possible to keep things private but also make them traceable? For this, a new paper outlines the TRCT (Traceable Anonymous Transaction Protocol for Blockchain) protocol [1]: The focus of the paper is on the anonymous cryptocurrencies such as Monero, Dash and ZCash. It uses an Extractable Proof of Knowledge (EPoK) to produce a Zero Knowledge Proof (ZKP) for a transaction. This can then be added to the RingCT method of anonymity to produce traceable transactions for the participants and the amount transacted. The transaction, though, is still kept anonymous. The paper pinpoints the usage of Monero in a number of crimes, such as for the Wannacry ransomware attack and where the adversaries converted their Bitcoin rewards into Monero tokens [here], and which has not been since been traced. This problem has become so difficult for law enforcement that privacy-protecting cryptocurrencies have been banned in Canada, South Korea and Australia. TRCT An overview of TRCT is defined in Figure 1. With this, we have a miner which collects broadcasted transactions, and creates a consensus with other miners. An Authority is then responsible for linking account addresses and transactions and which can trace anonymous account addresses of the actual payer and payee and resolve the transaction amount. For TRCT, the payer generates a long-term key pair and then creates a one-time address (Figure 1). This can then be sent to the payer. The transaction is then anonymised for the payer address, payee address and transaction value using the Ring CT protocol, and which integrates the EPoK scheme. The miner then receives this and checks that it is valid and that the payer has enough currency in their account to make the payment. Next, the miner will check the EPoK so that it can be traced by the authority — and without discovering the secret details in the transaction. The authority can then trace the hidden content in the transaction (Figure 2). Figure 1 [1] Figure 2: [1] While applied in RingCT, the TRCT can be generally applied to any permissionless and permissioned blockchain, as it does not affect the underlying logic of the blockchain. In this, a trusted authority creates a tracing key and publicises its public key to the miners and whether these miners may be enabled or not for the integration of EPoK. In a permissioned blockchain, there are typically fewer nodes that create the consensus, and where it is thus easier to broadcast and update the tracing key. Overall, the authority is then used to oversee all the transactions, and decide whether there are illegal transactions, and also trace them. The control of the tracing key can then use attribute-based encryption to control its usage and using threshold-based sharing to control the usage of the key. For example, the FBI, CIA and GCHQ could agree on a 2-from-3 share approach, where two agencies have to come together to regenerate the tracing key. This approach allows for different jurisdictions to generate their own tracing key and where they cannot trace within any other jurisdiction. The addition of tracing tags also allows the tracing of high-value transactions. Next, let’s cover ring signatures and RingCT. Ring signatures And so there has been a leak of information at the White House. Donald Trump calls in his Cyber Security leads and tells them, “I know one of you leaked the information, but I can’t tell which one”. How can Donald tell that one of his leads has leaked the information but does not know which one? Well, this can be achieved with a ring signature, and which provides anonymity, unforgivably and collusion resistance. A ring signature is a digital signature that is created by a member of a group which each has their own keys. It is then not possible to determine the person in the group who has created the signature. The method was initially created by Ron Rivest, Adi Shamir, and Yael Tauman in 2001, and in their paper, they proposed the White House leak dilemma. Creating the ring In a ring signature, we define a group of entities who each have their own public/private key pairs of (P1, S1), (P2, S2), …, (Pn, Sn). If we want an entity i to sign a message (message), they use their own secret key (si), but the public keys of the others in the group (m,si,P1…Pn). It should then be possible to check the validity of the group by knowing the public key of the group, but not possible to determine a valid signature if there is no knowledge of the private keys within the group. So let’s say that Trent, Bob, Eve and Alice are in a group, and they each have their own public and secret keys. Bob now wants to sign a message from the group. He initially generates a random value v, and then generates random values (xi) for each of the other participants, but takes his own secret key (si) and uses it to determine a different secret key, which is the reverse of the encryption function. He now takes the message and takes a hash of it, and thus creates a key (k). This key will be used with symmetric encryption to encrypt each of the elements of the ring (Ek), and then each element of the ring uses an EX-OR function from the previous element: Each of the random values for the other participants is then encrypted with the public key of the given participant. Bob then computes the value of ys in order to create the ring (the result of the ring must equal v). He will then inverse this value to produce the equivalent private key (xs). Bob now releases the overall signature, and the random x values, along with the computed secret key. To check the signature, the receive just computes the ring and checks that the result matches the sent signature. The basic method are: 1. Generate encryption with k=Hash(message). 2. Generate a random value (u). 3. Encrypt u to give v=Ek(u). 4. For each person (apart from the sender): 4.1 Calculate e=si^{Pi} (mod Ni) and where si is the random number generated for the secret key of the ith party, and Pi is the public key of the party. 4.2 Calculate v=v⊕e 5. For the signed party (z), calculate sz=(v⊕u)^d (mod Nz) and where d is the secret key of the signing party. We will end up with the signature (v=Ek(u)), and which completes the ring. The basic method involves creating Bob creating fake private keys for the other people in the ring: The verification of the ring is then: Ring Signatures in Monero The major problem with the Bitcoin network is that the amount of a transaction and the sender and receiver of the funds are not private, and someone who knows someone’s address can trace their transactions. This is the case because the blockchain needs to check that the sender has enough funds to pay the recipient. Thus many cryptocurrencies are looking for ways of anonymising the transaction. Ethereum, for example, uses zk-Snarks to hide identities. One method of preserving identity was proposed by Rivest et al and used RSA encryption. Unfortunately, it is not efficient for modern systems, thus, Greg Maxwell’s defined an elliptic curve method as a new way of creating the ring signature: the Borromean ring signature [paper]. The cryptocurrency Monero then adopted the method for anonymising transactions but has since migrated to a new method: Multi-layered Linkable Spontaneous Anonymous Group signature. This method hides the transaction amount and the identity of the payer and recipient [paper]. It is now known as RingCT (Ring Confidential Transactions), and was rolled out in January 2017 and mandatory for all transactions from September 2017. Conclusions TRCT provides a roadmap for the integration of tracing keys and the segmentation of rights of access. It is unlikely that we will see the implementation of this method is Monero anytime soon, but it could be applied to new methods. It is only interesting to see it applied to permissioned blockchains, and it could be useful in banking applications which require privacy but traceability. References [1] Duan, J., Wang, L., Wang, W., & Gu, L. (2023). TRCT: A Traceable Anonymous Transaction Protocol for Blockchain. IEEE Transactions on Information Forensics and Security.