[dmurray]

To continue, when they actually address the privacy and security implications of the design, they call out the possibility of a replay attack "when an outsider intercepts a communication and fraudulently delays or resends it...there is no known significant mitigation for replay attacks and yet they are not identified in the DPIA."

Firstly, surely there's a known mitigation here - replay attacks involving a delay can be mitigated by including a cryptographically signed timestamp in your beacon messages. Secondly, the damage from an attacker sending false negatives and false positives seems small compared to the privacy implications of deanonymization attacks (e.g. attacker listens for the beacons in several buses, offices or shopping centres, later identifies which ones were reported covid-positive, groups those into clusters each likely associated with an individual, and cross-references the location data with identifying data from another source). Why call out one but not the other?

[colmmacc]

There isn't enough space in bluetooth IDs to include a cryptographically signed timestamp, there isn't even really enough space to include a cryptographic signature for everything ... in the the Apple/Google design the Bluetooth power level is left unsigned due to space constraints. It really is a very very small amount of space.

An alternative design involved bluetooth IDs broadcasting small 63-bit ECDH shares and devices performing pair-wise key agreement. This would raise the difficulty level of replay attacks; they'd need to be bi-directional and roughly time synchronized (within a ~15 minute window) but it had other trade-offs including reducing the efficacy of the app due to bi-directional message receipt being required, and ballooning the amount of data that needs to be distributed to detect infection risk. So it wasn't taken.