Access Control in the Rfid Network of a Makespace

For the past months I have been participating in a makerspace in Madrid and now is the time to implement some level of access control to the space.

This is one of those opportunities to develop end to end projects.

The challenge

The idea is to install RFID sensor stations around the space in order to provide a second access method to the space while the keys are open and to authenticate access to the machines in a granular manner.

This involves maintaining an access control list or ACL for each RFID station group on the network.

An RFID station group is nothing more than the system composed of the RFID reader and the set of actuators that will react to a RFID reading event.

For example, a door enabled with a RFID reader will publish a message to a MQTT message queue to which the actuators will be subscribed to. On reception, the actuators will activate and open the door.

The question here is how do we authenticate the RFID card.

We could hardcode the access control list inside the RFID reader, which sounds like a terrible idea that would make it difficult to update the state of that ACL and obtain additional logs and metrics. The difficulty increases if we need to manage multiple RFID stations.

This calls for the need of maintaining the state of that ACL on a server in the network that any device can query to know if the RFID card belongs to its corresponding ACL.

The idea would be for:

• The RFID reader to request the ACL during setup to a REST endpoint for the ACL.
• The RFID reader to read the RFID card to subscribe to a topic managed by this server in which the ACL updates are provided.
• Develop a web interface for to manage the state of the ACLs.

In addition to this, we need to choose a viable data layer for our access control lists. However, we can manage by using a simple SQLite database for now.

To begin the definition of this architecture, we will use the C4 Model, which provides a way to formally define what we need and what we want to build.

System Context

The system context involves a high level view of what we need to build.

On this diagram we define the follwing actors.

• RfidUser: Which is the owner of a RfidCard with a unique identifier that identifies itself to the RfidStation.
• AppUser: Which is an administrator for the access control lists of the network.

We also define three systems.

• RfidCard: Which for now will be a simple token that sends back a unique hexadecimal number, note that this number should be secret in order to avoid replay attacks.
• RfidStation: Which is the RFID system equiped with a reader the RfidUser will authenticate to.
• RfidApp: The authentication server that contains the ACL for the RfidStation with the users allowed.

Data model

Regarding the data model, we will begin with something simple. However, this is expected to suffer changes.

This data model essentially shows the structure of the ACL tree we need to maintain for all RFID stations in the network.

Our assumptions involve that:

• Each RfidStation should have a unique ID.
• Each RfidIdentity should be unique.

There are some unknowns in this model that we will need to address in the future in order to integrate it with other systems.

For example, the RfidIdentity could contain additional parameters such as the username of the cardholder.

We could also define roles on the system that provide different levels of access control.

We need to define how administrators of the service will log into it. The best solution would involve deploying a centralized solution such as Active Directory or LDAP, which could allow integration of the same user accounts over multiple systems. However, this requires further investigation, as the makespace still does not have such a solution in place.

A simple user and password can be used to assemble the core functionality of the service until a more stable solution is available.

Container Context

Here we will focus on two systems, the RfidStation and the RfidApp.

First we will define the simplest one but not the least important, the RfidStation.

The RfidStation will be implemented using inexpensive Arduino hardware and a ESP32, which has a Wi-Fi device to connect to the wireless network for the domotics in the space.

The firmware of the ESP32 is installed via OTA from a ESPHome server in the network, which will allow us to update it without connecting it to the computer. The access to the Wi-Fi network, the MQTT server and the HTTP REST API will be hardcoded in the firmware and not expected to change unless we do it through the OTA in ESPHome.

The RfidStation will have an updated ACL in its temporal memory at all times given these two assumptions:

• Will retrieve the ACL for this device from the server.
• Will receive updates that affect this ACL.

The RfidStation will check this ACL before sending the MQTT message to the right actuator. In order to avoid brute force attacks there should be an incremental delay after each failed access attempt.

Second is the RfidApp we want to develop.

The RfidApp is composed of three components.

• The Data Store where the ACLs will live. Should be able to be backed up or restored.
• The ACL Notify Service is the component whose responsability is to publish the MQTT message to the network of RfidStations in case there is a change in their ACLs.
• The WebApp, which will be composed of two interfaces:
  • An authenticated REST API with TLS: This will return the ACL for a specific RfidStation, which will request the ACL on startup.
  • An authenticated Web interface: This will be the place from which the ACL for each RFIDStation will be managed.

Regarding security of the WebApp interfaces.

• The authenticated REST API authentication details will be hardcoded in the RfidStation firmware and access will be read-only.
• For the authenticated Web interface the authentication will be simple HTTP authentication on the first version, we will want to integrate it with the authentication network on the space in future steps.

Message Queue Protocol

We will need to define the protocol for the messages in que MQTT broker, this will involve the topics themselves and the MQTT messages.

Regarding the MQTT topics, we will define two types.

• Topics for RfidStation actuators.
• Topics for RfidStation ACL updates, in order to assure that the device has the last version of the ACL.

Regarding the first kind, they will depend on the specific logic of the RfidStation and are outside the scope for this project.

The second kind are topics for each RfidStation and will be defined by the notation “acl-update-rfidstation-[ID]” where the ID will be the ID of the RfidStation. This will assure that for each topic there is only one listener, the RfidStation itself, so that there are no unnecessary forwardings over the network.

It would be nice to have some kind of feedback from the subscriber that a subscription has been achieved.

We will need to define the following messages

• ACL Reload: This will trigger an HTTP request to the REST API to retrieve the new ACL.
• RfidStation Wake Up Event: With a simple message ID to provide feedback of subscription success.

We could also implement atomic updates of ACL IDs, but this would imply more complexity and we want to keep the first version simple and stupid, but reliable. Atomic updates would be useful for very long ACL lists that change a lot, but this is not expected to be the case.

We also want a wake-up event published by the RfidStation in the “acl-update-rfidstation-[ID]” topic for logging and debugging purposes.

All the events regarding the MQTT message queue will need to be posted on the Web App to provide feedback to the administrator or be written to a log file in the server.

Use cases for the web interface.

This is a high level view of the objectives that we want to achieve with the web UI. We can get as fancy as we want here, but these objectives need to be achieved.

We will model the web interface as a state machine of the different views.

The web interface is meant to be an administrator console that is able to complete the following tasks.

• See the state of the access control list for each RfidStation
• Define a new RfidIdentity on the system.
• Delete an existing RfidIdentity from the system.
• Add a defined RfidIdentity to the RfidStation.
• Remove a defined RfidIdentity from the RfidStation.
• Visualize the wake-up events of the RfidStations and the last time they showed up as online.
• Get a backup of the data store to a JSON file.
• Restore from a JSON file.
• Recover and change administrator password.
• Search bar to easily move between views. (Optional)

Ideally we want all these actions to be scriptable in order to easily test the backend and add extensions on the future.

Conclusion

We could go deeper in detail using the C4 model, but I believe that we first need a prototype in order to make further decisions without making too many assumptions. Consider this a first draft that might be subject to changes.

See you in the next one.