# Contact Tracing: Ensuring Privacy and Security
## 5 Framework Evaluation
The following mobile handsets were used to perform the experiment:  
1. iPhone 5S incompatible with GAEN and contact tracing applications. This phone serves as a comparison between devices running GAEN, as a device that cannot run GAEN;
2. A Nokia TA-1047 running Android 10, a cheap but GAEN-compatible smartphone, in developer mode;
3. A Samsung S9 Android 9 running GAEN, a typical consumer smartphone;
4. An iPhone 11 Pro running GAEN, a typical consumer smartphone;
5. A Ruggear RG-850 Android 10 phone running GAEN, a typical smartphone used with healthcare professionals. _Are the BLE beacons pseudonymous and do they rotate frequently?_ The GAEN-documentation sets the time interval for RPIs at roughly 10 min. By hooking up an Android phone in developer mode with the HCI Snoop Log enabled to a computer with Android Studio running, it is possible to filter for RPI changes. Figure 2 shows that every 10 min, the RPI changes to a new value. Deviations were observed; sometimes the RPI changes in 7 min, sometimes in 12 min. A pattern between these times could not be determined; it is reasonable to suspect that a pseudo-random generator determines a time shift. The log also shows the new _RollingProximityID_ value when the RPI rotates. These values appear random; no correlation between the values was observed. The question is whether these RPIs match the ones transmitted by the phone. A single GAEN-equipped phone with the Dutch CoronaMelder GAEN application was placed next to the interception station to investigate this. The purpose of this test is to compare the transmitted RPI with the received RPI. The Ubertooth intercepted the BLE broadcasts and saved them to a _pcapng_ file for later analysis. Using Wireshark for analysis, the following filter ensured that only GAEN BLE advertisements show up, which are close by (\(\geq\)45 dbm). Figure 3 demonstrates the output after capturing the data. Almost all packets were transmitted by _BD_ADDR 36f2:d3:c8:cd:32_. The four packets that were transmitted from other addresses, turned out to have a faulty cyclic redundancy check (CRC), a characteristic of an incomplete interception. All other packets showed the same RPI transmitted, with exception of the AEM as shown in Figure 4. The received RPI received _f18 cf57 sf05 df6e6779a562 cc413 bd_ matches the one transmitted by the telephone, as seen in the HCI Snoop Log. The experiment proved that the reported RPI in the HCI Snoop Log indeed matches with the RPI transmitted by the phone, and subsequently  
Figure 3: Wireshark Conversation. Figure 2: Time interval of RPI change. received by the Ubertooth. This experiment confirms the RPIs rotate frequently and are indeed pseudonymous. _Are Bluetooth hardware addresses in the advertisement data random and rotate frequently?_ The Google and Apple specification requires the MAC address to rotate frequently (Google, 2020), to avoid device tracking. This experiment checks to see if indeed the MAC changes. The results were analysed with Wireshark below. As Figure 5 shows, address _77:Scz9:ca:9c:55_ first started transmitting 0.144961s after interception started and stopped 193.8150 s later (193,959961 s after experiment start). Interestingly, 194.498694 s after experiment start, _55:7d:89:91:fc:d_ started transmitting. Could this be a MAC address change for the same device? To answer this, one could see in Figure 6 the RPI that the first address used. Figure 4: The Received RPI of a random package. Figure 5: The Wireshark addresses captured. Figure 6: RPI transmitted by 77:8C:E9:CA:9C:55. Wireshark can filter on this RPI, which shows that the new address transmitted the same RPI as seen in Figure 7.  
This experiment proves that even though GAEN randomises the MAC addresses frequently, it is possible to track the same device by using the RPI. Since RPIs rotate roughly every 10 min, and an RPI change forces a MAC address change as well, this means that an attacker has a maximum of 10 min to track a device.