“Second, I think it's important to consider the situation with
nonconformant tracking tags. There are several attacks here,
including:
Modifying an existing tage to make it nonconformant in
such a way that the countermeasures in this draft don't
work.
Making a new tag which is nonconformant, etc.
I think this framing is useful when considering two different sets
of countermeasures in this design:
The "sound maker" feature of having the device make noise when its
separated and moving (S 3.12.2.1) or when it is located
(S 3.12.3).
The BT-based "this device is following me" feature described in
S 3.4.3.
The key point I would like to make here is that countermeasure
(1) is potentially evaded without compromising the above invariants.
For instance, maybe I can take an AirTag and disable the speaker
in some way but it will still work for location tracking. Or
maybe I can wrap it in some sound insulating material. Clearly I
can fix the flashing lights. None of this seems like it impacts
the basic tracking functionality, including the surveillance
use case.
By contrast, I don't think it's necessarily feasible to easily modify
the tracker to use some different protocol that would still be
compatible with tracking but harder to detect (e.g., faster ID rotation)
because that would depend on changing the firmware. So that is
a harder attack to mount, especially if the firmware is signed.
Obviously you can burn out the radio or wrap it in a faraday cage,
but that breaks both tracking and unwanted tracking detection.
However, it might be able to build a fake tag which violated
these invariants.
My point here is that detection countermeasures need to depend
on properties of the system that are hard to subvert while
having it continue to be functional. “
From Eric Rescorla [ekr@rtfm.com](mailto:ekr@rtfm.com), Thu, 04 May 2023 00:05 UTC via unwanted-trackers-request@ietf.org
“Second, I think it's important to consider the situation with nonconformant tracking tags. There are several attacks here, including:
I think this framing is useful when considering two different sets of countermeasures in this design:
The "sound maker" feature of having the device make noise when its separated and moving (S 3.12.2.1) or when it is located (S 3.12.3).
The BT-based "this device is following me" feature described in S 3.4.3.
The key point I would like to make here is that countermeasure (1) is potentially evaded without compromising the above invariants. For instance, maybe I can take an AirTag and disable the speaker in some way but it will still work for location tracking. Or maybe I can wrap it in some sound insulating material. Clearly I can fix the flashing lights. None of this seems like it impacts the basic tracking functionality, including the surveillance use case.
By contrast, I don't think it's necessarily feasible to easily modify the tracker to use some different protocol that would still be compatible with tracking but harder to detect (e.g., faster ID rotation) because that would depend on changing the firmware. So that is a harder attack to mount, especially if the firmware is signed. Obviously you can burn out the radio or wrap it in a faraday cage, but that breaks both tracking and unwanted tracking detection. However, it might be able to build a fake tag which violated these invariants.
My point here is that detection countermeasures need to depend on properties of the system that are hard to subvert while having it continue to be functional. “