Validating with mac address as well as secure UUID

1

When using a beacon with Secure UUID enabled does the cloud/SDK also check the mac address of the beacon is correct

I’m trying to confirm that someone is not spoofing a beacon UUID/major/minor, even for a short period of time, between randomisation of the UUID from the cloud.

2

Our Secure UUID algorithms in the cloud can detect if a beacon is being spoofed (basically, we can detect the anomalies in the expected rotation pattern), and if it is, you’ll receive an email with an appropriate warning.

Spoofing a beacon between randomizations is much harder to detect, but it’s also a much less practical and viable vector of attack, as the attacker needs to set everything up on the spot, and the window of opportunity is extremely small.

iOS doesn’t expose the MAC address via the iBeacon, Core Location API, so we can’t rely on that as a prevention mechanism.

3

What is a typical length of time between randomisations?
Do you have any documentation available that describes the process that takes place between the beacon, app SDK and the cloud platform?

4

It’s ~ 10 minutes.

Long story short, what happens is: the beacon broadcasts an encrypted UUID + major + minor value, the SDK detects it and passes it on to the Estimote Cloud, the cloud handles the decryption and returns the “true” UUID, major and minor back to the SDK. The SDK then takes care of invoking the appropriate delegates, as necessary.

5

We need to restrict beacon spoofing as much as possible. As far as we understand, Secure UUID algorithm in the cloud can detect some anomalies. However, we should understand how to avoid a situation where someone is listening a Secure UUID enabled beacon in a public area and writes a list of encrypted UUID + major + minor values to their computer for the whole randomisation cycle and then creates a spoofing app utilising the whole list, i.e., creating a complete copy of the Secure UUID protected beacon.

Another possible security issue we may face is to listen the randomisation cycle for a shorter period (e.g., for a minute) and then use those values for a fake beacon.

How well the Secure UUID algorithm in the cloud and in the SDK can fight against that kind of security threats?