Analysis of SwissCovid app | Hacker News Reader

Analysis of SwissCovid app

lasec.epfl.ch

80 pointsned_ludd30 comments

>A big part of the contact tracing protocol (which was originally the DP3T protocol) is implemented by Apple-Google in a part of the system called GAEN. This part has no available source code although the law requires disclosure of the source code of all components of the system.

By the same logic, this would seem to require all of iOS and Android to be open source. Where does the "App" end and the underlying OS and libraries begin in this requirement?

They argue that GAEN is part of the Play Services on Android. And that the app was designed to work at first with DP3T protocol which (I'm not sure) requires only access to bluetooth on the device. But DP3T was replaced with GAEN.

(This just my understanding from the web page and wikipedia, I'm not familiar with all of this :) )

To justify such exclusion, SwissCovid promoters argue that GAEN is part of the operating system of the phone, or sometimes part of the Bluetooth communication interface of the phone, and that it is not common to require to disclose the source code of such parts. We deny that GAEN is any such part of the phone, at least on Android phones. GAEN is part of the Google Play Services which are independent of the operating system and of the communication interfaces. We could actually run a pre-standard version of SwissCovid on an Android phone which had no Google Play Services. However, this phone had the Android operating system and could use Bluetooth. Furthermore, most of the former DP3T protocol which was implemented in this pre-standard version disappeared in the current version of the app since an equivalent protocol is now in GAEN. We conclude that there is no founded technical justification for excluding GAEN from the components of the system.

Purely speculating, but the reason for GAEN being part of Play Services is probably that otherwise it would require an OS update to be installed, which means ~80% of the Android phones being used "out in the wild" would be incompatible (Ok, maybe a bit less in Switzerland). And (even more speculative), the reason for using GAEN instead of DP3T may be battery usage? So you could build a theoretically pure open source implementation, but then nobody would use it because it drains their battery twice as fast as normal...

You are correct about battery usage. The analysis they published[1] mentions this (in the 2nd paragraph of the introduction) :

"One difficulty of using Bluetooth in phones is that the operating system does not allow apps running in the background to use the Bluetooth advertising system. Hence, to do so,either the app must stay in the foreground, which drains the battery a lot, or the operating system must be changed. Apple and Google allied to provide a standard Bluetooth API which would not drain the battery. Hence, automated contact tracing apps must either be complian twith this API or make the user upset about heavy battery usage."

Singapore's TraceTogether app doesn't use GAEN api and does have this issue [2].

France's StopCovid app uses a different protocol called ROBERT[3], and they asked Apple to allow their app to run in the background[4]. So they also have battery issues.

[1]: https://lasec.epfl.ch/people/vaudenay/swisscovid-ana.pdf

[2]: https://en.wikipedia.org/wiki/TraceTogether#Description

[3]: https://github.com/ROBERT-proximity-tracing/documents

[4]: https://en.wikipedia.org/wiki/Exposure_Notification#Non-adop...

The part that has been open sourced is essentially UI. Some of the most consequential parts are in the Bluetooth metadata, and how this leads eventually to an average attenuation over a certain time period.

This has epidemiological consequences, as acknowledged by one of the leaders of the DP-3T team to the BBC: https://www.bbc.com/news/technology-52995881

Apple (and Google?) retain higher quality signals than what they make available to the apps.

It introduces new security issues, because Apple and Google have had to make choices that degrade the qualities of the protocol. See Sections 3.5 and 3.6 in the report. The Swiss Cyber Security Centre expressed negative sentiments towards the fact that Apple and Google didn't implement some of the recommended protocol improvements: https://www.melani.admin.ch/dam/melani/de/dokumente/2020/Rep...

Finally, this Bluetooth layer becomes a covert channel for transmitting information between phones. There is a lot that we can't tell from this outside.

"Although the source code of the app is available, we cannot compile it, run it, and make it work without signing an agreement with Apple or Google. We do not find it compatible with the notion of open source." <-- Isnt this the case with every app?

Yes, it's a ridiculous absolutist argument.

I think the point here is that on iOS, compiling/running/making it work requires an entitlement (i.e. permission) that is granted only to those who are signatories to Apple's agreement on getting access to the Covid API.

See the yellow "important" box on https://developer.apple.com/documentation/exposurenotificati... for some more info. Not sure how this works on Android but I assume there is a similar permissions gate to prevent other apps accessing this feature.

If you read the report itself, they elaborate in section A.3 that the app does run but crashes due to something related to notifications.

I'm speculating but I suspect the agreement they're referring to is the agreement for Google's proprietary Play Services API. I believe it's possible to compile Android itself and regular non-Google-Play Android apps without agreeing to anything but the terms of the open-source licenses.

I wonder what alternative they would propose? If you want people to be able to use your app, you have to support the most popular app platforms, and if that means signing and agreement with Apple and/or Google, you have to do that. Anything else is "ivory tower" thinking.

I think it’s pretty obvious? You describe the situation as if it has been discovered as a law of physics to which all humans are subject.

Change the system... honor open source principles.

If ivory tower thinking means, improved state of affairs, then.. ok... ? Call it whatever you want haha.

I'm against the walled gardens of Apple, Google, Amazon etc. too, I'm just saying that if you want to launch an app for which it is especially important that as many people as possible should be able to use it, you have to think pragmatically...

The point is that you shouldn't mislead the population in claiming this app is open source when it actually isn't.

Some consequential parts of the protocol are implemented as a black box.

Its no about platform but using proprietary stuff, you should be able to compile and run it on a complete opensource android without the proprietary parts.

I think that's the second point in the list:

> A big part of the contact tracing protocol (which was originally the DP3T protocol) is implemented by Apple-Google in a part of the system called GAEN. This part has no available source code although the law requires disclosure of the source code of all components of the system.

Since the first point is separate from that, it must be referring to something else?!

You should be able to compile and run app that is truly open source if you have right tools and skills.

No, it is not. Most apps on my phone are either compatible with microG (open source), or have their own notification system (such as Telegram).

Same thing happened in Germany, UK and France. They waited until Apple/Google could provide Low Energy Bluetooth support. Earlier apps had energy problems, bit did implement the tracking ID securely, decentralized. Now the OS update the new apps don't use their own decentralized tracking anymore, they switched over to. the OS provided new "Random ID", which is a centralized Tracking ID. All those countries are lying about the security implications. In CH at least there was some public criticism which is conveniently ignored, I guess. The implication is that each government has now to ask Apple and Google via their friendly NSA contacts for the ID's in question. Which is not different from the previous protocol to get the search history or location protocol for its citizens.

> Users may be traced or identified by surveillance systems of third parties while using SwissCovid.

How does that work? Do they mean the Bluetooth MAC or can the users also be traced/identified by third parties through the Apple/Google API?

Setting apart the technical parts, this is IMHO preoccupying:

> NCSC states that "Users can always turn off tracing if they are in what they consider to be a sensitive environment".

Data (location and/or contacts) is either sensitive data or is it not (according to local Laws), the concept of "less sensitive data that I can risk being not protected" as opposed to "more sensitive data that - to be safe - I must exclude from collection by turning off the app" is "crazy".

Example:

1) going to work and back: app on

2) at work: app on

3) at home: app on

4) going out to - say - procure something illegal or meet lover (cheating on wife), sensitive environment: app off

In this case absence of data may be data as well.

True but it's plausible deniability (empty batteries), or activate the developer-mode on android and fake the coordinates (not cheating the wife, but still a work)

> In summary, our observations are as follows. > Some servers are hosted by Amazon, as part of a CDN service.

FUD - This report is all about Fear, Uncertainty and Doubt and is every bit as dangerous as lying.

I find it difficult to believe that, even among the HackerNews crowd, this point registers near as important as having an easy to use, efficient way to do contact tracing for Covid-19.

Why does every attempt to make the world a better place have to be ripped apart and thrown in the dumpster fire?

Unfortunately, I agree with this view of the report. The report does do a mid-depth technical dive and raises the sort of things a security analyst would certainly look to verify, and I will use it as a base for other app analysis - but it conflates hypothetical risks with vulnerabilities. I am dealing with these precise technical issues around de-identification and encryption in a professional context right now. The paper uses nested and linked parenthetical observations and comments without resolving them to evidence, and it reads like a rant. The issue of not being able to rebuild a working app from the provided source code is indeed cause for suspicion, but it needs deeper analysis. The criticism that somehow key derivation is not encryption reads like the author was reaching out of their depth.

A security analysis needs to be more than just an uncharitable read of an architecture that shows it has exposure to scandal or discredit. These apps are going to have issues around data access, custody and control and a lot of others, but the analysis of them needs to be stronger.

I agree generally with you, but Prof Vaudenay is not "out of his depth". His publication record would show that he knows the difference between key derivation and encryption. The people who don't are those trying to write the overly simplified summaries to calm people's nerves, in particular in the case of Vaudenay is taking about, the Confederation government, who should know better.

> there is no founded technical justification for excluding GAEN from the components of the system

That can unfortunately be said of quite a few apps, but it's good that they pointed it out here. In any case, if you're running a phone with Google Apps installed, privacy can only be an illusion.

Nobody commenting on the (lack of) formatting? I mean, I know we techies love plain and simple markup but this looks like taking a piss at the readers.

The content is not that great and the plain text does nothing to make it feel technical coherent or valuable.

misleading title. Please use source titles in submissions.

You mean 'Own Analysis of SwissCovid'?

Or what it is now (title was edited, before it just mentioned one of the points)

Ahhh, have a nice day.

Reply on news.ycombinator.com