Mobile payments definizioni sicurezza e contesto normativo dic2010

64
Mobile Payments Definizioni, sicurezza e contesto normativo

Transcript of Mobile payments definizioni sicurezza e contesto normativo dic2010

Mobile Payments Definizioni, sicurezza e contesto normativo

Mobile Payments: una definizione

Con il termine Mobile Payments si intendono tutti quei pagamenti iniziati, confermati e ricevuti attraverso dispositivi mobili.

I Mobile Payments possono essere realizzati attraverso diverse tecnologie,

quali ad esempio Bluetooth, RFID/NFC, SMS, WAP, etc. E’ possibile in prima analisi distinguere due macrocategorie rispetto ai

Mobile Payments: Mobile Remote Payments - pagamenti effettuati a distanza

attraverso la rete cellulare ad es. GSM, UMTS e attivati attraverso canali quali SMS, WAP.

Mobile Proximity Payments - pagamenti effettuati a breve distanza utilizzando tecnologie a corto raggio quali RFID o Bluetooth, avvicinando il telefono a un lettore abilitato.

Remote Payments vs Proximity Payments

La tassonomia delle due macrocategorie individuate rispetto ai sistemi di Mobile Payment può essere ulteriormente dettagliata prendendo in considerazione tre aspetti principali:

Standard. Infrastrutture di mercato. Sicurezza.

I Remote Payments sono nati basandosi su una logica di servizio server-side e utilizzando protocolli di comunicazione nativi del mondo telefonico (SMS, IVR, USSD). Di recente si stanno però sviluppando soluzioni la cui logica di servizio si sposta sul terminale dell’utente, arricchendo la customer experience di quest’ultimo.

I Proximity Payments riguardano principalmente micropagamenti con transazioni offline, la cui logica di funzionamento è concentrata lato terminale (client-side). La rete di accettazione deve essere sviluppata ad hoc seguendo standard internazionali (ISO 18092 – ISO 14443) per quanto riguarda la tratta radio.

Primi cenni sulla sicurezza

Nel caso dei pagamenti di prossimità le transazioni tra terminale mobile e POS avvengono a non più di 10 cm. Gli standard disponibili su questa tratta sono incentrati sulla sola connessione, per cui devono essere le applicazioni stesse a curare la cifratura e la mutua autenticazione tra le due entità.

Nel caso dei pagamenti remoti invece, protocolli di comunicazione quali il

GSM assicurano una cifratura del canale radio “long range”. Al momento sono in fase di definizione le procedure di autenticazione e

cifratura a strati per garantire la separazione dei ruoli nel nuovo modello di servizio (gestore della SIM, gestore del servizio OTA, gestore del servizio di pagamento).

Evoluzioni dei terminali mobili

Le potenzialità insite sia nei Remote che nei Proximity Payments sono enfatizzate dalla tecnologia dei dispositivi mobili, che si sta evolvendo secondo tre linee di sviluppo principali:

La struttura delle USIM. I servizi OTA per la comunicazione remota con il terminale. I menu a navigazione web (Smart Card Web Server)

Le USIM rappresentano il cuore del pagamento mobile in quanto ospitano il Secure Element, cioè il luogo dove vengono mantenuti i codici di autenticazione e sicurezza dell’utente.

La possibilità di comunicare Over-the-Air con il terminale rappresenta la differenza principale tra un’applicazione di pagamento su carta, configurata una volta per tutte al momento della sua emissione, e un’applicazione mobile aggiornabile da remoto. Protocolli di comunicazione come il BIP (Bearer Indipendent Protocol) e il sovrastante CAT_TP (Card Application Toolkit_Transport Protocol) consentono di trasmettere maggiori quantità di dati rispetto al canale SMS, aumentando al contempo velocità ed affidabilità della comunicazione.

Le applicazioni su terminale seguiranno sempre più una logica di navigazione simile a quella del mondo web. Il mercato sembra dunque orientarsi verso soluzioni basate su web server ospitati sulla USIM (es. Smart Card Web Server).

SIM, USIM e UICC

Dal momento che si genera spesso confusione tra i termini SIM, USIM e UICC, occorre innanzitutto distinguere tra supporto fisico e moduli logici di quella che nel linguaggio comune viene chiamata SIM Card:

La UICC (Universal Integrated Circuit Card) è il supporto fisico, cioè la smart card rimovibile ad 8 contatti (simili a quelli delle carte EMV definiti nell’ambito dello standard ISO 7816) che contiene al proprio interno applicazioni e dati riservati, necessari al funzionamento del terminale mobile.

La SIM (Subscriber Identity Module) rappresenta uno dei moduli logici presenti all’interno della UICC. La SIM è gestita dal Mobile Network Operator (MNO) e contiene informazioni personali dell’utente come il numero telefonico (MSISDN) e la rubrica.

La USIM (Universal Subscriber Identity Module) rappresenta un’evoluzione della SIM (utilizzata nel sistema GSM) per i telefoni cellulari di Terza Generazione (UMTS).

Nuove interfacce per la UICC

Tre degli otto contatti elettrici che costituiscono la UICC non sono stati definiti nell’ambito dello standard ISO 7816. Sulla spinta della GSMA, l’ETSI ha dunque definito due nuove interfacce di comunicazione veloce per la UICC sfruttando i contatti lasciati liberi.

In particolare: SWP (Single Wire Protocol) – ETSI TS 102 613, contatto C6 – per il collegamento

dati veloce al controller NFC. Il colloquio applicativo tra UICC e controller NFC è gestito tramite protocollo HCI (Host Controller Interface) – ETSI TS 102 622.

USB (Universal Serial Bus) – ETSI TS 102 600, contatti C4 e C8 – per il collegamento veloce (12 Mbit/s) delle applicazioni presenti sulla UICC alle funzionalità multimediali del terminale mobile.

Attraverso la definizione di queste nuove interfacce, la UICC è in grado di connettersi su un canale dedicato al controller NFC, di ospitare contenuti multimediali fruibili attraverso Smart Card Web Server e di eseguire applicazioni in maniera autonoma rispetto al processore del terminale mobile (Baseband Processor).

Interfacce di Comunicazione: SWP e USB

Java Specification Request (JSR): si tratta di specifiche pubbliche per lo sviluppo di software Java.

In particolare le JSR 177 e JSR 257 riguardano il percorso dei dati tra il Secure Element (UICC) e l’interfaccia utente (display e tastiera).

La specifica JSR 177 (Security and Trust Services API – SATSA) riguarda nello

specifico le funzioni di sicurezza: estende le caratteristiche di sicurezza della piattaforma J2ME mediante l’aggiunta di API per la crittografia, firma digitale e la gestione delle credenziali dell’utente.

Comunicazione tra UICC (SE) e terminale Interfacce di Programmazione: JSR 177 (SATSA) e JSR 257

Baseband Processor

Interfacce di comunicazione e programmazione per la UICC

Specifiche pubbliche per lo sviluppo di software Java.

Riguardano la comunicazione tra le componenti NFC (SE e

Controller) e l’interfaccia utente. La specifica JSR 177 riguarda

nello specifico la sicurezza della comunicazione

Specifiche ETSI per il collegamento dati veloce (12 Mbit/s) tra le applicazioni sul

SE e le funzionalità multimediali del terminale

NFC

Specifiche ETSI per il collegamento dati veloce tra

SE e controller NFC. Il colloquio applicativo è

gestito tramite protocollo HCI

UICC (SE)

Browser

JSR 177 JSR 257 BIP

NFC Controller

Payment App/s

TicketingApp/s

Smart Card Web Server (SCWS)

ISO 7816 USB ISO 7816 USB

Single Wire Protocol (SWP)/ Host Controller Interface (HCI)

Modelli di business e Trusted Third Parties

Il modello di business che garantisce il maggior grado di interoperabilità è quello caratterizzato dalla presenza di una figura centrale, la Trusted Third Party che si interpone tra gli operatori di telefonia mobile, l’industria bancaria, i Service Provider e gli utenti finali e svolge la funzione di Trusted Service Manager (TSM).

Per poter svolgere questo lavoro la TTP deve poter fornire e gestire

una piattaforma comune su cui poggiare le applicazioni dei sistemi di pagamento e quelle della telefonia mobile.

Mobile Payments Focus sulla sicurezza

Rischi e contromisure

Addebito improprio sul conto dell’utente.

Mancato incasso da parte del merchant.

Indisponibilità e malfunzionamenti.

Abuso del sistema per finalità di riciclaggio di denaro o di finanziamento al terrorismo.

Nei Mobile Payment è possibile riscontrare tutti quei rischi che possono essere associati anche al mondo delle carte:

Le contromisure si basano per lo più sull’autenticazione delle entità e dei dispositivi e su misure tecniche a protezione dei dati (confidenzialità, integrità, non ripudio, disponibilità).

Sicurezza nei Proximity Payments Servizi OTA

I servizi OTA permettono di scaricare attraverso la rete i codici e le applicazioni che l’utente utilizzerà sul telefonino. Durante questa fase il flusso informativo transita sulla rete e può essere potenzialmente intercettato col rischio di compromettere la riservatezza.

Possibili punti critici:

Tratta Radio, in questo caso la rete GSM fornisce nativamente la cifratura del canale radio con algoritmo A5; si tratta di un servizio fornito dall’operatore MNO.

Servizio OTA, l’applicazione deputata a gestire i servizi OTA instaura un canale di comunicazione cifrato con il proprio TSM (ad esempio mediante TLS/SSL), si tratta di un servizio fornito dal TSM.

Cifratura dell’Issuer (Banca), i codici di sicurezza sono generati dall’Issuer e protetti con propria cifratura. Tali codici sono poi consegnati al TSM per la trasmissione finale al terminale mobile. Sul terminale dell’utente i codici sono depositati sul SE e attivati mediante chiavi fornite dall’Issuer al proprio utente.

Architettura di sicurezza di un TSM Sicurezza basata su vari livelli di cifratura

Fonte: Smart Card Alliance

Sicurezza nei Proximity Payments Secure Element

Il Secure Element situato nella USIM è costituito da un area di memoria e da un ambiente di elaborazione dedicato. La USIM è dotata infatti di un proprio processore, di coprocessore crittografico, nonché di memoria volatile e non volatile che può essere suddivisa in domini distinti e logicamente separati detti Security Domain (SD).

Ogni SD può essere assegnato in maniera dinamica e controllata a un distinto service provider.

Le specifiche GlobalPlatform v2.2 definiscono nella USIM una struttura gerarchica di SD. Tra queste si distingue la Issuer Security Domain (ISD) che ha funzionalità di controllo sugli altri Security Domain.

La ISD è creata all’atto di costituzione della SIM ed è sotto il controllo dell’MNO. In tale zona l’MNO mantiene le chiavi di sicurezza per:

Le funzioni OTA

La gestione della card

La gestione dinamica degli altri SD su cui sono caricate le applicazioni dell’utente.

Architettura Logica del SE

Sicurezza nei Proximity Payments Interazione terminale mobile - POS

Il pagamento in prossimità in una applicazione di mobile payment avviene avvicinando il terminale mobile al lettore POS ad una distanza inferiore ai 10 centimetri.

Su tale distanza viene instaurato un canale a Radio Frequenza (RF) che mette in comunicazione l’applicazione di pagamento sul Secure Element del terminale mobile con il lettore POS.

Per poter sfruttare l’infrastruttura di acquiring esistente, gli standard di comunicazione per tale tratta radio sono compatibili con quelli delle carte di pagamento contactless maggiormente diffuse (ISO 14443).

Ne segue che le varie tipologie di rischio a cui sono esposte le carte contactless per quanto riguarda la comunicazione carta – POS sono replicate nell’ambiente mobile payment.

Sicurezza nei Proximity Payments Interazione terminale mobile – POS: le minacce

Le principali minacce sono legate all’intercettazione e alla decodifica dei messaggi scambiati dal terminale sul canale radio, attraverso antenne direzionali ad alto guadagno e amplificatori a bassa cifra di rumore.

E’ possibile intercettare il canale radio fino a qualche metro di distanza (1 mt. nella modalità passiva, 10 mt. nella modalità attiva).

Ne segue che, sul piano teorico, sono possibili i seguenti attacchi:

Skimming: un falso lettore POS, dotato di apparato RF, interroga il terminale mobile per carpire informazioni della applicazione di pagamento (es: PAN, codici di autenticazione, etc.).

Man-in-the-middle: un terzo soggetto si interpone nel colloquio tra terminale mobile e POS, intercettando i messaggi e replicandoli, eventualmente con alterazioni, al destinatario.

Data modification e Corruption: si tratta di attacchi in grado di alterare il segnale RF, con la conseguenza di rendere indisponibile il canale (DoS: Denial of Service).

Eavesdropping (o sniffing): un terzo soggetto, dotato di un’opportuna antenna collocata nelle vicinanze, può ricevere e registrare i messaggi della transazione di pagamento.

Gli standard ISO di base del canale RF definiscono un semplice canale di trasmissione, su cui i messaggi transitano in chiaro. Spetta dunque alle singole applicazioni realizzare delle funzioni di sicurezza (es. cifratura e autenticazione) al di sopra del canale radio.

Sicurezza nei Proximity Payments L’approccio de-facto

Le applicazioni di mobile payment al momento sul mercato generalmente utilizzano procedure proprietarie solo parzialmente documentate.

Queste applicazioni usano i seguenti presidi di sicurezza:

Chiavi di sessione ottenute da “generatori di numeri casuali” e da una procedura condivisa tra le due parti.

Chiave “master” condivisa tra terminale mobile e POS. Essa è inserita all’atto della configurazione negli apparati e non viene mai inviata in chiaro sul canale radio. Tale chiave è utilizzata per scambio delle chiavi di sessione, nonché per le fasi di mutua autenticazione tra POS e terminale;

Cifratura dei messaggi della transazione mediante algoritmi simmetrici/asimmetrici e chiave di sessione (tale chiave cambia ad ogni nuova transazione);

Identificativo della transazione: ogni transazione è marcata con un valore univoco (transaction ID) che non può essere utilizzato in transazioni successive.

Sicurezza nei Proximity Payments La ricerca di standard condivisi

Il mercato in questo settore sta cercando di giungere a standard comuni e condivisi, in maniera da realizzare economie di scala e una interoperabilità dei prodotti su vasta scala.

Rilevante in tal senso è l’iniziativa congiunta di GSMA e NFC-Forum per la definizione delle caratteristiche tecniche del collegamento radio per dispositivi NFC.

L’NFC-Forum propone un’architettura dell’interfaccia radio che, sfruttando i protocolli di comunicazione di base ISO 14443 e ISO 18092, definisce tre modalità operative:

Card Emulation mode.

Peer-to-Peer mode.

Read/Write mode.

Sono in corso analisi per verificare la possibilità di sviluppare funzioni di sicurezza comuni alle tre modalità e per definire procedure affidabili in grado di assicurare isolamento e commutazione sicuri tra le stesse modalità operative.

Mobile Payments Il contesto normativo: la SEPA e l’EPC

SEPA (Single Euro Payments Area)

La SEPA comprende 32 Paesi Europei (circa 4500 banche). • Oltre ai 27 Stati membri dell’UE fanno parte dell’area anche Islanda,

Liechtenstein, Norvegia, Svizzera e Principato di Monaco.

Tra gli obiettivi della SEPA c’è quello di creare per gli strumenti di pagamento elettronico la stessa cosa che nel 2002 è avvenuta con il contante.

La SEPA (Single Euro Payments Area) è l’area in cui cittadini, aziende ed altri attori del sistema economico possono effettuare e ricevere pagamenti in euro all’interno dei confini nazionali o tra Stati diversi, sotto le stesse condizioni, diritti ed obblighi, indipendentemente dalla loro posizione.

EPC (European Payment Council)

Lo European Payment Council (EPC) è l’organo rappresentativo dell’industria bancaria Europea in relazione ai pagamenti. Esso definisce gli schemi di pagamento e le strutture (framework) necessari per realizzare in concreto la SEPA.

L’EPC fornisce una guida strategica per la standardizzazione,

stabilisce regole, best practice, supporta e monitora l’implementazione delle decisioni prese.

L’EPC è costituito da 74 membri che rappresentano banche,

banking communities e payment institutions.

Gli strumenti SEPA

Gli strumenti che permettono di attuare in concreto gli obiettivi della SEPA sono sostanzialmente tre: SEPA Credit Transfer Scheme (SCT) - abilita i prestatori di

servizi di pagamento ad offrire servizi di trasferimento credito attraverso la SEPA.

SEPA Direct Debit Scheme (SDD) - crea strumenti di pagamento che possono essere utilizzati per addebiti diretti nazionali ed internazionali.

SEPA Card Framework (SCF) - abilita i clienti ad utilizzare carte general purpose per fare e ricevere pagamenti, nonché prelevare denaro all’interno della SEPA.

Essi definiscono un insieme di regole, pratiche e standard per raggiungere l’interoperabilità rispetto a strumenti di pagamento a livello interbancario.

Rulebook e Implementation Guidelines

Per ciascuno degli strumenti individuati, l’EPC pubblica due tipologie di documenti: Rulebook – costituiscono la risorsa primaria per la

definizione di regole ed obblighi all’interno dello Schema, forniscono informazioni autorevoli su come esso funziona.

Implementation Guidelines – stabiliscono gli standard implementativi sulla base delle regole di alto livello definite dai Rulebook.

I Rulebook per il SCT e il SDD sono giunti alla versione 5.0, pubblicata il 1 Novembre 2010. Essi entreranno in vigore 12 mesi dopo la pubblicazione, quando verranno pubblicate le Implementation Guidelines ad essi relative.

La SEPA e il Mobile

Oltre a fornire gli strumenti descritti (SCT, SDD e SCF) che regolano essenzialmente la comunicazione inter-bancaria, l’EPC definisce regole e linee guida anche per quanto riguarda il tema dei Mobile Payments. Il Mobile è visto come un ulteriore canale di accesso agli schemi e alle infrastrutture di pagamento SEPA.

In proposito l’EPC ha pubblicato i seguenti documenti:

Trusted Service Manager - Service Management Requirements and Specifications (ver. 1.0 – Gennaio 2010, in collaborazione con la GSMA).

White Paper Mobile Payments (ver. 2.0 – Giugno 2010).

Il principio di base è che ciascuno dei settori coinvolti in un Mobile Contactless Payment (MCP) mantiene il proprio core business: i pagamenti per le Banche e i servizi mobile per i MNO.

Roadmap EPC per i Mobile Payments 1/2

Nel Marzo 2009 l’EPC, attraverso la valutazione del mercato potenziale e degli aspetti di business ed economici, ha approvato una roadmap che prevede una serie di passaggi con modalità diverse per i Mobile Payments in riferimento agli schemi SEPA:

Pagamenti in prossimità a valere su carte di pagamento (Contactless SEPA Card Payments) nella modalità Person to Business (P2B) e Business to Business (B2B).

Pagamenti in remoto a valere su carte di pagamento (Remote SEPA Card Payments) nelle modalità Person to Person (P2P), Person to Business (P2B) e Business to Business (B2B).

SEPA Credit Transfer in remoto (Remote SEPA Credit Transfers) nelle modalità Person to Person (P2P), Person to Business (P2B) e Business to Business (B2B).

Roadmap EPC per i Mobile Payments 2/2

La roadmap per i Mobile Payments prevede uno sviluppo in tre fasi:

Analisi dei requisiti dei servizi, includendo anche gli aspetti di business, di sicurezza, e tecnologici.

Pubblicazione di un libro bianco. Elaborazione di raccomandazioni e linee guida per

l’implementazione dei servizi.

Mobile Contactless Payment (MCP)

Nel documento pubblicato dall’EPC in collaborazione con la GSMA, un MCP è definito come “un qualsiasi pagamento SEPA basato su Carta eseguito da un Utente che utilizza una Mobile Contactless Payment Application (MCPA) fornita da un Issuer e caricata sulla UICC (fornita da un MNO) di un telefono cellulare equipaggiato con tecnologia NFC”.

Fonte: Trusted Service Manager - Service Management Requirements and Specifications (ver. 1.0 – Gennaio 2010)

Fornitura della Mobile Contactless Payment Application

Dal momento che l’Utente è già cliente di un MNO, che è peraltro il proprietario della UICC in riferimento alla fornitura e al mantenimento dell’Applicazione di pagamento, il delivery dell’applicazione sulla UICC dell’Utente è definito dal seguente schema:

Fonte: Trusted Service Manager - Service Management Requirements and Specifications (ver. 1.0 – Gennaio 2010)

Ruoli dell’Ecosistema

Gli attori coinvolti nell’ecosistema dei MCP sono i seguenti: Utente – è un cliente dell’MNO che ha un accordo con un Issuer del servizio di

MCP. E’ dotato di una UICC e di un telefono cellulare che supportano entrambi la tecnologia NFC.

Commerciante – è colui che accetta un MCP per il pagamento di beni o servizi acquistati dall’Utente. Ha un accordo con l’Acquirer ed è fornito di POS contactless.

Acquirer – è una Banca (o un Payment Service Provider) che elabora i dati della transazione del commerciante trasferendoli all’Issuer attarverso un’autorizzazione e una rete di compensazione.

Issuer - è una Banca (o un Payment Service Provider) che fornisce il servizio di MCP all’Utente. E’ responsabile del provisioning dell’App di Pagamento sulla UICC del dispositivo mobile dell’Utente e della personalizzazione dell’App con i dati dell’Utente. E’ altresì responsabile della gestione del life cycle dell’App.

MNO – offre una serie di servizi per il mobile, compresa la facilitazione dei servizi NFC. E’ il proprietario della UICC dell’Utente e fornisce la connettività OTA tra l’Utente e l’Issuer (o il suo TSM agent, in base all’implementazione sul mercato).

Service Management Roles (SMR)

Si tratta di un insieme di ruoli che possono essere eseguiti da una o più parti e riguardano il caricamento, il mantenimento e/o la cancellazione della MCP App sulla UICC.

L’implementazione di questi ruoli è definita in accordo con i requisiti dell’Issuer e dell’MNO.

Gli attori che svolgono i SMR hanno tipicamente relazioni tecniche e/o commerciali sia con l’Issuer che con l’MNO.

Nel caso in cui l’MNO e/o l’Issuer decidano di subappaltare parzialmente o totalmente questi ruoli a una terza parte, questo ruolo è svolto dal Trusted Service Manager.

Service Management Technical Roles

In conformità con il principio di separazione delle aree di responsabilità, l’EPC e la GSMA identificano due aree di responsabilità distinte per i Service Management Technical Roles:

Dominio di Responsabilità dell’MNO: riguarda la fornitura del “secure management framework” (per il mantenimento e l’esecuzione sicuri di applicazioni sulla UICC). L’MNO, quindi, deve:

• Gestire il ciclo di vita della UICC. • Gestire il security framework della UICC. • Fornire supporto ai Clienti.

Dominio di Responsabilità dell’Issuer: riguarda il delivery e la gestione della MCPA. L’Issuer, quindi, deve:

• Gestire il ciclo di vita della MCPA tenendo conto dei livelli di sicurezza e compatibilità richiesti.

• Fornire supporto ai Clienti.

Aree di Responsabilità

Service Management Commercial Roles

Oltre alle relazioni di tipo tecnico, tra MNO ed Issuer sussistono anche relazioni di tipo commerciale (Termini e Condizioni, Business Model, Service Level Agreement, etc.). La relazione commerciale tra MNO ed Issuer può essere implementata direttamente o indirettamente:

Una Relazione Diretta implica che il MNO e l’Issuer parlino in maniera diretta tra di loro e firmino un contratto.

Una Relazione Indiretta implica che ci siano degli “attori commerciali” che si interpongono tra il MNO e l’Issuer. Di conseguenza, MNO ed Issuer firmano contratti con gli attori commerciali. Questi possono assumere vari livelli di responsabilità, dipendentemente dalle attività che vogliono portare avanti.

Relazioni dirette ed indirette possono coesistere: la loro implementazione dipende dalle condizioni del mercato e dalle strategie commerciali che MNOs ed Issuers desiderano mettere in campo.

Intermediazione (Brokerage) del TSM

Per evitare che, nei mercati in cui sono presenti diversi MNO e diversi Issuer, ciascun Issuer debba negoziare separatamente con ciascun MNO, il ruolo del TSM potrebbe essere quello di porsi come intermediario (B2B Broker) tra le due entità, eseguendo le seguenti operazioni:

Acquisto (all’ingrosso) dei servizi dal MNO.

Packaging e pricing dei servizi nei confronti degli Issuer.

Gestione (come intermediario) dei Service Level Agreement tra gli Issuer e i MNO.

In questo modo l’Issuer avrebbe a che fare con un solo TSM per accedere alla base clienti di tutti gli operatori e, allo stesso modo, un MNO avrebeb bisogno di interfacciarsi con un solo TSM per accedere alla base clienti di vari Issuer.

Altri ruoli per il TSM

Oltre a svolgere il ruolo di intermediario appena descritto, il TSM può occuparsi anche di vendere i servizi di pagamento NFC agli Issuer e ai MNO.

In questo caso svolge anche le seguenti funzioni:

Promozione dei servizi di pagamento NFC nei confronti di Issuer ed MNO.

Acquisizione di MNO per rendere i loro servizi disponibili per abilitare i pagamenti NFC.

Portare i servizi sul mercato per proporli agli Issuer.

Service Management Overview

La figura mostra i domini di responsabilità dell’Issuer e dell’MNO, i Service Management technical roles e le relazioni commerciali che possono sussistere tra MNOs ed Issuers.

Fonte: Trusted Service Manager - Service Management Requirements and Specifications (ver. 1.0 – Gennaio 2010)

Il modello a tre parti

Fonte: Trusted Service Manager - Service Management Requirements and Specifications (ver. 1.0 – Gennaio 2010)

Il modello a quattro parti

Fonte: Trusted Service Manager - Service Management Requirements and Specifications (ver. 1.0 – Gennaio 2010)

Mobile Contactless SEPA Card Payment

Nel White Paper sui Mobile Payments pubblicato dall’EPC vengono definite due possibili procedure rispetto ai Mobile Proximity Payments: Tap and Go Double-Tap

Entrambe le procedure descritte riguardano transazioni P2B

o B2B nel caso il cardholder faccia parte del mondo business.

Scenario

Pagamento di una spesa di piccola entità presso un negozio.

Procedura

Il commerciante inserisce l'importo nel terminale POS.

Viene usata la carta di pagamento preselezionata, per questo tipo di pagamento, dal cliente sul dispositivo mobile, avvicinando il telefonino al terminale POS NFC-enabled.

La transazione viene eseguita come una standard SCP , il commerciante è in grado di controllare il pagamento e sul dispositivo mobile viene visualizzato il conto pagato.

Fonte: White Paper Mobile Payments (ver. 2.0 – Giugno 2010)

Mobile Contactless SEPA Card Payment Tap and Go

Scenario

Pagamento di un’elevata somma di denaro presso un negozio.

Procedura

Il commerciante inserisce l'importo nel terminale POS.

Il cliente avvicina il telefonino al terminale POS NFC-enabled

Viene usata la carta di pagamento preselezionata. Per confermare la transazione il cliente inserisce il suo "Personal-code" sul telefonino ed avvicina nuovamente il dispositivo al POS.

La transazione viene eseguita come una standard SCP, il commerciante è in grado di controllare il pagamento.

Fonte: White Paper Mobile Payments (ver. 2.0 – Giugno 2010)

Mobile Contactless SEPA Card Payment Double-Tap

Mobile Remote SEPA Card Payment

Anche per quanto concerne i pagamenti remoti l’EPC definisce due possibili procedure che riguardano due diversi scenari: Single-device Remote Payment and Service Access Multi-device Remote Payment and Service Access

Entrambe le procedure descritte riguardano transazioni P2B

o B2B nel caso il cardholder faccia parte del mondo business

Scenario

Il cliente vuole utilizzare il proprio telefono per effettuare un pagamento nei confronti di un commerciante su Internet, che vende contenuti per mobile (es. un Film).

Procedura

Il cliente naviga con il suo telefonino nella sezione d'acquisto del sito del commerciante.

ll sito riconosce che il telefonino è abilitato per i pagamenti da remoto ed offre al cliente questa opzione di pagamento.

Al cliente viene mostrata una richiesta di pagamento sul suo telefonino, nella richiesta è presente l’importo della transazione, l'identificativo del commerciante, la descrizione del servizio e una lista di carte supportate dal telefonino per il pagamento.

Il cliente seleziona una carta per il pagamento e conferma digitando il suo "Personal Code".

Viene effettuata una transazione standard SCP, e il commerciante riceve una notifica che la transazione è stata effettuata con successo.

Il commerciante fornisce il servizio al cliente.

Fonte: White Paper Mobile Payments (ver. 2.0 – Giugno 2010)

Mobile Remote SEPA Card Payment Single-device Remote Payment and Service Access

Scenario

Il cliente vuole utilizzare il proprio telefono per effettuare un pagamento nei confronti di un commerciante su Internet, al fine ottenere un servizio per un altro dispositivo.

Procedura

Dopo aver selezionato il servizio desiderato, viene offerta al cliente la possibilità di fornire al commerciante il suo numero di telefono o un altro identificativo.

Subito dopo, il cliente riceve sul suo telefonino una richiesta di pagamento che mostra: l’importo della transazione, l'identificativo del commerciante, una descrizione del servizio richiesto ed una lista di carte supportate per il pagamento. Il cliente conferma l'operazione digitando il suo " Personal Code".

Viene effettuata una transazione standard SCP, e il commerciante riceve una notifica che la transazione è stata effettuata con successo.

Il commerciante fornisce il servizio al cliente.

Fonte: White Paper Mobile Payments (ver. 2.0 – Giugno 2010)

Mobile Remote SEPA Card Payment Multi-device Remote Payment and Service Access

Appendice A Esperienze di Mobile Payment

Organizzazione dei Contenuti

Esperienze di Mobile Payment in Italia Servizi di pagamento offerti dai MVNO

Il caso Poste Mobile: Servizi Semplifica

Il caso Nòverca: Extended SIM 2.0

Il consorzio Movincom

Esperienze di Mobile Payment in Europa (da completare)

Il caso Payez Mobile

Il pilota a Nizza: Cityzi

Servizi di pagamento per i MVNO

PosteMobile è il maggiore operatore virtuale ESP (Enhanced Service Provider) italiano e opera sulla rete di Vodafone.

Attraverso i Servizi Semplifica offre la possibilità di

controllare il saldo della propria carta, effettuare ricariche e fare bonifici

pagare i bollettini postali direttamente attraverso il cellulare o il portale WAP;

spedire denaro all’estero, mediante il servizio MoneyGram;

acquistare il biglietto dell’ATAC, l’azienda di trasporto pubblico di Roma;

pagare il parcheggio con un SMS o una telefonata.

Per accedere a questi servizi è necessario innanzitutto associare il numero PosteMobile al conto BancoPosta o Postepay. Per il primo utilizzo dei servizi, è necessario inserire, dal menu integrato nella SIM, il codice PMPIN che si trova nella lettera consegnata insieme alla SIM PosteMobile. Subito dopo, verrà generato un nuovo codice PMPIN, da utilizzare ogni volta che si accede ai Servizi Semplifica.

In generale, il costo del servizio viene addebitato sul proprio conto di PosteItaliane, mentre il messaggio dell’avvenuta transazione viene addebitato sul conto telefonico.

Il caso PosteMobile: i Servizi Semplifica

I Servizi Semplifica si avvalgono di un sistema realizzato da PosteMobile che si basa su algoritmi di cifratura e firma digitale residenti sulla SIM.

Per garantire la massima sicurezza delle transazioni economiche, oltre al codice PIN di accensione del telefonino, la prima volta che si entra sul menu PosteMobile è richiesto l’inserimento del codice POP, presente sul retro della SIM, che permette di generare il già citato codice dispositivo PMPIN (PosteMobile PIN).

Il codice dispositivo PMPIN, che verrà richiesto ogni volta che si utilizza un servizio SEMPLIFICA, è unico in quanto generato su scelta del cliente.

La sicurezza delle transazioni è garantita da:

Firma digitale delle transazioni dispositive;

Cifratura delle trasmissioni con chiavi differenti per ogni utente;

Adozione di codici di sicurezza dispositivi;

Inaccessibilità delle applicazioni su partizione SIM.

Servizi di pagamento per i MVNO

Il caso PosteMobile: la sicurezza nei Servizi Semplifica

PosteMobile: valutazione della SIM

+ - Servizi utili: la SIM evita agli

utenti di recarsi fisicamente negli uffici postali.

Mette al centro l'utente. Funzioni “Acquista e paga” sono

quelle con le maggiori potenzialità Navigazione assistita. Adeguata gestione degli errori. Contenuti pertinenti, aggiornati e

affidabili. Font e colore adeguati.

Gestione dei menu migliorabile. Categorizzazione delle voci del

menu migliorabile. Brand PosteMobile totalmente

assente. Interfaccia piuttosto scarna.

Nòverca è un full MVNO che si appoggia su rete TIM. E’ nato nel 2008 grazie alla collaborazione tra Gruppo Acotel e Intesa Sanpaolo.

La Extended SIM 2.0 di Nòverca fa uso di tecnologie proprietarie per offrire una serie di servizi ai propri utenti. Semplicemente inserendo la SIM nel cellulare, senza scaricare nessuna applicazione aggiuntiva l’utente può accedere dal menu Nòverca ai seguenti servizi:

Vicino a te – (servizio di georeferenziazione) è possibile richiedere informazioni sui punti di interesse nelle vicinanze. Tali informazioni sono veicolate attraverso SMS;

Aggiorna Facebook e Aggiorna Twitter – (social network) è possibile, sempre tramite SMS, aggiornare il proprio status su Facebook o il proprio profilo su Twitter;

La tua banca– (servizio m-banking) accessibile ai clienti Intesa Sanpaolo. I servizi disponibili riguardano la richiesta del saldo e della lista degli ultimi movimenti, nonché la possibilità di ricaricare il proprio credito telefonico anche attraverso carta di credito.

Servizi di pagamento per i MVNO

Il caso Nòverca: Extended SIM 2.0

Nòverca ha inoltre espresso la volontà di proporre servizi di pagamento tramite tecnologia NFC.

Nòverca: valutazione della SIM

+ - Accesso a servizi ed informazioni

attraverso comandi integrati nella SIM stessa.

Apprezzabile l'intenzione di fornire servizi aggiuntivi.

Elevato livello di personalizzazione della SIM.

Contenuto di facile comprensione.

Servizi non totalmente funzionanti. Servizi non completamente innovativi. Funzioni ripetute più volte lungo le

diverse voci. Transazioni non adeguate rispetto ai tipici

scenari d'uso. Basso focus sulla funzione “Acquisti”. Gestione degli errori non adeguata. Architettura e struttura di non facile

comprensione. Navigazione “sfumata”. Categorizzazione delle voci del menu

migliorabile. Brand Nòverca totalmente assente. Interfaccia piuttosto scarna.

PosteMobile e Nòverca in sintesi

Le due SIM sono state valutate negli aspetti di: Funzionalità/Servizi; Architettura; Contenuto; Comunicazione. Per ognuna di queste caratteristiche sono stati individuati degli indicatori, ai quali è stato assegnato un punteggio, secondo una scala da 0 a 5 (0=livello minimo; 5=livello massimo).

Il consorzio Movincom

Si tratta di un consorzio di esercenti attivi anche sul canale mobile.

Movincom permette ai consorziati di ricevere pagamenti eseguiti tramite il telefono cellulare, attraverso lo sviluppo e la promozione di uno standard nazionale per i pagamenti in circolarità via mobile.

Il consorzio collabora anche con gli operatori di pagamento e con le telco.

Il numero di telefono è utilizzato come chiave univoca per identificare l’utente, che non deve mai inserire i dati sensibili del proprio strumento di pagamento per poter effettuare un acquisto.

Il costo del pagamento, autorizzato tramite telefono cellulare, viene addebitato sullo strumento di pagamento già in possesso dell’utente.

Obiettivi e struttura

Fonte: www.movincom.it

Il consorzio Movincom

L’esercente può scegliere quali tra le seguenti modalità mettere a disposizione dei propri clienti per permettere loro di effettuare acquisti attraverso il canale mobile:

SMS – l’ordine di acquisto viene inoltrato inviando un SMS con una specifica sintassi.

Applicazione Java – scaricabile sul telefono dell’utente, permette l’autocomposizione dell’SMS in base al bene selezionato.

Codici 2D – per l’invio automatico dell’SMS.

IVR o Drop Call.

Servizio di Assistente Personale telefonico.

Gli strumenti per autorizzare il pagamento

Fonte: www.movincom.it

Il consorzio Movincom La piattaforma di gestione e la registrazione al servizio

Movinbox è la piattaforma operativa promossa dal consorzio per la gestione del pagamento.

Essa permette di abilitare le richieste di acquisto su una molteplicità di strumenti di pagamento.

Fonte: www.movincom.it

Nella fase di attivazione del servizio il cliente, attraverso i canali del proprio operatore di pagamento, associa lo strumento di pagamento in suo possesso al telefono cellulare (MSISDN).

Attivazione del servizio 1

Il consorzio Movincom

Fonte: www.movincom.it

La disposizione del pagamento

Nella fase di disposizione del pagamento il cliente utilizza una delle modalità (SMS, Java, 2D Code) previste per la richiesta di acquisto. L’esercente inoltra la richiesta al corretto operatore di pagamento, il quale effettua la transazione.

A conferma dell’avvenuta transazione, dopo averne autorizzato la disposizione all’esercente interessato, l’operatore di pagamento invia un SMS sul cellulare dell’utente.

2 3

Fonte: www.movincom.it

Il consorzio Movincom L’ecosistema Bemoov - Interoperabilità

Esperienze di Mobile Proximity Payment

Il caso Payez Mobile

Tra le prime esperienze riguardo i mobile proximity payment, quella più interessante è Payez Mobile, progetto nato nel 2007 e attivo nelle città di Caen e Strasburgo.

Il progetto coinvolge circa 1.000 utilizzatori e 500 punti vendita dotati di

POS contactless. Il pagamento si effettua avvicinando il telefono cellulare dotato di

tecnologia NFC al POS; le applicazioni che consentono il pagamento sono installate nella SIM e non sono previsti limiti di importo nelle transazioni (al superamento della soglia dei 20€ è comunque prevista la digitazione di un PIN)

Appendice Il protocollo BIP e il CAT_TP

Il Bearer Indipendent Protocol (BIP) con il sovrastante CAT_TP (Card Application Toolkit_Transport Protocol) consente l’apertura di un canale dati tra il dispositivo, il server OTA e la (U)SIM Card.

IL BIP è in grado di generare pacchetti di dati della dimensione di 1472 Bytes.

Non solo aumentano le dimensioni dei pacchetti, ma anche il canale di trasmissione, che sfrutta la rete GPRS, consente una maggiore velocità di trasferimento.

Un canale dati che sfrutta il protocollo BIP può essere aperto dalla (U)SIM attraverso l’invio di un comando di tipo “open channel” al dispositivo ospitante.

Quando è il server OTA a voler aprire un canale dati di tipo BIP, il relativo comando deve essere impacchettato in un SMS, inviato dal server OTA alla (U)SIM card. Una volta aperto il canale dati, la (U)SIM può inviare e ricevere pacchetti di dati.

Il protocollo BIP e il CAT_TP

CAT_TP Funzionalità e standard di riferimento

Il CAT_TP, in quanto layer sottostante ai protocolli applicativi, fornisce le seguenti funzionalità, standardizzate dall’ETSI

(ref. TS 102 124 e TS 102 127):

Affidabilità del canale di comunicazione (non necessariamente sicurezza, che può essere gestita da un layer GSM 03.48 indipendente)

Segmentazione e concatenazione dei dati

Ritrasmissione dei messaggi

Modalità di indirizzamento per diversi bearers fisici (il GPRS usa IP, l’SMS usa il numero di telefono, il Bluetooth ha uno schema di indirizzamento proprietario ecc...)

Accesso ai canali BIP (è possibile aprire fino a 8 canali contemporaneamente)

Possibilità di multiplexing dei canali BIP

Apertura standardizzata del canale BIP lato server

Gestione remota tramite BIP e CAT_TP Un’architettura di riferimento (SIM Alliance)

Ref: SIMAlliance – Interoperability Stepping Stones Release 7

Piattaforme e SIM card per BIP e CAT_TP

Il CAT_TP ed il BIP sono supportati da diverse piattaforme OTA.

Alcuni esempi:

– ALM (Application Loader and Manager) OTA Platform by Oberthur

– MCTEL (U)SIM OTA Platform (http://www.mctel.net/)

– Cellnetrix (U)SIM OTA Platform (http://cellnetrix.com/)

– Mercurius OTA Management Platform by Movenda (http://www.movenda.com)

– Elatec OTA Platform (http://www.elatecworld.com/)

– etc.

Il CAT_TP ed il BIP sono inoltre supportati da diverse SIM card:

– FlyBuy by Oberthur

– SIMply ON by Sagem Orga

– UniverSIM Card by G&D

– etc.