Onion Information

Page Clicks: 0

First Seen: 03/12/2024

Last Indexed: 10/22/2024

Domain Index Total: 24

Scenario 1: Physical Access Control In this scenario, an individual carrying an Android smartphone approaches a locked door which gets unlocked as soon as the distance to the door is close enough and intention to access the room is assumed. This is determined by the smartphone which measures the proximity to a BLE (Bluetooth Low-Energy) beacon that is placed nearby the door. If the distance is sufficiently close and movement is towards the door, a credential is sent to the verifier which then triggers unlocking the door-lock through a proxy to the door-lock system. The individual can then enter the room. There are four actors in this scenario: Individual: To enter a locked door the authorized individual does need to carry the smartphone. This differs from scenario 2 where the individual does not need to carry anything which is the eventual goal of Digidow. Smartphone: The smartphone app acts as the PIA that holds a credential for unlocking certain doors and as a part of the sensor that determines proximity (together with the stationary BLE beacon). Therefore, the app on the carried smartphone needs to get the permission to scan for BLE signals in the background. Once this permission is granted, Android provides an API which listens for predefined signals and informs the application to verify them. The app filters this information by signal strength and actual state to see if the individual is approaching a door or if the door already got unlocked. This state tracking allows detection of movement that indicates intention to access a room and also helps to prevent sending multiple requests if a door has already been unlocked and the individual remains in proximity of the door. Once the distance is far enough again a new unlock request will be sent the next time the individual approaches the door. Based on the sensor reading (beacon information), the smartphone PIA identifies the appropriate verifier (door lock access controller) to send the unlock request to. Beacon: The second part of the sensor is a stationary BLE beacon. A Raspberry Pi is used to continuously broadcast that beacon so that it can be picked up by the smartphone part of the sensor implementation. This is achieved with hcitool (a readily available package in the Raspbian software package repository) which allows installing a beacon broadcast by running a simple command. Verifier: The Raspberry Pi also acts as the verifier to accept unlock requests from an authorized PIA. We implement a REST API that checks if the request is authorized and if this is the case, a command message will be sent to the door-lock system which unlocks the specified door. The entire verifier is implemented in Rust. For the first year prototype, the scenario runs in a dedicated local network segment at the Institute of Networks and Security. Service discovery is solely based on the data in the BLE beacon. The smartphone accesses the internal network segment through a VPN tunnel. As an additional security layer on top of the VPN tunnel and besides the authorization credential, the HTTP REST API uses TLS and all requests must be authenticated using an app-specific secret. It is noteworthy that, in this scenario, the smartphone acts as the PIA itself. Currently, we are planning to extend this scenario to a satellite PIA implementation, which will then report sensor readings to a hosted PIA implementation that is independent of the individual’s smartphone. This ensures the same sequence as in other scenarios and more control over the door access from the PIA as well as logging of interactions. This will also contribute to the location model as various sensor readings of the satellite PIA (discovered BLE beacons, GPS location, etc.) can be considered in the location modelling. The location model will, in turn, make the satellite PIA more scalable, as the PIA’s internal location representation will allow informed guesses of when and for which specific beacons to listen. Issues and Further Investigations Although this sounds simple, there are some catches to protect the individual to be tracked. Usually in such scenarios, the smartphone is constantly sending out Bluetooth signals which tell the sensor the proximity. This would allow other sensors to keep track of individuals as well and would, therefore, violate our privacy expectations. By switching the roles of the sensor and the smartphone, we can preserve privacy at the price of requiring the verifier to trust the smartphone app to some extent. So in our scenario, the external sensor part is constantly sending BLE beacons which the smartphone sensor part can process. If the sensor is close enough, the application can ensure that the individual is in front of the locked door and will send an unlock request to the verifier. The verifier authenticates the request and, if that is successful, triggers the actual unlocking of the door. For this prototype stage, we do not consider the trust expectation towards the individual’s smartphone as an issue as we assume that it is in the interest of the individual not to unlock doors if not physically present. One issue that we observed with the BLE proximity solution are the update intervals of BLE beacon discovery by the smartphone. Android provides an API to passively listen to beacons. While this improves the battery life of the smartphone, it adds additional delay to the process as it takes some time to wake up the smartphone from doze mode , connect to the network, and send the information to the verifier. Another issue we were facing was the resolution of the proximity measurement, as the update intervals may sometimes not be frequent enough to accurately tell the position on fast movements. This makes it especially hard to determine if a person is just passing a door or really standing in front of it with the intention to enter the room. Future work could try to add additional sensor readings such as those from the accelerometer of the smartphone which would allow determining if the movement vector is continuing or if the movement decelerated/stopped suddenly. The downside to this approach is that such additional sensors will consume more energy which, in turn, impacts the battery life. Another option would be the usage of ultra wide-band (UWB) for more accurate distance and relative position measurement with potentially less impact on battery life. Partners Funded by Host institution