Post tecnico
Sviluppare per EMV, Parte I
ID TECH produce e commercializza un'ampia gamma di dispositivi di pagamento, quasi tutti compatibili, oggi, con le "carte chip" (o "carte intelligenti"). I pagamenti effettuati con una carta chip sono genericamente definiti "EMV a contatto", o talvolta semplicemente "EMV". (EMV, naturalmente, è l'acronimo di Europay, Mastercard e Visa, il consorzio dei circuiti di pagamento.)
In termini di settore, una transazione EMV è quella conforme ai requisiti dei quattro volumi delle EMV Integrated Circuit Card Specifications for Payment Systems (disponibili su https://www.emvco.com/). Assimilare questa specifica richiede tempo. Con i suoi quattro volumi, si tratta di un documento piuttosto esteso. Tuttavia, ID TECH si impegna a rendere la "compatibilità EMV" un obiettivo facilmente raggiungibile per gli sviluppatori, offrendo una serie di strumenti gratuiti, SDK, demo e altre risorse pensate per accelerare il time-to-market degli integratori POS e di chiunque abbia bisogno di soluzioni rapide. conformità EMV.
EMV: da dove cominciare?
La maggior parte dei nuovi clienti di ID TECH ha una buona preparazione tecnica. Eppure, il livello di conoscenza dell'EMV con cui i clienti si avvicinano a un nuovo progetto varia notevolmente. La maggior parte conosce molto bene i sistemi di pagamento nel contesto degli MSR (lettori di banda magnetica). Alcuni hanno già lavorato con l'EMV, ma non con l'EMV contactless . Altri, invece, sono del tutto nuovi all'EMV.
Come punto di riferimento, consigliamo solitamente agli integratori di consultare il white paper gratuito di ID TECH intitolato EMV Transactions with the Universal SDK. La prima metà di questo white paper di 25 pagine offre un ripasso sul flusso degli eventi EMV. Le fasi principali di tale flusso possono essere riassunte come segue:
In ogni fase di questo processo, il lettore di carte comunica con il chip della smart card utilizzando protocolli di basso livello definiti nello standard ISO-7816. Quasi tutta la logica del lettore di carte a questo riguardo è racchiusa in quello che viene definito un EMV Level 2 kernel. In altre parole, è al di fuori della portata dello sviluppatore dell'applicazione di pagamento, che deve preoccuparsi soltanto di inviare comandi al kernel (e non alla carta stessa). Anche questa è una semplificazione. Lo sviluppatore dell'applicazione di pagamento invierà in realtà i comandi al reader; e il reader gestirà le interazioni sottostanti necessarie con il kernel, che a sua volta interagirà con la carta.
Comunicare con il Reader
Come si inviano i comandi al reader? Esistono due opzioni:
- Stabilire la connettività (tipicamente tramite USB o RS-232) con il lettore e inviargli direttamente i comandi firmware. Oppure:
- Utilizzando un SDK in linguaggio di alto livello, scrivere codice (in C/C++, C#, Objective-C, Java o Swift) che si avvale della libreria SDK appropriata di ID TECH per eseguire i comandi firmware sottostanti.
Il secondo metodo è generalmente più semplice, poiché richiede tempi relativamente brevi per padroneggiare le API in linguaggio di alto livello dell'Universal SDK di ID TECH (inoltre, mettiamo a disposizione numerosi esempi di codice su cui basarsi). Lo svantaggio del metodo n. 2 è che tende a vincolare l'applicazione a un unico linguaggio di sviluppo e sistema operativo. Con il metodo n. 1, la scelta del linguaggio (e del sistema operativo) è lasciata all'utente, ma è necessario conoscere l'API dei comandi firmware a livello di byte per il dispositivo in questione e gestire autonomamente tutti i problemi di connettività. svantaggio del metodo n. 2 è che tende a vincolare l'applicazione a un unico linguaggio di sviluppo e sistema operativo. Con il metodo n. 1, la scelta del linguaggio (e del sistema operativo) è lasciata all'utente, ma è necessario conoscere l'API dei comandi firmware a livello di byte per il dispositivo in questione e gestire autonomamente tutti i problemi di connettività.
Indipendentemente dalla scelta di comunicare direttamente con il lettore di carte (tramite connessione seriale, utilizzando comandi firmware grezzi) o tramite la connettività integrata e i comandi di alto livello dell'Universal SDK, è importante comprendere che una transazione EMV — e qui si fa riferimento al tradizionale EMV con contatto contatto , non contactless — si svolge in tre fasi. Nel linguaggio dell'Universal SDK, queste fasi vengono denominate Start Transaction, Authenticate Transaction e Complete Transaction (ciascuna con un metodo o una funzione corrispondente nell'USDK). Dal punto di vista del flusso del programma, ciò significa che il kernel restituisce il controllo al chiamante due volte durante il flusso della transazione: una prima volta dopo il ritorno di Start Transaction, e una seconda volta dopo Authenticate Transaction (ma prima di Complete Transaction). Questi punti di interruzione hanno implicazioni importanti per il flusso dei dati: in particolare, i TLV (triplette tag-lunghezza-valore) restituiti al termine di ciascuna fase sono diversi, ed è fondamentale acquisire i TLV necessari nel momento in cui sono disponibili, poiché potrebbero non esserlo in una fase successiva. Esempio tipico: il Tag 57 (dati della Traccia 2) è disponibile al termine di Start Transaction, ma non al termine di Complete Transaction.
Crittogrammi in EMV
Uno degli elementi di dati più importanti in qualsiasi transazione EMV è l'Application Cryptogram restituito nel tag 9F26. Una sessione EMV con contatto produce tipicamente due crittogrammi (il tag 9F26 viene restituito due volte): uno prima di Complete Transaction e l'altro dopo. L'evento che induce la carta a generare il crittogramma è denominato richiesta Gen AC (Generate Application Cryptogram).
Il motivo per cui questi crittogrammi sono importanti risiede nel fatto che costituiscono la prova inconfutabile che una carta chip autentica e legittima era fisicamente presente durante una determinata transazione. (Certificano inoltre i valori specifici dei dati generati nel corso di quella transazione.) Al momento del Gen AC, il kernel L2 presenta alla carta chip un elenco di oggetti dati (contenente dati specifici alla transazione in corso), e la carta chip risponde utilizzando la propria chiave privata (nota esclusivamente al chip) per firmare quei dati e produrre un artefatto digitale non falsificabile (un crittogramma di 8 byte) che attesta la legittimità della carta e dei dati. La validità del crittogramma può essere verificata dall'autorità online che autorizzerà (o declinerà, a seconda dei casi) la transazione. È per questo che sono state inventate le carte chip e che esiste EMV. I dati della MagStripe sono facilmente falsificabili. I crittogrammi generati su richiesta da un chip, invece, non lo sono.
Nel prossimo articolo continueremo questa discussione esaminando le tipologie di crittogrammi che la carta può produrre, il loro significato, le azioni che lo sviluppatore dell'applicazione di pagamento deve intraprendere e il loro impatto sul successo o sull'esito negativo di una transazione. Non perdere la Parte II!
Hai domande sulle transazioni EMV? Sui lettori di carte? Sulla tecnologia contactless? Sui portafogli digitali? Contatta i nostri esperti: