Double Privacy Pass With Commitments: Architecture for Privacy-Preserving Phone Service | Hudson

Hello. Oh, I just heard cheering. Was that for me? Oh, no. Someone just won a won a prize over there.

Anyways, hello everyone. Welcome to my talk on double privacy pass with commitments. Secure architecture for privacy preserving phone service. I'm Hudson and let's get to it. First of all, I'm going to introduce some actors uh for this presentation.

Uh the first one is me. I'm Hudson. I'm a freelancer for Least Authority and also a member of the security alliance uh aka SEAL that does hack prevention in the ecosystem. Least authority is a security consulting product development and security audit company. uh they've been very well known in the space for a long time having done the uh audit of Ethereum before it launched and of Zcash.

And then Freely is a privacy first wireless service who hired least authority to design uh this privacy preserving phone service for them. So here are some of the concepts that we're going to be going through today. Privacy by design. You want to collect as little data as possible uh and no more than what's needed to provide a service. Why is that?

Well, if hackers get into your database where it holds all of your IDs that you had someone scan for KYC, then the hackers and bad guys could take that when you don't really need to keep it for that long in the first place. So really, this this idea of privacy by design is as you're designing a like a protocol or like a system, you want to think about privacy at every level of the stack. Unlinkability is another really important concept for today. Uh different parts of the system need to cooperate and provide a service but no single party within that system should be able to reconstruct the complete picture of who the individual is. So if you have like a phone service, you have the billing department, you have like the profile page, you have all this other stuff, they shouldn't be able to link together.

And I'll go into that a little bit more as we get into some diagrams. Accountbased models are what we're used to, especially in the phone world. It's where you have traditional authorization models uh that correlate to when you create a profile. Basically, all this metadata is stored and it's all correlated into this profile that makes it really easy for um people to go and steal your information if they go in and hack databases. And then double privacy p pass plus commitments is an architecture that separates the information such as billing from telecom history such as uh call history, text etc.

So freely the phone service provider can't identify a user's phone number from their account login or name. It's all separate. But however, there, as I'm going to show you, we're using some really, really cool new technology and systems to make sure that they can still pay for their phone service while keeping it private and reliable. All right, lot of text up here. I'm just going to go through the example, but feel free to read it if you want.

So, you're at a music festival. You bought a ticket with a student discount, and when you get to the festival, they give you a wristband and two drink tickets. You're now in the festival, and you and a friend want drinks. So, you go to the drink stand and you use those drink tickets. Those drink tickets are a private interaction because they're not linked to how you bought that wristband.

That could be anybody. When I talk about unlinkability, that's what I'm talking about is this privacy preserving uh like tokens that could get sent out. Privacy Pass, which is uh like uh run by Cloudflare and a few other big companies, is a system that was originally used uh as a uh alternative to captions where you get these identification tokens and you can use them throughout your session or as it says here, the internet is a festival. When you arrive at the gates of a website, they scan your request, give you a session cookie and two privacy pass tokens. This is actually something that's in production today with Cloudflare.

You can look up privacy pass. There's a whole uh whole websites about it, but uh they could have given you just one token or multiple, but for our example, you get two and then you can use them to test your humanity when you authenticate on a website or confirm the legitimacy of your hardware or many other things like that. Okay, so here are the components of double privacy pass plus commitments. You have the privacy pass doubled twice the fun. I won't be getting into deeply why we're doubling privacy pass, but there's some really intricacies.

There's some intricacies in the uh way that phone plans are set up where you need to have uh privacy pass used across the system multiple times. Blind tokens are shortlived cryptographic tokens and the blind relay is the mixing service. So mixing services is also something I won't go into a lot of detail on today just because we don't have the time. So the mixing service blind relay, it's used to collect and forward messages between the backend components, but in a way that's privacy preserving. So it's going to like like if you activate a new SIM card, let's say, or process payments, all the individual customers finalize the these operations in large batches at specific times.

Now, why is do we do that? Why are we doing this in batches? The reason is if you have um a series of operations and you do you don't you do them just as they happen and just like when you're tracking like Monero or Zcash you can correlate the timing it's called a timing attack usually you can correlate the timing of an action by the individual who did that action unless you do it in batch because otherwise it's like oh only one guy signed up at at like 1258 and then at 1259 they're activated you could track that So yeah, it prevents observers from different points in time from the system from getting patterns. And this is an unlinkability between the issuance and redemption phase of the protocol specification. Here's a boring looking chart or diagram or whatever.

Uh but what we have at the top is this ID issuance where you get a user ID and you get a token, a privacy pass token in exchange. the uh actual redemption of that token goes through the issuance and redemption phase where you're validated for whatever action you're doing. Let's say signing up for a SIM card and it's the ID uh the token is then stored and then forwarded to the red redemption phase where it's validated and then removed from the pool of tokens. So it's just like using that drink ticket I was talking about earlier. they you're now proving that you need to you do a service which is in that case buying a drink but you don't have to reveal who you are.

You can do that with every single part of this phone plan. Blind tokens are another component of this. Um rather than relaying a permanent individual identifiers, we have these short-lived blind tokens to authorize actions. So these are derived from privacy pass protocol like I mentioned and they're little proof that customer author that uh to confirm a customer's authorization to perform a given action without revealing their identity or that a phone number is legitimate without disclosing its owner. The design enables the system to verify the legitimacy of an account or phone numbers and perform operations without exposing or linking those two identifiers.

So here's another chart. This one goes through, if you look at the very top row, the client is the person. The user service is what they're interacting with to actually perform the actions. The mixing service is the uh tool that like anonymizes and spits out different uh batches of actions at different times. And then the phone service is what gets changed on the back end.

So you can kind of just run through this and see that there's an issuance phase uh for for ID to kind of confirm who you are and get those tokens. There's an action issuance to actually use that token to validate the action that you want to do and then a redemption phase to validate the action after the issuance phase. Let's do an armadillo theme park example. So this is going to demonstrate unlinkability and the timebased batching. Um, so this is an armadillo themed theme park and the employees clock in uh at an employees onlyly building arriving at various times, but every shift begins at the spec at a specific hour.

So if you're like outside trying to track like, hey, I wonder Jim went in there, but I want to make sure I talk to Jim, but he's dressed as an armadillo like everybody else. So they they look for Jim and then all these armadillos come out an hour later and they can't figure out who which one's Jim because they're batching the armadillos that are being released from the building. So individuals may be seen entering the building at different moments yet every eight hours dozens of costumed armadillos emerge simultaneously. So an onlooker may watch and follow these armadillos but identifying the person inside of it is going to be difficult. So the employees access cards are the blind tokens in this example uh and they have access to different parts of the system while the employees only building is the mixing service that I was talking about.

So they relay or mix batches of operations together. Uh this demonstrates how double privacy pass plus commitments maintains a clear separation between the individual customers identities and their actions achieving unlinkability without sacrificing functionality. I kind of ran through this. Um there is a white paper on this called Double Blind Armadillo on the Freely website. Again, Freely is the company that um commissioned uh Least Authority to uh design and build out part of this platform.

And uh I'm Hudson and I am uh freelancing for Least Authority. You can always ask me questions, especially uh if you find something in this that's really cool and relevant to your project. Please reach out to me. I'd love to put you in touch with people who can help. Um, there's my website.

I'm also on X as Hudson Jameson. And thank you so much for um your time today, everyone. Have a great rest of your day.