Come proteggere i tag RAIN RFID nelle applicazioni retail?

Il rischio che accada è naturalmente relativamente basso, ma l’impatto sarebbe disastroso. La ricezione degli articoli nel centro di distribuzione fallirebbe a causa dell’elevato numero di “articoli mancanti”, i conteggi dell’inventario in negozio sarebbero imprecisi e il pagamento rallenterebbe per il ritorno ai codici a barre. Prevenire questo scenario è quindi fondamentale e gli standard RFID (GS1 EPC Gen2v2) prevedono funzionalità per farlo. Esistono diversi meccanismi per impedire modifiche ai tag RFID programmati.

Rendere impossibile qualsiasi modifica ai tag RFID, però, entra in conflitto diretto con le esigenze di privacy dei consumatori: poter disattivare definitivamente un tag o, in modo meno drastico, ridurne la distanza di lettura o nasconderne il numero univoco sono funzionalità fondamentali. Occorre quindi trovare il giusto equilibrio tra sicurezza e privacy.

In questo articolo esaminiamo le funzionalità di sicurezza e privacy di RAIN RFID e le buone pratiche per utilizzarle.

Meccanismi di sicurezza: blocco e password

Esistono due meccanismi strettamente collegati per proteggere i tag:

1. Password: per eseguire determinate azioni è necessaria una password
2. Blocco: definisce cosa è possibile fare con e senza password

I tag RAIN RFID hanno due password:

1. Password di accesso: utilizzata per consentire o impedire la lettura e la scrittura di specifiche aree di memoria del chip
2. Password Kill: utilizzata per consentire o impedire la disattivazione definitiva del chip

Non tutti i chip dispongono di password, poiché lo standard non le rende obbligatorie. Per esempio, Impinj Monza R6 non ha password di accesso né Kill: il chip non può quindi essere disattivato definitivamente con il comando Kill né protetto da password per la scrittura. Monza R6-P e R6-A, invece, dispongono di entrambe le password. Il comando Lock è obbligatorio nello standard.

Con il comando “Lock” puoi definire il comportamento del chip rispetto alle password. Scrivere le password, da solo, non produce alcun effetto: devono essere attivate tramite il blocco dei tag.

Il comando Lock consente quattro configurazioni:

1. Puoi scrivere nella memoria anche senza password di accesso
2. Puoi scrivere nella memoria fornendo la password di accesso
3. Non puoi più scrivere nella memoria, nemmeno disponendo della password di accesso
4. Puoi sempre scrivere nella memoria e non puoi più modificare questa impostazione né proteggerla con una password

La configurazione può essere definita per ogni area di memoria: memoria EPC, che contiene le informazioni di prodotto e il numero di serie, password Kill, password di accesso e così via. Quando una password è protetta in scrittura, è protetta anche in lettura: altrimenti chiunque potrebbe recuperarla facilmente. La memoria EPC non può essere protetta dalla lettura tramite password e blocco.

Quando la password è composta interamente da zeri, non è possibile disattivare definitivamente il tag. Prima di poter utilizzare il comando Kill, occorre quindi scrivere una password Kill che non sia composta soltanto da zeri.

La configurazione del blocco e le password vengono generalmente scritte durante la codifica dei tag.

Meccanismi di privacy: riduzione della distanza di lettura e occultamento di parte dell’EPC

La funzionalità di privacy più semplice dei tag RFID è il comando “Kill”. Una volta eseguito, il tag non funzionerà mai più. È ideale per la privacy dei consumatori, ma rende difficile abilitare processi come la gestione automatizzata dei resi e richiede l’applicazione di un nuovo tag quando il prodotto viene restituito.

Per superare questo limite sono stati introdotti due meccanismi di privacy più sofisticati:

1. Riduzione della distanza di lettura: modifica dinamicamente la portata, limitandola a pochi centimetri anziché a qualche metro
2. Occultamento della parte dell’EPC sensibile per la privacy: rende illeggibili l’identificativo del prodotto e/o il numero di serie

Entrambi i meccanismi sono protetti dalla password di accesso.

Queste funzionalità di privacy sono attualmente disponibili soltanto sui chip NXP UCODE 8/8m, ma si prevede che altri produttori di chip seguiranno presto.

Quindi, se per la sicurezza sarebbe sufficiente impedire qualsiasi modifica al chip bloccando permanentemente tutte le memorie e le password, questo disabiliterebbe in modo permanente anche tutte le funzionalità di privacy: una situazione decisamente indesiderata. L’uso delle password è dunque la strada da seguire.

Gestione delle password

La sfida è naturalmente come gestire le password. L’approccio più semplice sarebbe usare la stessa password per tutti i tag di un’organizzazione. Ma, se la password viene divulgata, tutti i tag diventano vulnerabili.

Anche senza una divulgazione, è possibile recuperare la password con un attacco “a forza bruta”, cioè provando tutte le password. Supponendo che un singolo lettore impieghi circa 5 millisecondi per ogni tentativo e sapendo che le possibilità sono 2 elevato a 32, ossia 4.294.967.296, si può calcolare che servono al massimo 248 giorni per “indovinare” la password. In media sarebbero 124 giorni. Inoltre, poiché i tag costano poco e sono facilmente reperibili, è possibile utilizzare più lettori in parallelo per tentare di recuperarne le password. Con un po’ di impegno, una password può essere recuperata nel giro di giorni.

Per aumentare notevolmente la sicurezza, serve una soluzione in cui ogni tag abbia una password diversa, così che la compromissione di una non abbia conseguenze sugli altri tag. Tuttavia, assegnare una password a ogni tag e memorizzarla in un database non sarebbe molto scalabile: richiederebbe una comunicazione di andata e ritorno tra client e server ogni volta che si vuole disattivare definitivamente un tag o attivare una funzionalità di privacy.

Fortunatamente, questo problema è già stato risolto molte volte in situazioni simili. Una funzione hash crittografica unidirezionale permette di calcolare una password a partire dal valore dell’EPC e da un segreto, cioè un’altra password univoca per ciascun brand. Una funzione hash unidirezionale funziona in modo tale che:

1. Se hai l’EPC e il segreto, puoi calcolare la password.
2. Se hai la password e l’EPC, non puoi calcolare il segreto.

Questo significa che, anche recuperando una o più password con un attacco a forza bruta, non puoi ricavare quelle degli altri tag. Significa inoltre che serve un solo segreto per brand, distribuibile in modo sicuro, senza bisogno di un database di password. È un meccanismo molto scalabile, sicuro e affidabile.

Estendere la soluzione ai retailer multibrand

Questa soluzione funziona bene per un retailer monobrand, ma diventa più complessa per chi vende prodotti di origini diverse. I retailer multibrand non possono imporre ai brand la propria strategia di gestione delle password, perché sarebbe impossibile implementarla nella supply chain.

Proponiamo che ogni brand implementi la gestione delle password come descritto sopra e distribuisca le chiavi di sicurezza ai retailer che vendono i suoi prodotti. Ogni prefisso aziendale GS1 (GS1 Company Prefix), o serie di prefissi, avrebbe un proprio segreto. Quando un retailer vuole attivare una funzionalità di privacy su un EPC, ne ricava il Company Prefix e lo usa per ottenere il segreto corretto, con cui generare la password necessaria.

Questa soluzione combina i vantaggi di password univoche per ogni tag con la semplicità di implementazione per brand e retailer.

Il rischio evidente riguarda la gestione delle chiavi dei brand: se un retailer divulga accidentalmente la chiave di uno o più brand, il problema si ripresenta. Occorre seguire le buone pratiche del settore per la distribuzione delle chiavi.

Se un brand non vuole condividere il segreto con i retailer, può comunque offrire un servizio API al quale il retailer invia un EPC per ottenere la relativa password. Questo richiede naturalmente connettività, ma è il modo più sicuro di procedere.

Conclusione: serve una standardizzazione

In sintesi, configurando correttamente i parametri di blocco del chip e impostando le password, è possibile proteggere i chip RFID da modifiche non autorizzate in modo scalabile, tutelando al contempo la privacy dei consumatori. Tutto questo è naturalmente integrato per impostazione predefinita nella soluzione Nedap iD Cloud.

Poiché questa soluzione funziona soltanto se tutti utilizzano questi metodi, raccomandiamo vivamente al settore di standardizzare l’approccio, affinché tutti i retailer e i consumatori possano beneficiare di un’implementazione di RAIN RFID sicura e attenta alla privacy.