Static Analysis of TraceTogether for Android

BlueTrace uses TempIDs as a means of preserving privacy while exchanging contact tracing records. However, we found that TempIDs still pose a privacy risk: because they are publicly broadcasted, it is important that a particular TempID is never associated with some other personal information. For example, if a string containing a TempID is transmitted in clear along with the user's IP address, then a link would be established between that TempID and the IP address.

We found that BlueTrace did not expose TempIDs to external parties. Only the BlueTrace app and the central server know what TempIDs were issued to a user. However, BlueTrace maintains a local store of TempIDs. This store is in clear, and an attacker with privileged access to BlueTrace would be able to read it. Such an attacker would thus be able to associate the user to the TempIDs. However, since this attack would require some form of compromise of the BlueTrace client, its impact is low. Please see Section 5.2.6 for more information.

BlueTrace contains a component that collects statistics and periodically sends them to a central server. This component was not present in OpenTrace. It collects the following data:

• some information about system state
• the number of contact tracing records collected over the period day
• the timestamp of the latest record collected

An analytics component also exists, which is identical to the one in OpenTrace; it mostly sends error messages to a central server, with no sensitive information.

Based on our analysis, the metrics and analytics components do not pose much of a privacy risk. It is possible for the metrics information to be used to infer some information about a user's location: for example, a relatively larger collection count would indicate more movement, or being in an area with more people.

BlueTrace has a pause feature that allows a user to manually pause contact tracing. We verified that this feature works as expected; when turned on, no contact tracing records are exchanged. Nevertheless, we recommend turning Bluetooth off as well should a user be concerned about their privacy.

BlueTrace's FCMService component allows the central server to remotely activate certain BlueTrace features. This component is also present in OpenTrace. The main features that can be activated remotely are scanning and advertising, which already run periodically. FCMService can also trigger BlueTrace to upload metrics to the server. We also verified that FCMService does not allow the central server to remotely unpause a paused BlueTrace app.

When analyzing the flow of privacy-related information through a system, we can either begin at the sources where the information is obtained, or at the sinks where the data leaves the system (and e.g. enters another app, or a remote server). Static sink analysis on Android is tricky due to the sheer number of ways an app can send data over the network. As such, we focus on tracing the flow of said information through the app from the place where it was created, to verify that the information does not reach anywhere it should not.

BlueTrace makes use of Firebase for cloud operations. In this report, we assume the Firebase transport layer is secure from man-in-the-middle attacks, i.e. any data sent between the app and the remote server via Firebase cannot be eavesdropped or modified, except in Section 5.2.11 where we consider the impact of an attacker that is able to eavesdrop on Firebase traffic.

Identification and contact details are gathered from the user during the registration process. This information includes a contact phone number, and also some other identifying information, such as the user's NRIC or passport number.

As we describe in Section 7.8, once identification information is collected, BlueTrace will send the information to the server via a Firebase function call. At this point, we assume the data is safely stored on the server end; analysis of the server infrastructure is out of the scope of this report.

At the same time, the identification information is also encrypted, and stored on disk as the preferences ENCRYPTED_USER_DATA and ENCRYPTED_PHONE_NUMBER. The encryption logic uses AES-GCM, and the secret key is generated and stored using Android's Keystore system. Barring any flaws in Keystore, this method of storing the data should be secure, and should be encrypted data be somehow leaked, it would not be possible to decrypt it without at least privileged access to the device.

BlueTrace decrypts the identification information preferences only in one place: when displaying user profile information in the UI.

Thus, as far as the BlueTrace client app is concerned, identification and contact details are kept private. While the information is actually present on the device and not just on the remote server, it is stored in an encrypted form.

Note that an unencrypted identifier is stored on the device: the TTID. This value is stored in the preference TTID, and is transmitted whenever Firebase functions are called. However, given only the TTID, it would not be possible for a third party to determine a user's actual identity.

We verified that contact tracing records received by BlueTrace stay on the device and do not get transmitted to any remote location. When BlueTrace receives a contact tracing record, it processes it, and then saves it into an SQLite database record_database. As described in Section 7.4.5 (Data Access Analysis), the only time contact tracing records are accessed from this database and transmitted out of the device is after contact tracing has been initiated. Thus, contact tracing records do not get uploaded to the server or anywhere else in normal use.

Metadata related to the contact tracing data is transmitted however, which we will discuss in Section 5.2.8.

As discussed previously, TempIDs can only be linked to a permanent user ID (and thus personal information) by decrypting them with a secret key (referred to as the TempID secret key), which only the health authority has. However, links between TempIDs and other identifying information might be possible. If, for example, it is known that a specific device sent out a particular TempID at a particular time, then collected contact tracing records could be looked up to see if they contain that TempID. If so, then it would be known that the device must have been nearby the location where the contact tracing record was received. We thus need to verify that TempIDs are never exposed such that they may be linked with some other identifying information.

TempIDs are created by the remote server, and downloaded via a Firebase function call (see Section 7.3 for more details). We assume that the remote server and Firebase transport are secure. The downloaded TempIDs are kept in a local store managed by TempIDManager.

We investigated all places where TempIDs are read from the local store, and determined that they only leave the app when they are sent in BlueTrace Encounter Messages, which do not contain any identifying information. We also looked at log messages; while BlueTrace does actually log messages containing TempIDs (see TracerApp.thisDeviceMsg()), they are only written when BlueTrace is compiled in debug mode, and thus do not appear on the non-debug versions of BlueTrace available on the Play Store.

Finally, we verified that BlueTrace does not retain any of the contact tracing records sent to other devices (which would contain TempIDs). TempIDs are cached momentarily in memory in the GattServer component (readPayloadMap), but this cache is usually flushed once the record exchange is complete. It should thus be unlikely for a third party external to the app to obtain any TempIDs, or link them to the device.

We next considered a scenario where an attacker might have privileged access to data within the BlueTrace app; for example, if BlueTrace was running on a compromised device, or some vulnerability was used to access data private to BlueTrace.

In such a situation, an attacker would be able to access the local TempID store. As detailed in Section 7.3, the store is backed by a file tempIDs, which contains a JSON-serialized list of TempIDs. There are usually enough TempIDs to last over a 24 hour period. TempIDs that have expired are not removed; they will only be removed when the file is overwritten, which happens when a new batch of TempIDs are downloaded (via TempIDManager.getTemporaryIDs()). The server decides when the next fetch time will be (the value can be found in the preference NEXT_FETCH_TIME); we found it to be an interval of around 12 hours on a test device. Also note that the tempIDs file will not be overwritten if new TempIDs could not be downloaded, e.g. due to lack of Internet connectivity.

All TempIDs found in the local store (about 12 hours worth) would thus be linked to the device containing the store. An attacker with access to those TempIDs would then be able to link the device to any other device containing contact tracing records with matching TempIDs.

We now consider a possible attack that a malicious actor with sufficient privileges could conduct.

Consider devices A and B. Let the critical period be the time interval in between the LAST_FETCH_TIME and NEXT_FETCH_TIME values on A. Suppose A and B were in close proximity ("met") during the critical period. An attacker can determine that A and B met if:

1. the attacker was able to read A's tempIDs file at any time during the critical period
2. the attacker has access to B's contact tracing records covering the critical period

Note that device B does not need to be a BlueTrace device, but could be a rogue device implementing the BlueTrace protocol but with direct access to received contact tracing records. In the case of a BlueTrace device, the attacker would have 21 days from LAST_FETCH_TIME to access the records, as collected contact tracing records will only be purged after 21 days. ⁴

There are a few mitigating factors for this attack. First, being able to access the TempID store on A is not easy. It might require fully compromising A, in which case the attacker might also have access to more useful information, such as A's GPS coordinates. Second, accessing B's contact tracing records is not easy as well, if B is a BlueTrace device; it might also require compromising B.

Here are some possible situations in which the attack might be useful:

• The attacker can carry out the attack, but does not have sufficient privileges to obtain any other location information from A nor B.
• The attacker is only able to carry out the attack after A and B met. At this point, the devices might not contain any location history that could be used to determine that A and B met, but the attack would be able to do so.

The second scenario would include situations where the attacker could read the file on A during the critical period, but could only obtain contact tracing records from B some time later.

Preventing this attack is difficult, as BlueTrace needs to maintain a local store of TempIDs to operate when offline. Only a design change to using asymmetric encryption would fully protect against it. To reduce the effectiveness of the attack, BlueTrace could try to reduce the number of TempIDs present in the system where possible. For example, it could remove all expired TempIDs from the tempIDs file (in TempIDManager.retrieveTemporaryID()), which would reduce the length of the critical period, and prevent an attacker from determining that A and B had met in the past.

We also note that it might be possible to locate TempIDs within the device's memory, and there could also be side-channel attacks allowing another process to extract TempIDs, whether from memory, or from the BLE stack.

As mentioned above, BlueTrace is designed to not keep track of a user's physical location. However, due to Android's permission model, it requires the ACCESS_FINE_LOCATION permission in order to make use of BLE; this permission also gives BlueTrace the ability to query a user's physical location, should it wish to. We thus need to verify that it does not do this.

On Android, fine-grained location information can be obtained using LocationManager, by calling LocationManager.getLastKnownLocation(). We searched for all instances in the code where a call is made to getLastKnownLocation(). We found only one such call, in the TwilightManager class (androidx.appcompat.app.TwilightManager). This is a standard library and is not part of BlueTrace. As such, we conclude that BlueTrace does not use getLastKnownLocation() to access the device's location.

We note that it is possible to determine a device's physical location through other means. However we have not found any code within BlueTrace that appears to do this.

BlueTrace contains two components that collect and send metadata to the remote server: Firebase Analytics and Metrics.

Firebase Analytics is used to send additional analytics information to the server. This tends to be during erroneous conditions, and none of the messages appear to contain any personal information nor data related to contact tracing.

As described in Section 2.2.2, BlueTrace periodically collects contact tracing statistics and sends them back to the server. This happens either after new TempIDs are downloaded, or when a specific Firebase Cloud Message is received (see Section 5.2.10 below, and Section 7.7). In either case, simple data about the system state, the number of contact tracing records collected over the previous day, and the timestamp of the latest record collected are sent to the server.

The amount of metadata sent to the server is minimal, and unlikely to have a big impact on privacy. However, the collection counts could be used to infer some information about the user's location; a user with a higher collection count would be more likely to have been in a place with many people, or have been moving through different locations. In general, we do not consider this to be a significant breach of privacy.

In addition to the above source analyses, we also inspected all places in BlueTrace where Firebase is used to send data to the cloud. We verified that sensitive personal data is never uploaded, except for two cases:

1. During the registration phase, the user's mobile number and NRIC/passport number are uploaded.
2. When an upload request is triggered by a health authority, after PIN verification, the user's contact tracing information is uploaded.

Both of these cases are as expected.

BlueTrace contains a feature that allows the server to remotely issue commands to client devices (see 7.7 for more details). The list of possible commands and what they do can be found in Section 7.2.7; they consist of commands that start BlueTrace, start scanning or advertising, and so on. This is not of much concern, as those actions already happen regularly on the device.

We now consider a few specific threat scenarios specific to privacy concerns. We will refer to the BlueTrace users whose privacy we wish to preserve as Alice and Bob. The goal of the attackers is to obtain private information about Alice and Bob: their personal identification information, and whether or not Alice and Bob have been in close proximity with each other.

We go through a few other privacy-centric features of BlueTrace, and whether they are implemented correctly.

We assume an attacker that is able to place one or more devices in close proximity to a target device, and be able to send and receive BlueTrace contact tracing records to and from the target. The goal of the attacker is to either cause a denial of service to the target device, or achieve remote code execution on the target device.

Note that in this report we do not investigate attacks that compromise the integrity of the contact tracing process, for example by creating fake contact tracing records, as we are primarily concerned with the risks to the end user.

Given our threat model, the attack surface consists of BLE layer messages sent from the attacker device to BlueTrace. This happens in the following situations:

• When the target scans for devices and processes the attacker's advertisement
• When the target (as a Central device) connects to the attacker and retrieves an Encounter Message (reading a characteristic)
• When the target (as a Peripheral device) is connected to by the attacker and is sent an Encounter Message (writing a characteristic)

Our analysis only focuses on potential vulnerabilities in BlueTrace; as such, we do not consider vulnerabilities in lower layer code such as Android's implementation of BLE, or the Bluetooth firmware or hardware.

We now go through each potential attack vector in detail to verify whether or not it can be used to compromise the target.

StreetPassScanner is the BlueTrace component that manages scanning of devices. It registers a BleScanCallback object to handle advertisements from remote devices: BleScanCallback.onScanResult() will process each scan result.

Most of the advertisement data sent by the remote device are parsed in lower layer code. onScanResult() only reads two untrusted values: an integer representing the transmission power, and an array of bytes known as the manufacturer-specific data. The values are stored in an object and then passed on for further processing. Based on our analysis, none of these values are used in situations that could lead to compromise; in fact the manufacturer-specific data is never accessed.

Please refer to Section 7.4.1 for more details.

StreetPassWorker manages the exchange of contact tracing records when a device acts as a Central device, and CentralGattCallback is the callback class that handles the data sent by remote devices. When a remote BlueTrace device is detected via scanning, StreetPassWorker will connect to it, and read the value of a specific characteristic. The value returned by this operation is an untrusted byte array.

CentralGattCallback will eventually decode the value byte array into a UTF-8 string, and then deserialize it as a JSON string (using the Gson library), into a V2ReadRequestPayload object. Please see Sections 7.4.2 (CentralGattCallback) and 7.5 for more details.

The values from the deserialized V2ReadRequestPayload object are used to initialize a ConnectionRecord object, which is then attached to an ACTION_RECEIVED_STREETPASS intent and locally broadcasted.

StreetPassReceiver receives the intent, extracts the ConnectionRecord, and uses the values within to create a new StreetPassRecord, which is finally saved to the database.

From this point, the values within the database are generally not accessed, except when uploaded to the server for contact tracing. See Section 7.4.5 (Data Access Analysis) for more details.

StreetPassServer manages the exchange of contact tracing records when a device acts as a Peripheral device, and the gattServerCallback object created as part of GattServer handles data sent by remote devices. When a remote BlueTrace device sends a request to write to a characteristic, the function onCharacteristicWriteRequest() will be called, with untrusted values.

Once the value is received fully as an array of bytes, it will be passed to the saveDataReceived() function, which will ultimately decode the byte array into a UTF-8 string, and then deserialize it as a JSON string (using the Gson library), into a V2WriteRequestPayload object. Note that this is symmetric to the processing happening in the Central Read data flow. Please see Sections 7.4.4 (GattServer Callbacks) and 7.5 for more details.

As in the Central Read case, the values from the deserialized V2WriteRequestPayload object are used to initialize a ConnectionRecord object, and then broadcasted with an ACTION_RECEIVED_STREETPASS intent.

StreetPassReceiver receives the intent, and proceeds identically to the Central case, eventually writing the data to the database, which from that point on will generally not be accessed.

Deserialization is often a source of vulnerabilities in Java code. We took a close look at the use of deserialization in BlueTrace to verify there are no bugs in how it is being used.

The Gson library is used to deserialize an untrusted byte array into an object in both the Central Read and Peripheral Write cases. As the deserialization call to Gson.fromJson() explicitly provides the type of the target object, it is not possible to cause the JSON string to be deserialized into an arbitrary Java object. The target objects (V2ReadRequestPayload, V2WriteRequestPayload) are simple and consist of a few string and integer fields. As such we did not find anything of concern in the deserialization code.

Nevertheless, we feel it might not be ideal to feed untrusted data from arbitrary Bluetooth devices into a complex parser, as is required with JSON deserialization. Any exploitable vulnerabilities in Gson would then become exploitable in BlueTrace. Given the simplicity of the data being sent between devices, it might be better to use a simpler format, e.g. a sequence of fixed-width values.

As untrusted data ultimately gets written into the database, we also investigated if there were any issues with the SQL commands used to insert data. Fortunately, all SQL queries are properly parameterized, and thus it should not be possible to conduct an SQL injection attack or similar.

We discovered a few minor bugs in BlueTrace, that do not have any impact on security. We summarize them here:

1. In StreetPassWorker, when a new Work object is used to replace an older one, an associated timeout handler is not replaced.
2. In StreetPassServer, when handling long writes, data is not written to the provided offset value but always appended to previously collected data.
3. In StreetPassServer, when handling long writes, a request to cancel a write is ignored.

As can be seen in the above analysis, we did not find any vulnerabilities in how untrusted data is processed within BlueTrace. This does not rule out the existence of any vulnerabilities, in particular in components we did not look at, such as lower-layer components like Gson, SQLite or the BLE stack. However, we conclude that users can have a level of assurance that BlueTrace is written securely.

BlueTrace's backend implementation can be divided into six major components:

• BluetoothMonitoringService (services.BluetoothMonitoringService), the top-level service that is launched during startup, and coordinates all other services.
• TempIDManager (idmanager.TempIDManager), downloads TempIDs from the server, stores them on disk, and provides the currently valid TempID to other components.
• StreetPass (streetpass.*), services that manage the dissemination and storage of contact tracing records: scanning, exchanging of records, and storing on disk.
• BlueTraceProtocol (protocol.*), implements the over-the-air message format used by BlueTrace, and is used by StreetPass.

In addition, there are also a few minor components worth investigating:

• Metrics (metrics.*), a service that collects and uploads app metrics
• FCMService (services.FCMService) is a service that receives remote messages sent via Firebase Cloud Messaging (FCM).
• User Registration (onboarding.newOnboard.register.*) contains the logic that registers a new user with the BlueTrace server components, including personal information.
• Debug Actions (PeekActivity and PlotActivity), special UI views for debugging purposes that are not normally accessible.

Android apps are event-driven: apps handle intents sent from within the app or from external services. BlueTrace processes 4 different kinds of events:

1. Global intents
2. Local intents sent via LocalBroadcastManager
3. CommandHandler messages, internal to BluetoothMonitoringService
4. Firebase Cloud Messaging remote messages

BlueTrace processes contact tracing records. These records are a log of encounters between two BlueTrace devices, where a Central device which connects to a Peripheral device. Both devices generate a record containing the TempID of the other device, as well as other required information.

As described in the white paper, Encounter Messages are transmitted between devices using BLE. These Encounter Messages are the lowest level form of contact tracing records, and are UTF-8 encoded JSON strings. The strings can be deserialized into JSON objects containing these values:

• protocol version
• organization code
• TempID of sending device
• device model of sending device
• received signal strength indicator (RSSI), when sent by a Central device.

After an Encounter Message is received, BlueTrace converts it into a ConnectionRecord, which is the same for both Central and Peripheral devices. The ConnectionRecord contains:

• protocol version
• organization code
• TempID of other device
• Bluetooth address and device model of Peripheral device
• Bluetooth address and device model of Central device
• RSSI
• transmission power: measured power as reported by a Peripheral device during BLE advertising, this is null if this device was the Peripheral .

The information in the ConnectionRecord is eventually converted into a StreetPassRecord that can be written into the database. StreetPassRecords contain the following fields:

• protocol version
• organization code
• TempID of other device
• device model of Peripheral device
• device model of Central device
• RSSI
• transmission power (might be null)
• timestamp, set to the time at which the StreetPassRecord was created.

As we reverse engineered the compiled version of BlueTrace, configuration variables set when the app was built appear as literal values. As such, in this report, we will report those values as they appear, even if there is evidence those values originated from a build configuration. For example, BuildConfig.APPLICATION_ID will be reported as "sg.gov.tech.bluetrace".

BlueTrace makes reference to a separate app called SwiftMED (com.swiftoffice.swiftmed). This appears to be a version of BlueTrace customized for use by the Singapore Armed Forces. BMS detects the presence of SwiftMED and disables BlueTrace while it is installed.

When a new BMS instance is created, onCreate() is called. This function calls the setup() function to do the following:

• Initialize CommandHandler, for handling commands internally.
• Initialize StreetPassWorker, which will register a few intent receivers.
• Register receivers for local intents via LocalBroadcastManager:
  • StreetPassReceiver for ACTION_RECEIVED_STREETPASS
  • StatusReceiver for ACTION_RECEIVED_STATUS
• Register receivers for global intents:
  • BluetoothStatusReceiver for android.bluetooth.adapter.action.STATE_CHANGED
  • SwiftmedInstalledReceiver for android.intent.action.PACKAGE_ADDED
  • SwiftmedRemovedReceiver for android.intent.action.PACKAGE_FULLY_REMOVED
• Register listener for preference changes; this just updates notifications when there is a change in language, via the PREFERRED_LANGUAGE preference.
• Initialize databases:
  • Creates a new StreetPassRecordStorage object
  • Creates a new StatusRecordStorage object
• Creates a new Volley request queue; this does not seem to actually be used.
• Set up the notification manager and channel
• Get an instance of the FirebaseFunctions object for region "asia-east2"
• Retrieve and store the current valid TempID into broadcastMessage, using TempIDManager.retrieveTemporaryID().

BMS's main event handler is a function called runService(), which handles Command objects. The top-level event handlers for intents and messages eventually create Commands which are passed in to runService().

Command is an enumeration class, representing possible actions that can be performed by BMS. In general, Commands derive from intents; the enum index representing a Command is extracted from an intent's extra data using the key COMMAND_KEY (sg.gov.tech.bluetrace_CMD). Commands may also have an associated argument, which can be extracted from the associated intent's extra data using the key COMMAND_ARGS (sg.gov.tech.bluetrace_ARG).

These are the known Command indices in BlueTrace version 2.0.15:

Intents sent to BMS are handled via onStartCommand(). This function extracts a BMS Command from the intent's extra data as described in 7.2.4. If no intent is supplied (possible when onStartCommand() is called to restart the service due to the START_STICKY flag, see documentation of Service.onStartCommand), or if the intent does not contain a Command index, then the Command is set to ACTION_INVALID.

onStartCommand() then checks to see if BlueTrace is supposed to be paused, by checking the value of the preference PAUSE_TS; if the current time is before the time represented by PAUSE_TS, then BlueTrace should be paused.

If BlueTrace is to be paused, onStartCommand() will return immediately, except if the Command associated with the intent is ACTION_USER_PAUSE. For more details on pausing, please see Section 7.2.10.

Otherwise, onStartCommand() will then verify that the ACCESS_FINE_LOCATION permission is available, and Bluetooth is enabled. Again, it skips this verification step if the Command is ACTION_USER_PAUSE.

Finally, if the intent is not null, runService() will be called with the Command and intent, in order to process the Command. Otherwise, an ACTION_START command will be queued for processing using CommandHandler.

CommandHandler (services.CommandHandler) is a subclass of Handler, and implements a separate message queue for Commands, internal to BMS. BMS uses it to schedule Commands for processing, without needing to create associated intents, and also to query the current status of scheduled Commands.

Messages are sent using Handler.sendMessage() or Handler.sendMessageDelayed(), with an associated Command's index as the what argument to the message. CommandHandler eventually handles the messages using handleMessage, and processes the associated Command by calling runService() with the Command and a null intent.

Actual processing of commands takes place in the runService() function.

Before processing the Command, runService() performs the same checks as in onStartCommand(): it checks if BlueTrace is not supposed to be paused, if location permissions are available, and if Bluetooth is enabled. If not, unless the command is ACTION_USER_PAUSE, runService() will return immediately.

Otherwise, the Command will be processed as per below.

BMS is shut down when it receives the ACTION_STOP Command, or when other circumstances require it to be terminated. This will eventually call stopService(), which we describe here.

stopService() first calls teardown(), which will in turn call BLEAdvertiser.stopAdvertising() (which calls BLA.stopAdvertising()), StreetPassServer.tearDown(), and StreetPassScanner.stopScan(). All pending messages in CommandHandler are removed, and any pending intents for scans, advertisements and TempID updates are cancelled.

All the receivers setup during initialization are unregistered.

Finally, StreetPassWorker is cleaned up by calling StreetPassWorker.terminateConnections() and StreetPassWorker.unregisterReceivers().

BMS is started on boot via the BOOT_COMPLETED and QUICKBOOT_POWERON intents. As specified in AndroidManifest.xml, the class boot.StartOnBootReceiver will receive these intents. This utility class calls Utils.scheduleStartMonitoringService(), which will send a service intent to BMS with the ACTION_START Command after 500ms.

BMS implements BlueTrace's pause feature, via the Command ACTION_USER_PAUSE and the preference PAUSE_UNTIL. When a pause is requested via the UI, an ACTION_USER_PAUSE Command is sent to BMS via an intent, with a timestamp indicating the time at which BMS should be paused till. As described in Section 7.2.7.9, this will set the PAUSE_UNTIL preference to the timestamp. Subsequently, checks in onStartCommand() and runService() will avoid performing any actions while the time PAUSE_UNTIL is in the future.

Note however that there are no checks on PAUSE_UNTIL in other components such as StreetPass, BLE Services and FCMService; these components will still continue running. Due to the architecture of BlueTrace, this means that scanning and advertising will still continue until the scanning and advertising duration is reached; at that point, new scans/advertisements will be scheduled via CommandHandler, but as these are processed by runService(), they will be skipped.

BlueTrace will automatically unpause itself once the PAUSE_UNTIL timestamp is in the past. The UnpauseAlarmReceiver registered when pausing takes place serves to trigger BMS to begin operations immediately at that point, instead of waiting till the next scheduled scan or advertisement.

BlueTrace can be manually unpaused by providing a negative timestamp as an argument to the ACTION_USER_PAUSE Command. This happens when the user clicks the "unpause" button in the UI.

BMS detects when SwiftMED is installed via SwiftmedInstalledReceiver (receivers.SwiftmedInstalledReceiver), which receives android.intent.action.PACKAGE_ADDED intents. When SwiftMED is installed, SwiftmedInstalledReceiver will send an intent to BMS with an ACTION_PAUSE_FOR_SWIFTMED Command. Similarly, SwiftmedRemovedReceiver (receivers.SwiftmedRemovedReceiver) detects when SwiftMED is removed, and will send an intent to BMS with an ACTION_START Command.

The presence of SwiftMED is checked inside runService(), before advertising, scanning, and performing self-checks, and none of those actions are taken should SwiftMED be installed.

TempIDs are represented using the TemporaryID class (idmanager.TemporaryID). The class has the following fields:

• start time, time at which this TempID is valid
• expiry time, time at which this TempID expires
• contents, the actual TempID value in the form of a Base64 string.

The function getTemporaryIDs() is used to download new TempIDs from the remote server. It is asynchronous and returns a Task.

getTemporaryIDs() makes an asynchronous Firebase function call to the function getTempIDsV2, with the following arguments:

• ttId, set to the user's TTID
• appVersion, set to the version of the app as reported by PackageManager

If the call completes successfully, the callback registered by getTemporaryIDs() extracts the values tempIDs, status, and refreshTime from the returned result. It then verifies that tempIDs is an array of TemporaryID objects, and that status is a string of value "success". tempIDs is then converted into a JSON string using the Gson library, and then saved into the file tempIDs with UTF-8 encoding.

The preference NEXT_FETCH_TIME is set to the value of refreshTime after converting it to milliseconds. The preference LAST_FETCH_TIME is set to the current time.

Upon completion of the call, whether or not successful, a callback registered by getTemporaryIDs() creates a new Metrics object, and calls Metrics.upload(). See Section 2.2.2 for more information about this component.

Other components can ask TempIDManager for a currently valid TempID by calling the function retrieveTemporaryID().

retrieveTemporaryID() reads the contents of the file tempIDs, and then converts it into an array of TemporaryID objects by deserializing it using Gson. The array is then sorted by start time, and then converted into a Queue by creating a LinkedList and inserting the elements of the array into the list. Finally, the first TemporaryID in the queue that is valid (the current time falls between the start time and the expiry time) is returned.

StreetPassScanner (StreetPassScanner) is used to detect nearby BlueTrace devices, and add them to a worklist for processing. It uses a BLEScanner, part of the BLE Services component, to perform the actual scanning.

StreetPassWorker manages the exchange of contact tracing records when a device acts as a Central device (StreetPassServer manages the logic when devices acts as Peripheral devices). Peripheral devices discovered by StreetPassScanner are added to a work queue in StreetPassWorker, which will go through each device and exchange records as required by the protocol.

StreetPassReceiver (BMS.StreetPassReceiver) is a small class that is registered to receive ACTION_RECEIVED_STREETPASS intents. For some reason it is implemented as an inner class of BluetoothMonitoringService.

When an ACTION_RECEIVED_STREETPASS intent is received, StreetPassReceiver will extract the associated ConnectionRecord, and then use the values within to create a new StreetPassRecord. A coroutine is then launched to save the StreetPassRecord, by calling StreetPassRecordStorage.saveRecord().

StreetPassServer manages the exchange of contact tracing records when a device acts as a Peripheral device (see StreetPassWorker for corresponding Central device code). A new StreetPassServer object is created by BMS when processing the ACTION_START Command.

StreetPassRecordDatabase (persistence.*) is the database providing persistency to StreetPass. Besides the main StreetPassRecordDatabase class, there are also a few other classes to represent database-backed objects. StreetPassRecordDatabase is implemented using Room, which generates the implementation of the database code during compile-time. The implementation classes have a suffix of "_Impl".

StreetPassRecordDatabase is backed by an SQLite3 database file named record_database. The database consists of two tables:

• record_table, holding contact tracing records
• status_table, holding status messages

The status messages stored in status_table are added when ACTION_RECEIVED_STATUS intents are received by StatusReceiver in BMS. In practice the only status messages that are sent are by StreetPassScanner when scanning starts and stops, and are not of much interest, and so we do not focus on it in this report.

StreetPassRecord objects hold the actual contact tracing information, and are backed by rows in record_table via the StreetPassRecordDao data access object. StreetPassRecord objects were already described in Section 7.1.3; we note down the table columns corresponding to each property of the object here.

StreetPassRecordDao provides the following functions:

• insert(); to insert new StreetPassRecord objects
• purgeOldRecords(); to delete old StreetPassRecord objects given a timestamp
• getCurrentRecords(), getLastRecord(), getMostRecentRecord(), getRecords(), getRecordsViaQuery(); to query for StreetPassRecord objects stored in the database
• countRecordsInRange(), liveCountRecordsInRange(); to count the number of StreetPassRecord objects within a certain time period
• nukeDb(); to delete all StreetPassRecord objects from the database, referred to as nuking the database

The parent class BlueTraceProtocol contains the following properties:

• version of the protocol
• API object for acting as a Central device
• API object for acting as a Peripheral device

The two API objects must be implementations of the Kotlin interfaces CentralInterface and PeripheralInterface respectively.

CentralInterface has two methods that must be implemented:

• prepareWriteRequestData(), generates an Encounter Message containing this device's TempID, to be sent to a Peripheral device
• processReadRequestDataReceived(), processes the provided Encounter Message from a Peripheral device, to generate a ConnectionRecord object

PeripheralInterface has two methods that must be implemented:

• prepareReadRequestData(), generates an Encounter Message containing this device's TempID, to be sent to a Central device
• processWriteRequestDataReceived(), processes the provided Encounter Message from a Central device, to generate a ConnectionRecord object

These 4 functions are used in StreetPass to convert between Encounter Messages sent/received via GATT, and ConnectionRecord objects.

BlueTrace version 2.0.15 contains only one protocol implementation, for version 2 of the BlueTrace protocol (the version described in the white paper). This is implemented by classes in the protocol.v2 namespace: BlueTraceV2 is the protocol class, with API objects of classes V2Central and V2Peripheral.

The majority of the work is actually done in two utility classes, V2ReadRequestPayload and V2WriteRequestPayload These classes represent the version 2 Encounter Messages.

BlueTraceProtocol contains a protocol selection class named BlueTrace that is used to retrieve the correct protocol implementation given a characteristic UUID. For the sake of clarity, we will refer to this BlueTrace class as the "protocol selector".

As per the BlueTrace protocol design, each version of the protocol will use a unique UUID value for the characteristic to be read and written via GATT (see 7.4 for more details). The protocol selector maintains a mapping from characteristic UUID values to protocol versions, in characteristicToProtocolVersionMap; and another mapping from versions to implementations, in implementations.

characteristicToProtocolVersionMap is statically set to contain a single entry, mapping the UUID 117BDD58-57CE-4E7A-8E87-7CCCDDA2A804 to version 2.

implementations= is statically set to contain a single entry, mapping version 2 to a BlueTraceV2 object.

The function getImplementation() is used by StreetPass to retrieve an appropriate protocol implementation given a UUID. It does this by looking up the two maps. Due to the values of the map, this means that it will only handle the UUID 117BDD58-57CE-4E7A-8E87-7CCCDDA2A804, and return the BlueTraceV2 object.

The function supprtsCharUUID() is used by StreetPass to check if there is an implementation to support a given UUID. It does this by looking up characteristicToProtocolVersionMap, and thus will only return true when the UUID is 117BDD58-57CE-4E7A-8E87-7CCCDDA2A804.

As BlueTrace stores SafeEntry records on disk, an attacker with privileged access to BlueTrace (like Dan from Section 5.2.11) would be able to determine all the locations visited by the user. SafeEntry records are purged every 25 days ¹¹, so there would be up to 25 days worth of check-ins exposed.

However, most people using SafeEntry without BlueTrace would load the SafeEntry URL into their web browser. This URL would then be logged in the browser's history. The URL itself contains enough information to infer the location visited by the user. Thus, unless the user takes care to clear their browser history of SafeEntry URLs, or uses some alternate setup to access the SafeEntry URLs without having them being logged, the relative loss of privacy from using BlueTrace's SafeEntry feature is minimal.

Since SafeEntry by design involves logging an individual's access to a location to a central server, there is no privacy impact from BlueTrace contacting the Firebase server to process check-ins and check-outs. The Firebase calls do end up linking the user's TTID with the SafeEntry records, however, but such a link already exists since both BlueTrace and SafeEntry systems would have common identifying information about an individual, such as their NRIC.