NFC-tag-passordbeskyttelse vs permanent låsing: Hva du bør velge før distribusjon

Når en NFC-tag brukes i en offentlig eller kunde-rettet distribusjon, bør innholdet ikke forbli redigerbart ved et uhell. Men "lås taggen" kan bety flere forskjellige ting, og å velge feil kan skape et problem som ikke kan fikses etter produksjon.

Den praktiske avgjørelsen er om taggen skal forbli skrivbar, kreve et passord for beskyttede minneoperasjoner eller bli permanent -skrivebeskyttet. Et fjerde spørsmål ligger utenfor dette valget: Hvis prosjektet må bevise at en fysisk kode er ekte, er enkel passordbeskyttelse eller -lesebeskyttet låsing ikke nok.

Denne veiledningen er for B2B-team som forbereder NFC-klistremerker, etiketter, kort, skjermer eller andre telefon-lesbare tagger for massedistribusjon. Den fokuserer på implementeringsbeslutningen, produksjonssekvensen og akseptkriteriene i stedet for app-spesifikke programmeringstrinn.

 

Fire forskjellige krav kalles ofte "sikkerhet"

Disse er ikke utskiftbare. En permanent låst URL kan fortsatt kopieres og reproduseres på en annen vanlig tag. Et passord kan begrense noen minneoperasjoner uten å kryptere en offentlig NDEF-URL. Et sikkert autentiseringsprosjekt kan fortsatt bruke en NDEF-URL, men sikkerhetsverdien kommer fra den kryptografiske protokollen og backend-verifiseringen, ikke fra det faktum at taggen er -skrivebeskyttet.

Hvis du trenger det bredere grunnleggende NFC først, SynteksGrunnleggende veiledning for NFC-taggereier den introduksjonsoppgaven. Denne siden starter på punktet der tag-innholdet og distribusjonsarbeidsflyten allerede eksisterer.

 

 

Hva betyr permanent låsing på vanlige NTAG21x-brikker

NXP beskriver NTAG213, NTAG215 og NTAG216 som NFC Forum Type 2 Tag-kompatible IC-er med både enfelt-programmerbar skrivebeskyttet-låsefunksjonogkonfigurerbar 32-biters passordbeskyttelse. Det er separate mekanismer.

INTAG213/215/216 datablad, de statiske låsebytene og dynamiske låsebytene kontrollerer om definerte bruker{0}minnesider kan skrives på nytt. Når en relevant låsebit er angitt, blir det beskyttede området -skrivebeskyttet. Låse-bitprosessen er enveis-: en programmert låsebit kan ikke bare endres tilbake fra 1 til 0.

Det er derfor permanent låsing hører hjemme på slutten av en godkjenningsprosess, ikke i begynnelsen av kodingen.

DeChrome Web NFC-dokumentasjonbruker det samme operasjonskonseptet for støttede tagger: å gjøre en tagg -skrivebeskyttet er en permanent,-enveis operasjon og kan ikke reverseres gjennom den vanlige NDEF-arbeidsflyten.

 

Passordbeskyttelse er reversibel kontroll, ikke kryptering

NTAG21x gir også konfigurerbar passordbeskyttelse. NXP dokumenterer en passord-autentiseringskommando, et beskyttet-områdestartpunkt og tilgangsinnstillinger som kan begrense skriveoperasjoner eller, avhengig av konfigurasjon, lese- og skriveoperasjoner.

Det gjør passordbasert-kontroll nyttig når en autorisert operatør kanskje må endre beskyttet innhold senere.

Et 32--tagpassord bør imidlertid ikke markedsføres som kryptering eller høy-sikkerhetsautentisering. Det er en tilgangskontroll- for minneoperasjoner. Hvis en tag inneholder en offentlig URL som noen skal lese, gjør passordbeskyttende skriv ikke den nettadressen konfidensiell.

Det skaper også en operasjonell avhengighet: noen må eie passordet, utstedelsesprosedyren, gjenopprettingspolicyen og verktøyene som brukes til å autentisere og oppdatere taggen. Å miste kontrollen kan gjøre en teoretisk omskrivbar distribusjon til en praktisk talt uopprettholdbar en.

 

Bruk distribusjonslivssyklusen til å velge låsestrategien

Den mest vedlikeholdbare offentlige distribusjonen er ofte en stabil-bedriftskontrollert nettadresse som skrives til taggen, etterfulgt av endringer på tjenersiden{1}. I den modellen kan NFC-minnet bli -lesbart mens landingssiden, kampanjeinnholdet, garantiinformasjonen eller produktinformasjonen fortsatt kan redigeres på nettet.

Synteksnettsted NFC tag guidedekker det separate spørsmålet om URL-basert NFC-implementering. Låsevedtaket her begynner etter at destinasjonsarkitekturen er godkjent.

 

Ikke lås en leverandør-eid destinasjon permanent uten en migreringsplan

En permanent lås fryser det som er lagret på brikken, ikke det som skjer på internett. Denne forskjellen er bare nyttig hvis organisasjonen kontrollerer destinasjonen eller har en pålitelig migrasjonsvei.

Før du låser en tag til en URL, må du bekrefte:

• hvem som eier domenet;
• hvem kontrollerer viderekoblinger;
• om destinasjonen kan flytte til en annen plattform senere;
• om nettadressen inneholder en-leverandørspesifikk bane som kan forsvinne;
• om unike tokens per-tag må forbli gyldige for forventet distribusjonstid;
• hva som skjer når en kampanje, ansatt, produktpost eller lokasjon blir pensjonert.

En permanent kode som peker til en engangs SaaS-URL kan bli en permanent fysisk påminnelse om en midlertidig programvarebeslutning. For tagger med lang-levetid bør kontroll av nettadressen behandles som en del av produktspesifikasjonen.

 

 

Låsing bør følge koding og funksjonell godkjenning

En sikker produksjonssekvens skillerskriving, bekreftelseoglåsing.

1. Frys nyttelastregelen.Definer nøyaktig NDEF-posttype, URL-struktur, unike-tokenregel og eventuelle variable data.
2. Kod taggen.Skriv den godkjente nyttelasten ved å bruke den angitte produksjonsprosessen.
3. Les den tilbake elektronisk.Bekreft at den lagrede posten samsvarer med kildedataene.
4. Test brukerresultatet.Trykk på den ferdige taggen med representative måltelefoner eller lesere og bekreft at den tiltenkte handlingen er fullført.
5. Bekreft destinasjonen.Sjekk omdirigeringer, HTTPS-atferd, kontoeierskap og eventuell unik kartlegging.
6. Godkjenn en produksjon-ekvivalent prøve.Prøven skal bruke den endelige brikken, innlegget, materiale, overflatetilstand og kodingsregel.
7. Bruk den godkjente beskyttelsestilstanden.La det være skrivbart, konfigurer passordkontroll eller lås permanent i henhold til prosjektspesifikasjonen.
8. Bekreft innleggets-låsestatus.Les innholdet på nytt og bekreft at den tiltenkte skrivebegrensningen faktisk er i kraft.
9. Registrer resultatet.Behold kravet til kartlegging, prøverevisjon og lås-tilstand sammen med produksjonsposten.

Denne rekkefølgen forhindrer en vanlig feil: oppdage en feil nettadresse, duplikattoken eller feil NDEF-post først etter at taggen allerede er gjort permanent -skrivebeskyttet.

 

 

For unike nettadresser betyr kartfilen like mye som låsetilstanden

En gruppe med NFC-tagger kan inneholde en felles URL, eller hver brikke kan ha en annen token. Unik koding legger til en annen feilmodus: NFC-taggen kan låses riktig, men tilordnes feil fysisk element.

For per-koding kan produksjonsposten trenge felt som:

Låsing fikser ikke en dårlig kartlegging. Den riktige sekvensen er å verifisere tilordningen først, og deretter bruke den irreversible tilstanden.

 

Hva du skal teste etter at en tag er permanent -lest

Sluttkontrollen skal bevise både at innholdet fortsatt fungerer og at den godkjente vernetilstanden eksisterer.

For store bestillinger, definer om hver kodet vare eller en statistisk kontrollert prøve skal kontrolleres på hvert lag. Den prøvetakingsplanen er en kjøper/produsentavtale; den bør ikke erstattes av en vag uttalelse om at taggene er "testet".

 

Permanent låsing løser ikke fysisk tukling

En -skrivebeskyttet NFC-tag kan ikke skrives om gjennom vanlige minneoperasjoner, men en offentlig kode kan fortsatt fjernes, dekkes, erstattes eller fysisk skades.

For offentlige installasjoner, vurder om prosjektet også trenger:

• manipulere-evident konstruksjon;
• periodisk fysisk inspeksjon;
• en trykt QR-reserve;
• et kontrollert aktiva/lokaliseringsregister;
• backend-overvåking for uventede destinasjoner eller tokenbruk;
• en erstatningsprosedyre for skadede eller manglende tagger.

Det fysiske sikkerhetskravet avhenger av miljøet. En anmeldelse-tag for benkeplater, en utendørs eiendeletikett og et -produktgodkjenningsstempel har ikke samme trusselmodell.

 

Passordbeskyttelse er ikke en erstatning for autentisering

Denne forskjellen er viktigst i anti-forfalskningsprosjekter.

En standardkode kan låses permanent slik at minnet ikke kan redigeres, men de synlige eller lesbare dataene kan fortsatt kopieres til en annen kode. En fast UID kan være nyttig som en identifikator, men å stole på en identifikator alene tilsvarer ikke kryptografisk bevis.

Hvis forretningskravet er «hindre uautorisert omskriving», kan låsing eller{0}}passordbasert skrivekontroll være passende. Hvis kravet er "bevis at dette fysiske produktet er ekte", bør prosjektet evaluere en brikke og backend designet for autentisering.

Denne sikkerhetsarkitekturen er med vilje utenfor denne artikkelens omfang. Ikke gjør en lav-offentlig nettadresse-tag til et "anti-forfalskningsprodukt bare ved å endre låsetilstanden.

 

Definer låsetilstand i tilbudsforespørselen, ikke etter produksjon

For direkte innkjøp av telefon-lesbare NFC-tagger og etiketter, Syntek'sNFC-tagkategorier den kommersielle eieren. Hvis prosjektet krever intern-koding og verifisering,NFC-leser- og skribentkategorier den relevante maskinvarebanen.

 

Ombestillinger trenger en lås-tilstandsendring-kontrollregel

En gjentatt ordre bør ikke arve ordet "samme" uten å definere hva som må forbli det samme.

Revalidering bør vurderes når en endring påvirker:

• brikkemodell eller minne/beskyttelsesadferd;
• NDEF-posttype eller URL-struktur;
• vanlig versus unik koding;
• passordkonfigurasjon eller beskyttelsesomfang;
• permanent lås politikk;
• trykt serie- eller QR-kartlegging;
• innlegg, antenne eller ferdig materiale;
• monteringsflate eller tiltenkt telefon/lesersett.

En endring av kosmetisk kunstverk krever kanskje ikke en fullstendig teknisk retest, men en endring som kan endre RF-adferd, datatolkning, kartlegging eller skrivebeskyttelse bør utløse gjennomgang av det berørte laget.

 

Beslutningsregelen

Velg beskyttelsestilstanden fra vedlikeholdsmodellen, ikke fra ordet "sikker".

Hold taggen skrivbarmens utplasseringen fortsatt er under oppstart.Bruk passord-kontrollert tilgangnår autoriserte fremtidige minneoppdateringer er et reelt driftskrav og den valgte brikken støtter den nødvendige oppførselen.Bruk permanent -leselåsnår den kodede nyttelasten er endelig og ikke skal skrives om.Bruk kryptografisk autentiseringnår virksomheten må bekrefte ektheten i stedet for bare å forhindre vanlige redigeringer.

For bulkproduksjon er den sikreste sekvensen:

definer nyttelast → kode → les tilbake → testdestinasjon → verifiser kartlegging → godkjenne ferdig prøve → bruk beskyttelse → verifiser beskyttelse → frigjør batch

Den sekvensen hindrer en irreversibel lås fra å bli en irreversibel produksjonsfeil.