Device name accessible

[jimmo]

As Herald is a connectable peripheral, the default GAP service will be available to any client. This includes the "Device Name" characteristic, which is a user-configurable value (e.g. "Jim's Pixel 2").

This makes the device trackable, as it exposes a value that is likely to be relatively unique.

It's very difficult to suggest an effective mitigation for this. See this blog post for more information https://github.com/vteague/contactTracing/blob/master/blog/2020-06-22OutstandingPrivacyIssues.md#unique-phone-names-eg-names-iphone

As this is a well known issue, I'm not raising it as a security vulnerability (although it really is). However, it's very important that anyone implementing Herald should definitely be made aware of this, so it would be good to add to the documentation.

COVIDSafe has a workaround for this (only on Android) but I do not think it is particularly effective as the message is confusing, and requiring the user to rename their phone has an unfortunate usability cost for other Bluetooth scenarios.

I am less familiar with the iPhone, but although iOS hides this value (always reporting "iPhone"), I think while investigating CVE-2020-12856 I saw that the hiding is disabled while the pairing prompt is being shown to the user. (So an attacker can initiate pairing and quickly read the value). Of course on iPhone, it's worth being aware of Bleee https://hexway.io/research/apple-bleee/

[adamfowleruk]

iPhone deviceName is always "iPhone" these days. An Apple device advert also exposes the exact model (iPhone9,3) via another characteristic that doesn't require authentication either, without notifying the iPhone's owner to someone requesting it. Apple has a special way of sharing the name (E.g. "Adam's iPhone") that isn't in these characteristics. Also worth reading the two research papers from INRIA in France around Apple and Google Bluetooth device Bluetooth security and tracking. (Especially popets-2020-003). Older iPhones, like the iPhone 6, don't advertise anything unless an app uses Bluetooth. In modern iPhones, if Bluetooth is enabled, they always advertise these services and characteristics.

It's worth bearing in mind that these OS' API allow an app to specify what to advertise, but not to restrict what the OS advertises. So the TxPower and Flags elements in the advert are always there on modern phones, for example, as well as a set of OS specific services and characteristics that an app cannot disable itself.

Also worth noting that the Bluetooth spec deals with an app acting as a peripheral and a central as a single Bluetooth device, with a single Bluetooth MAC address, no matter how the OS' API expose this to an app user. (We use this in our 'connect back' mechanism, for example).

In summary, it's something we do take in to account, but which the OS vendors themselves will have to provide a mitigation for or an API call we can use to restrict such capability.

I'll leave this on the backlog rather than change to a 'wontfix', as we'd love to have an OS API to call to prevent this, but it's just not available today.