Protezione dell'autenticità delle carte mifare, protezione contro la clonazione

In effetti, non mi mancava nulla, le uniche opzioni sono davvero:

1. condividi la chiave segreta principale dello schema di emissione sull'intera rete POS (un'idea ba-adware)
2. utilizzare un HSM sul lato server per creare le chiavi di sessione per la comunicazione NFC, il che significa che il POS e il server devono scambiare un ciclo di richiesta / risposta dell'API nel mid-swipe affinché il POS possa essere autenticato con la scheda

Apparentemente, Mifare è stato progettato come una soluzione a basso costo ea basso rischio - qualcosa che, se rotto, consentirebbe all'attaccante di ricavarne meno valore rispetto allo sforzo di romperlo, ed è notevolmente sicuro in questo ruolo.

Esistono altre tecnologie (ad es. link ) che ti consentono di fare più sicurezza e amp; flussi di lavoro più robusti e vengono forniti con un cartellino del prezzo per abbinarlo.

EDIT alla fine ho optato per un'API lato server dove

1. il componente server ha accesso alle chiavi della carta tramite HSM e
2. può rispondere alla stringa card-challenge con la stringa challenge-response
3. e nella stessa risposta API invia la chiave di sessione all'appliance
4. la chiave di sessione è a sua volta protetta utilizzando lo stesso tipo di tecnologie che un blocco PIN sarebbe protetto (chiavi di sessione, DUKPT, archiviazione sicura della chiave sull'appliance).

Dove "appliance" è "l'apparecchio che parla alla scheda Mifare". Il risultato finale sembra "abbastanza buono" perché:

1. le singole chiavi master card non sono condivise con le appliance - la maggior parte delle implementazioni dipendono dalla chiave master della carta per essere condivise in qualche modo e questo è un no-go per il mio caso d'uso
2. è necessaria solo una chiamata API all'HSM nel cloud per fare in modo che la comunicazione avvenga - la maggior parte delle altre implementazioni che ho visto fanno il pieno pass-through card <-> HSM che significa 2-4 chiamate al minimo durante il movimento di scorrimento della carta - che è un no-go per il mio caso d'uso
3. nel peggiore dei casi l'attaccante può capire la chiave di sessione dello scambio individuale - e questo se e solo se è riuscito a superare lo stesso tipo di crittografia che protegge i blocchi PIN nel settore PCI

Quindi immagino che questo sia il punto ideale per ciò di cui ho bisogno.

DESfire EV1 è ora considerato sicuro (post-2008) e non può essere clonato. Comprali direttamente da NXP. Le chiavi segrete non possono essere annusate, poiché non lasciano mai la carta. L'UID è irrilevante e impostarlo in modo casuale può confondere anche un attore di media abilità.

Ecco un link al codice per la gestione delle carte DESfire (anche se su un Teensy 3.2, usando il C ++ leggermente semplificato di Arduino)

link: link

estratto: Carte Mifare Desfire EV1 Nel 2009 è arrivata sul mercato la nuova generazione: il Mifare Desfire Carte EV1 che sono state migliorate ancora una volta e fino ad oggi non è noto alcun attacco. Quindi se usi le carte Desfire EV1 non hai bisogno di un portafoglio in acciaio inossidabile. L'acquisto di carte Desfire EV1 è più difficile. Non ci sono così tante offerte e quelle più economiche richiedono l'acquisto di quantità di 50, 100 o anche 500 carte. Ho trovato queste due società che vendono anche piccole quantità: RyscCorp e Smartcard Focus. Puoi anche ordinare da Smartcard America che vendono tramite eBay ma la loro spedizione è molto costosa in altri paesi. Fai attenzione alle offerte contraffatte della Cina su eBay: non vi è alcuna garanzia che i cloni cinesi soddisfino gli stessi criteri di sicurezza delle carte NXP originali. Confronto Mifare Classic < - > Desfire Mifare classico Mifare Desfire EV1 Identificativo unico 4 byte L'UID può sempre essere letto senza crittografia 7 byte L'UID può sempre essere letto senza crittografia in modalità normale, ma richiede la chiave master PICC in modalità ID casuale. Archiviazione EEPROM Su una scheda con 1kB di memoria: 16 settori di 4 blocchi di 16 byte ciascuno (Blocchi e settori hanno dimensioni fisse) Fino a 28 applicazioni di cui ciascuna può contenere fino a 32 file di dimensioni variabili chiavi Ogni settore può essere protetto con due chiavi (chiave A e chiave B) con permessi diversi per chiave Ogni applicazione può essere protetta con un massimo di 14 chiavi diverse con permessi diversi per chiave crittografia Proprietario (Crypto-1, 48 bit) DES (56 bit), 2K3DES (112 bit), 3K3DES (168 bit), AES (128 bit) Sicurezza La crittografia è stata violata nel 2008 Nessun attacco conosciuto oggi Mentre le carte Classic sono completamente statiche, le carte Desfire memorizzano i dati in "file" di dimensioni dinamiche contenuti in "applicazioni". Cos'è un'applicazione? Un'applicazione non è altro che un contenitore per i file. Immagina una carta RFID rilasciata agli studenti di un'università. Con la stessa carta lo studente può mangiare nella mensa e può parcheggiare la sua auto. In questo esempio ci sarebbero due applicazioni indipendenti sulla carta: una domanda di mensa e una di parcheggio. Lo studente può addebitare denaro per il pranzo e per il parcheggio che è memorizzato in un file nell'applicazione corrispondente. Ogni applicazione ha una o più chiavi di crittografia (il chiavi dell'applicazione) che consentono di modificare il valore memorizzato nella rispettiva applicazione. Ogni chiave può avere solo il permesso di lettura, solo il permesso di scrittura o entrambi. Inoltre la carta ha un'altra chiave importante: la chiave master PICC, che è la "chiave divina". La chiave master PICC consente di creare ed eliminare applicazioni, assegnare chiavi a ciascuna applicazione o persino formattare l'intera scheda. Ma è interessante notare che la chiave master PICC NON può accedere ai dati memorizzati nelle applicazioni. Né la mensa né il mazzo di parcheggio conoscono la chiave principale del PICC. Hanno solo accesso alla loro applicazione corrispondente ma non al di fuori di essa.