Best practice per carte fedeltà (codice a barre e NFC)

2

Attualmente sto cercando di determinare il modo migliore per progettare un sistema che integri sia i codici a barre che i passaggi NFC.

I codici a barre verranno visualizzati sullo schermo del telefono. Il codice a barre (2D, Aztec, come meglio per le schermate dei telefoni) conterrà un numero di 16 cifre che sarà effettivamente un "pass ID", quando si interrogano il database è possibile vedere il nome del titolare, il saldo ecc. Quando questo codice a barre viene scansionato, il il commerciante sarà in grado di vedere un'immagine del titolare dell'account associata al codice a barre per convalidare che sono il proprietario. Questi dati sono ottenuti da un database offline (aggiornato ogni 5 minuti) contenente informazioni su ciascun passaggio. Potremmo cambiare il numero di 16 cifre dopo ogni transazione, ma poiché vogliamo che le schede NFC facciano riferimento allo stesso saldo, non l'abbiamo fatto.

Le carte NFC sono un nuovo territorio per me. Ho familiarità con gli "hack" comuni usati nelle carte classiche di Mifare, quindi utilizzeremo almeno le carte Mifare Plus. Per quanto mi riguarda, la scheda NFC deve semplicemente informare il lettore NFC del suo numero di 16 cifre nello stesso modo in cui lo fa il codice a barre in modo che il saldo prepagato possa essere aggiornato.

La preoccupazione che ho con le schede NFC è che il contenuto può essere clonato / modificato, il che è molto più semplice di quello che sarebbe stato fare con il codice a barre (ricorda che è su uno schermo del telefono, non fisico). Per imbrogliare con il codice a barre, devi fare uno sforzo per ottenere un'immagine visiva del pass di qualcun altro, e anche se ciò accade, possiamo semplicemente aggiungere la pass ID e rimborsare il proprietario originale su una nuova passata. Con NFC potrei semplicemente passare il mio telefono su qualcuno che passa, vedere il loro pass ID, aggiornare il mio pass ID e voilà, sto usando il loro saldo.

Quindi, in conclusione, penso che quello che chiedo sia un'opinione di professionisti sul fatto che io stia pensando lungo le linee giuste. Apprezzo che non posso semplicemente archiviare un pass ID in chiaro nella scheda NFC e non mi aspetto problemi. Capisco che ci deve essere una forma di crittografia o un modo per prevenire la clonazione / modifica lì. Vorrei solo sapere se il concetto che ho fornito sembra saggio da un'ampia panoramica.

Per essere chiari, le schede NFC sarebbero facoltative per coloro che non possono visualizzare un codice a barre sul proprio smartphone (ad esempio, gli anziani, come una tessera per autobus), a differenza dei clienti che hanno entrambi (che potrebbero teoricamente, ma non ottenere alcun vantaggio).

    
posta jskidd3 26.07.2016 - 02:10
fonte

4 risposte

3

Le schede NFC possono autenticare il lettore. Mifare Plus (e anche Classic, ma sono guasti) possono implementare ACL sui settori in modo che sia necessario presentare una chiave per leggere / scrivere un settore. Puoi avere due chiavi diverse per settore, chiamate chiave A e chiave B, e un bitfield controlla quale chiave può fare cosa e se è consentito l'accesso non autenticato.

I credo Mifare DESFire può anche fare crittografia sulla carta stessa, quindi non solo il livello di trasporto viene crittografato e il lettore autenticato, la carta dimostra semplicemente di avere la chiave segreta dell'utente senza mai rivelarla , dove come Plus e Classic stanno facendo solo l'autenticazione ma poi si comportano come dispositivi di memorizzazione stupidi. Non citarmi su questo però, controlla i fogli dati per te.

Quindi, se usi Mifare Plus, consiglierei di impostare una chiave per i settori che contengono i dati sensibili, quindi inserire un ID utente, un nonce e un MAC. Il MAC dovrebbe essere aggiornato ogni volta che la carta viene usata in modo che anche se qualcuno riesce a copiare una carta, non sarà in grado di usarla se la carta legittima è stata usata nel frattempo perché il nonce sarebbe già stato usato, e non possono crearne un altro perché il MAC non sarebbe più valido.

Per i codici QR, mai usa un codice statico con solo l'ID dell'utente. Richiede che l'app mobile abbia una connessione al server, quindi quando viene utilizzata l'app deve richiedere un nuovo token dal server e visualizzare solo quel token. Sarà solo una volta e avrà una durata limitata. Questo è simile all'approccio basato sulla carta sopra, eccetto per il fatto che il telefono e la macchina POS non comunicano, non c'è modo di aggiornare il nonce e il MAC, quindi è meglio che il telefono ne richieda uno nuovo ogni volta. L'unica volta che sarebbe accettabile utilizzare un ID statico è se hai bisogno di un altro metodo di autenticazione per utilizzare effettivamente i fondi della carta.

È possibile mantenere due tipi di token, uno per la scheda NFC e uno per il telefono. Quello NFC sarebbe statico (ID utente) ma protetto da un nonce e MAC, mentre quello del telefono è dinamico. L'utilizzo di entrambi i tipi non dovrebbe influire sull'altro. Inoltre, la carta non ha nemmeno bisogno di essere a conoscenza del suo equilibrio poiché questo è mantenuto sul server comunque. Conservare l'equilibrio sulla carta sarebbe un rischio inutile, non importa quanto sia buona la crittografia (ricorda quando la gente pensava che Mifare Classic fosse al sicuro? Immagina il disastro se avessi il saldo sulla carta e qualcuno ha trovato il modo di aggiungerne qualche centinaio equilibrio ...)

Se decidi di seguire la rotta DESFire e può effettivamente fare crypto su scheda, è sufficiente memorizzare l'ID utente e una chiave privata sulla scheda. Sul server mantieni la chiave pubblica, e ogni volta che la carta viene utilizzata il lettore dovrebbe chiedere alla carta di firmare una sfida casuale con la sua chiave, e il server può quindi verificare se la firma è valida. Poiché la chiave non viene mai trasmessa ed è praticamente impossibile estrarla, questo approccio è sicuro. È simile a come funzionano le carte di credito. Puoi anche accoppiare questo approccio con la carta di autenticazione del lettore prima di parlarne, proprio come faresti con il Plus impostando le corrispondenti chiavi di settore e bit ACL.

Finalmente puoi ruotare periodicamente le chiavi di settore, su ogni transazione il lettore prova ogni tasto usato negli ultimi X mesi (la durata della carta), e una volta effettuato l'accesso aggiorna la chiave della carta all'ultima. Ciò impedirebbe a un dipendente canaglia di aver estratto la chiave dal software POS di copiare le carte, anche se il nonce + MAC molto probabilmente lo sconfiggerebbe comunque, ma un altro livello di sicurezza è sempre buono. La rotazione delle chiavi dovrebbe essere fatta regolarmente, ma il numero totale di chiavi utilizzabili deve rimanere ragionevole - questo dovrebbe essere calcolato sulla base della durata massima di una carta e del ritardo accettabile della transazione. Ad esempio, se la durata è un anno e ruoterai le chiavi ogni mese, lo scenario peggiore sarebbe che il lettore debba provare gli ultimi 12 tasti, il che richiederebbe circa un secondo. Regola i valori in base alle tue esigenze.

    
risposta data 26.07.2016 - 03:03
fonte
2

Temo di non avere familiarità con NFC, ma ho qualche suggerimento riguardo il codice a barre mostrato sullo schermo del telefono.

È possibile utilizzare una semplice operazione di crittografia per proteggere il codice a barre prima che venga presentato. Potrebbe anche essere possibile che lo stesso scambio di dati sia presentato anche in formato NFC.

Il problema principale che vedo con il tuo suggerimento originale è che il codice a barre è statico. È come una password che non viene mai modificata. La cosa migliore sarebbe aggiungere una certa protezione contro gli attacchi di replay, in modo che ogni volta che venga utilizzato legittimamente, sarà necessario un nuovo codice a barre prima che possa essere elaborata un'altra transazione.

  1. L'app deve essere precaricata non solo con l'ID membro di 16 caratteri, ma anche con un Salt segreto. Salt deve essere univoco per dispositivo, quindi quando l'app è installata, il dispositivo dovrà essere registrato online una tantum sull'apparecchiatura del server prima che venga restituito un Salt.

  2. Il codice a barre presentato generato offline contiene:

    • L'ID dispositivo.
    • Un contatore, che viene incrementato per ogni nuovo codice a barre.
    • Un valore hash SHA-256 di ID dispositivo + contatore + sale segreto.
      • Puoi troncare il valore hash in modo significativo senza subire un significativo colpo di sicurezza.

Quando il codice a barre viene letto sul terminale, sarà

  • trova l'ID dispositivo
  • confronta il valore del contatore e assicurati che sia superiore al valore dell'ultima transazione utilizzata
  • genera il valore hash per verificare l'autenticità del codice a barre
  • procedere con la transazione utilizzando l'ID membro corrispondente

Se Counter non è un'opzione per te (richiede la sincronizzazione bidirezionale dei terminali), potresti invece usare un valore di data / ora.

In effetti puoi persino usare una combinazione.

C'è una lacuna che è che se un terminale viene rubato, anche il sale per tutti i dispositivi viene rubato. Se si desidera una maggiore sicurezza, è possibile utilizzare una coppia di chiavi pubblica / privata per ciascun dispositivo, quindi hash l'ID membro crittografato utilizzando la chiave privata. Il terminale dovrebbe solo memorizzare la chiave pubblica.

    
risposta data 26.07.2016 - 15:42
fonte
1

(troppo lungo per un commento)

Poiché i codici a barre vengono visualizzati dai telefoni, è possibile visualizzare anche quelli univoci per ogni transazione aggiungendo numeri di sequenza.

In questo modo un codice a barre clonato può essere utilizzato al massimo una volta se la transazione viene controllata online; e per i sistemi offline, fino al prossimo download di dati (che include la sequenza più alta per ogni "scheda").

Per impedire a un utente malintenzionato di generare codici a barre falsi con nuovi numeri di sequenza, sarà necessario crittografare / firmare digitalmente il contenuto del codice a barre, preferibilmente utilizzando una chiave per utente.

Una tecnica simile è utilizzata nel protocollo senza contatto EMV. Potresti trovare molte ispirazioni nelle documentazioni tecniche dei sistemi di pagamento esistenti come questo.

    
risposta data 28.07.2016 - 17:07
fonte
0

Il migliore qui sarebbe utilizzare la protezione della carta Plus in Livello di sicurezza 1. Ciò significa anche che il tuo lettore non ha bisogno di supportare Mifare Plus, tutto può essere fatto in modalità Classica.

Puoi quindi eseguire un'autenticazione reciproca in modo che tu sappia che la carta è autentica. Nota che anche se un truffatore può leggere tutti i dati sulla carta, non può usarli.

Questo significa usare una chiave condivisa sulla carta per fare un'autenticazione al lettore e alla carta. Poiché la chiave non può essere estratta dalla carta, la carta non può essere clonata.

Lo stesso "tipo" di protezione potrebbe essere utilizzato sui codici a barre, incorporando dati segreti nel codice a barre che verrà aggiornato ogni transazione e di volta in volta.

Se si utilizza l'app per eseguire un'autenticazione su un endpoint dell'API per ottenere il BarcodeSecret aggiornato e anche per implementare la protezione Plus sopra, non sarà necessaria una foto del titolare, sarà molto difficile copiare la carta / codice a barre.

    
risposta data 26.07.2016 - 03:11
fonte

Leggi altre domande sui tag