[DISCUSSION] Solution without closed source dependencys

[theScrabi]

EDIT: tl;dr: We are working an an open implementation of the Google/Apple protocol (I call it PPCP, which may be wrong). You can find and contribute to our repository here: https://github.com/theScrabi/CoraLibre-android-sdk

Dear Corona-Warn-App developpers we have read your code and documentation. We like your effort and your open mind for the community. As there is a small but willing comunity of people who refuse to use closed source Google or Apple dependency and so can not use the Corona-Warn-App, I'd like to discuss the posibility of a Google Free FLOSS solution.

What we know so far is that it's currently hardly possible to create the corona app without the use of the closed source GMS. This comes along with the nearby android exposure notification API, which implements the PPCP protocol. From what we can see in the code so far, the contact points between the android exposure notification API and the Corona-Warn-App are few as for the most common calls to the API a wrapper class is used. That's great! Also there are only about 14 code files that include parts from the GMS library. We therefor think it might be feasible to create a version of the app that does not require GSM services.

As statet in this issue the current maintainer have no plans to implement an own exposure notificatoin API, but might be open to support an alternative if available.
What we understand so far is that the part that runs the actual BLE contact tracing as well as providing a highlevel API for exposure likelihood and key handling would need to be reimplemented. We had several thoughts about how this might be possible.

• As its offtenly staded that PPCP is close to DP-3T, I question if it is possible to reuse some parts of the prestandard DP-3T android sdk.
• Prestandard DP-3T used forground services. Would it be possible to implement a GMS free non root version that would always display a notificatino while running the advertising and receiving service? Now i know this is not a good idea as people tend to close this notificaion, but was it techinically feacable to replace GMS by such a sollution?
• A solution that would work on phones with root access such as Lineage-OS or /e/ could maybe be to introduce a privileged extentsion like the one used by the fdroid app. This might make it possible to expose functions to the Corona-Warn-App that would normally only be accessible for higher privileged applications. Maybe this could be a replacement for GMS.
• One other way was to compleatly break loose from Smartphones and focuse on microcontroller based tracing beacons. For example on ESP32 or the CCC Card10. This way not only users with Lineage-OS or rooted smartphones could profit from an alternative implementation but also people who don't use a smartphone at all.

If a community based solution is possible what would be the next steps to go?

---

Internal Tracking ID: EXPOSUREAPP-5775

[uschindler]

I agree, there should maybe some abstract wrapper class or interface that encapsulates the Google Play Services stuff. Especially as Google already mentioned that the play services stuff may move to core Android (maybe AOSP). Also Huawei may have another variant of the same API without play services on their newer phones.
So I tend to think that another abstraction here would be a good idea, so it's easy to add more exposure notification API code.
On the other hand: If Google moves the stuff away from Google Play Services on newer devices, I am sure the API will stay the same and Google Play services will delegate to the Andoid layer.

[ttobsen]

Here is a good example of a GSM free fork:

https://f-droid.org/de/packages/org.telegram.messenger/

While the original Telegram app uses GSM, in example for location sharing, the fork is 100% GSM free, without losing any functionality (in this case they use Open Street Maps iirc).

Removing the Google dependency could also improve the user acceptance by wiping concerns against US big data companies.

[MalteJ]

Personally, I can only encourage you to build a libre version of the ENA API for Android.
But to be crystal clear:
In the foreseeable future the Corona-Warn-App project will rely on the official Google and Apple APIs!

My personal advice to you: Fork this repo, give it a new name (e.g. CoraLibre or CoronaLibre) and integrate it with your libre ENA API. Try to change as few as possible of the upstream code so you can stay really close to this upstream repository. If you have a working fork, completely libre, and some minor changes in the upstream code base would help you to integrate the upstream commits (e.g. by doing some Dependency Injection here and there) feel free to create PRs. We will definitely accept no code changes that have impact on the UX (e.g. the mentioned Android notification hack).

All the best,
Malte

PS: Please be careful when publishing your app: Afaik you may not use the Corona-Warn-App name, brand, logo and designs.

[ttobsen]

In the foreseeable future the Corona-Warn-App project will rely on the official Google and Apple APIs!

Then in the foreseeable future, it will not be possible for everyone to use the app. I'm using a Fairphone 2 with their Google free Fairphone Open OS, no GSM available.

So the question is: Why is it necessary to use the Google APIs for this app? Are there any technical reasons?

I think the most important feature for such an app is, to make it available to the biggest user spectrum possible. But when using Google APIs this target can't be reached. :-(

[theScrabi]

@MalteJ That is great! Thank you for the reply. So I guess the next thing is to somehow be able to write a libre ENA API that is compatible to Privacy-Preserving Contact Tracing. The question was can it be pulled off and has someone experiment with it already?

[marcauberer]

In the foreseeable future the Corona-Warn-App project will rely on the official Google and Apple APIs!

Then in the foreseeable future, it will not be possible for everyone to use the app. I'm using a Fairphone 2 with their Google free Fairphone Open OS, no GSM available.

So the question is: Why is it necessary to use the Google APIs for this app? Are there any technical reasons?

I think the most important feature for such an app is, to make it available to the biggest user spectrum possible. But when using Google APIs this target can't be reached. :-(

I think using Googles / Apples solution is the only option for now, since the development of an own "Google free" solution would cost time and money.
Please read the Notification Exposure Documentation in this project for more information.

[MalteJ]

@MalteJ That is great! Thank you for the reply. So I guess the next thing is to somehow be able to write a libre ENA API that is compatible to Privacy-Preserving Contact Tracing. The question was can it be pulled off and has someone experiment with it already?

I do not know any project that is trying to create a compatible API. But I know a few folks that would be very interested in such a project and maybe could also help. @theScrabi Are you an Android developer? Can you start developing such an API?

[theScrabi]

I am an android developer, however I am not sure if I could write such an API as I have little experience with bluetooth and that API (yet). I started to read my self into the documentation and prestandard DP-3T and I think to see some parallels, so maybe by modifying prestandard DP-3T android sdk it might be possible to create a compatible API, but I don't know for certain right now.
If I tried it I'd need help.

[MalteJ]

@theScrabi you will find most of the documentation here:
https://www.apple.com/covid19/contacttracing/

I think when you start developing a lib there will appear some helping hands from the community 🙂

Feel free to post a link to your project in this thread!

[theScrabi]

So I've been researching a bit more, as I try to persue the idea of modifying the prestandart dp-3t android sdk. So here is a comparison of both based on what I found out so far (no assurance for accuracy, please correct me if I am wrong):
DP-3T and PPCP are both decentralized and generate a new Token every ~15 minutes. In both protocolls that token derives from a general key that will be newly generated every 24h. On DP-3T that key derives from a $SK_0$ which will be generated only once when the app is installed. Then every 24h a new $SK_i$ is derived from it by applying a HMAC function on $SK_{i-1}$. At PPCP this equivalent is the Temporary exposure key $Tek_i$. It will be generated by a random function so no deriving here.
For DP-3T $SK_i$ and a Constand string are then Hashed and put into a stream cipher function. From this stream every 15 minutes 16 bytes are taken and used as Ephermal ID which is the id that gets broadcasted via Bluetooth.
The equivalent for the EPhid for PPCP is the Roling proximity identifier. First the Rolling Proximity identifier key $RPIK_i$ is derived from $Tek_i$ together with the string "EN-PRKI" using an HKDF function.
About every 15 minutes a rolling proximity identifier $RPI_{i,j}$ is then derived from it by encrypting the $RPIK_i$ together with $PaddingData_j$ padding data contains several information including a counter that will represent the time that $RPI_{i,j}$ was generated. The $RPI_{i,j}$ is then concatenated together with the Associated Encrypted Metadata $AEM_{i,j}$ which contains encrypted information about the sending power and the protocol version. The concatinated data is then broadcasted via Bluetooth.

The Broadcasting in both cases is send as Payload of the BLE Advertising packages.
If someone was found to be Corona positive he/she must upload all $SK_i$ and Timestamps $i$ of the past 14 Days for DP-3T, and all $Tek_i$ for the past 14 Days for PPCP.

One thing that concerned me a little is that the App apparently can not see the received $RPI_{i,j}$. The app can only give the infected $Tek$s it received from the server to the framework, and ask how high the risk is that the user got infected. That the app has no access to the $RPI_{i,j}$ is ok, but here it says that an algorithm calculates the risc based on the exposure duration, however I could not yet find any information about this algorithm.

The next thing I will do is frok the prestandard DP-3T android sdk and try to get it working so we can start modifying it :)

[theScrabi]

Here is the repository of the CoraLibre-android-sdk. So far it still contains the prestandard DP-3T android sdk.

[theScrabi]

@MalteJ you said we can not use the name or the package name of "Corona-Warn-App" which is ok. We will not, but can we leave the paths of the package names of the java files? If not pulling changes from this repo will get harder as files are going to be stored in different locations.

[MalteJ]

You just shouldn't use the name for any marketing stuff. I don't care about path names. :)

[theScrabi]

We are making progress. The prototype of the encryption core for the Apple/Google is done. It needs to be verified by a security expert:
https://github.com/theScrabi/CoraLibre-android-sdk/tree/master/coralibre-sdk/sdk/src/main/java/org/coralibre/android/sdk/internal/crypto/ppcp

@MalteJ According to this file, page 11, Apple/Google hand out test vectors if you kindly ask them. Do you know if these testvectors are public available or who I can kindly ask to get them?