search

google / eddystone

Specification for Eddystone, an open beacon format from Google
Apache License 2.0
3.08k stars 762 forks source link

ETLM MIC computation ambiguity #194

Closed kaYcee closed 7 years ago

kaYcee commented 7 years ago

I am about to implement ETLM protocol according to the specified algorithm. The EAS-EAX paper defines a header H, which is obviously empty for ETLM. I was told by a beacon manufacturer that the OMAC calculated from H should entirely be ignored and not taken into account for overall MIC calculation. Which is weird, as the paper specifies an initial value of "0000000000000001H" for header OMAC computation, irrespective of the actual header provided. Section 6 Definitions of the paper states that ....the header space Header (...) are nonempty sets of strings, hence a missing header should be handled like the empty string. Could you please confirm which algorithm has finally been implemented in Google's Proximity Beacon API? This is important because the message tag changes depending on the interpretation. Thanks!

mashbridge commented 7 years ago

the header should be empty (as in zero length)

kaYcee commented 7 years ago

hi @mashbridge! Yes, this is undoubtedly so. But for the prefix mentioned in the paper, "0000000000000001", the CMAC is still calculated (="5d4202f32b11d716fb6b56b3f623b955") and taken into account for overall XORing, right?

mashbridge commented 7 years ago

it's probably easiest to compare your implementation to Nordic's, which is already known to be correct: https://github.com/NordicSemiconductor/nrf5-sdk-for-eddystone/

kaYcee commented 7 years ago

Thx @mashbridge! Now the situation is clear; in case the header/ad is empty (as is for ETLM) the initial header/ad prefix still needs to participate in the overall OMAC calculation and XORization. Leaving this part out leads to a wrong MIC. Confirmed with Cifra, CryptoJS and Python Crypto library.

ben1983 commented 7 years ago

benji_00703@hotmail.com

Sent by MailWisehttp://www.mail-wise.com/installation/4 – Your emails, with style.:)

-------- Mensaje original -------- De: kaYcee notifications@github.com Enviado: Wednesday, November 30, 2016 10:48 AM Para: google/eddystone eddystone@noreply.github.com Asunto: Re: [google/eddystone] ETLM MIC computation ambiguity (#194)

Thx @mashbridgehttps://github.com/mashbridge! Now the situation is clear; in case the header/ad is empty (as is for ETLM) the initial header/ad prefix still needs to participate in the overall OMAC calculation and XORization. Leaving this part out leads to a wrong MIC. Confirmed with Cifra, CryptoJS and Python Crypto library.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/google/eddystone/issues/194#issuecomment-263926562, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ASnVuKAlatXDiy44p_qUMQJEXSWnAbyvks5rDajkgaJpZM4LAGnS.