Bluezone - Electronic mask

• vi

• en

• contact-tracing

• promote-app-to-friends

• “Protect yourself: This app is to alert if you have been in close contact with people who has tested positive for COVID-19” Source: [website], checked on 2020-05-18

• “Protect our community: By joining Bluezone community, you have got connected to protect the community” Source: [website], checked on 2020-05-18

The App Operators can establish the social graph of all Bluezone users, plus the time periods when they were within contact range of each other, at any time. Users additionally can be identified if they have provided a phone number to the App.

This has been shown in a proof of concept. Source: [github-thaidn-bluezone], checked on 2020-08-27 .

• In the most recent update, Bluezone stopped using Contact tracing with static Contact IDs in favor of Contact tracing with changing pseudonyms created by iterating a hash function. This eliminates various attack vectors that existed against this previous version. Source: [github], checked on 2020-08-27

• Smart phone theft is facilitated, because the emitted beacon points potential thieves to the location of a smart phone (e.g. on a person, or left in a car or office).

• Reduced battery life of smart phones; claimed to be minor. Source: [website], checked on 2020-08-27

• “The Ministry of Information and Communications and the Ministry of Health recommend that the whole country install Bluezone for themselves and for 3 others” Source: [website], checked on 2020-05-18

• Presumably the number of concurrent App Users in a certain region must be a significant percentage of people in that area. This is true for all technical approached to contact tracing.

The App website states: “According to the rule (App Assay interpretation: government policy), a person who has been identified as infected with COVID-19 will be put in quarantine and get treatment, so there is no way you can accidentally “get close” to such a person and Bluezone does not have this feature as well.” Source: [website], checked on 2020-05-18 .

This implies that users who are known to be infected will be put into mandatory quarantine. (This itself is not a consequence of the App, but of government policy.) It is unknown whether contacts of known infected people, as identified by the App, will also be subject to this policy; if it is, it would be a direct consequence of using the App. Note other consequences of technical Contact Tracing. Source: [technical-analysis], checked on 2020-05-18

• Each App Instance broadcasts a Contact ID over Bluetooth Low Energy (BLE). As of the most recent release, this Contact ID consists of 12 bytes and changes every 15 minutes. While these broadcast Contact IDs are being generated deterministically, for an outside observer they appear random and cannot be correlated by anybody other than the App Operator, as long as the App User has not been declared as infected. Source: [whitepaper], checked on 2020-08-27

  Source: [github], checked on 2020-08-27

• This broadcast is heard and the broadcast Contact ID is recorded by other App Instances on other App Users’s smartphones. The duration and strength of the contact is also recorded. Source: [whitepaper], checked on 2020-08-27 Source: [github], checked on 2020-08-27

• The Contact IDs for a given App User are generated from a App User-specific random seed called the Base ID. Source: [whitepaper], checked on 2020-08-27 Source: [github], checked on 2020-08-27

• The broadcast Contact ID for a specific 15-min period are a few selected bytes of the values of a Secure hash of the previous period’s Contact ID, except for the first Contact ID of the day, which is the value of a Secure hash of a Daily Key plus a constant. In other words, the Contact IDs for a given day are all derived from a Daily Key that’s specific to that day, and will be different on the next day. Source: [whitepaper], checked on 2020-08-27 Source: [github], checked on 2020-08-27

• The Daily Key, in turn, is the value of a Secure hash of the previous day’s Daily Key, with the very first Daily Key being the initial random seed called the Base ID. Source: [whitepaper], checked on 2020-08-27 Source: [github], checked on 2020-08-27

• When an App User is determined to be infected, the health authorities initiate a process, as a result of which the mobile phone and the App Instance of the infected App User are identified, and the App User’s App Instance is instructed to upload the recorded Daily Key for the first day of the likely period of infectiousness (14 days). Source: [whitepaper], checked on 2020-08-27 Source: [github], checked on 2020-08-27

• All App Instances of all other Bluezone users periodically download the uploaded Daily Keys of all users from the cloudcomponent. Because the Daily Key of an App User is sufficient to calculate all future (from the date of the Daily Key) Contact IDs this App User’s App Instance has broadcast, the App Instance of any other App User can now check whether any of those calculated Contact IDs appears in their list of recorded Contact IDs in the relevant time period. Source: [whitepaper], checked on 2020-08-27 Source: [github], checked on 2020-08-27

• Bluezone appears to also implement a second, Bluetooth-GATT-based data exchange facility by which iPhones can participate even when Bluezone is not currently running in the foreground. However, it appears this functionality is currently disabled and we have been unable determine how this functionality would identify App Users. Source: [github], checked on 2020-08-27

• “With each person installing the app for themselves and getting the smartphones of 3 other people installed with Bluezone, in a month, the whole Viet Nam will get protected” Source: [website], checked on 2020-05-18

• “If the number of users is large enough, even those who do not use smartphones are also protected.” Source: [website], checked on 2020-05-18

• Several third parties have questioned the effectiveness of contact tracing in general (irrespective of this App) for fighting the disease, see Contact Tracing.

• No numerical information about the App’s actual effectiveness has been found.

• For the purposes of communicating with the devices of other App Users, Contact IDs appear random, and change every 15 minutes. These, by themselves, are not correlated nor correlatable to specific individuals by other App User. Source: [whitepaper], checked on 2020-08-27

• Unless an App User opts out from providing a phone number, the App Operator can identify the App User through their phone number. This is because the App submits the App User’s phone number to the App’s Cloud Component during activation and it can be linked through the Firebase identifier for this App User. Source: [technical-analysis], checked on 2020-05-18

• While it is possible for an App User to skip entering their phone number into the App, the App strong encourages the App User to provide it, and explains that certain features (“support”) is not available to App Users who opt out. Phone numbers are widely considered personally identifiable information (PII). While no information is available which percentage of App Users have provided their phone number, from the structure of the App we would expect that this would be a large number. Source: [technical-analysis], checked on 2020-05-18

• The Contact IDs of the App User are only associated with their phone number outside of the App User’s smartphone once the contact history of the App User has been uploaded to the Cloud Component.

• As it has been shown that such an upload can be triggered remotely by the App Operator, without consent or notification by the App User, App Users rely on the App Operator’s public statements that will only do that with the consent of the App Users. Source: [website], checked on 2020-08-27

• It is unclear why the App asks the App User for their phone number in the first place. There appears to be no functionality in the App that requires the phone number, and from a customer support perspective (the stated reason in the App), it will be the App User calling support, not the other way around. It is possible that requesting a phone number is simply intended as a measure to reduce fake mass signups. Source: [technical-analysis], checked on 2020-05-18

• The White Paper asserts “there is no information that might lead to personal identities of users being worked back from their Bluezone ID (App Assay note: Contact ID).” Source: [whitepaper], checked on 2020-05-18

  However, this ceases to be true once the list of Exposure Contacts has been uploaded to the Cloud Component.

• It is unknown whether the App Cloud Component records the IP Address of the mobile device during registration, together with the Contact ID. IP Addresses are also widely considered Personally Identifiable Information and depending on the information available to an Attacker or the App Operator, can be used to associate IP Addresses with specific individuals. Source: [technical-analysis], checked on 2020-05-18

• on Cloud Component: Not known.

• on Smartphone Component: determined by the backup settings of the App User.

• In the most recent version, the newly implemented /choice/contact-tracing-iterated-pseudonym approaches global best practices.
• However, the existence of silent upload functionality that can be triggered remotely is inconsistent with global best practices.

The following data is being transmitted:

• The App User’s Contact IDs' are broadcast continually (24x7) by the App User’s smartphone via Bluetooth Low Energy (BLE). This broadcast is available to anybody who cares to listen. As the Contact IDs appear random and change frequently, by themselves they are not information that needs to be protected. However, once an App User has been marked as infected and their Daily Key has been conveyed to other App Instances, a partial unmasking of the App User can be accomplished for the time period from the start of the validity of the Daily Key. Source: [whitepaper], checked on 2020-08-27

• There terms were found that govern the use of this data.

• No information is available on whether or not data held by the Cloud Component is ever transmitted beyond the App. This data contains the phone number of infected App Users.

• privacy-policy-none

• On the Cloud Component: no information available.

• On the Smartphone Component: relies on protections by the smartphone operating system. Source: [technical-analysis], checked on 2020-08-27

• Contact IDs by the App are intended to be public, so they do not need to be confidential.

• Contact IDs can easily be replayed or spoofed by anybody.

• the communication between the Smartphone Components and the Cloud Components is performed over HTTPS.

Source: [technical-analysis], checked on 2020-05-18

All people involved in the creation, operation and governance of the App.

It is particularly notable that the App’s cloudcomponent is now hosted by a company that is operated by the Vietnamese Ministry of Defense. This company has the largest market share in the Vietnamese telecommunications services market, and as such it may be able to bring together other information not usually available to an App Operator if it intended to use this App to surveil App Users and their contacts (e.g. de-anonymized IP addresses).

• App Users can deactivate and delete the App.

• However, the App Users cannot remove information related to them from the Cloud Component. This includes their phone number, and the list of their Exposure Contacts once uploaded Source: [technical-analysis], checked on 2020-05-18

• Some of the source code for the Smartphone Component is available on Github under the GNU General Public License Version 3. Source: [github], checked on 2020-08-27

• Other components of the Smartphone Component are not available on Github, including the code that uploads an App User’s Base ID and contact history to the cloudcomponent upon silent request by the App Operator. Source: [github-thaidn-bluetooth], checked on 2020-08-27

• Source code for the Cloud Component is not available.

• App stores on iOS and Android. Source: [website], checked on 2020-05-18

• Recommendation by existing users facilitated through “tell somebody about this app” functionality built into the App. Source: [technical-analysis], checked on 2020-05-18

• Developers can log issues on Github, or send e-mail to an e-mail address published in the source code. Source: [technical-analysis], checked on 2020-05-18

• App Users can submit questions through the website Source: [website], checked on 2020-08-27

• data on the Cloud Component: no information found, presumed No.

• data on the Smartphone Component: subset shown in the user interface; no download supported Source: [technical-analysis], checked on 2020-05-18

• data on the Cloud Component: no information found, presumed No.

• data on Smartphone Component: uninstall the App

Partially. No information is provided on:

• the actual effectiveness of the App
• risks for abuse by App Creators
• the fact that silent upload functionality appears to exist in the deployed App while such functionality is not mentioned in the documentation or present in the published source code. Source: [github-thaidn-bluezone], checked on 2020-08-27

• The Smartphone Component stores and processes:

  • the App User’s Base ID, from which all Contact IDs are derived;

  • the App User’s phone number;

  • a Firebase token that corresponds to the App Instance;

  • a list of all received Contact IDs, including time of contact and signal strength of the contact.

• The Cloud Component receives (and likely stores and processes):

  • all App Users' phone numbers (who have not opted out), together with their Firebase tokens;

  • when uploaded:

    • the App User’s Base ID, from which all Contact IDs can be derived;

    • all Contact IDs recorded by that App User together with time of contact and signal strength of the contact.

• MemoZone, contribution unclear Source: [website], checked on 2020-08-26 .

• mobifone, contribution unclear Source: [website], checked on 2020-08-26

• Firebase (Google), for authentication and messaging Source: [technical-analysis], checked on 2020-08-26 .

• Viettel provides the hosting of the Cloud Component Source: [technical-analysis], checked on 2020-08-26 . Wikipedia notes that Viettel “is a state-owned enterprise and operated by the (Vietnamese) Ministry of Defense”. {{ sourceref “wikipedia-viettel” “2020-08-26” %}}.

The contractual or legal obligations of any of the service providers are not known.

• custom Bluetooth Low Energy (BLE) beacons Source: [whitepaper], checked on 2020-08-27

• a custom Bluetooth Gatt profile (apparently disabled) Source: [whitepaper], checked on 2020-08-27

• architecture-smartphone-cloud

• contact-tracing-iterated-pseudonym

• userid-pseudonymous-global

• The English-language whitepaper is out of date, but the Vietnamese-language version has recently been updated. It documents the basic contact tracing algorithm. Source: [whitepaper], checked on 2020-08-27 .
• Major other parts of the system (such as when and what uploads occur) are not documented.

• The public documentation strongly suggests that collected contact histories are only stored on the App User’s smartphone. This is misleading as they are being uploaded at least when the App User has been marked as potential infected.

• The public documentation strongly suggests that all (not just some) of the source code for the smartphonecomponent of the App is available as open source on Github. However, it has been shown that major functionality present in the app is not on Github.

• Specifically, the functionality that allows the App Operator to silently upload a App User’s contact history is not mentioned in public documentation, nor available in source code. Source: [github-thaidn-bluezone], checked on 2020-08-27

• Some of the source code for the Smartphone Component: https://github.com/BluezoneGlobal

• While there are links labeled “Privacy Policy” from the app stores, these links only lead to a general information page about the App. For this reason, we catogorize the App as not having a Privacy Policy.

• It is surprising that a number of apparently independent parties provided strong pushback on Hacker News on an independent review of this app Source: [hackernews], checked on 2020-05-18

• Please note the general disclaimer. We appreciate feedback and corrections.

• This assay is not exhaustive, for reasons that include available resources and the unavailability of key documentation about the App.

• This assay relies on English-language documents, which may be less complete and less accurate than any presumed Vietnamese-language documents. Vietnamese-language documents were accessed with Google Translate, which may produce inaccurate results. Also, many of the available English-language documents were clearly written by non-native English speakers and often use terms that native English speakers would not use, or not use in this context. Our interpretation of some of those terms may be incorrect with respect to the intention of the writer.

• App website (self-assertion) [website]

• White paper, accessed with Google Translate, and White paper (English) (self-assertion) [whitepaper]

• Github repositories (self-assertioninference) [github]

• Blog post by Thai Duong and resulting discussion here (inference) [vnhacker-fixed-id]

• Discussion in response to this issue filed on Github, accessed with Google Translate (self-assertioninference) [github-documents-issue-3]

• Discussion on the problem with fixed Contact IDs in response to this issue filed on Github, accessed with Google Translate (self-assertioninference) [github-react-native-bluetooth-scan-issue-4]

• Issue with generating predictable Contact IDs (inference) [github-react-native-bluetooth-scan-issue-2]

• App Assay: technical analysis (inference) [technical-analysis]

• Invocation of Cloud Component API (self-assertion) [api-invocation]

• Discussion on Hacker news (inference) [hacker-news]

• Issue with generating random IDs (inference) [github-react-native-bluetooth-scan-issue-5]

• Discussion MAC Address randomization for Bluetooth on Stackoverflow [bt-address-randomization]

• Wikipedia entry on Viettel (inference) [wikipedia-viettel]

• self-green

• others-green

• self-green

• others-yellow

The App has several privacy issues which can be avoided through a changed implementation including:

• The App Operator can silently upload any App User’s complete contact history and supposedly secret Base ID. This given the App Operator the ability to silently assemble a real-time social graph of all App Users. This is unnecessary for the stated purpose of the App and not conveyed to App User.

• The App Operator can easily determine the real-world identity of any App User who has entered their phone number into the App.

• Many aspects of the technology, operations and governance of the App are not documented, nor independently overseen. Where information exists, App Users largely depend on the word of the App Creators only.

• We recognize that several major improvements have been made in the most recent version of Bluezone.

Critical:

• Remove the functionality from the code that allows silent upload that can be triggered by the App Operator.

• Restore trust in the implementation by publishing the full source code of the Smartphone Component including instructions that are known to enable independent reviewers to build the App on all platforms.

• Do not ask App Users for their phone number at time of registration, as it does not appear to be needed. Should there be good reasons to need the phone number, they need to be explained which they currently aren’t.

Important:

• Review the published white paper on a regular basis and make sure it accurately reflects the current state of the implementation. Remove outdated copies of the white paper (e.g. on Github).

• Augment the white paper to describe all data at rest, and data in motion for all components of the App.

• Respond to all open issues raised by the public on the bug tracker; currently several major issues have had no response.

• Publish the State Machine of the App so it can be clearly understood what happens in terms of data exchange and behavior of the App triggered by which events. (E.g. the App seems to have states doubt, pending, safe, infected, verified; document what they mean and how the App behaves in those states)

• Publish the source code of the Cloud Component.

• Research and publish key statistics of the App on a regular basis. This should include not only how many active users there are, but also key disease-relevant metrics such as:

  • how many App Users have tested positive and whose Daily Key was published to other App Users through Bluezone.

  • how many of their contacts were identified through the App;

  • how many of their contacts then tested positive as well.

To further increase public confidence in the App:

• Migrate the implementation to an independently validated, major implementation of Bluetooth-based contact tracing, such as the Apple/Google framework.

• Perform development on the public Github repository, not elsewhere.

• Commission an independent Audit of all aspects of the App, in particular the operations of the Cloud Component and the interaction of the entire App system with the public health system.

• Clean up the code base to remove obsolete and duplicate code. Improve the overall quality and documentation of the code, and implement automated tests.

• Convene an independent oversight board that maintains a list of questions submitted by the public, researches answers to those questions in full cooperation with the App Creators and publishes answers in a timely manner.