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 "smart card"). I pagamenti effettuati con una carta chip sono comunemente definiti "contact EMV", o talvolta semplicemente "EMV". (EMV, naturalmente, è l'acronimo di Europay, MasterCard e Visa, il consorzio dei circuiti di pagamento.)
In termini tecnici 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/). Acquisire piena padronanza di questa specifica richiede tempo. Trattandosi di quattro volumi, si tratta di uno standard piuttosto articolato. 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 iniziare?
La maggior parte dei nuovi clienti ID TECH ha un buon background tecnico. Tuttavia, il livello di conoscenza dell'EMV che i clienti portano a un nuovo progetto varia considerevolmente. La maggior parte conosce molto bene i sistemi di pagamento nel contesto degli MSR (lettori di banda magnetica). Alcuni hanno già lavorato con EMV, ma non conoscono il pagamento contactless EMV. Altri sono invece del tutto nuovi a 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 riepilogo del flusso degli eventi EMV. I principali eventi di tale flusso possono essere così sintetizzati:
In ciascuna fase di questo processo, il lettore di carte dialoga con il chip della smart card utilizzando alcuni protocolli di basso livello definiti nella norma ISO-7816. Quasi tutta la logica del lettore di carte a questo riguardo è racchiusa in quello che viene denominato kernel EMV Level 2. In altre parole, è fuori dalla portata dello sviluppatore dell'applicazione di pagamento, che deve preoccuparsi soltanto di inviare comandi al kernel (e non alla carta stessa). Anche questa, però, è una semplificazione. Lo sviluppatore dell'applicazione di pagamento invierà di fatto i comandi al lettore; sarà poi il lettore a gestire le interazioni sottostanti necessarie con il kernel, che a sua volta interagirà con la carta.
Comunicazione con il lettore
Come si inviano i comandi al lettore? Esistono due opzioni:
- Stabilire una connessione (tipicamente tramite USB o RS-232) con il lettore e inviare direttamente i comandi firmware. Oppure:
- Utilizzando un SDK in linguaggio ad alto livello, scrivere codice (in C/C++, C#, Objective-C, Java o Swift) che si avvale della libreria SDK appropriata di ID TECH per emettere i comandi firmware sottostanti.
Il secondo metodo è generalmente più semplice, poiché richiede tempi relativamente brevi per padroneggiare le API in linguaggio ad alto livello dell'Universal SDK di ID TECH (inoltre, mettiamo a disposizione numerosi esempi di codice su cui basarsi). Lo svantaggio 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 mediante la connettività integrata e i comandi ad alto livello dell'Universal SDK, è fondamentale comprendere che una transazione EMV — qui si intende il tradizionale EMV con contatto , non contactless — si svolge in tre fasi. Nella terminologia dell'Universal SDK, queste fasi vengono denominate Start Transaction, Authenticate Transaction e Complete Transaction. (Ciascuna dispone di un metodo o 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: la prima dopo il ritorno di Start Transaction e la seconda dopo Authenticate Transaction (ma prima di Complete Transaction). Questi punti di interruzione hanno implicazioni importanti per il flusso dei dati, poiché, tra l'altro, dopo ogni fase della transazione vengono restituiti TLV (triplette tag-lunghezza-valore) diversi. È quindi fondamentale acquisire i TLV necessari nel momento in cui sono disponibili, in quanto potrebbero non esserlo in una fase successiva. Esempio tipico: il Tag 57 (dati Track 2) è disponibile al termine di Start Transaction, ma non al termine di Complete Transaction.
I crittogrammi in EMV
Uno degli elementi di dati più importanti in qualsiasi transazione EMV è l'Application Cryptogram restituito nel tag 9F26. Una sessione EMV a contatto produce tipicamente due crittogrammi (9F26 viene restituito due volte): uno viene generato prima del completamento della transazione, l'altro dopo. L'evento che induce la carta a produrre il crittogramma è chiamato richiesta Gen AC (Generate Application Cryptogram).
L'importanza di questi crittogrammi risiede nel fatto che costituiscono la prova inconfutabile che una carta a chip autentica e legittima era fisicamente presente durante una determinata transazione. (Attestano inoltre i valori specifici dei dati generati nel corso di quella transazione.) Al momento del Gen AC, il kernel L2 presenta alla carta a chip un elenco di oggetti dati (contenente dati specifici della transazione corrente), e la carta a chip risponde utilizzando la propria chiave privata (nota esclusivamente al chip) per firmare tali 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 rifiuterà, a seconda dei casi) la transazione. È per questo che sono nate le carte a chip e che esiste EMV. I dati su MagStripe sono facili da contraffare. I crittogrammi generati su richiesta da un chip, invece, non lo sono.
Nel prossimo articolo continueremo questa discussione esaminando i tipi di crittogrammi che la carta può produrre, il loro significato, le azioni che lo sviluppatore di applicazioni di pagamento deve intraprendere e il loro impatto sull'esito della transazione. Non perdete la Parte II!
Hai domande sulle transazioni EMV? Sui lettori di carte? Sulla tecnologia contactless? Sui portafogli digitali? Contatta i nostri esperti: