Where the limits of our access control security are
Six layers of protection in iCober SAC, from the card to the cloud connection. We are also honest about what the system does not promise and cannot do.
When a customer asks me: "Is this secure?", I do not simply answer "yes".
Security has to be something you can explain and measure — above all, you have to show what the system protects against and where its limits lie.
In our case it is not only about securing the waste container itself. It is also about protecting residents' data and our customer's data.
1. A card that cannot be copied from its number alone
With DESFire EV2 and EV3 cards, the reader does not treat the card as a plain identifier that only has to be read and copied.
Instead of asking the card "what is your number?", the reader starts an authentication exchange. It sends a random challenge, and the card has to prove that it knows the right cryptographic key.
The key is never sent over the air. Intercepting the exchange between the card and the reader therefore gives an attacker nothing that would let them simply copy the card.
In practice this means that reading a card's identifier is not the same as cloning it.
| Ordinary proximity card | DESFire EV2 / EV3 | |
|---|---|---|
| What identifies the card? | A fixed number/identifier | Cryptographic authentication |
| Does the card send its key? | Not applicable — protection may rest on the number alone | No — the key never leaves the card |
| Can an intercepted exchange be reused? | In some systems it can make copying the identifier easier | Each authentication uses a new, random challenge |
| What does knowing the card number give you? | It may be enough to impersonate the card, depending on the system | The number alone is not enough to authenticate |
| Does every card share the same key? | Depends on the system in use | In our implementation the key is derived separately for each user |
| What if one card is compromised? | The scope depends on the system architecture | One card's key reveals neither the master key nor the keys of the other cards |
What does this mean for the customer?
We do not build security on the assumption that "nobody will try to copy a card".
We assume someone may get hold of a card, may try to read its communication or learn its identifier. The system is designed so that knowing the card number or intercepting the exchange is not enough to gain access.
That is the essential difference between a simple proximity identifier and a card that uses cryptographic authentication.
In our implementation the session key is derived separately for every user from a master key, through a one-way function. Learning one card's key therefore exposes neither the master key nor the keys of the other cards.
2. No personal data on the device
The reader stores only the card identifier and the type of permission. Who stands behind the card is known to the customer's panel alone.
Stealing or dismantling a reader exposes nobody's data. That is a real benefit in GDPR terms.
3. To the cloud over an encrypted connection only
Devices talk to the server exclusively over an encrypted TLS connection.
Data travelling between the device and the server is therefore not sent in the clear — tapping the link itself reveals nothing.
On top of that, each customer's data is logically isolated from the rest. The system does not treat all data as one shared pool that every customer can reach into.
| Unencrypted connection | TLS connection | |
|---|---|---|
| What can be seen along the way? | The content being transmitted | The data is encrypted |
| Is intercepting the transmission enough to read the data? | Yes | No — it would require breaking the cryptography in use |
| What does eavesdropping achieve? | It may reveal the transmitted data | Intercepted data should be of no use without the keys |
Important: encryption protects data above all in transit. Protecting data on the server and controlling access to it are separate layers of security.
4. Revoking a card means access is really revoked
Deleting a card in the administration panel is not yet the end of the process.
The system treats a card as revoked only once the device confirms that it has received and applied the permission change.
The administrator therefore does not have to wonder whether the "delete card" instruction actually reached the device.
The system can distinguish clearly between:
- the instruction sent,
- the instruction received by the device,
- the change actually applied.
That is a meaningful difference from a system that shows "card deleted" in the panel while the device may go on honouring its permissions for some time.
5. No coverage does not mean lost data
Losing the network connection does not automatically mean losing the event history.
The decision to open the container is made locally by the device, based on the permissions stored in it. There is no need to wait for a server response every time.
If the device is temporarily offline, events are recorded locally. Once communication is restored they are passed to the server and synchronised with the system.
A fault or a brief loss of coverage should therefore not turn the opening history into a gap in the data.
6. A phone can replace a card — without changing the security model
The phone does not get special, "easier" access.
The app uses the same authentication mechanism based on a cryptographic challenge and response. The device has to verify that the app communicating with it holds the right permissions.
For the user it simply means: a phone instead of a card, but not at the expense of security.
From the system's point of view the same rule still applies: access does not follow from knowing a user identifier. The device has to verify the other side's permissions correctly.
What I will not say
I will not say that it cannot be broken — nobody honest says that. I will say that I know where the limits are, because I measured them and wrote them down. And that each of these layers exists so that the data of our customers and their residents is safer than it was yesterday.
How these mechanisms work in the device: SAC access control. Why lock a bin in the first place is on the prevent unauthorised disposal page.