NFC-tag-adgangskodebeskyttelse vs permanent låsning: Hvad skal man vælge før implementering

Når et NFC-tag bruges i en offentlig eller kunde-vendt implementering, bør indholdet ikke forblive redigerbart ved et uheld. Men "lås tagget" kan betyde flere forskellige ting, og at vælge den forkerte kan skabe et problem, som ikke kan løses efter produktionen.

Den praktiske beslutning er, om tagget skal forblive skrivbart, kræve en adgangskode til beskyttede hukommelsesoperationer eller blive permanent -skrivebeskyttet. Et fjerde spørgsmål ligger uden for dette valg: Hvis projektet skal bevise, at et fysisk tag er ægte, er simpel adgangskodebeskyttelse eller-skrivebeskyttet låsning ikke nok.

Denne vejledning er til B2B-teams, der forbereder NFC-klistermærker, etiketter, kort, skærme eller andre telefon-læsbare tags til masseimplementering. Den fokuserer på implementeringsbeslutningen, produktionssekvensen og acceptkriterier i stedet for app-specifikke programmeringstrin.

 

Fire forskellige krav kaldes ofte "sikkerhed"

Disse er ikke udskiftelige. En permanent låst URL kan stadig kopieres og gengives på et andet almindeligt tag. En adgangskode kan begrænse nogle hukommelseshandlinger uden at kryptere en offentlig NDEF URL. Et sikkert godkendelsesprojekt kan stadig bruge en NDEF-URL, men sikkerhedsværdien kommer fra den kryptografiske protokol og backend-bekræftelse, ikke fra det faktum, at tagget er -skrivebeskyttet.

Hvis du først har brug for det bredere NFC-grundlæggende, er SynteksGrundlæggende guide til NFC-tagsejer den introduktionsopgave. Denne side starter på det punkt, hvor tagindholdet og implementeringsworkflowet allerede eksisterer.

 

 

Hvad betyder permanent låsning på almindelige NTAG21x-tags

NXP beskriver NTAG213, NTAG215 og NTAG216 som NFC Forum Type 2 Tag-kompatible IC'er med både enfelt-programmerbar læse-låsefunktionogkonfigurerbar 32-bit adgangskodebeskyttelse. Det er separate mekanismer.

I denNTAG213/215/216 datablad, de statiske låsebytes og dynamiske låsebytes styrer, om definerede bruger-hukommelsessider kan skrives igen. Når en relevant låsebit er indstillet, bliver det beskyttede område skrivebeskyttet-. Låse-bitprocessen er en-vej: en programmeret låsebit kan ikke blot ændres tilbage fra 1 til 0.

Derfor hører permanent låsning til i slutningen af ​​en godkendelsesproces, ikke i begyndelsen af ​​kodningen.

DeChrome Web NFC-dokumentationbruger det samme operationelle koncept for understøttede tags: at gøre et tag -skrivebeskyttet er en permanent,-envejsoperation og kan ikke vendes gennem den normale NDEF-arbejdsgang.

 

Adgangskodebeskyttelse er reversibel kontrol, ikke kryptering

NTAG21x giver også konfigurerbar adgangskodebeskyttelse. NXP dokumenterer en adgangskode-godkendelseskommando, et beskyttet-områdes startpunkt og adgangsindstillinger, der kan begrænse skrivehandlinger eller, afhængigt af konfiguration, læse- og skrivehandlinger.

Det gør adgangskodebaseret-kontrol nyttig, når en autoriseret operatør muligvis skal ændre beskyttet indhold senere.

En 32-bit tag-adgangskode bør dog ikke markedsføres som kryptering eller høj-sikkerhedsgodkendelse. Det er en adgangskontrol- til hukommelseshandlinger. Hvis et tag indeholder en offentlig URL, som nogen skal læse, gør password-beskyttende skrivninger ikke denne URL fortrolig.

Det skaber også en operationel afhængighed: nogen skal eje adgangskoden, udstedelsesproceduren, gendannelsespolitikken og de værktøjer, der bruges til at autentificere og opdatere tagget. At miste denne kontrol kan gøre en teoretisk omskrivbar implementering til en praktisk talt uvedligeholdelig en.

 

Brug implementeringslivscyklussen til at vælge låsestrategien

Den mest vedligeholdelige offentlige implementering er ofte en stabil, virksomheds-kontrolleret webadresse skrevet til tagget, efterfulgt af indholdsændringer på server-siden. I den model kan NFC-hukommelsen kun blive læse-, mens destinationssiden, kampagneindholdet, garantioplysninger eller produktoplysninger forbliver redigerbare online.

Syntekshjemmeside NFC tag guidedækker det separate spørgsmål om URL-baseret NFC-implementering. Låsebeslutningen her begynder efter, at destinationsarkitekturen er blevet godkendt.

 

Lås ikke en leverandørejet destination-permanent uden en migrationsplan

En permanent lås fryser, hvad der er gemt på chippen, ikke hvad der sker på internettet. Denne sondring er kun nyttig, hvis organisationen kontrollerer destinationen eller har en pålidelig migreringssti.

Før du låser et tag til en URL, skal du bekræfte:

• hvem ejer domænet;
• hvem kontrollerer omdirigeringer;
• om destinationen kan flytte til en anden platform senere;
• om webadressen indeholder en-leverandørspecifik sti, der kan forsvinde;
• om per-tag unikke tokens skal forblive gyldige i den forventede implementeringstid;
• hvad der sker, når en kampagne, medarbejder, produktregistrering eller lokation bliver pensioneret.

Et permanent tag, der peger på en SaaS-URL til engangsbrug, kan blive en permanent fysisk påmindelse om en midlertidig softwarebeslutning. For tags med lang-levetid bør kontrol af webadressen behandles som en del af produktspecifikationen.

 

 

Låsning skal følge kodning og funktionel godkendelse

En sikker produktionssekvens adskillerskrivning, verifikationoglåsning.

1. Frys nyttelastreglen.Definer den nøjagtige NDEF-posttype, URL-struktur, unikke-tokenregel og eventuelle variable data.
2. Indkode tagget.Skriv den godkendte nyttelast ved hjælp af den specificerede produktionsproces.
3. Læs den tilbage elektronisk.Bekræft, at den gemte post stemmer overens med kildedataene.
4. Test brugerresultatet.Tryk på det færdige tag med repræsentative måltelefoner eller læsere, og bekræft, at den påtænkte handling er fuldført.
5. Bekræft destinationen.Tjek omdirigeringer, HTTPS-adfærd, kontoejerskab og enhver unik kortlægning.
6. Godkend en produktions-ækvivalent prøve.Prøven skal bruge den endelige chip, indlæg, materiale, overfladetilstand og indkodningsregel.
7. Anvend den godkendte beskyttelsestilstand.Lad være skrivbar, konfigurer adgangskodekontrol eller lås permanent i henhold til projektspecifikationen.
8. Bekræft post-låsetilstanden.Læs indholdet igen og bekræft, at den påtænkte skrivebegrænsning faktisk er i kraft.
9. Optag resultatet.Behold kravet om kortlægning, prøverevision og lås-tilstand sammen med produktionsposten.

Denne rækkefølge forhindrer en almindelig fejl: opdagelse af en forkert webadresse, duplikattoken eller forkert NDEF-record først, efter at tagget allerede er gjort permanent skrivebeskyttet-.

 

 

For unikke URL'er betyder kortfilen lige så meget som låsetilstanden

En batch af NFC-tags kan indeholde en fælles URL, eller hver brik kan bære et andet token. Unik kodning tilføjer endnu en fejltilstand: NFC-tagget kan låses korrekt, men tilknyttes det forkerte fysiske element.

Til kodning pr-stykke kan produktionsposten have brug for felter som:

Låsning løser ikke en dårlig kortlægning. Den korrekte rækkefølge er først at verificere kortlægningen og derefter anvende den irreversible tilstand.

 

Hvad skal testes, når et tag kun er læst-permanent

Den endelige inspektion skal både bevise, at indholdet stadig fungerer, og at den godkendte beskyttelsestilstand eksisterer.

For store ordrer skal du definere, om hver kodet vare eller en statistisk kontrolleret prøve skal kontrolleres ved hvert lag. Denne prøveudtagningsplan er en køber-/producentaftale; det bør ikke erstattes af en vag erklæring om, at taggene er "testet".

 

Permanent låsning løser ikke fysisk manipulation

Et -skrivebeskyttet NFC-tag kan ikke omskrives gennem normale hukommelsesoperationer, men et offentligt tag kan stadig fjernes, dækkes, udskiftes eller beskadiges fysisk.

Ved offentlige installationer skal du overveje, om projektet også har behov for:

• tamper-evident konstruktion;
• periodisk fysisk inspektion;
• et trykt QR-faldback;
• et kontrolleret aktiv/lokalitetsregister;
• backend-overvågning for uventede destinationer eller tokenbrug;
• en udskiftningsprocedure for beskadigede eller manglende tags.

Det fysiske sikkerhedskrav afhænger af omgivelserne. Et bordanmeldelsesmærke, en etiket til udendørsaktiver og et produkt-godkendelsesstempel har ikke den samme trusselsmodel.

 

Adgangskodebeskyttelse er ikke en erstatning for godkendelse

Denne sondring betyder mest i anti-projekter om forfalskning.

Et standardmærke kan låses permanent, så dets hukommelse ikke kan redigeres, men de synlige eller læsbare data kan stadig kopieres til et andet mærke. Et fast UID kan være nyttigt som en identifikator, men at stole på en identifikator alene svarer ikke til kryptografisk bevis.

Hvis forretningskravet er "forebyg uautoriseret omskrivning", kan låsning eller adgangskodebaseret-skrivekontrol være passende. Hvis kravet er "bevis at dette fysiske produkt er ægte", skal projektet evaluere en chip og backend designet til godkendelse.

Denne sikkerhedsarkitektur er bevidst uden for denne artikels anvendelsesområde. Gør ikke et offentligt URL-tag til en billig-pris til et "anti-forfalskningsprodukt ved blot at ændre dets låsetilstand.

 

Definer låsetilstand i RFQ, ikke efter produktion

Til direkte indkøb af telefon-læsbare NFC-tags og etiketter, SynteksNFC tag kategorier den kommercielle ejer. Hvis projektet kræver intern-kodning og verifikation, skalNFC-læser- og forfatterkategorier den relevante hardwaresti.

 

Genbestillinger kræver en lås-tilstandsændring-kontrolregel

En gentagelsesordre bør ikke arve ordet "samme" uden at definere, hvad der skal forblive det samme.

Genvalidering bør overvejes, når en ændring påvirker:

• chipmodel eller hukommelses-/beskyttelsesadfærd;
• NDEF-posttype eller URL-struktur;
• fælles versus unik kodning;
• adgangskodekonfiguration eller beskyttelsesomfang;
• permanent lås politik;
• trykt serie- eller QR-kortlægning;
• indlæg, antenne eller færdigt materiale;
• monteringsflade eller beregnet telefon/læsersæt.

En ændring af kosmetisk kunstværk kræver muligvis ikke en komplet teknisk gentest, men en ændring, der kan ændre RF-adfærd, datafortolkning, kortlægning eller skrivebeskyttelse, bør udløse gennemgang af det berørte lag.

 

Beslutningsreglen

Vælg beskyttelsestilstanden fra vedligeholdelsesmodellen, ikke fra ordet "sikker".

Hold tagget skrivbartmens implementeringen stadig er under idriftsættelse.Brug adgangskode-kontrolleret adgangnår autoriserede fremtidige hukommelsesopdateringer er et reelt driftskrav, og den valgte chip understøtter den nødvendige adfærd.Brug permanent læse-beskyttet låsningnår den kodede nyttelast er endelig og ikke bør omskrives.Brug kryptografisk godkendelsenår virksomheden skal verificere ægtheden i stedet for blot at forhindre almindelige redigeringer.

For bulkproduktion er den sikreste rækkefølge:

definere nyttelast → indkode → læs tilbage → testdestination → verificer kortlægning → godkend færdig prøve → påfør beskyttelse → verificer beskyttelse → frigiv batch

Den sekvens forhindrer en irreversibel lås i at blive en irreversibel produktionsfejl.