Sådan kodes RFID-kort til adgangskontrolsystemer

Kodning af RFID-kort til adgangskontrolsystemer kan lyde som en teknisk opgave, der foregår bag kulisserne, og som kun installatører og softwarespecialister behøver at beskæftige sig med. I praksis er processen langt tættere knyttet til den daglige drift, end de fleste indkøbere forventer. Hvis kodningen er forkert, kan kortet se korrekt ud, være printet fejlfrit og alligevel ikke virke ved døren. Endnu værre kan det give adgang til de forkerte områder, holde op med at fungere efter en systemopdatering, kopiere en eksisterende adgangslegitimation eller skabe supportsager, hvor fejlen placeres hos læseren, softwaren, sikkerhedsafdelingen eller kortleverandøren. Korrekt kodning af RFID-kort er derfor ikke kun et teknisk spørgsmål. Det handler også om sikkerhed, arbejdsgange og driftskontinuitet.

Mange virksomheder griber emnet an i den forkerte rækkefølge. De spørger, hvordan RFID-kort skal kodes, før de har afklaret, hvilke data der skal skrives, hvad adgangskontrolsystemet forventer, og om den valgte korttype overhovedet passer til miljøet. Denne rækkefølge skaber overraskende mange problemer. Et projekt med kodning af adgangskort fungerer kun problemfrit, når kortteknologi, læserkonfiguration, legitimationsformat, adgangsregler og udstedelsesproces er afstemt. Hvis blot ét element ikke passer, bliver kodningen baseret på gætteri, og det hører ikke hjemme i et RFID-baseret adgangskontrolsystem.

Afklar adgangskontrolsystemets krav

Den første regel er enkel: Før der kodes noget, skal det præcist afklares, hvad adgangskontrolsystemet forventer. Det omfatter korttype, læserteknologi, det krævede legitimationsformat og oplysninger om, hvorvidt systemet læser kortets serienummer, en programmeret datablok, sektorbaserede data, en sikker applikation eller en anden specifik struktur. RFID-kortkodning omtales ofte, som om alle adgangskort fungerer på samme måde. Det gør de ikke. Nogle systemer anvender kortnummer og facilitetskode. Andre anvender et internt, kundespecifikt nummer. Nogle bruger adgangslegitimationer ved lavfrekvensen 125 kHz, mens andre anvender smartcards ved 13,56 MHz. Visse systemer er desuden bundet til en bestemt leverandørs datastruktur. Kodningsmetoden skal derfor passe til de faktiske RFID-læsere til adgangskontrol og det konkrete driftsmiljø – ikke blot til beskrivelsen i en brochure.

En ejendomsadministrator i Texas oplevede konsekvenserne under en bygningsudvidelse. Teamet antog, at de nye RFID-medarbejderkort blot skulle have den korrekte facilitetskode og det rigtige kortnummer, fordi det havde været tilstrækkeligt i det gamle kontor. På den nye etage var læserne imidlertid konfigureret til at fortolke legitimationsdataene anderledes efter en delvis sikkerhedsopgradering. Kortene var kodet ensartet, men de var konsekvent kodet forkert til det nye miljø. Resultatet blev en uge med forvirring i receptionen og gensidige beskyldninger, før det blev erkendt, at det egentlige problem var opstået, inden det første kort overhovedet blev kodet.

Definer legitimationsstrukturen før kodning

Derfor er den næste regel lige så vigtig: Definer legitimationsstrukturen, før encoderen tages i brug. I enkle, ældre systemer kan det betyde, at lokationskode, facilitetskode, kortnummerserie, paritetskrav og bitformat skal fastlægges. I mere avancerede systemer skal det muligvis besluttes, hvilke data der placeres hvor, om kortet anvender en sikker applikation, om UID-aflæsning er tilladt, og hvordan kortet skal understøtte fremtidige udvidelser. Dette trin kan virke mindre spændende, men det forhindrer, at kort kodes i enkeltstående partier uden en langsigtet og sammenhængende struktur.

Et universitet i Canada håndterede dette korrekt, da institutionen redesignede sine adgangskort til campus. I stedet for blot at bede kortkontoret om at »kode adgang for de studerende« dokumenterede universitetet kravene fra kollegierne, bibliotekets adgangsporte og laboratoriernes læsere samt hvilke funktioner der skulle holdes adskilt. Først derefter fastlagde teamet arbejdsgangen for kodning af RFID-kort. Planlægningen krævede mere tid i begyndelsen, men forhindrede det uoverskuelige kortmiljø, som mange uddannelsesinstitutioner ellers ender med at skulle håndtere i årevis.

Vælg stabil hardware og software til kodning

Når legitimationsstrukturen er fastlagt, skal der vælges egnet hardware og software til kodningen. Nogle organisationer anvender en dedikeret encoder til RFID-kort. Andre bruger en kortprinter med et integreret kodningsmodul, mens nogle benytter adgangskontrolleverandørens værktøjer til registrering og udstedelse. Der findes ikke én løsning, som er rigtig for alle, men arbejdsgangen skal være stabil og reproducerbar. Hvis medarbejdere manuelt flytter data mellem systemer, indtaster kortnumre i regneark eller koder kort gennem løst forbundne værktøjer, vil antallet af fejl før eller siden stige.

Et privathospital i Malaysia oplevede dette under udstedelsen af medarbejderkort. Sikkerhedsafdelingen anvendte ét program til at tildele adgangsrettigheder, HR-afdelingen opbevarede medarbejderdata i et separat system, og kortkontoret kodede kortene med et selvstændigt værktøj og en delvist manuel importproces. Hospitalet blev ikke ramt af én stor teknisk fejl, men af noget mere belastende: en vedvarende strøm af mindre fejl. Forkerte afdelinger, forældede tilladelser, dublerede kortnumre og forsinkede erstatningskort blev en del af hverdagen. Da hospitalet integrerede registrerings- og udstedelsesprocessen bedre og reducerede de manuelle dataoverførsler, blev kodningen af RFID-kort langt mere forudsigelig. Erfaringen var klar: Kodningssoftwaren er vigtig, men processen omkring den er endnu vigtigere.

Beslut hvilke data der skal skrives på kortet

Det næste trin er at beslutte, hvilke data der skal lagres på kortet, og hvilke der skal forblive i backend-systemet. Det er en af de vigtigste beslutninger ved kodning af adgangskort, men også en af de beslutninger, der lettest håndteres forkert. Nogle organisationer forsøger at lægge for mange oplysninger på kortet, fordi de antager, at flere data giver større fleksibilitet. I praksis bliver systemet vanskeligere at vedligeholde, jo flere data der gemmes på kortet uden et klart formål. En velfungerende kodningsløsning begrænser kortets data til det nødvendige. Kortet bør indeholde de oplysninger, som systemet reelt skal bruge til at identificere eller godkende brugeren – ikke alle tænkelige datafelter, som nogen måtte finde interessante.

En biotekvirksomhed i Singapore var tæt på at begå denne fejl, da den redesignede sit program for medarbejderkort. Én gruppe ønskede, at kortet skulle indeholde afdelingsoplysninger, rolleklasse, lokationskode, internt ID, markeringer til nødprofiler og parkeringsgruppe som en del af legitimationsstrukturen. En anden gruppe stillede et mere relevant spørgsmål: Hvilke data behøver læseren faktisk for at træffe den korrekte adgangsbeslutning? Det spørgsmål forenklede hele systemet. Størstedelen af kompleksiteten blev bevaret i adgangskontrolplatformen, mens kortet kun indeholdt de data, der var nødvendige for sikker identifikation og valg af applikation. Kortene blev lettere at kode og genudstede, og løsningen blev langt mindre sårbar i den daglige drift.

Test de kodede kort i det faktiske system

Derefter følger testen, som mange teams gennemfører for hurtigt, fordi de første kort tilsyneladende fungerer. Det er ikke tilstrækkeligt. At et kort kan åbne én dør i et testlokale, dokumenterer ikke, at kodningsmodellen er korrekt. En grundig test bør omfatte flere kortlæsere, flere døre, forskellige adgangsniveauer, reelle brugerprofiler og relevante undtagelsessituationer. Hvis systemet også omfatter elevatorstyring, parkeringsadgang, tidsregistrering eller områdespecifikke begrænsninger, skal disse funktioner ligeledes testes. Kodning handler ikke kun om at gøre chippen læsbar. Adgangslegitimationen skal fungere korrekt i hele det faktiske system.

En kombineret kontor- og erhvervsejendom i Dubai oplevede, hvorfor dette er vigtigt. Den første serie medarbejderkort åbnede drejekorset i lobbyen uden problemer, og projektteamet antog derfor, at kodningen var korrekt. De samme kort virkede imidlertid ikke på udvalgte lejeretager og opførte sig uforudsigeligt ved indgange uden for normal åbningstid. Årsagen var en uoverensstemmelse mellem den kodede legitimationslogik og flere læserprofiler, som gennem tiden var blevet konfigureret forskelligt. En bredere systemtest ville have afsløret problemet tidligere. Ejendommen måtte i stedet erfare, at »kortet kan læses« og »kortet er kodet korrekt til hele systemet« ikke betyder det samme.

Hold trykte kortdata og kodede data afstemt

Et andet vigtigt princip er, at det trykte kortnummer og den kodede adgangslegitimation ikke må behandles som identiske værdier, medmindre systemet er opbygget sådan. I visse systemer kan det trykte medarbejdernummer, person-ID'et i databasen og det kodede kortnummer være tre forskellige værdier. Hvis medarbejderne antager, at værdierne er ens, kan der opstå alvorlige fejl. Et erstatningskort kan eksempelvis være printet med korrekt navn og nummer, men indeholde en forkert kodet identitet. Fejlen opdages måske først, når kortet anvendes ved en aktiv dør. Sådanne problemer bliver ofte fejlagtigt tilskrevet kortprinteren eller læseren, selv om den egentlige årsag findes i kodningsprocessen.

En logistikvirksomhed i Polen løste dette problem ved at indføre en enkel, men effektiv kontrol. Alle kodede RFID-kort skulle gennemgå en verificering efter skrivningen, hvor det blev kontrolleret, at chipdata, det synlige kort-ID og den tilknyttede brugerprofil stemte overens. Kontrollen tilføjede få sekunder til udstedelsesprocessen, men fjernede en lang række skjulte kortfejl. Inden for adgangskontrol er nogle få ekstra sekunder ved udstedelsen langt billigere end flere timers support, efter at kortet er taget i brug.

Styr sikker kodning og nøglehåndtering

Sikker kodning bliver endnu vigtigere, når systemet anvender smartcards som MIFARE DESFire eller andre applikationsbaserede adgangslegitimationer. I sådanne miljøer handler kodning ikke blot om at skrive et nummer. Processen kan omfatte nøgler, applikationer, filstrukturer, datablokke og beskyttede sektorer. Grunddisciplinen er stadig den samme: Kend systemets krav, og hold styr på dataene