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
Interfacce di Comunicazione: SWP e USB
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).

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.

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 e
Controller) e l’interfaccia utente. Payment Ticketing Specifiche ETSI per il
La specifica JSR 177 riguarda App/s App/s collegamento dati veloce tra
nello 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

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

Nei Mobile Payment è possibile riscontrare tutti quei rischi che possono
essere 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 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

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.

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.

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.

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.

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 (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.

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:


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
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 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.

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.


Il modello a tre parti


Il modello a quattro parti


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.

Tap and Go
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)

Double-Tap
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 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

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,
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.

Multi-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.


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
Il caso PosteMobile: i Servizi Semplifica
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: la sicurezza nei 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.

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 l'utente.  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.

Il caso Nòverca: Extended SIM 2.0
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.

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 
-
Servizi non totalmente funzionanti.
attraverso comandi integrati  Servizi non completamente innovativi.
nella SIM stessa.  Funzioni ripetute più volte lungo le
 Apprezzabile l'intenzione di diverse voci.
fornire servizi aggiuntivi.  Transazioni non adeguate rispetto ai tipici
 Elevato livello di scenari d'uso.
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.

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
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

Gli strumenti per autorizzare il pagamento

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.

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).


La disposizione del pagamento

2 3
Nella fase di disposizione del pagamento il A conferma dell’avvenuta transazione, dopo
cliente utilizza una delle modalità (SMS, Java, 2D averne autorizzato la disposizione all’esercente
Code) previste per la richiesta di acquisto. interessato, l’operatore di pagamento invia un
L’esercente inoltra la richiesta al corretto SMS sul cellulare dell’utente.
operatore di pagamento, il quale effettua la
transazione.

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 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.

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.

Mobile payments definizioni sicurezza e contesto normativo dic2010

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Viewers also liked

Viewers also liked (10)

Similar to Mobile payments definizioni sicurezza e contesto normativo dic2010

Similar to Mobile payments definizioni sicurezza e contesto normativo dic2010 (20)

More from CATTID "Sapienza"

More from CATTID "Sapienza" (20)

Recently uploaded

Recently uploaded (9)

Mobile payments definizioni sicurezza e contesto normativo dic2010