Post tecnico
Sviluppare per EMV, Parte II
Nella Parte I di questo articolo, abbiamo esaminato le transazioni EMV e la loro struttura. Abbiamo visto che:
- A differenza delle transazioni MSR (banda magnetica), una transazione EMV si svolge in più fasi.
- La maggior parte dello scambio di dati tra la carta chip e il lettore avviene a livello di kernel , al di fuori del controllo della logica applicativa.
- I risultati della transazione vengono restituiti sotto forma di TLV ("tag").
- Una crittogramma (un dato univoco di 8 byte prodotto dalla carta tramite una chiave privata nota solo alla carta stessa) viene generato prima della fase di Completamento della transazione; un secondo crittogramma viene prodotto dopo la chiamata per completare la transazione.
- Il crittogramma viene restituito dalla carta nel tag 9F26 (un tag definito da EMVCo, non un tag proprietario ID TECH).
In genere, il primo crittogramma (insieme a qualsiasi altro dato TLV richiesto dal processore back-end) viene inviato al processore in tempo reale, tramite rete, per ottenere un codice di autorizzazione (nel tag 89), prima di avviare la fase di Completamento. È responsabilità dell'utente eseguire la richiesta di autorizzazione online (poiché né il lettore né il nostro SDK gestiscono questa parte), utilizzando le API web del proprio gateway. La maggior parte dei gateway dispone di propri SDK per semplificare questa operazione.
Il gateway (o "processore back-end") risponderà alla richiesta di autorizzazione con i tag 89, 8A, 91 e (facoltativamente) 71 o 72. Per completare la transazione, questi TLV dovranno essere passati al metodo emv_completeTransaction() dell'Universal SDK. Il codice riceverà notifica dei risultati tramite una callback. Nella callback sarà disponibile un riferimento ai dati della transazione, che includerà un insieme di TLV. Tra questi sarà presente il secondo e ultimo crittogramma (citato in precedenza), che — ancora una volta — si troverà nel tag 9F26.
Tipi di crittogrammi
Il crittogramma restituito nel tag 9F26 è opaco: non è possibile determinarne il tipo ispezionandolo direttamente. Tuttavia, è possibile analizzare il tag 9F27 (anch'esso restituito insieme a 9F26) per identificare il tipo di crittogramma ricevuto. Il nibble superiore di 9F27 contiene le informazioni necessarie. I bit possono essere interpretati come segue (informazioni tratte da EMV Book 3):
In linea generale, 9F27 avrà un valore (esadecimale) di 80, 40 o 00, che corrisponde rispettivamente ad ARQC, TC o AAC. Questi valori indicano, nell'ordine: "procedere online", "approvato" o "rifiutato".
È importante comprendere che questi valori rappresentano esclusivamente la raccomandazione. Non sempre questo consiglio è vincolante. Ad esempio, la carta è obbligata a restituire un AAC nel secondo crittogramma (in fase di Completamento) se il crittogramma originale era un ARQC, ma l'applicazione di pagamento non era in grado di andare online. L'AAC, in questo caso, non significa automaticamente che la transazione venga rifiutata; tale decisione spetta all'autorità online (in ultima istanza, l'emittente). Nello scenario EMV speciale noto come Quick Chip (o Faster EMV), si otterrà sempre un AAC, poiché la richiesta online avviene in un momento successivo. Non è un problema! È comunque possibile inviare la transazione per il regolamento. Il consiglio della carta è semplicemente raccomandazione. La decisione finale spetta all'autorità online.
Si noti che negli Stati Uniti (considerato un mercato esclusivamente online), nel primo crittogramma si otterrà quasi sempre un ARQC. Un'eccezione si verifica quando la carta è scaduta o sussiste un altro motivo per cui la transazione deve essere rifiutata in modo definitivo; in tal caso, è possibile (teoricamente) ricevere un AAC dopo la prima richiesta "Gen AC".
Acquisizione dei dati TLV
Nell'Universal SDK, che si occupa di gestire la comunicazione con il lettore ID TECH tramite USB, RS-232, Bluetooth, jack audio o Ethernet (a seconda del tipo di lettore), tutte le comunicazioni relative alle transazioni da e verso il lettore sono asincrone. Ciò significa che è necessario registrare una o più routine di callback personalizzate nell'SDK per "ricevere risposta" dal lettore. Le istruzioni per eseguire questa operazione sono fornite non solo nella documentazione dell'SDK, ma anche nel codice di esempio incluso con l'SDK. L'utilizzo dei callback non ha nulla di misterioso. Si consiglia di dedicare del tempo allo studio del codice di esempio dell'SDK per comprendere il flusso operativo.
L'aspetto fondamentale da tenere a mente è che una transazione EMV si svolge per fasi, e al termine di ciascuna fase vengono restituiti TLV diversi. Un'idea errata molto comune è che tutti i tag di interesse vengano forniti in una sola volta, al termine della fase di Completamento. Non è così. Sarà necessario raccogliere i TLV in ogni fase.
Quali tag ci si può aspettare in ogni fase? Ecco i tag più comuni, suddivisi per fase della transazione:
Avvio transazione:
4F
50
57
5A
5F20
5F24
5F25
5F2D
5F34
84
9F20
DFEE12
DFEE23
Autentica Transazione:
95
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
Transazione Completa:
95
99
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
9F5B
Quasi tutti questi sono tag standard definiti dal settore da EMVCo. Quelli che iniziano con 'DF' sono tag proprietari di ID TECH. Per un elenco completo dei tag proprietari di ID TECH e dei relativi significati, fare riferimento al documento 80000503-001, ID TECH TLV Tag Reference Guide, disponibile per il download nella nostra Knowledge Base.
Il tag di cui ha bisogno non è presente? Nessun problema. È possibile utilizzare l'Universal SDK per richiedere tag aggiuntivi al momento della transazione. I dettagli relativi a questa procedura sono descritti non solo nella documentazione SDK, ma anche nel nostro white paper su EMV Transactions with the Universal SDK.
Quali Tag Sono Crittografati?
Se il lettore è stato configurato con l'iniezione delle chiavi e la crittografia è attiva, i tag contenenti dati sensibili avranno il loro contenuto crittografato. Ciò include ovviamente qualsiasi tag contenente dati di traccia (ad es. tag 57) o dati PAN (5A). Per l'elenco completo dei tag crittografati, consultare documento 80000502-001-F, ID TECH Encrypted Data Output. Se stai utilizzando un'unità demo (iniettata con una chiave demo), puoi decifrare i dati manualmente usando il nostro strumento online. In generale, però, non dovresti mai avere la necessità di decifrare i dati autonomamente nel codice in produzione , poiché trasferirai i dati direttamente al tuo processore.
La crittografia è un argomento ampio. Non lo approfondiremo ulteriormente in questa sede, ma se sei curioso di saperne di più, ti invitiamo a consultare i nostri articoli precedenti sull'argomento.
Hai domande?
A questo punto, probabilmente hai molte domande. Non preoccuparti! Abbiamo una vasta gamma di risorse gratuite disponibili sul nostro Knowledge Base, e se hai ancora domande, i nostri tecnici sono a portata di telefono.