
Analysis of SwissCovid app - ned_ludd
https://lasec.epfl.ch/people/vaudenay/swisscovid.html
======
dignick
>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?

~~~
niea_11
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._

~~~
rob74
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...

~~~
niea_11
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](https://lasec.epfl.ch/people/vaudenay/swisscovid-ana.pdf)

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

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

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

------
jamisteven
"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?

~~~
rob74
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.

~~~
nix23
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.

~~~
rob74
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?!

------
rurban
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.

------
_ink_
> 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?

------
jaclaz
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.

~~~
nix23
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)

------
greggrahamer
> 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?

~~~
motohagiography
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.

~~~
jeffrallen
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.

------
LockAndLol
> 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.

------
PostPlummer
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.

------
detaro
misleading title. Please use source titles in submissions.

~~~
nix23
You mean 'Own Analysis of SwissCovid'?

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

~~~
nix23
Ahhh, have a nice day.

