Security mode and level in proximity beacons

1

Hi, I am interested in the security field of IoT applications. I read this article about ‘BLE security levels and modes’ and I am wondering what is the mode and level that estimote beacons uses?

LE Security Modes and Levels
LE security modes are similar to BR/EDR service-level security modes (i.e., Security Modes 2 and 4) in that each service can have its own security requirements. However, Bluetooth LE also specifies that each service request can have its own security requirements as well. A device enforces the service-related security requirements by following the appropriate security mode and level.

1- LE Security Mode 1 has multiple levels associated with encryption. Level 1 specifies no security, meaning no authentication and no encryption will be initiated. Level 2 requires unauthenticated pairing with encryption. Level 3 requires authenticated pairing with encryption.

2- LE Security Mode 2 has multiple levels associated with data signing. Data signing provides strong data integrity but not confidentiality. Level 1 requires unauthenticated pairing with data signing. Level 2 requires authenticated pairing with data signing.

If a particular service request and the associated service have different security modes and/or levels, the stronger security requirements prevail. For example, if either requires Security Mode 1 Level 3, then the requirements for Security Mode 1 Level 3 are enforced.
Because Security Mode 1 Level 3 requires authenticated pairing and encryption, NIST considers this the most secure of these modes/levels and strongly recommends its use for all LE connections. Security Mode 1 Level 1 is the least secure and should never be used. Also, because Security Mode 2 does not provide encryption, Security Mode 1 Level 3 is strongly preferred over Security Mode 2.

1 Like
2

We use Mode 1 Level 1, and we use our own authentication procedure to make sure that the client connecting to the beacon is allowed to access and change its settings. There’s a key to each beacon stored securely in Estimote Cloud, and only the owner of the beacon has access to that key, and this key is the base for the authentication procedure.

That’s for securing connection/configuration. There’s also the matter of securing advertising—as of today, beacons by default broadcast plain-text identifiers, but you can enable our Secure UUID extension to iBeacon, or enable Eddystone Ephemeral ID (Eddystone-EID), and then the identifiers broadcast by the beacon are “scrambled” and once again there’s keys in Estimote Cloud that only the owner has access to, that allow authorized apps to “decipher” these secure identifiers.

Luckily, neither with configuration nor with secure advertising you actually need to do the work yourself—our SDKs automatically take care of fetching the keys and doing all the authentication, provided that you registered the app in your Estimote Cloud account.