Leaked Data & the trust issue

[LilithWittmann]

The client leaks the following information via the API to the luca servers:

• the phone number (request URL: https://app.luca-app.de/api/v3/sms/request)
• the location history (Request URL e.g. https://app.luca-app.de/api/v3/scanners/54f0a623-4753-4265-9e62-9ae1e76c2228)

That means that there is all information provided to the server that would be needed to build movement profiles around a phone number.

The luca app maintainers mentioned multiple times that the app is built based on trust to them, so this is not an issue from their perspective.

But as I see no reason why I should trust a few incompetent venture-funded 🤡 with influencer friends, I don't see why the entire security concept should work out.

From an architectural perspective, it would be totally possible (e.g. by utilizing the signal protocol and decentralized storage of the personal/tracking data) to work without a trusted central platform to tackle the same issues. But as the luca team didn't come up with these ideas themselves, I don't think it makes sense to discuss them here 🤷‍♀️.

[reneme]

As we state in our security objectives (particularly O2 and O3), Check-Ins cannot be associated to the user. Neither can any two Check-Ins be associated to each other to form a movement profile of a user. Obviously, this doesn't apply to users that shared their Check-In history with the health authority.

You are right, that the phone number is sent in the clear to the Luca Server for SMS verification. That phone number isn't stored. However, there's no technical way for clients to make sure of that.

After successful verification, the guest registration process posts the user's encrypted personal contact data, creating a server-side user object. This object is not associated with the plaintext phone number.

When performing a Check-In the user_id is encrypted for the health authorities with the daily keypair. Therefore, the Luca Server has no way of linking Check-Ins to that user_id.

Would you mind explaining how the endpoint you refer to as "location history" leaks a reference to the user's phone number or said user object?

PS: We're happy to engage with anybody and are grateful for input, suggestions and constructive criticism. In all of our conversation we treat people with respect. We kindly ask you to keep it professional next time.

[LilithWittmann]

No, I don't treat people who want free audits for their crappy closed source, patented bs project 🤷‍♀️

You are right, that the phone number is sent in the clear to the Luca Server for SMS verification. That phone number isn't stored. However, there's no technical way for clients to make sure of that.

Yes so let's just assume that you store it in your logs (together with all the request metadata).

After the registration, I check in to the place you get the same request metadata (e.g. ipv6 address or an HTTP caching header). I as a user can't make sure in the app that you don't submit any metadata that makes me trackable over multiple requests. And so it's super super easy to use the request for location details together with the verification request to build user profiles. (and don't get me started on all the "comfort features" you are planning…)

[reneme]

We are aware of this and state it in our document. We're also not satisfied with that situation and are thinking about other solutions. Fact remains, that we cannot get rid of the direct communication between Luca Server and mobile apps.

[LilithWittmann]

Why do you think that you can't get rid of the centralized part of your architecture?

The simplest solution I could think about just right now would be:
Use the ricochet.im protocol and generate for every check-in a new identity for the guest. Use this connection between guest and venue owner to exchange check-in information (encrypted with the GA-Public-Key, that the Guest received from a trusted PKI) as you do right now through your centralized servers. Store the check-in information locally on the device of the owner of the venue. Transmit the check-in information via a protocol of your choice (e.g. email) to the Gesundheitsamt if needed.

[reneme]

Thanks for the input, that's indeed an interesting suggestion.

Am I right, though, that we're talking about two different aspects here?

1. The central storage of (encrypted) data on the Luca Server
2. Leaking of information due to direct communication between App and Luca Server

Both points are worth discussing, in my opinion, but we shouldn't mix them up.

Central Storage

Given that the data is encrypted with distributed keys (owned by the venue owner), we don't see a striking benefit in storing the data in a distributed fashion. It complicates the system, however, because it'd require some sort of database under each venue owner's discretion. Note that venues might have multiple QR code scanners (think of a large shop with multiple entrances) or guests might do self-check-ins via a printed QR code.

What do you think would be the benefit of storing the data in a distributed fashion?

Information Leakage due to Direct Communication

We did think of using a Tor service to obfuscate such meta-data leakage when communicating with the Luca Server. Admittedly, this idea was not developed further simply because of time limitations. It would definitely be worthwhile to reconsider.

[LilithWittmann]

Both points are worth discussing, in my opinion, but we shouldn't mix them up.

But by removing the central storage (so centralized infrastructure) the issue of "Information Leakage due to Direct Communication" is basically fixed too.

The benefit of removing centralized storage would be, that even if your servers/webapps get compromised (and attackers can access the private keys - what would be easy because you manage them in a browser 🤯). They still would not have access to venues' guest data, because it's stored decentralized.

[sventuerpe]

Let’s try some threat and risk assessment. This discussion seems to be about a worst-case scenario in which an adversary observes all data exchanged between client instances and the application back-end. The concern seems to be that such an adversary could analyze traffic data and unencrypted metadata to infer traces of guests across multiple locations and to identify the persons corresponding with those traces through their phone numbers. Is this correct? If so:

• Which types of agents are actually capable of implementing this?
• How would they use this information?
• What would they gain from doing so?
• At what cost-benefit ratio?
• How would they pursue the same goal without Luca?
• How much would their cost-benefit ratio hence change due to Luca?

[ksaadDE]

Let’s try some threat and risk assessment. This discussion seems to be about a worst-case scenario in which an adversary observes all data exchanged between client instances and the application back-end. The concern seems to be that such an adversary could analyze traffic data and unencrypted metadata to infer traces of guests across multiple locations and to identify the persons corresponding with those traces through their phone numbers. Is this correct? If so:

* Which types of agents are actually capable of implementing this?

* How would they use this information?

* What would they gain from doing so?

* At what cost-benefit ratio?

* How would they pursue the same goal without Luca?

* How much would their cost-benefit ratio hence change due to Luca?

Yup a bit work needs to be done to practically do that (you already know :D)

But if you think about it: which is easier to attack? Lets say 1k Devices vs one up to ten centralized Servers, which may have the same setup (depending on the deployments) therefore the same vulnerabilities... they needing constant Administration and one flaw bugs them all, compared to the decentralized devices, which having different OS (Versions) and a lot of different flaws.

Hacking decentralized Environments sounds a lot harder. (Which is in case not the truth, but it's harder than hacking centralized Services, depending on the Setup).

I don't think intercepting the traffic (once you get it) is a big deal. Every Skid does it in the Labz.

About the "who would / could do that"... well a lot of people can do it, it's not "that hard".
I don't say it's easy, but it's very very possible. Especially if the Data are worthy for someone (which is the case).
Spin up some AWS Instances, doing some proxying, using PIs ... shouldn't be a big deal!

Cost-Benefit. Well you would invest a big sum, that's true. But if you compare it to the improvements in privacy and security, I don't know. It seems to lower the risk and bring a lot of trust in, which results in more customers and at the end users, which should be the primary goal, if I'm not fully on the wrong path. :-)

I know a lot of people who step far away from Luca, because the Infrastructure is centralized and the Code is to a point a bit messy...

[ksaadDE]

The client leaks the following information via the API to the luca servers:

* the phone number (request URL: https://app.luca-app.de/api/v3/sms/request)

* the location history (Request URL e.g. https://app.luca-app.de/api/v3/scanners/54f0a623-4753-4265-9e62-9ae1e76c2228)

That means that there is all information provided to the server that would be needed to build movement profiles around a phone number.

The luca app maintainers mentioned multiple times that the app is built based on trust to them, so this is not an issue from their perspective.

But as I see no reason why I should trust a few incompetent venture-funded clown_face with influencer friends, I don't see why the entire security concept should work out.

From an architectural perspective, it would be totally possible (e.g. by utilizing the signal protocol and decentralized storage of the personal/tracking data) to work without a trusted central platform to tackle the same issues. But as the luca team didn't come up with these ideas themselves, I don't think it makes sense to discuss them here woman_shrugging.

I would like to see some respect for the Developers, even if their last actions weren't very honorable ... (Lic File issues, Messy Code, Flaws).... Having a respectful conversation improves the App more than making it more and more worse (and even the situation for the Developers and Investors).

Besides that your point is very very valid and I see that issue too. I know a lot of people who are concerned in that matter.
But keep in mind, perfect security (and even privacy) is not possible.
You will need to take a few steps back, even if it might look very simple for you and you would do it better.

And a decentralized infastructure also resulted in hate like with the actual Corona App by Telekom and SAP... (Which I still don't really get, since the App was "ok" - Bugs are always the case - compared to the dev time)

So when both ways results in hate, because on side wants the privacy and security and the other side doesn't wants it (for other reasons?) and we have to solve that Corona issue... what do we try next?

To sum up, yes it's serious. Tracking is not funny and can end up with horrible consequences.
Not only our LEOs and state-driven Institutions could abuse such information (which may seem harmless at the beginning)...
Also other state-driven Institutions from other Counties or even Large Companies for their "business interests" could abuse that info.
Basically it would be the replacement of the old tracking capabilities (=marketing purposes) without having any regulations for it :-D

Greetz

[AmazingTurtle]

@Kilode where did the Corona Warn App by Telekom get bashed for using a decentralized infrastructure? I did not read any of that.