Programma di autenticazione del chip - Chip Authentication Program

Un dispositivo EZIO CAP Gemalto con stile Barclays PINsentry

Il Chip Authentication Program (CAP) è un'iniziativa di MasterCard e specifica tecnica per l'utilizzo di smartcard bancarie EMV per l' autenticazione di utenti e transazioni nel banking online e telefonico. È stato anche adottato da Visa come Dynamic Passcode Authentication (DPA). La specifica CAP definisce un dispositivo portatile ( lettore CAP ) con uno slot per smartcard, un tastierino numerico e un display in grado di visualizzare almeno 12 caratteri (ad esempio, un display a stella ). I clienti bancari a cui è stato emesso un lettore CAP dalla propria banca possono inserire la propria carta EMV ( Chip and PIN ) nel lettore CAP per partecipare a uno dei numerosi protocolli di autenticazione supportati . La CAP è una forma di autenticazione a due fattori, in quanto affinché una transazione abbia esito positivo devono essere presenti sia una smartcard che un PIN valido. Le banche sperano che il sistema ridurrà il rischio che i clienti ignari inseriscano i propri dati in siti Web fraudolenti dopo aver letto le cosiddette e- mail di phishing .

Principio operativo

La specifica CAP supporta diversi metodi di autenticazione. L'utente inserisce prima la propria smartcard nel lettore CAP e lo abilita inserendo il PIN. Viene quindi premuto un pulsante per selezionare il tipo di transazione. La maggior parte dei lettori ha due o tre tipi di transazione disponibili per l'utente con una varietà di nomi. Alcune implementazioni note sono:

Codice / identificazione

Senza richiedere ulteriori input, il lettore CAP interagisce con la smartcard per produrre una password monouso decimale , che può essere utilizzata, ad esempio, per accedere a un sito Web bancario.

Risposta

Questa modalità implementa l' autenticazione challenge-response , in cui il sito Web della banca chiede al cliente di inserire un numero di "challenge" nel lettore CAP, quindi copiare il numero di "risposta" visualizzato dal lettore CAP nel sito web.

Cartello

Questa modalità è un'estensione della precedente, in cui non solo un valore di "sfida" casuale, ma anche dettagli cruciali della transazione come il valore trasferito, la valuta e il numero di conto del destinatario devono essere digitati nel lettore CAP.

I tipi di transazione sopra indicati vengono implementati utilizzando una delle due modalità. Una di queste modalità ha due forme in cui può operare, creando tre modalità distinte, sebbene non siano denominate in questo modo nelle specifiche.

Modalità 1

Questa è la modalità per le normali transazioni monetarie come un acquisto online tramite un commerciante. Un valore di transazione e una valuta sono inclusi nel calcolo del crittogramma. Se la carta non lo richiede o il terminale non lo supporta, sia l'importo che la valuta vengono impostati a zero.

Modalità 2

Questa modalità può essere utile per autenticare un utente in cui non è in corso alcuna transazione, come l'accesso a un sistema bancario Internet. Nessun valore della transazione, valuta o altri dati sono inclusi, rendendo queste risposte molto facili da precalutare o riutilizzare.

Con firma dei dati di transazione (TDS)

Questa modalità può essere utilizzata per transazioni più complicate, come il trasferimento di fondi tra conti. Più campi di dati relativi alla transazione vengono concatenati e quindi sottoposti a hashing con un crittogramma Mode2 come chiave per l'algoritmo di hashing. L'hash risultante viene utilizzato al posto del crittogramma calcolato in un'operazione non TDS Mode2.

Mode1 suona molto come un uso specifico di Mode2 con TDS, ma c'è una differenza fondamentale. Nell'operazione Mode1, i dati di transazione (importo e tipo di valuta) vengono utilizzati nel calcolo del crittogramma oltre a tutti i valori utilizzati in Mode2 senza TDS, mentre Mode2 include i suoi dati di transazione in una fase successiva anziché includerli nella fase di calcolo del crittogramma . Se non fosse per questa differenza, tutte le operazioni potrebbero essere generalizzate come un'unica operazione con dati di transazione opzionali variabili.

Dettagli del protocollo

Un lettore di codici elettronici Nordea

In tutte e tre le modalità, il lettore CAP chiede alla carta EMV di emettere un pacchetto di dati che conferma l'annullamento di una transazione di pagamento EMV fittizia, che coinvolge i dettagli inseriti dall'utente. Questo messaggio di conferma contiene un codice di autenticazione del messaggio (in genere CBC-MAC / Triple DES ) generato con l'aiuto di una chiave segreta specifica della carta memorizzata in modo sicuro nella smartcard. Tali messaggi di annullamento non rappresentano alcun rischio per la sicurezza della normale applicazione di pagamento EMV, ma possono essere verificati crittograficamente e vengono generati da una carta EMV solo dopo aver inserito il PIN corretto. Ha fornito ai progettisti del CAP un modo per creare una forte evidenza crittografica della presenza di una scheda EMV attivata da PIN e ha visto alcuni dati di input, senza dover aggiungere nuove funzioni software alle schede EMV già in uso.

Una smartcard EMV contiene un contatore di transazioni (in genere a 16 bit) che viene incrementato con ogni pagamento o transazione CAP. La risposta visualizzata da un lettore CAP consiste essenzialmente nelle varie parti della risposta della carta (Application Transaction Counter, MAC, ecc.) Che viene quindi ridotta a bit specifici come determinato dal record Issuer Authentication Indicator (IAI) memorizzato nella carta ( questo è impostato in base all'emittente, sebbene se un emittente lo desideri, potrebbe essere impostato casualmente per ciascuna carta purché venga mantenuto un database dell'IAI di ciascuna carta), infine, dopo che i bit indesiderati sono stati scartati (essenzialmente la posizione assoluta dei bit è irrilevante, un bit nell'IAI che è 0 significa che il bit corrispondente nella risposta della scheda verrà eliminato anziché essere semplicemente impostato a 0). Infine il valore viene convertito da binario in un numero decimale e visualizzato all'utente. Di seguito viene fornito un esempio troncato:

1. Il dispositivo CAP seleziona l'applicazione EMV, legge le informazioni IAI dalla scheda e l'utente seleziona un'azione da eseguire (in questo esempio, IAI sarà 111011011000 ₂ ).
2. Dopo aver inserito correttamente il PIN, il dispositivo CAP invia una richiesta di 011100111010 ₂ come transazione ARQC (Authorization Request Cryptogram).
3. La smartcard dà una risposta di 110101110110 ₂ e il dispositivo CAP annulla la transazione falsa.
4. Il dispositivo CAP utilizza la maschera IAI: 111011011000 ₂ per eliminare i bit; quei bit che corrispondono a uno 0 nella maschera vengono eliminati.
5. Quindi la risposta finale è 1100110 ₂ o 102 in decimale.

Il processo del mondo reale è ovviamente un po 'più complesso in quanto la carta può restituire l'ARQC in uno dei due formati (il semplice Response Message Template Format tipo 1 (id. 80 ₁₆ ) o il più complesso Response Message Template Format 2 (id. 77 ₁₆ ) che divide i dati ARQC in valori TLV separati che devono essere riassemblati in sequenza per corrispondere a quelli del formato di tipo 1.

Nella modalità di identificazione, la risposta dipende solo dai bit richiesti dall'IAI poiché l'importo e il numero di riferimento sono impostati su zero; questo significa anche che la selezione di risposta e l'inserimento di un numero di 00000000 genererà di fatto una risposta di identificazione valida. Più preoccupantemente, tuttavia, se una richiesta di risposta viene emessa da una banca, utilizzando la modalità di segno con lo stesso numero e un importo di ¤0,00 genererà nuovamente un risultato valido che crea la possibilità per un truffatore di istruire un cliente a fare un "test "challenge response per un importo di ¤0.00 che verrà infatti utilizzato dal truffatore per verificare un comando di risposta in modo che possa aggiungersi come beneficiario sul conto della vittima; questi attacchi potevano essere effettuati contro banche che utilizzavano dispositivi di autenticazione forte che non annullavano le attività fino a quando non veniva immesso un importo di almeno 0,01. La probabilità di questo tipo di attacchi è stata affrontata nel 2009 quando sono state introdotte nuove generazioni di dispositivi, implementando la funzionalità di separazione sicura dei domini conforme alla nota di applicazione MasterCard datata ottobre 2010. Allo stesso modo, naturalmente; una banca che implementa il comando di identificazione consente a un truffatore di richiedere a una vittima di eseguire una transazione di risposta di "prova" utilizzando 00000000 come riferimento e sarà quindi in grado di accedere con successo all'account della vittima.

Lo stesso contatore di tentativi PIN sulla carta viene utilizzato come in altre transazioni EMV. Quindi, proprio come in un terminale ATM o POS, l'immissione di un PIN errato per tre volte di seguito in un lettore CAP bloccherà la carta.

Incompatibilità

La specifica CAP originale è stata progettata per utilizzare le normali transazioni EMV, in modo tale che l'applicazione CAP potesse essere distribuita senza aggiornare il firmware delle schede EMV esistenti, se necessario. L'implementazione preferita utilizza un'applicazione separata per le transazioni CAP. Le due applicazioni possono condividere determinati dati, come il PIN, mentre altri dati non sono condivisi nei casi in cui è applicabile solo a un'applicazione (ad esempio, i dati di gestione del rischio del terminale per EMV) o vantaggi per avere separati (ad esempio, contatore delle transazioni, quindi che le transazioni EMV e CAP incrementano contatori separati che possono essere verificati in modo più accurato). Il lettore trasporta anche dati specifici di implementazione, alcuni dei quali possono essere sovrascritti da valori nella scheda. Pertanto, i lettori CAP generalmente non sono compatibili con le carte di banche emittenti diverse.

Tuttavia, i lettori di carte emessi dalla maggior parte, forse tutte, le banche del Regno Unito sono conformi a un sottoinsieme CAP definito dall'APACS , il che significa che, nella maggior parte dei casi, le carte emesse da una banca del Regno Unito possono essere utilizzate in un lettore di carte emesso da una banca diversa.

Vulnerabilità

I ricercatori dell'Università di Cambridge Saar Drimer, Steven Murdoch e Ross Anderson hanno condotto una ricerca sull'implementazione della CAP, delineando una serie di vulnerabilità nel protocollo e nella variante britannica sia dei lettori che delle carte. Sono stati riscontrati numerosi punti deboli. I ricercatori della Radboud University hanno scoperto una vulnerabilità nell'ABN AMRO e.dentifier2 olandese , che consente a un utente malintenzionato di comandare a un lettore connesso tramite USB di firmare transazioni dannose senza l'approvazione dell'utente.

Utenti

Svezia

• Nordea ha utilizzato CAP nel novembre 2007. La soluzione Nordea eCode è utilizzata da Nordea sia per l'e-banking, l'eCommerce (3DS) e anche con eID. Il lettore che ha alcune funzionalità più avanzate che estendono la CAP, rende le implementazioni della CAP di Nordea più sicure contro i trojan e gli attacchi man-in-the-middle . Quando viene utilizzato per l'eID, l'utente può presentare la sua "dichiarazione fiscale" online o qualsiasi funzione di e-government implementata. Il dispositivo è inoltre dotato di una porta USB, che consente alla banca di eseguire Sign-What-You-See per l'approvazione di transazioni sensibili.

Regno Unito

Un dispositivo CAP nazionale con una moneta da 20 centesimi da scalare

Un dispositivo Natwest CAP con una moneta da 10p in scala

• La UK Payments Administration ha definito un sottoinsieme di PAC per l'utilizzo da parte delle banche del Regno Unito. Attualmente è utilizzato da:
  • Barclays Bank
  • Ulster Bank
  • NatWest
  • Banca cooperativa e sorriso
  • Royal Bank of Scotland
  • Lloyds Bank
  • A livello nazionale
• I lettori CAP di Barclays, Lloyds Bank, Nationwide, NatWest, Co-operative Bank / Smile e RBS sono tutti compatibili.
• Barclays ha iniziato a rilasciare lettori CAP (chiamati PINsentry ) nel 2007. Il loro sito web di online banking utilizza la modalità di identificazione per la verifica dell'accesso e la modalità di firma per la verifica delle transazioni. La modalità di risposta viene utilizzata come parte della nuova applicazione PingIt Mobile Payment per l'autenticazione dei dettagli dell'account. Il dispositivo è ora utilizzato anche nelle filiali, sostituendo i tradizionali dispositivi a chip e pin per prevenire ulteriormente i tentativi di frode.
• Le carte bancarie emesse da HBOS sono tecnicamente compatibili con il sistema, sebbene HBOS non abbia (ancora) introdotto lettori CAP da utilizzare con il proprio online banking.

Implementazioni software

Esiste un'implementazione software scritta in Python che supporta la Modalità 1, la Modalità 2 e la Modalità 2 con TDS da utilizzare solo per scopi didattici. La funzione di identificazione (senza challenge) corrisponde alla funzione m1 con challenge "00000000".

Si noti che l'utilizzo di questo software per operazioni finanziarie reali può comportare alcuni rischi. In effetti, il vantaggio dell'utilizzo di un lettore autonomo è quello di isolare la carta bancaria dal malware potenzialmente presente sul PC. Usarlo in un lettore non protetto comporta il rischio che un keylogger intercetti il ​​PIN e il malware del punto vendita acceda ai dettagli della carta o addirittura intercetti una transazione per modificarla o eseguire la propria transazione.

Guarda anche

• 3-D Secure

Riferimenti