Roberto Garavaglia
Le nebbie di un novembre appena iniziato sono destinate a diradarsi rapidamente; una (inattesa?) folata di vento sembra aver scosso il clima uggioso di un mese, in cui usualmente si celebra ciò che è stato (e non ciò che sarà): vento di novità.
Google ha annunciato di supportare nella nuova versione del proprio sistema operativo (Android 4.4 KitKat), una funzione che permette di gestire transazioni NFC sicure, tramite l’adozione di HCE (Host Card Emulation), un’architettura aperta su cui è possibile sviluppare soluzioni applicative che emulano una carta di pagamento, senza la necessità di ricorrere ad un Secure Element disponibile sul telefonino.
Con l’HCE è dunque possibile (almeno potenzialmente) affrancarsi dall’operatore di rete mobile (ma anche dal produttore di telefoni cellulari … per par condicio), semplificando la gestione del ciclo di vita di un’applicazione NFC, anche non di pagamento (si pensi ad esempio alle implementazioni in ambito loyalty, couponing e trasporto).
Come è possibile tutto questo? E, soprattutto, quali sono i limiti e le potenzialità di una siffatta soluzione?
Procediamo con ordine.
COME FUNZIONA L’HOST CARD EMULATION
Prima di spiegare come funziona l’HCE, riassumiamo rapidamente quali solo le componenti di base, necessarie per effettuare una transazione NFC in un contesto Mobile Proximity classico:
- NFC Controller
Un componente elettronico che risiede all’interno del cellulare, mediante il quale è possibile comunicare con un altro dispositivo NFC (ad esempio un POS opportunamente equipaggiato per leggere carte contactless); - SECURE ELEMENT (S.E.)
E’ uno spazio fisico sicuro che può essere ricavato all’interno della SIM o del telefonino, piuttosto che in un supporto hardware rimovibile (p.e. un micro-SD Card), nel quale viene ospitata un’applicazione di pagamento (ma anche non di pagamento) tecnicamente chiamata MCPA (Mobile Contactless Payment Application); - TSM
In estrema sintesi, il TSM è il soggetto tecnologico esterno che si occupa del provisioning della MCPA e del suo intero ciclo di vita (ha accesso al Secure Element).
Nel caso di una transazione di pagamento NFC, la MCPA ospitata nel Secure Element è un’applicazione di pagamento EMV compliant, del tutto simile a quella installata all’interno del microchip presente sulle comuni carte di credito/debito.
In uno scenario cosi definito, la transazione di pagamento avviene in modalità Card Present e i valori di MSC (Merchant Service Charge, ossia la fee che viene fatta pagare all’esercente dal proprio Acquirer), sono più contenuti rispetto a quelli che, in condizioni normali, si avrebbero per una transazione di tipo CNP (Card Not Present).
Con l’HCE è possibile emulare una carta di pagamento, permettendo ad un’app installata sul cellulare, di parlare direttamente con l’NFC Controller, evitando il passaggio dal Secure Element fisico.
Se fin qui è tutto chiaro, proviamo ad aggiungere qualche “complessità necessaria”, che ci permetterà di comprendere se ed in che modo, il solo impiego dell’HCE sia tale da riproporre le medesime condizioni a contorno, valide per l’effettuazione di una transazione Card Present.
Una transazione di tipo Card Present (cui sottendono valori di MSC più bassi), si caratterizza per essere supportata da opportuni strumenti di mitigazione del rischio, tali da:
- garantire che il Cardholder (ossia il titolare della carta) sia effettivamente colui che dice di essere. Fra questi strumenti si annoverano le credenziali associate al Cardholder stesso, rilasciate da un soggetto che ne ha previamente verificato l’identità e che è chiamato a concedere un’autorizzazione nel momento in cui viene effettuato il pagamento;
- una sicurezza crittografica applicata all’intera tratta in cui si esegue la transazione di pagamento.
Nel mondo HCE, è pertanto necessario che le medesime condizioni descritte siano riproposte. Ciò si rende possibile (almeno potenzialmente), implementando le seguenti technicalities:
- allocazione del Secure Element all’interno di un Secure Environment, per esempio in un’architettura cloud gestita dalla banca (issuer), acceduto dal telefono nel momento in cui viene eseguito un pagamento NFC (è il riferimento al cloud, che permette di considerare il S.E. smaterializzato);
- messa in sicurezza della tratta che collega il Secure Environment al telefono, mediante autenticazione mutua delle parti e crittografazione dei dati in transito;
- generazione di un token associato alla carta di pagamento contestuale alla transazione NFC.
Soffermiamoci sul terzo punto, a mio personale avviso quello più rilevante e su cui credo sia ancora necessario investire in termini di standardizzazione: il processo di generazione del token.
Appare evidente che la generazione di un token “spendibile” nella transazione di pagamento NFC, deve poter avvenire a posteriori di un processo di autenticazione (“forte”, direbbe la PSD2 …), atto a garantire che il soggetto avviante il pagamento, sia colui il quale è stato in precedenza (ossia in fase di emissione della carta) correttamente identificato.
Tale attività, per la meccanica transazionale descritta, ricade – come è ovvio – nel dominio dell’Issuer, che è dunque responsabile: dell’identificazione del soggetto attuante il pagamento, dell’autenticazione del medesimo, della generazione del token e della trasmissione in sicurezza dello stesso.
QUALI SONO GLI STANDARDS E I PROTOCOLLI DI RIFERIMENTO ADOTTATI DA GOOGLE
Nell’implementazione dell’HCE, Google dichiara che Android 4.4 supporta molti dei protocolli e degli standards adottati dai comuni lettori NFC, nel rispetto dei quali sono attualmente sviluppate applicazioni di pagamento contactless.
In particolare, il nuovo sistema operativo implementa l’emulazione di carta basata sulle specifiche NFC-Forum ISO-DEP (a loro volta basate su ISO/IEC 14443-4) ed è in grado di gestire le Application Protocol Data Units (APDUs) definite dall’ISO/IEC 7816-4.
CHI SONO GLI ALTRI PLAYERS CHE HANNO ADOTTATO L’HCE
Se il colosso di Mountain View è certamente una voce altisonante, non è corretto pensare che l’Host Card Emulation sia un’invenzione targata Google.
Su questa architettura (che, ricordo, non è pensata solo per i pagamenti), sono già state sviluppate altre soluzioni di diversi players.
SymplyTapp, è una startup texana che, nel 2012, inizia a proporre una soluzione “Proximity Transaction as a Service”, che sfrutta le funzionalità dell’HCE. La società di Austin, offre la virtualizzazione del Secure Element in un Trusted Transaction Environment, facilmente integrabile in una piattaforma di issuing adottata da una banca. Il sistema di autenticazione è basato su OAuth, uno standard aperto su cui è stato sviluppato il processo autenticazione e di rilascio delle credenziali.
Nel febbraio del 2013, in Spagna, il gruppo bancario Bankinter, annuncia di aver sviluppato una soluzione di pagamento NFC, che non prevede l’impiego di Secure Element. In collaborazione con Visa Europe e due partner tecnologici (Seglan e Net1, quest’ultimo proponente una soluzione di Mobile Virtual Card), il sistema “di virtualizzazione adottato, usa un’autenticazione a due fattori, è in grado di raggiungere appropriati livelli di sicurezza, compatibili con gli standards EMV e non richiede alcun cambiamento nell’infrastruttura di accettazione” dichiara Carlos Alberto Pérez Lafuente, Director of Innovation di Bankinter.
Nel giugno 2013, Bell ID, società Olandese leader nei sistemi di gestione dei tokens (per smart cards, telefoni NFC, …) operativi su piattaforme single/multi-application, annuncia la propria soluzione “Secure Element in the Cloud” (un nome di per sé esaustivo!).
L’azienda di Rotterdam vanta referenze a livello mondiale e propone una suite di prodotti che, adottando l’Host Card Emulation, permette di smaterializzare il Secure Element nel cloud, consentendo di effettuare pagamenti NFC del tipo Card Present.
Nella configurazione più completa, Bell ID è in grado di affiancare al processo di tokenizzazione la generazione di PAN dinamici, raggiungendo un’ottimale livello di sicurezza e garantendo la possibilità di operare anche in assenza di campo (p.e. quando il telefonino si trova in zone schermate o sotterranee).
INCOGNITE E PERPLESSITÀ DELL’HCE
Concludo non senza prima aver analizzato (nell’economia consentitami dall’articolo), alcuni punti che rappresentano, tuttora, delle incognite, potenzialmente tali da minare lo sviluppo in concreto dell’Host Card Emulation e delle soluzioni di virtualizzazione del Secure Element.
- Reale indipendenza dall’operatore telefonico?
Se è pur vero che, nelle soluzioni descritte, il Secure Element potrebbe non essere più nel dominio dell’operatore di rete, è altrettanto corretto riflettere sulle quantità di sicurezza, gestite e memorizzate localmente (ossia sul cellulare) al fine di consentire l’autenticazione e la crittografazione dei dati fra il Secure Environment remoto e il telefonino stesso. Per tali informazioni è necessario (ri)trovare un “luogo sicuro” idoneo a custodirle. Ciò conduce inevitabilmente a pensare che la SIM, potrebbe candidarsi ad essere nuovamente quell’ospite ideale, suggerendo al tempo stesso una ridefinizione dei modelli di business (nella valutazione dei quali, non sottovaluterei l’aspetto riferibile alla strong authentication ed alla digital signature). - Prestazioni e impatto sulla user experience
Smaterializzare il Secure Element e dislocarlo remotamente rispetto all’NFC Controller, implica inevitabilmente l’introduzione di un ritardo in quelle fasi che, oggi, si realizzano totalmente in locale e – appunto – offline. Ciò significa che è necessario efficientare al miglior livello possibile, il dialogo e la trasmissione fra il cloud ed il cellulare, pena un impoverimento della user experience. - Interazione con i TSM pregressi
Poiché si è più volte affermata l’importanza di considerare l’NFC come un ecosistema, nel quale il pagamento potrebbe non essere che un’istanza, è doveroso richiamare l’attenzione su quei servizi che, allo stato attuale, sono erogati da applicazioni custodite in Secure Element fisici, gestite da TSM pregressi (si pensi ad esempio ai servizi di loyalty o di trasporto pubblico).
In una prospettiva di virtualizzazione del S.E., è necessario integrare i diversi (e pregressi) TSM, laddove si volesse trasferire nel nuovo Secure Element tutte le applicazioni preesistenti, o (alternativa intrigante, lo ammetto …) pensare ad uno scenario multi –S.E./heterogeneous S.E. - Un nuovo schema Card Present?
Tutte le soluzioni presentate (da Simply Tapp sino all’annuncio di Google), propongono un’incognita rilevante: come saranno realmente trattate dai circuiti, le transazioni di pagamento NFC abilitate dall’HCE? I livelli di sicurezza ed i metodi di autenticazione, che si prevedono di raggiungere ed implementare con l’adozione di tale tecnologia , saranno sufficientemente (e realmente) considerati “Card Present alike”?
Come si può notare, siamo forse solo all’alba di un nuovo modo di pensare all’NFC e, recuperando l’incipit dell’articolo, nel clima autunnale che prelude all’inverno, è difficile scorgere il sole all’improvviso.
