A Grammar for Proportionality Analysis in Digital Systems

Transcript

Thank you, thank you for inviting me here. Also in India. You know, there was this privacy judgment in India that happened because of Aadhaar. And the privacy judgment put privacy in Article 21, not only upheld it as a constitutional right in India.

But it also turned around, you know, in computer science traditionally we have thought of privacy as secrecy, right? If you look at IEEE S&P, if you look at cryptography like the way Shruti talked earlier, we have talked about privacy as secrecy. But this judgment, I think, put privacy in dignity and autonomy more than secrecy, right? And? And I don't think that computer science has techniques to deal with stuff like dignity, autonomy, and Article 21 rights .

That's not the way we have been looking at privacy and security at all, right? So the test that this judgment prescribed for digital systems, looking at large public service digital systems right? These are not private applications but public service digital systems such as UPI, is that there has to be a law. Uh, it has to be supported by a law. The state must show us a legitimate aim in doing this. There has to be a legitimate state interest. The state must also show proportionality right?

So any digitalization involves a risk. There is a privacy risk, there is a security risk, and the risk cannot be made, can be minimized but cannot be made zero, right? So the benefits in some way must outweigh the risk, and that's the proportionality that will be part of this talk. And I think they also talked about procedural safeguards. But when you talk about proportionality , you know, weighing the benefits and the risks, that's a, that's a weird beast, right? I mean, every time, anywhere, people have tried to do that they have fallen foul, and the burden lies with the state and logically must be done. So GDPR,

the law in Europe, says that this has to be done before deployment, right? So that, and in India we sort of ignored that bit, and our DPD Act says that this has to be settled by litigation post facto right? After the, after the horse has bolted. And So, so the question is, whichever way you do it, what are the methods? That's what, that's what I will try to address . So weighing risks to precise gains, right?

You know the the the digitalization that you are bringing in like electronic health programs. So both articulations have to be precise if you have to balance it, right? I mean , if they are not balanced correctly, then people will just talk past each other. So you require a grammar. That's where the grammar comes in. And I will try to suggest what a grammar for a smart articulation may look like. And this is not an easy problem. In GDPR , you know, the Dutch welfare scandal shows a— And in GDPR, you know, there are 2,000

fines resulting in some 4 billion euros in fines total since GDPR came in. So all those prior proportionality analyses have gone wrong. Right? Whoever did it, GDPR requires that there has to be a prior proportionality analysis, and those have gone wrong. So in the Aadhaar judgment also, the majority weighed that the benefits— there is a targeted delivery to the poor . De-duplication of Aadhaar was upheld as the main reason why Aadhaar is constitutional. And the verdict for the majority was it's proportionate. The dissenting arguments say that the exclusion, the authentication failure, is an architecture for surveillance.

And the verdict for the dissent was unconstitutional. You know, trained Supreme Court judges applied the same test on the same data. Came to completely opposite conclusions . So, so this is not an easy business, right? I mean, this is— This requires new computer science. So I'll talk about the grammar for risk and I will build around two cases. Maybe I'll talk about the payment system a little bit more because everybody understands UPI, you know, the way you make a payment.

And if time permits, maybe I'll talk about electronic voting also. That's the, that's the, that's the holy grail; there is the hardest of all systems to design, right? And— So here is something that I borrow from the security literature in computer science, right? And— How to specify a risk model? So there is a tool in security called " ideal functionality." So in a real protocol, which is on the right-hand side, There are actors or players A, B, C, D, right?

So in the UPI application, this will be a payer, the payee, the bank, or whoever is involved there—A, B, C, D kind of people. So they execute a protocol, a well-defined protocol among each other, right? And you model an adversary; that's a threat model. So the adversary can corrupt one or more of the actors, can corrupt all hardware , can corrupt all software, And sees almost every message that transpires, right? Who has paid to whom , and so on and so forth.

And then you model the risk of what the adversary can do, right? That's what we do in security and we model this in an ideal functionality framework by saying that the actors don't— >> So

>> There are two banks involved, you know, B0 and B1. There should be a regulator; there are none here, but there should be one. There is a weak regulator called the RBI which is not doing much in this case, but there needs to be a regulator in this application. There has to be an adversary which is violating privacy, making payments fail , making a payer and payee fight with each other, right? And then there is an app. You know, we say that it is our Indian sovereign payment structure, but to me, it looks like it's controlled by Google and Walmart, right? It's PhonePe and Google Pay, primarily.

And there have to be some trust assumptions—which parties are trusted and for what exactly—that's what models your privacy risk. So, I would say the reasonable expectation is that the bank should be trusted only for their relationship with their client, but not with the other payee's information, and definitely not the purpose of the transaction. The bank has no business knowing that I bought coffee at Blue Tokai, right? Uh, The regulator should be trusted only for dispute resolution; it should not get to see any part of the transaction.

Otherwise, everyone else in the system should be untrusted. The network should be unreliable but eventually deliver. We will call it partially synchronous, if not completely asynchronous, partially synchronous. Uh, the big question is the app; should it be trusted and should it not be trusted, right? It depends on the kind of threat model that you are talking about if you don't trust the app. >> In a threat model, I would say that both

parties require a proof of payment, non-payment, or whatever happened. Finally, there has to be a file dispute and resolve dispute protocol. And you know, it's a financial application, so commit, valid, and funded. So if the transaction goes through, commit. If the transaction doesn't go through, abort. And there is an adversarial network that will control the delay, control the order, but the final status is always delivered. So for example, a little bit of thought will tell you there are two parties communicating, and they have to communicate with the bank.

In case of a network failure, there can be no ACK, right? And you will have to wait on an ACK of an ACK, and an ACK of an ACK of an ACK, so it gets into a circular domain. So my view and Blue Tokai's view of how the transaction has gone must match, right? So it cannot be that I think I have paid and Blue Tokai thinks that I have not paid. And that will require a fierce fight. Right? I am still fighting with somebody to recover the ₹ 1000 that I paid two days back.

Right? And that party thinks I did not pay. My Google Pay shows that I paid. So that’s a problem. So whatever is our view of the transaction, it must match in both ways. So there have to be these guarantees. No unauthorized transaction, no credit without debit, no double spending, no residual debt. Consistency, that all parties must converge on the same final state and probability. Right? Otherwise, there is no dispute resolution. So what would be a leakage function in such a framework?

What is the initial information that will leak? If you take something like UPI, you leak the start time, the transaction ID, the identity of the two parties, and the amount transferred is the message you are currently leaking. That's a baseline. Right? That's all that you are leaking right now. You are leaking the completion time, you are leaking the network metadata, IP address, who is talking to whom. My phone's IP address is known to NPCI. The bank's IP address is known. It is known that I talk to the bank.

The payee talks to the bank, and all these are the information metadata that you will leak, which models the minimum privacy loss that you will incur. Um, you are also leaking account details , authentication records that will make your payment linked to other payments and so on and so forth, because using things like phone numbers as IDs need not be the case. In an ideal, in a good threat model, I would not want to leak any of this information. So the baseline is that you are leaking identity, you are leaking transaction time, and you are leaking the amount paid. You are leaking the metadata to at least two banks.

>> Parking analysis too, you have to now say that, if this is the risk, if this is information that will risk, do the benefits outweigh the risks? Right, so there is a second part of the analysis that you will always do. So, Whether such a system can be built? Yes, such a system can be built. You know, there are examples of these systems, several systems all over the, all over the world. I will just talk for two minutes about, you know, voting, that’s a, that’s a harder protocol, much, much more difficult.

So, in an electronic voting system, to justify electronic voting, you have to ensure that the votes are correct. You have to say that the ballots are secret. You have to ensure that only authorized voters have voted. One vote per voter. You have to make it publicly verifiable . I mean, I think that's a major responsibility in a digital election. And you have to show that nobody can be coerced, right? So there will be no coercion at all. If you are giving a receipt to anyone, a voter should not be able to prove to any coercer how she voted right?

The voter should not be able to prove that I voted for BJP. That proof should be impossible. That's coercion resistance. And why is voting difficult? Voting is difficult because you have to achieve these goals assuming that everybody is corrupt. Election officials are corrupt, voting machines are corrupt, all hardware is corrupt. Some voters are corrupt, right? So there is an absolutely zero-trust model under which you have to prove this, right? So this is considered the holy grail in computer science in terms of privacy and security; it is probably the hardest application to build simply because there is no provision to trust anybody, right? And

So you will say that the minimal leakage in this case is that the voter voted and the voter voted at this time. This is information you can't hide because any watcher in the public who is watching the election will see me walk up to a polling booth and vote. So they will know that Subhash or Ashish voted at roughly 10:30, but other than that and the final outcome, you are not allowed to leak any information, right? That's what an ideal functionality of voting will state. And for verifiability, you should be able to give proof to the individual that a vote has been recorded correctly —that you know the vote has been cast as intended.

And you have to be able to provide a universal proof that the tally is correct. There has been no vote injection, no vote deletion, no >> Uh, So that's how you model risk in a typical system. And public systems must show that they realize these goals. If they can't realize some aspect of them—if in the voting case it may not be possible or may make the system too complex to realize this—then you must articulate what risks you have not mitigated.

I think that's a crucial part because that goes into the risk analysis, right ? And So I think that, you know, there are three papers; I have not gone into the solution at all. There is a paper that we wrote with Subodh, where we show that for a UPI-like system, this is indeed achievable, both for person-to-person transactions, you know, pay in a payment mode, and also in a transaction over the internet. Even if the network is unreliable, the ideal functionality is realizable, right? And The voting, that paper is also with

Subodh right? So we have got a paper that shows that even, Even for an electronic voting protocol, the ideal functionality is achievable, right? And even if all election officials are corrupt, the election can be made secure. Even if the hardware is corrupt, the election can be made secure . Uh, And we also did, you know, a piece of research for something that is much in discussion today, that how do you make an electoral roll secure and private.

Uh, so how do you ensure that there has been no unauthorized deletion from an electoral roll, uh, there has been no unauthorized addition to an electoral roll and just contains the names. >> So I will take yours later.

>> What if I am not good at catching? >> So I will take yours later. Let's take that one first. >> Thanks. I have two questions. First, I really liked the talk. When I say it’s simple, I mean it really deeply that it’s simple, which I love. So I have two questions. One, the first one: in the partially synchronous case, after GST is done, the Global Stabilization Time, you have asset guarantees in your database, right? We have no other problems that we have to deal with.

But I was really interested to know your opinion on distributed consensus-based databases or payment channels there. And the second thing that I wanted to ask was Privacy-preserving voting system you said, or F-pay, F-dash, right? I wanted to look at, or maybe it was a question in my mind, and maybe you would be able to tell me more, is how can you maybe use the literature from Ross Anderson as well with the economics and cryptography stuff, where maybe you could look into rational adversaries or like rational corrupt individuals who could; so in that case, your cryptographic protocol might not be so computationally complex.

>> You know, let's take the second question first. I think that won't work in voting . Voting is a You know, process of electing your government, that has to be absolutely secure and publicly verifiable. There is no question of incentive that comes in there. But that may come in the payment system , right? That Whether some party has an incentive to; in fact, you have to assume that.

You know, for example, take a simple example of a payment system that is not digital: I pay you ₹ 10 for coffee, you take it in one hand and then refuse, saying I didn't take it, I won't give you coffee. There is only one way to resolve that, and that is a swift fight, right? There is no other way to resolve that question . The reasonable expectation that you won't do it is because you want to conduct a business; denying me coffee, cheating me out of ₹ 10 will make your business go for a toss. So, that's an incentive-based scheme, that you know you have to play honest.

After getting ₹ 10 from me, you have to give me the coffee. So, we do that all the time in any bartering system, right? And in any kind of a bartering system, that assumption has to be there. In fact, in a paper-based payment system , you don't have proof that I gave you ₹ 10, right? And the second is a witness, but at least in a digital system, you will have proof; I can always prove that I gave you ₹ 10. Regarding consensus, You know, I am not a great fan of consensus.

>> Actually. >> Thank you. >> Thank you.