Waar liggen de veiligheidsgrenzen van onze toegangscontrole?
Zes beveiligingslagen in iCober SAC — van de kaart tot de verbinding met de cloud. We zijn ook eerlijk over wat het systeem niet belooft en niet kan.

Wanneer een klant mij vraagt: “Is dit veilig?”, antwoord ik niet simpelweg met “ja”.
Beveiliging moet kunnen worden uitgelegd en gemeten. Vooral moet duidelijk zijn waartegen een systeem bescherming biedt en waar de grenzen liggen.
In ons geval gaat het niet alleen om de beveiliging van de afvalcontainer zelf. Het gaat ook om de bescherming van de gegevens van bewoners en onze klant.
1. Een kaart die niet kan worden gekopieerd met alleen het kaartnummer
Bij DESFire EV2- en EV3-kaarten behandelt de lezer de kaart niet als een eenvoudige identificatiedrager waarvan het nummer alleen maar hoeft te worden uitgelezen en gekopieerd.
In plaats van de kaart te vragen: “Wat is je nummer?”, start de lezer een authenticatieproces. De lezer stuurt een willekeurige uitdaging en de kaart moet bewijzen dat zij de juiste cryptografische sleutel kent.
De sleutel wordt tijdens de communicatie niet verzonden. Alleen het onderscheppen van de communicatie tussen kaart en lezer levert een aanvaller daardoor geen informatie op waarmee de kaart eenvoudig kan worden gekopieerd.
In de praktijk betekent dit dat het uitlezen van het kaartnummer niet hetzelfde is als het klonen van de kaart.
| Gewone contactloze kaart | DESFire EV2 / EV3 | |
|---|---|---|
| Hoe wordt de kaart geïdentificeerd? | Vast nummer/identificatiemiddel | Cryptografische authenticatie |
| Verstuurt de kaart haar sleutel? | Niet van toepassing — de beveiliging kan uitsluitend op het nummer zijn gebaseerd | Nee — de sleutel verlaat de kaart niet |
| Kan onderschepte communicatie worden hergebruikt? | In sommige systemen kan dit het kopiëren van het kaartnummer vergemakkelijken | Bij iedere nieuwe authenticatie wordt een nieuwe, willekeurige uitdaging gebruikt |
| Wat levert kennis van het kaartnummer op? | Afhankelijk van het systeem kan dit voldoende zijn om de kaart na te bootsen | Alleen het nummer is niet voldoende voor authenticatie |
| Heeft iedere kaart dezelfde sleutel? | Dat hangt af van de toegepaste oplossing | In onze implementatie wordt voor iedere gebruiker een afzonderlijke sleutel afgeleid |
| Wat gebeurt er als één kaart wordt gecompromitteerd? | De gevolgen zijn afhankelijk van de systeemarchitectuur | De sleutel van één kaart onthult noch de hoofdsleutel, noch de sleutels van andere kaarten |
Wat betekent dit voor de klant?
We baseren de beveiliging niet op de aanname dat “toch niemand zal proberen de kaart te kopiëren”.
We gaan ervan uit dat iemand toegang tot de kaart kan krijgen, de communicatie kan proberen uit te lezen of het kaartnummer kan achterhalen. Het systeem is zo ontworpen dat alleen kennis van het kaartnummer of het onderscheppen van de communicatie niet voldoende is om toegang te krijgen.
Dat is het wezenlijke verschil tussen een eenvoudige contactloze identificatiedrager en een kaart die cryptografische authenticatie gebruikt.
In onze implementatie wordt voor iedere gebruiker met een eenrichtingsfunctie een afzonderlijke sessiesleutel uit de hoofdsleutel afgeleid. Als de sleutel van één kaart bekend raakt, worden daardoor noch de hoofdsleutel, noch de sleutels van andere kaarten onthuld.
2. Geen persoonsgegevens op het apparaat
De lezer bewaart uitsluitend het kaartnummer en het type toegangsrecht. Alleen in het klantenportaal kan worden vastgelegd wie bij de kaart hoort.
Diefstal of demontage van de lezer onthult geen persoonsgegevens. Dat is een concreet voordeel vanuit het oogpunt van de AVG.
3. Alleen een versleutelde verbinding met de cloud
De apparaten communiceren uitsluitend via een versleutelde TLS-verbinding met de server.
Daardoor worden gegevens tussen apparaat en server niet als leesbare tekst verzonden. Alleen het onderscheppen van de verbinding levert niets bruikbaars op.
Bovendien zijn de gegevens van afzonderlijke klanten logisch van elkaar gescheiden. Het systeem behandelt niet alle gegevens als één gezamenlijke database waartoe iedere klant toegang heeft.
| Verbinding zonder versleuteling | TLS-verbinding | |
|---|---|---|
| Wat is onderweg zichtbaar? | De inhoud van de verzonden gegevens | De gegevens zijn versleuteld |
| Is onderschepping van de verbinding voldoende om de gegevens te lezen? | Ja | Nee — daarvoor zou de toegepaste cryptografische beveiliging moeten worden doorbroken |
| Wat levert het onderscheppen van gegevens op? | De verzonden gegevens kunnen zichtbaar worden | Zonder de juiste sleutels horen onderschepte gegevens niet bruikbaar te zijn |
Belangrijk: versleuteling beschermt gegevens vooral tijdens de overdracht. De beveiliging van gegevens op de server en de toegangscontrole tot die gegevens vormen afzonderlijke beveiligingslagen.
4. Een ingetrokken kaart betekent dat de toegang daadwerkelijk is ingetrokken
Het verwijderen van een kaart in het beheerdersportaal is op zichzelf nog niet het einde van het proces.
Het systeem beschouwt de toegang van de kaart pas als ingetrokken nadat het apparaat heeft bevestigd dat de wijziging van de toegangsrechten is ontvangen en toegepast.
De beheerder hoeft daardoor niet te twijfelen of de opdracht “kaart verwijderen” het apparaat daadwerkelijk heeft bereikt.
Het systeem maakt dus duidelijk onderscheid tussen:
- opdracht verzonden,
- opdracht door het apparaat ontvangen,
- wijziging daadwerkelijk toegepast.
Dat is een belangrijk verschil met een systeem dat in het portaal “kaart verwijderd” toont, terwijl het apparaat de kaart mogelijk nog enige tijd accepteert.
5. Geen bereik betekent geen verlies van gegevens
Het wegvallen van de netwerkverbinding leidt niet automatisch tot verlies van de gebeurtenishistorie.
Het apparaat beslist lokaal en op basis van de opgeslagen toegangsrechten of de container wordt geopend. Er hoeft niet bij iedere poging op een antwoord van de server te worden gewacht.
Als het apparaat tijdelijk geen verbinding heeft, worden gebeurtenissen lokaal opgeslagen. Zodra de communicatie is hersteld, worden ze naar de server verzonden en met het systeem gesynchroniseerd.
Een storing of tijdelijk ontbrekend bereik hoort daardoor geen “gat” in de historie van openingen te veroorzaken.
6. De telefoon kan de kaart vervangen — zonder een ander beveiligingsmodel
Een telefoon krijgt geen speciale, “gemakkelijkere” toegang.
De app gebruikt hetzelfde authenticatiemechanisme op basis van een uitdaging en een cryptografisch antwoord. Het apparaat moet controleren of de app waarmee het communiceert over de juiste toegangsrechten beschikt.
Voor de gebruiker betekent dit eenvoudigweg: een telefoon in plaats van een kaart, zonder concessies aan het beveiligingsmodel.
Voor het systeem blijft hetzelfde uitgangspunt gelden: toegang wordt niet uitsluitend verleend omdat iemand het identificatienummer van een gebruiker kent. Het apparaat moet de toegangsrechten van de andere partij correct verifiëren.
Wat ik niet zal beweren
Ik zal niet zeggen dat het systeem onmogelijk te kraken is — niemand die eerlijk is, doet zo'n uitspraak. Wel kan ik zeggen dat ik de grenzen ken, omdat ik ze heb gemeten en vastgelegd. En dat iedere beveiligingslaag bedoeld is om de gegevens van onze klanten en hun bewoners beter te beschermen dan gisteren.
Hoe deze mechanismen in het apparaat werken, leest u op de pagina SAC-toegangscontrole. Waarom het zinvol is een container af te sluiten, leggen we uit op de pagina over het beperken van afval van onbevoegden.