Does this interoperate with Apple's implementation?

[marcdownie]

Have you been able to verify your code against values sent over the air by Apple or Google?

We have a number of 'FD6F' advertising packets sniffed from the latest iOS 13.5 beta with 20-byte advertising data including these (and ~140 other):

0fe41af90fe5025a8c4d1068738989fc4e93dc7e
48c05d63b4371e880521694aee9846111480b498
87a759aa6e92b623f355ca55dfd463e025d7a1e7
7dd4e13ccf4c0182a0262eee4594061f569986fa

Apple's API claims that these generated from within the 24 hour validity period from a TEK:

A2469729B173B8D69F87D51BD9D6D06B

starting at ENIntervalNumber = 2647728

The 16-byte RPIs output from this repositories make_rpi do not appear as prefixes in our sniffed bluetooth set for any interval number ~5000 around the TEKs ENIntervalNumber. It's always possible that we are loading our key wrong into your code, sniffing the advertising data incorrectly or that Apple's beta API is incorrect, or mendaciously making up TEKs to report during the beta. We're happy to provide captured RPIs, TEKs and methods to help, if you want to pursue this.

[phooky]

Hi Marc-- I haven't seen any real data and I'd love to see the captured TEKs/RPIs! Could you attach some? The spec is a bit of a moving target and a vague in places, and I don't doubt that I've gotten something wrong.

[marcdownie]

These should all be generated from within the 1 day validity period of the TEK (A2469729B173B8D69F87D51BD9D6D06B, rollingStartNumber= 2647728 (e.g May 4th 7pm CDT -> May 5th 7pm CDT)):

run1_capture.txt

We can only get one TEK per 24 hours per device; so, right now, we've got exactly one TEK. This should double shortly.

We've verified the collection of the advertising data on multiple OSs; and our python / pycrypto implementation of the crypto part of the spec produces the same RPIs as your implementation given the TEK. So, I'm beginning to think that Apple is lying about the TEK, Apple has made an error in their code, or we've made the same error twice feeding the code these two numbers.

The first few RPIs we get out of our code and yours (starting at 2647728) are:

ad82097611ef23dc4cfaf9d076edacee
3428d09259788c1afe3deda63677ab64
25c32f20651b5ead8625020600a06e60

[phooky]

Hi Marc,
I've poked around a bit here and can't reconcile what we're generating with their data. If you have additional data, I'd be happy to give it a whirl, but something seems fishy here. The two bits of my code I have the least confidence in are my HKDF function and my use of AES-128 CTR mode. Do you know if Google has a beta android implementation we can try?

[phooky]

(Ok, got a build of their example code running; will try it on my phone tonight.)

[marcdownie]

Are you looking at this: https://github.com/google/exposure-notifications-android ?

We thought for a brief moment that "Exposure Notifications Android Reference Design" meant that it had working crypto in it, but alas, unless I've missed something, it just calls their closed-source API. But we're trying to get it running.

[phooky]

That's indeed what I was looking at! I haven't managed to get a version of play services that seems to implement the API, though. I'm going to poke around and see if I can find someone internal at either company that knows what's up.

[marcdownie]

We aren't going to get quality time with the Android code until Monday (bue we've been assuming that google/exposure-notifications-android/app/libs/play-services-nearby-18.0.2-eap.aar was all we needed?). But we've collected and tested 4 more TEKs from Apple's code, and there's no change --- we can't get positive hits from any of them. Frobbing our python implementation in various ways (interval endianness, various byte orders for initialization vectors / keys) has yielded nothing. Curiously, while we do see RPI roll-overs aligning with the MAC address roll-overs from iOS (otherwise there would be no point to this spec --- you'd be able to track everybody all of the time, because one of these two things would be constant between successive packets), we don't see an RPI roll-over at the end of exactly 24 hours / 144-10-min periods after the key says it starts it's validity... I'll keep you posted.

…

On Sat, May 9, 2020 at 11:35 AM Adam Mayer ***@***.***> wrote: That's indeed what I was looking at! I haven't managed to get a version of play services that seems to implement the API, though. I'm going to poke around and see if I can find someone internal at either company that knows what's up. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABBHRMHQKAB5JN2Q55H6NLRQWA4LANCNFSM4M2Y7W7Q> .

[marcdownie]

We find the same set of RPIs generated with this implementation here: oseiskar/corona-sniffer#3 --- all of our crypto implementations seem to produce the same, incorrect, RPIs.

[marcdownie]

We've just finished a longer trawl through our logs and most bizarrely we have an RPI that's successfully generated from "our" code in our logs. But only one.

TEK / Diagnosis Key = C32BDCEC2CC4811BE1B412FCDAE37DB4
Rolling Period for the key starts at = 2648736
At interval number 2648736 + 143 (i.e the very last one before the new TEK arrives) we see 8087fcc42f8e0b9c9a496245c4da72531a7a1b6d over the air for a period of time between May 12 18:56:25 CDT and May 12 19:17:40 CDT (the last 4 bytes are the encrypted metadata)

Several things are odd about this.

Firstly, why only one? We're generating and searching +/- 10000 intervals around each validity period on each TEK. Even if we miss the occasional RPI over the air, we'd expect to match most of the 144 in any given period. The device is sitting next to the bluetooth scanner.

Secondly, the times are slightly off. Unless there's something about unix epoch time that I don't know, period 143 should be between May 12 18:50:00 and 19:00:00. The rolling period is too late (by 6mins) and too long (by a factor of ~2.5).

[marcdownie]

Ok! 13.5 beta 4 has improved the situation dramatically. We'll do another two days / TEKs worth of runs to make sure there aren't any RPI's we've captured that can't be generated by our code, but already I can tell that Apple's code (and your code, and my code) are much closer. The rolling interval seems random between 20 and 30 mins, so only 1/3 of the potential 144 RPIs will be seen in any day.

I'll close this after a complete days worth of keys has been seen and verified, although we still have to see if we can generate RPIs successfully and I haven't spent any time with the encrypted metadata. Many thanks!