Immune, first analysis of the code: well, but beware of the privacy slip


Following the release of the Immuni app source code, we compiled the app on O.S. Android. However, after the setting phase (permits, province of residence, information) the app does not activate (since the use of the Apple and Google API is reserved for government entities and approved devs).

So we have analyzed the code, paying particular attention to the app’s external communications, the data it requires and how the OTP will work; given that as already mentioned by some, for now we only have the app code, but not the server and backend codes used to validate the codes (which will be managed by the Ministry of Health).

A first judgment on the Immuni app code

It must be said that this article requires a preliminary knowledge of the functioning of the Google and Apple APIs, which we have already extensively talked about first here and then here. Our analysis is embedded in a path that has accompanied the reader towards an in-depth knowledge of the real functioning of the tracking apps, with an eye turned to the protection of personal data and the impact that the app may have on the rights and freedoms of person.

It cannot be denied that, from an initial analysis, the software appears well made, clear, well layered and also very full-bodied. After all, Bending Spoons is not the latest addition, on the contrary, it is among the leaders in the mobile app sector.

Many information designed to convince and reassure the user

From the outset it is noted that particular attention was paid to communication. A long series of information aimed at “convincing” the undecided user.

In fact, the Singapore experience teaches us that only 50% of users who had downloaded the app actually activated it. Hence the obvious need to continue the user’s decision-making process, assuming that the arrival point is not the download, but the activation.

And then we find declarations like:

“Immuni does not collect your name, surname, date of birth, address, telephone number or email. Immuni cannot trace your identity or that of the people you come in contact with.

Immuni does not collect any geolocation data, including GPS data. Your movements are not tracked in any way. The data saved on your smartphone and the connections to the server are encrypted.

Your data is saved on the server in Italy, is managed by public subjects and controlled by the ministry of health. All data are deleted when no longer needed and, in any case, no later than December 31, 2020

To help the National Health Service take care of you, Immuni sends your province of residence to the server of the Ministry of Health, the notice of the correct functioning of the app, as well as the previous exposure data “.

Analysis of app calls to the server

One moment… The previous exposure data?

This last statement makes our ears prick. So will Immuni also notify the server of who received the notification? It would seem a deviation from the guidelines of the classic DP3T which inspired the system hypothesized by Apple and Google.

Let’s analyze at this point, code in hand, all the calls that Immuni makes to the server (not Google and Apple, of course), in order to find out which data travels to the cloud and what they take away from the smartphone.

The main API, relating to the communication with the server of the declared positivity, is “/ v1 / ingestion / upload”. This API loads the Keys for self-diagnosis on the server, accompanying them with the province data and (attention) also with any previous exposure reports (i.e. the exposure reports received).

The report made by the app on the infected user

In other words, we can clarify and summarize as follows:

If I am infected and if I have received exposure warnings in the past, a warning is generated reports, obviously anonymous and without codes, composed of date, duration (in steps of 5 minutes up to 30 minutes) e intensity (signal) of any exposure to other Keys found to be infected. If the overall level of risk that comes out of this report is high, the alert notification is generated. In any case, it is kept for 14 days and then sent just in case I test positive.

This report should be collected by the server for statistical purposes only. Let’s imagine that the interest of the app is to understand the density of the outbreak and how much and how citizens react to notifications.

Among the API on the server side there is also the one used to verify the OTP.

Modern Application: all the steps to manage change effectively

The procedure for uploading the codes to the health server

Before analyzing it, let’s check how the system necessary to authorize the infected person to declare himself will work, in order to warn those who have been in contact with him.

Then activating the procedure to allow the upload of all the codes with which I have been visible around the city (technically the Tracking Exposure Keys of the previous 14 days will be sent, which are the array of proximity IDs that are shot out via bluetooth ), the app generates a random code locally. No reference to the phone or Device ID or Device Tracing Key.

The app draws letters of the alphabet and regenerates each time the app is started.

The healthcare professional enters it into the system using a specific tool that will be granted to the structures and, at that point, the app with a button will carry out the counter-check.

The matching on the server will return a token which will then be used to authorize the upload of the Keys.

It is time to check the API for generating the Token.

Token generation for upload and security

Its name is “/ v1 / ingestion / check-otp” is has the sole purpose of verifying that the OTP generated by the server has been verified.
LTP is encrypted with the sha256 algorithm and is accompanied by a boolean that must be set to “true” if it is a fake send, used to misdirect any traffic sniffs.

This allows an additional degree of security to the entire protocol.

The communication is in fact in https, so the content regardless is obscured and it is not easy to understand (snorting) if it is a fake upload.

The server verifies that it has been authorized (by the healthcare professional) and returns the token which is then used for uploading.

To date, as we do not yet have the server’s source code, we cannot know more.

In any case, everything will be encrypted with sha256.
Speaking of which, we like to point out that the OTP does not arrive in the clear, but only its hash.

The server verifies that this hash has been “verified” (previously by the healthcare professional) and gives the ok. From the hash, there is no going back to the OTP.

Notification will be very simple. The message that is read in the source code is: a user with whom you came in contact has tested positive for COVID-19. Find out now what you need to do.

By opening the app, an image like the one below appears.

But our analysis didn’t end there. We went further, knowing that information on “where and when” we were in contact with the infected is still stored in the app (albeit anonymously).

A privacy smudge: you know when the infection occurred

We wanted to be sure that a system had been adopted whereby a user should not be able to know “when” and with what intensity he met the positive. In this case, even without talking about the protection of personal data pursuant to the GDPR, the app could still have an important impact on the company, considering that such information would greatly restrict the range of probability, allowing to identify (or to hypothesize) the identity of the positive. The hunt for the greaser must be absolutely avoided.

And, unfortunately, we have found a screen (hopefully work in progress) which, at present, allows access to this useless information by the user.

In essence, the user will be able to know “when” the infection occurred and, with a good dose of memory and deduction, he may be able to trace “who” reported himself as infected. With all due respect to any privacy speech. Substantial, non-normative privacy.When the app enters “possible risk contact” mode, the main page shows us a screen where it reads clearly “Immuni found that two days ago you had the last contact with a positive user at COVID-19”.

Screenshot aside, what is effective within the code that controls this function?

Analyzing it, we found a function that calculates the days since the last contact with the subject at risk.

However, to be honest, qhis function is not called in that message, so much so that the text string mentioned above, seems never to be changed and always remains on “2 days ago”. It would seem like a work in progress (or an error). We await enlightenment on such an important issue.

Downloading the keys of the infected

Another call is the one that requires the server to download the daily diagnosis Keys, the new keys of the patients tested positive for covid-19, in order to match those saved in your operating system.

The update is currently set to a 2-hour timing (but we find a “// fixme” comment, so it will probably be retouched). For display completeness the server is asked for the settings (via the call “v1 / settings”) That set this timing and other things like the minimum exposure level to trigger the notification.

These are downloaded via blocks, “chunks”. Each chunk contains a number of new keys to feed to the A / G library.
The app through the API “/ V1 / keys / index” check that there are new chunks to download since the last update. In case of new chunks available, a chunk is downloaded via the “/ v1 / keys / {chunkNumber}” API and saved in storage. As always, the data is encrypted and is fed to the A / G library without the app reading or processing the content. Then they are canceled.

Before concluding this first analysis on the app’s hot topics (data collected and communications), there was much talk about the need on Android to activate geolocation.

In reality, “geolocation” (only on android) must be activated when bluetooth is to be activated. The Google framework requires this for any app that scans with nearby Bluetooth.

GPS activated but no data used

Android requires it because, by scanning with Bluetooth, Beacons of geolocated buildings (e.g. shops) could also be scanned and therefore indirectly – and theoretically – find the position of the phone by crossing data.
For this reason, Google requires that you keep your location active while using this feature, to make sure that the user is aware of this possibility, regardless of whether the app makes use of the GPS sensor or not. It is, paradoxically, a guarantee for users, against other apps that can understand where we are indirectly. And, therefore, will Immuni use GPS data or not?

Again, let’s go back to the source code and read the permissions. You don’t need a nerd, it’s really clear.

The app asks for and uses only two Android permissions: internet and bluetooth. Even in the code (as well as in the declarations), Immuni will not access any location data. But it was obvious.

In conclusion

In conclusion, although the system is well structured from a privacy-regulatory point of view, this must also be done from a privacy-substantial point of view.

Leaving the data relating to the date and time of the possible infection clear is the worst possible approach. Paradoxically, a centralized system that also provides a collection of real personal data would be less invasive, rather than an app that provides for the display of this information.

We therefore hope for anonymization of the data relating to “when the infection occurred and with what intensity”, also because this information is absolutely useless. Once the parameters have been set to define the exposure “at risk of contagion”, there does not seem to be any need to give further information to the user. If it is decided that a test is needed for that type of exposure, it doesn’t matter when and how. We are sure that it is a “work in progress” and that this aspect will be reviewed.

Having said that, we have put another piece into understanding the Italian tracking system. TO this point is only missing the release of the server codes and those of the backend to validate the codes, in use by healthcare professionals (as well as the release of the protocols to be followed for the latter).

live streaming, 26 May

DPO: what are the new security risks associated with mobility and smartworking?


Source link


Please enter your comment!
Please enter your name here