Building and Managing Population-Scale Digital Public Infrastructure Safely - Shailendra Thakur

This talk explores the architecture and principles behind digital public infrastructure systems in India, particularly focusing on real-time digital payments. The speaker discusses the significance of sovereignty in data management, promoting open innovation and co-creation among ecosystem partners while emphasizing the importance of modularity and interoperability in system design. They highlight the need for secure, auditable systems that adopt open standards and frameworks, ensuring users have full data control and trust in the systems. Additionally, attention is given to the challenges posed by quantum computing on cryptography, advocating for the adoption of quantum-safe algorithms. The session concludes by addressing the critical aspects of building diverse and resilient hardware and software systems to withstand various security vulnerabilities.

I'll take you through some of the thought process and how many of you do software design? Hardware? Um And how many of you actually write code even today? Oh, great. So, we have we have real technical core core technical people out here. Uh So, scale sovereignty governance open innovation co-creation. When you think of population scale systems, um of course, everybody knows UPI. Um that's a flagship. But

then there are other systems. Aadhaar as a identity layer. Uh it's the largest identity layer in the world. Um UPI is the largest payment digital real-time digital payment system in the Uh we are a subsidiary of uh NPCI called NPCI Bharat Bill Pay Limited. We have built and we run and operate with three digital public infrastructures. One, BBPS, which is for retail bill payment. The Bharat Connect

for Business, which is trying to do uh what UPI did to digital payments. Uh we are trying to make all the business workflows interoperable, real-time, seamless, safe, and always there. Banking Connect is our newest effort in harmonizing the user experience when they are doing net banking based payments for e-commerce transactions. Today there are some some friction points there. We are trying to solve them. Right? When we

look at building these large-scale systems, there are some key aspects that uh we have to be aware of. We have to be uh very actively thinking about them. Uh architectures for open innovation and co-creation. Why? Because you build ecosystems. Um and ecosystem essentially means that you'll have partners. And partners essentially means they will have conflicting interests. So you need the architectures which will support co-creation and open

innovation. you don't want anybody to arm twist you. So open source. Uh and sovereignty as the strategic What's sovereignty as a strategic layer? When you think of sovereignty, when you think of full control, what comes to your mind? Any any guess? Data localization, yes. Let's say we have localized the data. And we have put it on on a public hyper scalar cloud in India. One of their

centers is in Hyderabad and one in let's say Mumbai. Do you think you you have met the goal? No? Because they can delete it. Whoever can delete it owns it. Uh then we will take through uh Q&A. So we will go through the three uh layers, the sovereign fundam- foundational DPI uh rails, the interoperable and open standards and the open innovation and co-creation. We'll spend more time

on on on the bottom layer the sovereign DPI rails on how and why to create them how to think about creating them how do you design because essentially this is where all your design principles all your architectural thought process and your flexibility has to come in because you build this once in 20-30 years. So uh I'll not focus on the identity layer we'll still stay within the

uh real-time payments real because that's what we do that's our bread and butter so we do and that's what uh we have the learnings from which I'll be sharing with you guys. Real-time payments uh you saw that we connect the consumer bill payments in real times and Bharat Connect for business is the one where we are modernizing the or rather bringing in interoperability uh and open loop

open systems for uh enterprises to interact and perform their businesses. Banking Connect for interoperable net some of the architectural principles that are applicable for this layer is uh modularity interoperability everything has to be modular at modular at what level modular at what's my contract? How do I own my contract? How do uh I how or how does that module fulfill that contract? So your modules have to

have contracts very well defined contracts. Not we are not talking just about okay do I write it as a library and can 10 people uh import it? That's one way of looking at it but how do you make sure that that library that you're creating is serving that purpose? You define the contract you stay with that contract, and you deliver that contract every time. That's one way

of looking at modularity, interoperability. Open standards, well, why do you think that all our phones can call each other? I may be using one manufacturer's phone, you may be using some other. Why do you think we are able to call Because standards. So, when you build API, you build standards. Standards essentially means protocols, states, information exchange models that you build, and then everybody adopts it. That's how

you make it open. But then you will see that everything is getting centralized. You have built open standards, but somebody will play the role of of of switching that information, connecting all the channels. So, those channels will have information. And hence, we must have consent-based data minimalism. Security by design, we'll get into security by design a little bit more in depth. So, um key key patterns that

you look forward to is is even driven reconciliation. Why? My system may be up. Your system may be down. Money has to flow. So, when your system comes up, that event has to close. The schema cannot be fixed. Today, um we think, "Okay, I need this." Uh so so it's very very easy in college and all our capstone projects. We say HRMS for student attendance. This is

student this ID this ID this ID, right? That's a very fixed schema. We are we are design we are Our entire ecosystem is telling us to think in fixed schemas. The challenge is the reality of life will make that schema obsolete within a year. So, you need to have a schema evolution mechanism. Resilience, multi-region, all of this you will know because if you are building anything which

has to survive, uh you will have active backup, active active, one is two and n is two m m kind resiliencies. Very critical. Everything that you do, every software has to have a software bill of material. Any idea why that is important? Software bill of material. We have uh developers here. Any any any wild guess why software bill of material should exist? Licensing. One thing is licensing,

another? Another? How do you know something is not getting injected in your binary next time, which is malicious? License you can buy. Trust lost. Sure. Cash. You can, but it will not solve here. You will need um the bill of material is critical to understand what's coming in as a dependency in your system. Who owns that dependency? Even in in open source software, let's say your primary

software is Apache. Does that software use some other libraries which are uh say licensed under multiple licensing mechanisms. One of them could be a BSL. Let's say a dependency of that Let's not take a name, but let's say ABC software. I'm using for file management. It's an open source and licensed under MIT. A dependency is licensed under BSL. Should I be using that ABC software? I have

to be very careful. BSL essentially means I cannot do anything production grade. BSL only means that I can do non-production, testing, UAT, experiment. That's why your software bill of material is very important. On the security, quantum is coming. And hence the research is also happening. Quantum safe uh algorithms are there. Now, at least four of them are approved. The lattice-based uh NIST-approved four Um but what does

it mean by when we say quantum safe cryptography for security? Why do we need this term? What does quantum do? Let's say today you are using AES 256 for your encryption. Very common. Easy. You have either block-based or con- continuous uh buffer-based. What does quantum do to that 256 bits of encryption? It only does time shift. Today, if you use an algorithm which is only, let's say,

80 bits of encryption, Will you consider it safe? No. Why? Because today's compute can crack it quick enough time. Where the sensitivity of time is not material enough for the information to lose its value. Quantum does that to higher order of security. A 256-bit encryption will in quantum terms will possibly only give you 56 bits of equivalent security. So, essentially, all the current top-of-the-line cryptography that we

have is um rendered kind of suboptimal. It's not as if humans will be able to read it, but machines will be able to brute-force possibly few milliseconds. So, one way would have been, "Okay, so why not create AES 4096? That will be safe." Another thing that the cryptography requires is random keys. Why do you need random keys? The random keys are the seeds which then initialize your

curves. The curves are the points on which you parabolic computation to derive the uh encoded or encrypted string and output. So, a post-quantum will also have a quantum random number generator. Today's random number generators are not random enough. So, that's why you need And you need the expansion of the curve. And once you have these two, you don't need AES 4096. Possibly AES 1024 will survive. Or

AES 512 will be sufficient. But there are mathematical holes in AES or some or similar mechanisms, and that's why the NIST research has approved four lattice-based algorithms to be safe for that kind of mathematical attack, also. So, that's that's part of the quantum cryptography that you must start thinking. Why I my system has to be quantum safe today, not tomorrow. You have to start having the capability

to be quantum safe today. Because you are not going to replace the entire system again. Secure data exchange, very simple. How many of you send your payload as open in on HTTPS? Not even HTTP, HTTPS. Your applications will have REST APIs. How many of you are encrypting that payload? Yes, your channel is encrypted. So, what if your channel is compromised by man in the middle? >> [clears

throat] >> How does HTTPS work? Today, I when I open a browser, does server know it is Shalindra Thakur? Do I know which server that is? Yes. So, server doesn't know whom they are talking to. They could be talking to a high compute browser which will crack the stuff in man in the middle, and then your payloads are visible. So, secure It's of data is not only

about transport layer security. It's also about your data being secure. And mutual TLS will become standard everywhere because the servers will start to know or want to know who is the client. Today, Shailendra Thakur looks same as They don't know. And that's a big hole. The entire internet is facing that big hole today. The solution has existed for nearly 30 Nobody has adopted it. See, very common

to think, "Okay, I In the privacy area, I am sending my bank account or my Aadhaar card number." It's a personal identifiable data. I will hash it and send it. Is it safe enough? Privacy experts will say, "Yeah, safe enough." No, it's not safe enough. You know why? Aadhaar number is only 12 digits or at max 16 digits. to prevent such problems like I can precompute the

entire hash of the population. It's called shore attack or also the rainbow attack. Any identifier of any nature will always be of a limited string. I'm not talking about the UUID 64s and four version four and all of that. I'm talking about what we humanly recognize. Your PAN, your Aadhaar, your account number, your DL. In fact, your engineering registration number, it's all PII. Everybody with current laptop

can pre-compute the hashes of all the possible identifiers. So, how do you How do you make sure that this doesn't become attack vector? You go to homomorphic encryption. Where processing on an encrypted data is possible without decrypting it. Okay? Permission to data minimalism is is more of a philosophy that has to be practiced. That collect only what is required for your service. Make sure that it is

safe, secure, and uh based and covered under consent. DPDP is coming. So, I don't know how many of you are facing DPDP, but almost every organization that is doing a service or has a SaaS has to think very seriously about it. Because the penalties are very se- severe. And when we are building systems for large audience, the technical capabilities do not the technical capabilities, the features, the

richness, the ease of use, all of that will bring the audience in. But what keeps the audience with you is the trust. Do they trust your system? Today, everybody is keeping money in bank because we trust the bank. Tomorrow, if we don't trust the bank, the money will not be in bank. Right? Trust. And it's very important that your systems are auditable. So, auditable systems where every

action, every outcome and decision is explainable and auditable. What does it mean? Why was this service denied? Let's say I fire an API. API request is rejected. Why was it rejected? Is there a rule that is always and fairly applied to that? Will it always return that reject under that condition? And can I prove it? The provenance of an action and decision is what auditable means. And

once we introduce the immutability to that decision, whatever decision record is, can it is it immutable? Can your operations team or developer go and modify the data in database? If yes, your system is not immutable. Somebody can go and modify it. Maybe it's an insider job. Maybe it's a social engineering attack on that person. So, when you couple security, safety, with auditable, immutable actions, that's when you

build trust. That's what keeps the audience with you. The um There are many systems who who have, you know, entice the user group do this activity, you know, post this and I'll give you 10 rupees or you'll get Bitcoin or whatnot. But, have the user base stayed with them? You will find that the missing trust was the reason why the user base moved away. And then, you

have all of all the techies would have heard this term, RBA. Role-based access control. And then, infosec folks will say deep packet inspection. You heard? Firewall. Web application firewall. Perimeter control. You have heard all these terms, right? What does it mean? Role-based access control. If you are a developer, you will have access to this. If you are a production support, you will have access And all of

that, right? Do you think it is keeping your system We are all thinking software. What I have listed is some of the attacks on the hardware. And these are I have not intentionally listed the ones which have been detected in 2025 and an attack created in 2026. But look at So, Platypus Intel SGX processors, which are in You do a side channel attack, it will leak you

the secrets of the encryption And you don't need the physical access to it. Spectre that's also a CPU-based attack. All CPUs All CPUs in the world do branch prediction and instruction preloading. There is no CPU in the world which will not do that. This is an attack which utilizes that to create a vulnerability and gain access to secure enclave. Red bleed This one is very interesting one.

So, uh Intel and AMD patched the Spectre attack using an OS fix. So, the attack was on hardware. They fixed it in OS. Red bleed defeats that fix. And this came immediately after they patched it. Like, within 15 days of patching, it came. Heartbleeds In fact, the last one actually did a attack on a lattice algorithm and defeated it, and that's why they're winner of the NIST.

So, they attacked the the uh L1 cache of the CPU where for fractions of picosecond uh the key is So how do you survive all of these, right? How do you survive them? Your hardware collection has to be a jungle. if you ever use only one kind of hardware, you are a sitting duck. One attack one successful attack will get replicated across all your hardware, all your

server, all your routers. Your hardware has to be diverse. And that's why I say win by surviving long enough. Why long enough? Attacks will happen. If you survive that long enough, you will get the patch. If you don't have the uh if you i- let's say you are on AWS and you are using Graviton. I I don't I'm not saying that AWS is not good. You let's

say you are using Graviton and all your uh virtual machines, EC2 instances, everything is on Graviton. What happens if an attack is discovered on Graviton? Everything is compromised for you. Doesn't matter what is your perimeter security. So hardware diversity, very strict software dependency and supply chain controls, including reproducible builds. We will not touch reproducible builds today. It's a topic on its own. But if your build does

not create identical binary to the last bit level, unlikely ever discover an attack which has happened on your sub software supply chain. How do you discover an attack on your software supply chain? Your automated build systems have to continuously build every release and version of your software that you are you you have used or anybody else is using so that any dependency which got imported does not

generate malicious code for It has to be reproducible. I will just say that it has become it it's a full long area of its own but if it is not reproducible, you don't know what is executing. Notary mechanisms, we all know signing and then secure enclaves. Uh at least it gives you little bit of you know sense of feeling that okay, my my my execution environment is

has validated certain things and it is not jumping around and and so on and so forth. we will not even go into a ransomware attacks right now because ransomware attacks also use some of these mechanisms where it looks like a benign payload and then it jumps out of your How to counter that? That's again a deep topic in its own. Some of the questions here. You have

built a system fully on public cloud, what is the risk? Make a guess. What is the risk? I don't know. Espionage, data chiffonning, downtime, embargo. The biggest But this can be mitigated, right? Data leak, you can bring your own keys, encrypt it with large keys, bring your own mechanisms. You can handle all of That's what people are doing. Even the HIPAA certified ones are doing These can

be mitigated. What cannot be mitigated? Account delete. Last year someone made an administrative mistake in a Google Cloud configuration at the Google GCP layer. 10,000 companies wiped out. their systems were on Google, their backup cold storage was also on Google. Everything's connected to your account. Account delete, gone. One mistake by an adminis- with an somebody who is a who has an admin access on that cloud deletes

you. Your company, done, finished. Out of those 10,000, only one company survived where someone was paranoid enough to take a tape backup. How many of you you have seen tape backup? Ah, great. I like you. In this only paranoid will survives. Bigger than data leak, account delete. Yeah. You are building a new shiny toy with AI. Self-hosted, local inference. No, I I I will run my AI.

It's local. My GPU is doing the inference using pre-trained weights. What's the So, I have downloaded this open source model from Facebook. 120 billion parameter model and I'll run it on my GPU, right? What's at risk? It outdated. Outdated is one risk, but let's say if my business can survive that outdating. What are the risk? AI is unattended. I have anyway decided but I will run it

locally and I'm okay with that non-deterministic because I'm building uh AI. So, non-deterministic is one challenge. Let's say I'm more than likely okay with that non-deterministic because it's a moral question rather than a engineering answer because there's no way you can make a AI determinate or rather generative AI deterministic. You can make the deep learning and the previous generations deterministic. That was very deterministic. The ones which

which are coming with attention and then uh attached to a um per- perception layer or in other words, the transformers and LLMs, they are non-deterministic. But what's the risk? Okay. Real risk? >> [snorts] >> Copyright infringement. Model misbehavior. Jailbreak. And many more. Last week Anthropic settled for settled a lawsuit for 6.7 billion dollars. AI generated content, who owns the copyright? Who gets the copyright? It's not even

a question. There was a case. There was a photographer. It's a very famous case if you ever study copyright. Very very famous wildlife photographer. He went into a deep jungle. He left his camera there. A monkey came, took pictures. absolutely brilliant pictures because no human was there. So, jungle became normal. Who owned the copyright? Case went on for 20 years and finally the photographer won. So, you

don't want to fight a case for 20 years. Oh, with [laughter] the monkey. But there is another story there. We are downloading that weights and running it as inference. Not your weights, not your model. You don't know what it will do. On the real-time payments, we all we all know how to design APIs. Some of you will say rest. The challenge, rest will leak your state everywhere.

Why? The first principle, the payload has to be sufficiently rich enough to make all the decisions on single payload. Your state is leaked there. very slow. Interesting, but slow. RPC, the oldest one. The new you know, sibling of that is GRPC. It's very good for your internal APIs and internal communication systems, not so much for for public. So, what's the catch? So, you you you will end

up anyway defining an API which will hide away the state, be asynchronous. How many of you return your responses in 200? HTTP 200. It won't scale. Let's say I make a query uh if you are running a graph QL service, I make a query and it literally downloads your entire database. Try returning that in 200, okay, done. It that won't survive even uh 50 simultaneous users. Forget

population So, asynchronous web hook based. Everything has to go back later in time. But that later is possibly few milliseconds, not instantly. We'll talk about interoperable open standards and central governance. N BBL operates in this layer. We not only build, but the middle layer of how a DPI operates, why a DPI operates, it's the governance layer. The governance layer has uh few responsibilities. A few responsibilities of

um You want to get into the technical aspect or you want to get into the philosophical aspect? Technical, hands up. Show of hands. Philosophical? Great. So, technical uh on the technical aspect, what I was saying uh asynchronous APIs, essentially it means saga is distributed, it's not in your full control. Your state is distributed. You will only see half the state and half the state will be somewhere

else and you still your system still has to function. What becomes important? Your open Because in that open standards, if you know you get certain responses, you can guess the state on the other side. Observability, which is open telemetry telemetry and service level obs- ob- observations that should always be available to you. Uh resilience and then a sandbox. Why a sandbox? The partners have to build it

along with For example, NBBL does not have a front end. We power almost all of you when you pay a bill today you're using our systems. If you pay a bill, there will be a small B that will come somewhere powered by NBBL. That's us. But the front end is not us. The front end is PhonePe, GPay PayTM, what not. So they build with us. They build

with us in sandboxes. So the governance function on the three platforms that we do First is ecosystem alignment. The fair play. Clear deliverables. And open to scrutiny. We are always open We possibly face more than few audits every year. And the partners can always come and ask us, "Why do you think that this transaction passed or failed?" So that is open to scrutiny. "Why do you think

introducing this new feature capability is important?" That's build systems where partners are there, you you can't have unilateral decision-making. That's open to scrutiny. Clear statements of purposes, service guarantees, and resource recourse I should be able to say "No, I don't agree to this." And hence, we have we operate three DPIs each enabling open innovation, co-creation at and ecosystem acceleration. Open, interoperable protocols and APIs. Regulatory oversight, which

is the RBI, which regulates us. And one goal of economic acceleration of This we spoke about how the bottom layers will enable it. Uh I'm being timed out, so going a little fast. How uh the bottom layers are supporting But open innovation is is critical. We don't do innovation as much as we would like in India. So, the aim of all the DPIs If there was no

Aadhaar, I don't think we would have had direct benefit transfer possible. That's an innovation on top of an DPI. So, open innovation. Diverse ecosystem partners, and diversity is a strength and liability. Everybody will have diverging business needs, technology needs, user segments, and users. And variance in user preference and adaptability. A 60-year-old person will adapt technology differently than a 20-year-old person. An 80-year-old will require a different kind

of technology. And hence, that is a challenge. Uh which gets solved by diversity by open standards that allow innovation and information model versioning with backward compatibility. You can have very simple services for old age people, much more advanced services for a younger generation using same API but different versions. AI led innovation, we said right? Not your wait, not your model. But then, how do you do it?

Data provenance, your data mutations have to be provable. All your decisions traceable. Be careful, AI rent and the pipe will be real. Anybody who's trying to build using the pipes of all the well-known names, today it is $25 a month. You don't know when it is $2,500 a And you will not know when another zero will get added. Oracle is a classical Outcomes and observability of AI

is still fuzzy. There is There is today there is no way uh we can prove why an LLM, why? I'm not even saying how. Why an LLM produced an output that it produced. Uh enough amount of research is required, but today it is not possible to say why. Uh this is some of the innovations that we do, but here you see the divergence and diversity in our

ecosystem. Look at the types of partners that we deal with. That's what you have to deal with in terms of when you want to build an API. Government, regulator, different business entities, ERPs, payment systems, fintechs, universities, physical touch points, citizen service centers the Bangalore has the citizen service center they are also using they are also powered by uh us for the bill payments so every time you

go there make a bill payment for your electricity or anything else it's coming there but this is a snapshot uh and with that thank you >> [music]