cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kevbod
Newcomer I

Centralised vs decentralised tracking apps - security

As a UK resident, i am doing some personal research into the pros and cons of centralised vs decentralised apps. The UK National Health Service has chosen the centralised approach.

 

Using the BBC article below and other sources, it seems when an infected user reports themselves in a decentralised model, the database of users is downloaded to the phone itself, the phone then does the contact matching and risk analysis itself plus sends alerts.

 

Can anyone help me to identify exactly what is going to the phone of the corona virus infected user?

  1. A whole world DB, a single country, the phone users local area?
  2. What Personally Identifiable Information, if any is included in this DB or is it just the anonymous ID?

My initial thought here was that the whole DB is being sent to a phone whose security status cannot be verified and any Tom, Fred or Harry could download that DB merely by downloading the App and claiming to be infected.

 

If the uptake of these apps is as wide as expected, there are possibly huge security implications here.

 

Your thoughts and responses will be gratefully received.   Kevin Boddrell CISSP

 

https://www.bbc.co.uk/news/technology-52355028

5 Replies
denbesten
Community Champion

Re: Centralised vs decentralised tracking apps - security

Matching happens on your own phone.  Here's the general idea:

 

Each day, my phone generates a new ID#.  Then when you and I are both at McDonalds, your phone records my number for that day, along with when and where it was seen.  If I subsequently test positive, I upload my ID#'s (but not my name or location history) for the past two weeks to a public database.  Daily, your phone checks the public database to see if any of the uploaded ID#s are in its local database.   If it finds my ID#, it tells you that at 3:00 PM on Wednesday, you were within bluetooth range of a potentially contagious person at McDonalds.  

 

So, each day everyone's phone downloads 88,000 new ID#'s (the worldwide total of new daily cases yesterday) and compares the list against the numbers it has collected over the past 14 days.  

 

Unlike a centralized approach, this does not require big horsepower to centrally crunch large volumes of data and there is no central cache of PII.  Of course, it also means that the authorities do not automatically get a list of names for contact tracing (unless you turn yourself in).  

kevbod
Newcomer I

Re: Centralised vs decentralised tracking apps - security

Many thanks for your prompt reply. A few questions here please.

If i understand you correctly, the local DB on the phone is appended to on a daily basis. I'm guessing the daily regeneration of #ID is a security feature. If that ID changes daily daily on your phone and one would guess all other phones, how can the matching take place? Is there an element to the #ID that places it to your phone even though the #ID has changed?

 

If we move on to the next phase of the story and you become infected and you hit some sort of button on the App to tell the world that this is the case. That initial connection to another phone may have been collected on a train and that person is 400 km away from you now. I'm guessing your #ID and the #ID of the connections you made go to some sort of central server to alert your connections? Am I right in thinking the #ID suffices to send that alert and no telephone number is required?

 

I would be interested to know what App you are using, but that is not essential if you do not wish to say.

denbesten
Community Champion

Re: Centralised vs decentralised tracking apps - security


@kevbod wrote:

Many thanks for your prompt reply. A few questions here please.

If that ID changes daily daily on your phone...how can the matching take place?


The ID does not "change".  A new one is generated each day.  So, on any given day, my phone has 14 IDs -- today's, yesterday's, the day before, etc.  If I become infected, I upload the previous 14 IDs to the public/central database.   The local database on your phone keeps a copy of all the ID#s it has seen over the past 14 days.  Your phone downloads the public database and does the comparison.   The only thing in the public/central database is a list of ID#s, 14 for each currently infected person. Unless you become infected, your ID#s are never uploaded to the public database. 

 

Effectively, your phone will pop up a message saying that "ID#12345678 has been reported infected.  You were close to that ID at McDonalds and then Starbucks on Wednesday."  If we both followed the same schedule on Thursday, you would also get a second alert, but with a different ID#.  So, you would know that you were exposed on both days, but you would not know that it was me both times. 

 

The actual spec is a bit more complex (and available online), but this is the basic idea.  This page has a more in-depth overview.

 

One apparent shortcoming in the whole system is that each app has its own central database, so you will only be alerted if we happen to use the same app.  Hopefully, the various authorities will eventually see the value in cross-populating the databases.

 

I do not have a tracking app on my phone.  That is not a big thing around me.  My government is instead focusing on manual contact tracing.

 

kevbod
Newcomer I

Re: Centralised vs decentralised tracking apps - security

Many many thanks for your responses. My conclusion here is that both centralised and decentralised have similar issues. Can I please reiterate I am an individual and have no connection to any UK governmental organisation. Some friends, who were fearful of a "Big Brother " App asked me my opinion on the UK NHS App and that is my sole reason for researching into this area.

 

As usual in the security world, nothing is black and white but a number of shades of grey. I cannot find the article now but i did see that anonymous #IDs could be decrypted, if that is the right word to use, but what would actually be gained in terms of useful information is doubtful. In the UK, the sole piece of personal information given is the Post Code (ZIP code for our American friends) and only the first half is used, which is a regional identifier.

 

In the decentralised model, there still seems to be some sort of central server holding and disseminating the #ID database of infected users and also that database is passed out to any mobile device that reports itself as being infected. The security state of that mobile device does not appear to be verified and is deemed an acceptable risk. The UK App similarly only stores any information when and if the user reports themselves as suspected to be infected and the tracking, processing and alerting is done centrally, not at the phone.

 

As mentioned in a previous reply, both models rely on the honesty of the user to report themselves and there could be many reasons why they may not do so e.g. loss of earnings. This fact alone may make the efficacy of any App, questionable.

 

With the UK App, at the point the infected user wishes to reserve a  COVID-19 test, then further PII is naturally required. App or no App, this would be the same. The UK reason for choosing their model is to gain better insight into user infections - I cannot possibly comment on this medical arena.

 

Both models seem to work and it is a users choice which model they go for, if they install one at all.

 

The greatest future issue for me, as stated by the replies, is cross border functionality. The issue of leaving ones mobile device permanently open to Bluetooth hacks is a far greater concern in terms of security.

 

I would gladly welcome more comments please and will close the question soon if nothing more is forthcoming.

denbesten
Community Champion

Re: Centralised vs decentralised tracking apps - security

Per the spec, the initial id# is randomly generated, so there really is nothing to "decrypt". 

 

Unquestionably,  one more app enlarges the Bluetooth attack surface, but the lions share of the risk was accepted when we collectively started buying airpods, forcing BT to remain permanently enabled.