Implement key cycling like FakeTag

[olivluca]

Hello, the FakeTag project cycles through 100 keys, switching key every hour.
I prepared a pull request to implement the same functionality for an esp32-c3 I had lying around, but the prospect of having a self powered, cheap, tag is appealing.
Do you think it would be possible to implement the same functionality with the st17h66?
I have the tags my cart, I'm undecided if I can press "Checkout" 😉 (and I can even recycle the esp32 to program them 😁)

[biemster]

I'm working on that and should be a relatively minor change, for now I don't see why that wouldn't work (but don't pin me down on it).

[olivluca]

Another nifty feature of FakeTag is that it uses the status byte to encode the detections (not needed here) and the battery status (potentially useful).
To retrieve the status byte with your FindMy python implementation it's just a matter of using the last byte of the decoded tag data, i.e.:

def decode_tag(data):
    latitude = struct.unpack(">i", data[0:4])[0] / 10000000.0
    longitude = struct.unpack(">i", data[4:8])[0] / 10000000.0
    confidence = bytes_to_int(data[8:9])
    status = bytes_to_int(data[9:10]) #added line
    return {'lat': latitude, 'lon': longitude, 'conf': confidence, 'status':status}

I just tested to be sure and I got back what I wrote in the status byte from apple's servers.

[biemster]

Battery status would indeed be very handy, I did not see any code related to that in the SDK yet though (although I did not really search for it either).
That status byte is indeed a funny thing, I was wondering already how @dakhnod was doing that.

[olivluca]

I was going to ask him but I thought it would be more fun to just try 😉

[dakhnod]

You can encode any data in the status byte, apple is using the first two bits for battery and the other bits for god knows what

[biemster]

I've gained a lot of experience on https://github.com/biemster/st17h66_blinky and https://github.com/biemster/st17h66_RF, the key cycling should be relatively easy now (and is high on my list)

[johnbaker26222]

Has there been any progress with this? Would also love this option so the potential thief doesn't know I'm tracking him

[biemster]

It's still in design phase. I've come up with 2 easy solutions, but I'm still thinking of a 3rd proper one:

1. Hardcode a few (100?) keys in an array and cycle through them every now and then (10min?)
2. Increment the public key by 1 (or n?) after every broadcast

Solution 1 is dependent on the amount of RAM/ROM, and might still enable others to track you when they learn enough keys, solution 2 is not dependent on the amount of space, and only allows others to track you if they know this (very easy!) scheme.

Preferred solution is 3) where the new key is derived in a cryptographic way, although I have to hone my crypto skills to figure out how to do that.

People in this thread can vote if they like, I'll go with the preferred solution then when I get the time. In the meantime, it seems that the anti tracking measures are having difficulty finding the tags in the current implementation already, as reported by @vadimkozhin and others: #7 (comment)

[johnbaker26222]

I vote for one of the east solutions first, with a flag on the flasher script to turn it off and on

[dakhnod]

@biemster I don't quite understand what you mean by "Increment the public key by 1 (or n?) after every broadcast".
After all, a public key is absolutely useless without the private key, and I would boldly state that even changing one bit of a public key makes it pretty much impossible to decode the data encoded with it...

[biemster]

That was not very clear indeed @dakhnod , I meant to add the curve generator to the public key, so the new point corresponds to priv +1. (or +n, depending on how many times the generator point is added). There are some very easy ways to do this, we only need the x coordinate anyway. Then when we request the reports, we request a whole range that belongs to the initial private key, and a lot of subsequent points.

EDIT: it's point doubling which is easy on the x coordinate actually, so my proposal is to add the public key point to itself, which then corresponds to 2*priv, 4*priv, 8*priv, etc.

[dakhnod]

@dakhnod ahh, got it. I think that's how AirTags do it.
I chose against that method to avoid synchronization issues if the Tag restarts for whatever reason...

[biemster]

yeah it might require a couple extra API calls to figure out at which iteration the Tag is.

[Itheras]

I am failing to understand why this is requested so much. changing keys doesn't prevent iPhone detection . if someone tries to use it for stalking for example . checking if my neighbor is there by scanning for an id, changing the keys does noting since I just have to scan for a ble message that identifies as apple that comes and goes with a particular strength. it someone goes to the extent of having a ble scanner to see broadcasts It would immediately know something is up if a bag or bicycle or anything has a ble signal emanating from it no mater what id it sees. damn if I really want to track someone by using ble adv ids I might of well just keep an eye for their phone wifi probe requests for a particular wifi network. to be short changing the keys for a thief or person willing to use any type of wireless signal scanner doesn't nothing. they know its there and just by signal strength can tell where it is and to whom it belongs based on that info. I feel it just complicates things. I can go to a mailbox an see what addresses are using darknod device id not needed. I may just use vibration to prevent broadcast until there is no movement as a way not to trigger iPhone detection. if changing key are implemented in my view is just a way to be closer to apple implementation which if I understand correctly still defaults to single key broadcast after power failure. doing this poorly will be just spamming apples api. Genuinelly is there something I am not taking into account ?

[olivluca]

No anti theft device is effective 100%: a gps tracker can be jammed (illegally, but I doubt a thief worries about that), wifi and bluetooth can be jammed, cellular data can be jammed, etc.
If a thief is determined to get your car, bike, other belongings, there's nothing you can do, really.
However, as far as I understand, rotating the key will at least avoid to alert a less sophisticated thief that carries an iphone with him.

[biemster]

yes exactly that @olivluca, most thieves that are after anything smaller than a car will not be very sophisticated.

And for me another concern is bulk bluetooth broadcast capture in places like malls etc. They should have a lot harder time tracking you too (at least using the tag) when the key is cycled.

But yeah if someone is really after you or your stuff specifically, this will not help much. But then that someone probably has better means to get what they want then just following your bluetooth tag.

[Itheras]

Correct it just in my testing broadcasting a single key every 5 sec or rotating keys does nothing in terms of detection a iPhone will still trigger whit openhaystack based tags the sensitivity is decreased regardless of a static or changing key . unless we change the key with every broadcast that would will do something with the detection. but I see you point especially mass scanners . but again if example you use a malls wifi in reality not much is being done. i just wonder if the extra complexity is warranted for the gains. and Thanks I didn't think of those scenarios you are right.

[biemster]

@Itheras you're saying even with key cycling an iPhone will trigger on the tag? I did not realize that (although original AirTags also cycle the keys ofcourse).

Maybe we should run some experiments how quickly a key needs to be cycled before it triggers a detection?

[Itheras]

@biemster Correct if we cycle the key using the timings apple uses the detection doesn’t change much it already low with single adv. But i will imagine that cycling it faster will decrease detection rate.

[olivluca]

I don't know if this is still relevant https://positive.security/blog/find-you

For the experiment, I chose to iterate through 2000 key pairs and send one beacon every 30 seconds (a public key will therefore be repeated every ~17 hours)

The tracked person was using an iPhone with iOS 15.3.1 with all relevant settings configured to receive Find My Safety Alerts

The stealth AirTag clone was with the tracked person for over 5 days, also when leaving their house

[humpataa]

So has this been looked into? Like @Itheras I don't see any use of changing keys if this does not have the purpose of hiding tags from iPhone users. I have made a puck.js to work as a clone and after carrying it 10 minutes with me on my bycicle, a message from Apple's "findmy" app showed up telling me that there might be an AirTag with me that I don't own. Obviously my little new friend.
If changing the key regularly will stop my iPhone from recognising, the question is: how many keys do we need to use in what time frame?

[biemster]

I have my doubts that key cycling will hide the tags from iphone users. I did not test this yet though (no iphone), so I would be delighted if you could test this out on your puck?

[humpataa]

Will try, I have my doubts as well. Actually, I don't know why the AirTags change key every 24 hours anyway.
IF the app recognises tracking by unknown keys it must be a number of "contacts" in between these 24 hours.
When I use the subway and someone sits near me for 20 minutes having an AirTag in his pocket it would be stupidly annoying if the app raises alarms all the time. So the time for recognising must be rather long meaning changing the key every two minutes wouldn't make sense. Unless you have a 1000 and they would not repeat in 24 hours.
I think I will try with a new key every 15 minutes making it 96 keys.

[biemster]

Great! that will be a nice test. The AirTags change key every now and then to avoid bluetooth sniffers to be able to track them I guess.