Meraki Scanning API

Location and Privacy

Meraki understands that some end users may be concerned about the collection and use of location information. In an effort to address these concerns, Meraki developed location services with privacy in mind, including a number of security mechanisms to eliminate uniquely identifiable elements from the data that it collects. Meraki also recommends that its customers and partners implement a number of privacy-friendly features.

Hash Function

Meraki uses probe requests, data frames, and bluetooth beacon frames to locate and store client location. Because the location data contain raw MAC addresses, Meraki implemented a number of security mechanisms to anonymize the data in an irreversible fashion. Using a unique Meraki algorithm, the Meraki cloud hashes, salts and truncates MAC addresses so that they are not identifiable. The Meraki cloud then stores only that hashed, salted and truncated version of the MAC address. This anonymization process is described in more detail below.

The hash function is as follows:

Code Snippet
Copyhash(mac bytes, org secret) =
SHA1(mac bytes ++ org secret).takeRight(4)
where:
++ indicates concatenation;
takeRight(4) returns the least significant 4 bytes of the SHA1; and
org secret is a per-customer salt.
Example:
client MAC is 11:22:33:44:55:66
org secret is t3lrdd
least significant 4 bytes of SHA1(112233445566t3Irdd) = 0x0e456406

SHA1 is a widely known one-way cryptographic function. Using SHA1 hashes in this manner is the current industry standard. In order to provide an additional layer of security beyond SHA1 hashing, Meraki’s hash function truncates the hash to 4 bytes. This produces an information theoretic loss, as the domain of the function is larger than the range: a 6-byte MAC allows (2^48) possibilities whereas a 4-byte hash allows (2^32) possibilities. This results in 65,000 possible (org + MAC) combinations for each one 4-byte hashed MAC address. Therefore, given a MAC that has been salted, hashed, and truncated with the unique Meraki algorithm, it would be mathematically impossible to know with a reasonable degree of certainty what the original client MAC address was.

The hash function leads to information theoretic loss, and the original MAC address of client can never be recovered.

alt_text

Cisco Meraki includes a customer-specific org-secret in the hash function. As a result, Cisco Meraki does not have any visibility into client behavior across our customers networks worldwide. And, of course, no Cisco Meraki customer can see the analytics of another customer’s organization or where foot traffic goes after leaving the presence of its own WiFi / BLE network.

Finally, Cisco Meraki’s website offers a global opt-out feature that allows users to submit the MAC addresses of their devices, after which the Meraki cloud will no longer detect their MAC addresses either for its built-in Location Analytics views or for real-time export via the Scanning API. Cisco Meraki also recommends that retailers and others using the Scanning API post notices on the availability of this global opt-out in prominent locations, preferably in the storefront or at building entrances where location detection is taking place.

Data Privacy

Cisco Meraki’s Scanning API, outlined above, exports raw MAC addresses to a specified third-party server. There are a number of privacy protection mechanisms that we have implemented, including:

No customer identity tie-in mechanisms

Cisco Meraki does not directly provide any way of tying MAC addresses to customer identity. These systems must be separately built and hosted by a customer, partner or service provider.

No customer contact mechanisms

Cisco Meraki does not provide any mechanism by which the API data can be used to contact customers in any way. For real-time user engagement, Cisco Meraki customers must build and maintain their own platform for contacting customers.

Cisco Meraki recommends a number of best practices for users of its API, including:

  • Code Snippet
    Copy**Opt-in**
    • Cisco Meraki customers should make it explicitly clear at the time of identity tie-in (e.g., via a splash page or through a mobile app) that user-provided information may be linked to a device’s MAC address for more extensive engagement.
  • On-premise notification
    • As with the use of the built-in Location Analytics, notice should be prominently displayed in areas using of the Location API data.
  • Opt-out
    • In addition to providing an opt-in policy, Cisco Meraki customers should make their own customers aware of Cisco Meraki’s global opt-out policy (allowing an opt-out by MAC address) and provide an intuitive means of accessing Cisco Meraki’s opt-out page. Cisco Meraki’s global opt-out is available at https://account.meraki.com/optout.
Next