Mobile payments definizioni sicurezza e contesto normativo dic2010

  • 1,222 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,222
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
74
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Mobile PaymentsDefinizioni, sicurezza e contesto normativo
  • 2. 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.
  • 3. Remote Payments vs Proximity PaymentsLa tassonomia delle due macrocategorie individuate rispetto ai sistemi di MobilePayment può essere ulteriormente dettagliata prendendo in considerazione treaspetti 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.
  • 4. 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).
  • 5. Evoluzioni dei terminali mobiliLe potenzialità insite sia nei Remote che nei Proximity Payments sono enfatizzate dallatecnologia 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).
  • 6. SIM, USIM e UICCDal momento che si genera spesso confusione tra i termini SIM, USIM e UICC, occorreinnanzitutto distinguere tra supporto fisico e moduli logici di quella che nellinguaggio 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).
  • 7. Nuove interfacce per la UICC Interfacce di Comunicazione: SWP e USBTre degli otto contatti elettrici che costituiscono la UICC non sono stati definitinell’ambito dello standard ISO 7816. Sulla spinta della GSMA, l’ETSI ha dunquedefinito due nuove interfacce di comunicazione veloce per la UICC sfruttando icontatti 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).
  • 8. Comunicazione tra UICC (SE) e terminale Interfacce di Programmazione: JSR 177 (SATSA) e JSR 257 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.
  • 9. Interfacce di comunicazione e programmazione per la UICC Baseband Processor Browser Specifiche ETSI per il collegamento dati veloce (12 Mbit/s) tra le applicazioni sul JSR 257 JSR 177 BIP SE e le funzionalità multimediali del terminale NFC ISO 7816 ISO 7816 USB Specifiche pubbliche per lo sviluppo di software Java. Riguardano la comunicazione UICC (SE) tra le componenti NFC (SE eController) e l’interfaccia utente. Payment Ticketing Specifiche ETSI per il La specifica JSR 177 riguarda App/s App/s collegamento dati veloce tranello specifico la sicurezza della SE e controller NFC. Il comunicazione Smart Card Web Server (SCWS) colloquio applicativo è gestito tramite protocollo Single Wire Protocol (SWP)/ HCI Host Controller Interface (HCI) NFC Controller
  • 10. 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.
  • 11. Mobile PaymentsFocus sulla sicurezza
  • 12. Rischi e contromisureNei Mobile Payment è possibile riscontrare tutti quei rischi che possonoessere associati anche al mondo delle carte: 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.Le contromisure si basano per lo più sull’autenticazione delle entità e deidispositivi e su misure tecniche a protezione dei dati (confidenzialità,integrità, non ripudio, disponibilità).
  • 13. 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.
  • 14. Architettura di sicurezza di un TSMSicurezza basata su vari livelli di cifratura Fonte: Smart Card Alliance
  • 15. 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.
  • 16. Architettura Logica del SE
  • 17. 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.
  • 18. 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.
  • 19. 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.
  • 20. 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.
  • 21. Mobile PaymentsIl contesto normativo: la SEPA e l’EPC
  • 22. SEPA (Single Euro Payments Area) 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. 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.
  • 23. 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.
  • 24. 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.
  • 25. 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.
  • 26. 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.
  • 27. Roadmap EPC per i Mobile Payments 1/2Nel Marzo 2009 l’EPC, attraverso la valutazione del mercato potenziale edegli aspetti di business ed economici, ha approvato una roadmap cheprevede una serie di passaggi con modalità diverse per i Mobile Payments inriferimento 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).
  • 28. Roadmap EPC per i Mobile Payments 2/2La 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.
  • 29. 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)
  • 30. 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)
  • 31. 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).
  • 32. 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.
  • 33. Service Management Technical Roles Aree di ResponsabilitàIn conformità con il principio di separazione delle aree di responsabilità,l’EPC e la GSMA identificano due aree di responsabilità distinte per i ServiceManagement 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.
  • 34. Service Management Commercial RolesOltre alle relazioni di tipo tecnico, tra MNO ed Issuer sussistono ancherelazioni di tipo commerciale (Termini e Condizioni, Business Model, ServiceLevel 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 implementazionedipende dalle condizioni del mercato e dalle strategie commerciali che MNOsed Issuers desiderano mettere in campo.
  • 35. Intermediazione (Brokerage) del TSMPer evitare che, nei mercati in cui sono presenti diversi MNO e diversi Issuer,ciascun Issuer debba negoziare separatamente con ciascun MNO, il ruolo delTSM potrebbe essere quello di porsi come intermediario (B2B Broker) tra ledue 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 allabase clienti di tutti gli operatori e, allo stesso modo, un MNO avrebeb bisognodi interfacciarsi con un solo TSM per accedere alla base clienti di vari Issuer.
  • 36. Altri ruoli per il TSMOltre a svolgere il ruolo di intermediario appena descritto, il TSM può occuparsianche 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.
  • 37. 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)
  • 38. Il modello a tre partiFonte: Trusted Service Manager - Service Management Requirements and Specifications(ver. 1.0 – Gennaio 2010)
  • 39. Il modello a quattro partiFonte: Trusted Service Manager - Service Management Requirements and Specifications(ver. 1.0 – Gennaio 2010)
  • 40. 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.
  • 41. Mobile Contactless SEPA Card Payment Tap and GoScenario Pagamento di una spesa di piccola entità presso un negozio.Procedura Il commerciante inserisce limporto 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)
  • 42. Mobile Contactless SEPA Card Payment Double-TapScenario Pagamento di un’elevata somma di denaro presso un negozio.Procedura Il commerciante inserisce limporto 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)
  • 43. 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
  • 44. Mobile Remote SEPA Card Payment Single-device Remote Payment and Service AccessScenario 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 dacquisto 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, lidentificativo 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)
  • 45. Mobile Remote SEPA Card Payment Multi-device Remote Payment and Service AccessScenario 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, lidentificativo del commerciante, una descrizione del servizio richiesto ed una lista di carte supportate per il pagamento. Il cliente conferma loperazione 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)
  • 46. Appendice AEsperienze di Mobile Payment
  • 47. 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
  • 48. Servizi di pagamento per i MVNO Il caso PosteMobile: i Servizi SemplificaPosteMobile è il maggiore operatore virtuale ESP (Enhanced Service Provider) italiano eopera 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 PosteMobileal conto BancoPosta o Postepay. Per il primo utilizzo dei servizi, è necessario inserire, dalmenu integrato nella SIM, il codice PMPIN che si trova nella lettera consegnata insiemealla SIM PosteMobile. Subito dopo, verrà generato un nuovo codice PMPIN, da utilizzareogni 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.
  • 49. Servizi di pagamento per i MVNO Il caso PosteMobile: la sicurezza nei Servizi SemplificaI Servizi Semplifica si avvalgono di un sistema realizzato da PosteMobile che si basa sualgoritmi di cifratura e firma digitale residenti sulla SIM.Per garantire la massima sicurezza delle transazioni economiche, oltre al codice PIN diaccensione del telefonino, la prima volta che si entra sul menu PosteMobile è richiestol’inserimento del codice POP, presente sul retro della SIM, che permette di generare ilgià citato codice dispositivo PMPIN (PosteMobile PIN).Il codice dispositivo PMPIN, che verrà richiesto ogni volta che si utilizza un servizioSEMPLIFICA, è 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.
  • 50. PosteMobile: valutazione della SIM + - Servizi utili: la SIM evita agli  Gestione dei menu migliorabile. utenti di recarsi fisicamente negli  Categorizzazione delle voci del uffici postali. menu migliorabile. Mette al centro lutente.  Brand PosteMobile totalmente Funzioni “Acquista e paga” sono assente. quelle con le maggiori potenzialità  Interfaccia piuttosto scarna. Navigazione assistita. Adeguata gestione degli errori. Contenuti pertinenti, aggiornati e affidabili. Font e colore adeguati.
  • 51. Servizi di pagamento per i MVNO Il caso Nòverca: Extended SIM 2.0Nòverca è un full MVNO che si appoggia su rete TIM. E’ nato nel 2008 grazie allacollaborazione tra Gruppo Acotel e Intesa Sanpaolo.La Extended SIM 2.0 di Nòverca fa uso di tecnologie proprietarie per offrire una seriedi servizi ai propri utenti. Semplicemente inserendo la SIM nel cellulare, senzascaricare nessuna applicazione aggiuntiva l’utente può accedere dal menu Nòverca aiseguenti servizi: Vicino a te – (servizio di georeferenziazione) è possibile richiedere informazioni suipunti di interesse nelle vicinanze. Tali informazioni sono veicolate attraverso SMS; Aggiorna Facebook e Aggiorna Twitter – (social network) è possibile, sempre tramiteSMS, aggiornare il proprio status su Facebook o il proprio profilo su Twitter; La tua banca– (servizio m-banking) accessibile ai clienti Intesa Sanpaolo. I servizidisponibili 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.Nòverca ha inoltre espresso la volontà di proporre servizi di pagamento tramitetecnologia NFC.
  • 52. Nòverca: valutazione della SIM + Accesso a servizi ed informazioni  - Servizi non totalmente funzionanti. attraverso comandi integrati  Servizi non completamente innovativi. nella SIM stessa.  Funzioni ripetute più volte lungo le Apprezzabile lintenzione di diverse voci. fornire servizi aggiuntivi.  Transazioni non adeguate rispetto ai tipici Elevato livello di scenari duso. personalizzazione della SIM.  Basso focus sulla funzione “Acquisti”. Contenuto di facile  Gestione degli errori non adeguata. comprensione.  Architettura e struttura di non facile comprensione.  Navigazione “sfumata”.  Categorizzazione delle voci del menu migliorabile.  Brand Nòverca totalmente assente.  Interfaccia piuttosto scarna.
  • 53. PosteMobile e Nòverca in sintesiLe due SIM sono state valutatenegli aspetti di: Funzionalità/Servizi; Architettura; Contenuto; Comunicazione.Per ognuna di questecaratteristiche sono statiindividuati degli indicatori, aiquali è stato assegnato unpunteggio, secondo una scalada 0 a 5 (0=livello minimo;5=livello massimo).
  • 54. Il consorzio Movincom Obiettivi e struttura 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. Fonte: www.movincom.it
  • 55. Il consorzio Movincom Gli strumenti per autorizzare il pagamentoL’esercente può scegliere quali tra le seguenti modalità mettere adisposizione dei propri clienti per permettere loro di effettuare acquistiattraverso 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. Fonte: www.movincom.it
  • 56. 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.1 Attivazione del servizio 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). Fonte: www.movincom.it
  • 57. Il consorzio Movincom La disposizione del pagamento2 3Nella fase di disposizione del pagamento il A conferma dell’avvenuta transazione, dopocliente utilizza una delle modalità (SMS, Java, 2D averne autorizzato la disposizione all’esercenteCode) previste per la richiesta di acquisto. interessato, l’operatore di pagamento invia unL’esercente inoltra la richiesta al corretto SMS sul cellulare dell’utente.operatore di pagamento, il quale effettua latransazione. Fonte: www.movincom.it
  • 58. Il consorzio MovincomL’ecosistema Bemoov - Interoperabilità Fonte: www.movincom.it
  • 59. 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)
  • 60. AppendiceIl protocollo BIP e il CAT_TP
  • 61. 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.
  • 62. CAT_TP Funzionalità e standard di riferimentoIl CAT_TP, in quanto layer sottostante ai protocolli applicativi, fornisce le seguentifunzionalità, 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
  • 63. Gestione remota tramite BIP e CAT_TPUn’architettura di riferimento (SIM Alliance) Ref: SIMAlliance – Interoperability Stepping Stones Release 7
  • 64. Piattaforme e SIM card per BIP e CAT_TPIl 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.