UNIVERSITÀ DEGLI STUDI DI PISA
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea:
SERVIZIO DI NON RIPUDIO IN UN
SISTEMA DI PAGAMENTO CON
DISPOSITIVI MOBILI
Candidato:
Lorenzo Mereu
Relatori:
Prof. Gianluca Dini
Prof. Marco Avvenuti
Sommario
INTRODUZIONE ... 8
1 SISTEMI DI M-PAYMENT ... 10
1.1 M-Payment ... 10
1.1.1 Il Sistema di Pagamento CAFE (Conditional Access For Europe) ... 11
1.1.2 Banca Sella: “ Pagare con il cellulare “ ... 12
1.1.3 Limiti dei sistemi attuali e nuove soluzioni ... 13
1.2 Documento Digitale e Trust Model... 15
1.2.1 Crittografia a chiave pubblica... 17
1.3 Concetto di token sicuro ... 19
2 STANDARD... 23
2.1 Introduzione agli standard ... 23
2.2 3GPP TS 51.011... 25
2.2.1 Protocollo di scambio ... 27
2.3 3GPP TS 51.011... 28
2.4 Comandi APDU... 30
2.4.1 Comandi Terminal Profile, Envelope e Terminal Response ... 31
2.4.2 Formato dei Comandi Proattivi, dei Comandi Envelope e Terminal Response34 2.5 Over-The-Air (OTA)... 35 2.6 3GPP TS 23.040... 36 2.7 3GPP TS 22.048... 37 2.8 3GPP TS 23.048... 41 2.9 3GPP TS 42.019... 43 2.10 3GPP TS 43.019 ... 46
2.10.1 Attivazione di una Applet (Applet Triggering) ... 49
2.11 Standard GSM ... 50
2.12 Global Platform ... 51
2.12.1 Securety Domains e Card Manager ... 52
3 SIM CARD... 56
3.1 Java Card e SIM card... 56
3.2 Archittura di una JavaCard... 58
3.2.1 Caratteristiche della JavaCard Virtual Machine ... 62
3.3 JavaCard e OpenCard Framework... 63
3.3.1 Open Card Framework ... 64
4 REQUISITI DI UN SISTEMA SICURO ... 65
4.1 Premessa ... 65
4.2 Gestione delle chiavi... 65
4.3 Public Key Infrastructure (PKI)... 68
4.3.1 Certification Authority ... 69
4.3.2 Registration Authority ... 71
4.3.3 Sistema distribuito di directory... 72
4.3.4 Utenti finali... 73
4.4 PKI e non ripudio: compromissione delle chiavi... 73
4.5 Marcatura temporale... 75
4.6 Non Ripudio e Timestamping ... 77
4.6.1 Tipi di non ripudio... 78
4.6.2 Non ripudio dell’origine ... 79
4.6.3 Non Ripudio del destinatario... 80
4.6.4 Non ripudio della sottoscrizione... 81
4.7 Il Time stamping nel commercio elettronico ... 82
4.8.1 I Request For Comments ... 85
4.8.2 Lo standard ANS.1 ... 86
4.9 Cryptographic Message Syntax (CMS)... 88
4.10 Requisiti di una TSA ... 89
4.11 Transazioni di una TSA ... 91
5 SPECIFICHE PER LA REALIZZAZINE DI M-P@Y ... 93
5.1 Premessa ... 93
5.2 Attori ... 93
5.3 Scenario... 95
5.4 Il Servizio di Non Ripudio in M-P@y... 96
5.4.1 Compromissione delle chiavi ... 96
5.4.2 Non ripudio dell’origine e del destinatario in M-P@y ... 98
5.5 Servizio di Timestamping in M-P@y ... 99
5.6 Architettura di M-P@y... 100
5.7 Protocollo di Pagamento... 102
5.7.1 Transazione tra Server TSA e Server B... 107
5.7.2 Transazione tra Server TSA e Mobile Equipement ... 107
5.8 Ulteriori messaggi ... 109
5.8.1 Sequence Diagram... 112
5.9 Gestione delle situazioni di errore ... 119
5.9.1 Sequence Diagrams ... 120
5.9.2 Memorizzazione delle marche temporali emesse ... 125
5.10 Memorizzazione delle marche temporali ricevute ... 126
5.10.1 Database del server B ... 127
5.10.2 File della WIM Card del Mobile Equipment ... 128
6 REALIZZAZIONE DEL PROTOTIPO M-P@Y ... 132
6.1 Differenze tre una Java SIM card e una Java Card ... 133
6.2 Implementazione di un’Applet... 134
6.3 Implementazione di una Toolkit Applet... 137
6.4 Implementazione dell’Applicazione Java Card... 144
6.4.1 Librerie sim.access e sim.toolkit ... 145
6.4.2 Package JCMPayment ... 155
6.5 Package SIM... 156
6.6 Mobile Equipement... 158
6.7 Implementazione del TSA ... 158
6.7.1 La libreria org.bouncycastle ... 158
6.7.2 Realizzazione del server di marcatura temporale ... 159
6.7.2.1 Implementazione delle strutture di RFC3161... 160
6.7.2.2 Realizzazione del programma server... 161
6.7.2.2.1 Thread SMSListener ... 162
6.7.2.2.2 Thread TCPConnectionHandler ... 163
6.7.2.2.3 Gestione simulata della rete GSM... 164
6.7.2.2.4 Gestione del database dei token emessi ... 167
6.7.2.2.5 Creazione del certificato di chiave pubblica della TSA ... 167
6.7.2.3 Descrizione UML del package TSA... 171
6.7.3 Implementazione dal servizio dal lato client ... 172
6.8 Implementazione del Timestamping dal lato client ... 173
6.9 Strumenti Software e Hardware utilizzati ... 174
6.10 Problemi con le Cyberflex Access e-gate cards ... 176
6.10.1 Impossibilità di usare la Firma Digitale... 177
6.10.2 Problemi di Linking... 178
6.10.3 Lunghezza dei metodi... 182
BIBLIOGRAFIA ... 186
Indice delle Figure
Figura 1 - La firma digitale come applicazione della cifratura asimmetrica ... 19Figura 2 - Scenario con un dispositivo non fidato (PC)... 20
Figura 3 - Struttura interna di una Smart Card e di una SIM Card... 26
Figura 4 - Paradigma del protocollo standard: Smart Card – Host Application ... 28
Figura 5 - Paradigma SIM Application Toolkit: Proactive SIM – ME ... 29
Figura 6 – Struttura del Commad APDU... 30
Figura 7 – Struttura del Response APDU ... 31
Figura 8 - Invio di un ENVELOPE Data Download SMS-PP alla SIM... 34
Figura 9- Formato BER-TLV per Comandi Proattivi, ENVELOPE e TERMINAL RESPONSE... 35
Figura 10 - Scenario di utilizzo dei meccanismi di sicurezza dello standard... 38
Figura 11 - Suddivisione di un Command Packet in più Secured Packet... 41
Figura 12 - Architettura della SIM API... 44
Figura 13 - Architettura di una Java SIM Card ... 47
Figura 14 - Componenti dell’architettura Java Card ... 59
Figura 15 – Separazione della VM JavaCard su due ambienti ... 63
Figura 16 - Formato del certificato X.509 ... 67
Figura 17 - Infrastruttura a chiave pubblica... 73
Figura 18 - TSA e non ripudio dell'origine ... 79
Figura 19 - TSA e non ripudio del destinatario... 81
Figura 20 - Scambio di messaggi codificati con regole BER tra dispositivi in grado di interpretare ASN.1... 87
Figura 21 - Architettura di M-P@y con servizio di timestamping ... 100
Figura 22 - Richiesta del Codice Nx al Token Sicuro ... 113
Figura 23 - Transazione portata correttamente a termine ... 114
Figura 25 – Aggiornamento volontario di Nx ... 116
Figura 26 - Proposta d’Acquisto M1 alterata ... 117
Figura 27 – Conferma di Pagamento M2 alterata ... 118
Figura 28 – Conferma Proposta d’Acquisto rimandata troppo a lungo ... 119
Figura 29 - Transazione completata con successo... 121
Figura 30 - Transazione abortita da B a causa di un errore nel timestamping ... 123
Figura 31 - Transazione abortita da ME a seguito di un errore nel timestamping... 124
Figura 32 – Ciclo di esecuzione di un’Applet ... 135
Figura 33– Ciclo di esecuzione di una Toolkit Applet... 138
Figura 34 - Ciclo di esecuzione dell'Applet realizzata ... 143
Figura 35- Package sim.toolkit ... 146
Figura 36- Struttura del Package SIM ... 157
Figura 37- Suddivisione in package della libreria org.bouncycastle... 159
Figura 38 - Activity diagram del server TSA... 161
Figura 39- Activity diagram del thread SMSListener creato dal server TSA... 162
Figura 40- Activity diagram del thread TCPConnectionHandler creato ... 163
Figura 41- Package SimGSMApi ... 165
Figura 42- Struttura della tabella Access dei token emessi dalla TSA... 167
Figura 43- Classe X509V3CertificateGenerator del package org.bouncycastle.jce... 169
Figura 44- Package TSA ... 172
INTRODUZIONE
I movimenti e gli accordi di diverse società, da quelle della telefonia mobile a quelle delle banche fino alle diverse imprese informatiche e alle pubbliche amministrazioni dimostrano una continua tendenza verso una progressiva e positiva innovazione nel settore dei servizi e dei sistemi mobili e in particolare nei servizi di pagamento elettronico attraverso dispotivi mobili o chiamati più comunemente servizi di M-Payment.
Ciò è favorito da un elevato numero di terminali mobili, di strumenti e di diverse tecnologie di sviluppo che permettono un rapido aggiornamento dei servizi sviluppati.
Questo non fa altro che accrescere una maggiore competizione che richiede in risposta ai clienti di sviluppare dei servizi innovativi di grande affidabilità e qualità. Due sono le strategie di mercato che si sviluppano nel campo della telefonia mobile, quella che fa uso del WAP (Wireless Application Protocol) e quella del mondo GSM. Si prenderà in considerazione quest’ultima soluzione e in particolare si parlerà dei servizi basati su SIM Application Toolkit e sulla crescente capacità di elaborazione e memorizzazione offerta dalle SIM card
multi-applicazione (MASC).
I servizi a valore aggiunto (m-banking, m-commerce, applicazioni location-based) sono inoltre personalizzabili attraverso un meccanismo di caricamento
“over-the-air” e costituiscono un approccio complementare al WAP. La
connessione avviene tramite l’invio e la ricezione di Short Messages Service
(SMS) sulla rete mobile, che nei cellulari è possibile visualizzare attraverso dei
Lo scenario è ancora più competitivo se consideriamo che parallelamente alla disponibilità di questi ambienti applicativi sono resi disponibili nuovi servizi portanti GSM di fase 2+ come GPRS (General Packet Radio Services) e UMTS
(Universal Mobile Telecomunications System) che apportano una maggiore
velocità e qualità dei servizi.
Nel corso della trattazione dovremo affrantare diversi temi che sono la base per sviluppare sistemi di mobile-commerce; in primo luogo si devono affrontare tutte le problematiche riguardanti la sicurezza e il non- ripudio delle transazioni e degli strumenti che devono essere utilizzati affinché l’utente possa convergere all’utilizzo dei nuovi sistemi di pagamento; e in secondo luogo per sviluppare i servizi e le applicazioni si dovranno studiare, sia i diversi standar che nel corso degli anni hanno subito diversi cambiamenti derivante dal fatto che si vuole garantire una certa interoperabiltà, versatilità e compatibilità tra le diverse tecnologie e strumenti di utilizzo, sia il linguaggio Java Card come soluzione di implementazione delle applicazioni o applet e il loro interfacciamento al SIM
1 SISTEMI DI M-PAYMENT
1.1 M-Payment
I sistemi di pagamento sono visti come il vero fattore di sucesso nel commercio elettronico a patto che riescano a replicare per funzionalità d’uso e caratteristiche i tradizionali sistemi di pagamento.
Attualmete, l’evoluzione del commercio elettronico è legata alla necessità di sviluppare sistemi di pagamento pratici e sicuri. La mancanza di questi requisiti è stata una delle maggiori difficoltà che le aziende, compagnie telefoniche e banche hanno dovuto affrontare in questi anni. Infatti, l’applicazione di sistemi di pagamento tradizionali in internet, necessita dell’inserimento, da parte dell’utente, di dati cosiddetti sensibili quali, ad esempio, il numero della carta di credito. Ad oggi però, non è garantita un alto grado di sicurarezza sulla circolazine di tali dati sul web. Tale difficoltà non ha certamente invogliato ne le aziende ne gli utenti i quali, sempre più esigenti, gradirebbero effettuare pagamenti ovunque anche senza avere a disposizione un normale PC.
Quindi i sistemi di pagamento elettronico che si vogliono prendere in considerazione sono quelli che vengono effettuati tramite dispotivi mobili.
Nei prossimi paragrafi verrano riportati degli esempi di questi sistemi di pagamento mettendo in rilievo alcune particolarità di utilizzo e tecnologie orientate a garantire i requisiti di sicurezza e flessibilità da cui non si può prescindere e che maggiormente preoccupano i consumatori.
Da questi esempi si dovranno identificare i vantaggi e i limiti per poter sviluppare poi un sistema che offra una reale alternativa sia ai diversi sitemi di pagamento elettronico che a queli tradizionali.
1.1.1
Il Sistema di Pagamento CAFE (Conditional Access For
Europe)
Esempio di sistema di pagamento con dispositivo elettronico è il sistema
CAFE (Conditional Access For Europe)[AJSW] Il suo obiettivo è quello di
sviluppare sistemi innovativi per accesso condizionato tra cui i sistemi di pagamento digitali.
Esso fa uso di un borsellino elettronico, che poi sarebbe un piccolo calcolatore tascabile o di un PDA (Personal Digital Assistant). Il sistema CAFE è un sistema di pagamento di tipo pre-pagato e richiede hardware anti-intrusione (per esempio smartcard); è fondamentalmente pensato per effettuare pagamenti dal borsello elettronico ad un terminale di un qualsiasi punto vendita che può essere un negozio virtuale, un telefono, un terminale POS.
Un rilevante aspetto di CAFE è l'alto grado di sicurezza di tutte le parti coinvolte. Questo è garantito senza la necessità che ciascuna parte debba fidarsi delle altre.
Sia il fornitore di denaro che il singolo utente hanno, per ciò che riguarda la sicurezza, una dipendenza limitata dai dispositivi anti-intrusioni che però non posono essere installati sul PDA in quanto si può introdurre un uomo nel mezzo (concetto di Token sicuro che verrà preso nei paragrafi successivi)
I dispositivi anti-intrusione che proteggono il fornitore di denaro elettronico dalla possibilità che l’utente stesso o un uomo nel mezzo possa operare delle spese non lecite non possono essere installati sul PDA o sul calcolatore, devono essere installati sul borsello elettronico del compratore.
In CAFE, il dispositivo anti-intrusione è un chip smartcard dotato di processore per crittografia inserito all'interno del borsello. Il guardiano può essere fissato all'interno del borsello o montato su una smartcard, in modo da poter essere cambiato.
Un’altra misura di sicurezza standard che CAFE applica è la firma digitale, indispensabile per sistemi con sicurezza multi-parte dove ogni messaggio con un qualche valore legale deve essere firmato per acquistare certezza legale. In particolare, il borsello deve inviare un ordine firmato per prelevare denaro dal fornitore, e chi riceve pagamenti deve possedere una ricevuta firmata per depositare denaro.Inoltre, l'inizializzazione del borsello deve garantire che i segreti utilizzati per creare la firma non siano noti a nessuna altra parte.
1.1.2
Banca Sella: “ Pagare con il cellulare “
Uno dei motivi perché l’e-commerce non ha avuto ancora un grande sviluppo è che l’utente deve immettere dei dati propri nella rete che è ritenuta poco affidabile; la BancaSella propone una soluzione, implementando un sistema di pagamento con carta di credito GestPay dove è necessario inserire una sola volta i dati dell’utente nel suo database utilizzando un codice e non il codice della carta di credito.
"Paga con il Cellulare" prevede che al momento dell'acquisto, l'utente già registrato venga autenticato tramite Codice identificativo, numero di cellulare chiamante e Pin-Pay assegnato dal sistema. In pratica si dovrà chiamare un numero di telefono dal proprio cellulare e digitare i codici di validazione del pagamento. Tra l’altro vi è la modalità del "Paga con il Codice": l'utente registrato inserirà il proprio codice e Pin-Pay nelle pagine del sistema Banca Sella e convaliderà il pagamento.
alla pagina di registrazione o cliccando sul pulsante "Modifica profilo".
1.1.3
Limiti dei sistemi attuali e nuove soluzioni
Da una prima analisi si può notare che i servizi proposti non sfruttano ancora a pieno le potenzialità messe a disposizione dalle nuove tecnologie, in particolare, non vengono sfruttate adeguatamente la versatilità e le caratteristiche intrinseche di sicurezza delle più recenti SIM Card.
L’autenticazione degli utenti avviene tramite una telefonata ad un centro servizi e tramite la digitazione di un PIN mnemonico. La verifica dell’identità non avviene localmente alla SIM Card, ma viene effettuata da remoto, inviando informazioni sensibili sulla rete GSM. La rete GSM, tuttavia, non si può considerare completamente sicura, sia per quanto riguarda la confidenzialità delle informazioni che viaggiano su di essa sia per quanto riguarda la possibilità di clonare le SIM Card utilizzate per l’autenticazione sulla rete (esiste la concreta possibilità di ottenere le chiavi presenti sulla SIM Card ed utilizzarle per realizzare una SIM clone).
Da queste considerazioni risulta evidente quanto la garanzia di autenticazione che questi servizi vantano venga meno di fronte a problemi di sicurezza del sistema GSM.
Esiste un altro aspetto critico di questi servizi: essi non tutelano completamente l’utente. Infatti viene utilizzato il meccanismo tradizionale nome-utente/parola-chiave per identificare l’acquirente e per autorizzare una transazione. Entrambe queste informazioni sono già note al Centro Servizi e l’utente deve solo comunicarle per farsi riconoscere. Fra l’altro, nelle soluzioni appena viste queste informazioni sono “ascoltate” anche dal gestore di telefonia mobile.
Quindi sia il Centro Servizi che il gestore potrebbero utilizzare questi dati per effettuare pagamenti per conto dell’utente. Quest’ultimo si troverebbe nell’impossibilità di ripudiarli, o al limite, se il pagamento si appoggia alla carta di credito, dovrebbe verificare con attenzione l’estratto conto.
Solo il prossimo avvento delle SIM Card, che ormai hanno una capacità di memorizzazione e di elaborazione in grado di memorizzare una o più applicazioni, e che sono in grado di effettuare sia operazioni di crittografia simmetrica e asimmetrica e di firma digitale possono rendere il cellulare uno strumento di pagamento realmente sicuro e versatile. Inoltre è possibile estendere la comunicazione tra SIM card e il Mobile Equipement sfruttando il SIM Toolkit
Application (SAT); attraverso il SAT infatti, si possono implementare piccole
applicazioni Java che eseguite sulle SIM cards permetteno all’utente di disporre di svariati servizi a valore aggiunto e tutto attraverso lo strumento più semplice e versatile a disposizione: gli SMS.
Esempi concreti di questo utilizzo sono da una parte la soluzione di Oberthur [rif. OBER], con la distribuzione delle SIM card nominate SIMphonicIC e la realizzazione di un sistema per la sviluppo di applicazione di m-commerce che possono essere scaricate dinamicamnete nelle SIM card; dall’altra la soluzione della società Rapsodia Software [rif. RAPS], che ha costruito una piattaforma di m-banking, sempre, attraveso la tecnologia delle SIM card e del SIM Application Toolkit.
Lo sviluppo di queste nuove tecnologie ci permetterà di vedere il nostro dispositivo mobile, non più come semplice strumento di comunicazione, ma anche come un oggetto fidato con cui potremo effettuare ogni genere di acquisto.
Questo lavoro, quindi, si propone di realizzare un sistema di pagamento attraverso dispositivi mobili, che chiameremo M-P@y, che sfrutti la tecnologia
delle SIM card, che offri i requisiti di sicurezza citati prima e che sia in grado di risolvere il problema di non ripudio, introducendo nella progettazione un elemento di marcatura temporale generato da una terza entità fidata.
A tal fine dovremo precisare il loro significato e quali sono i metodi con cui è possibile soddisfarli in modo che la comunicazioni tra gli attori del servizio di
M-Payment possa essere ritenuta sicura. Un sistema che garantisce ciò viene
denominato Trust Model; all’interno di un Trust Model si focalizza anche il concetto di Token Sicuro il quale definisce come possa essere garantita la sicurezza tra dispositivo mobile e i disositivi esterni.
1.2 Documento Digitale e Trust Model
Come si è accennato negli esempi citati dei paragrafi precedenti o comunque nei sistemi in cui sono necessarie transizioni di tipo business e di commercio elettronico è molto importante avere la possibilità di spedire documenti a grande distanza e velocità, ma nello stesso tempo bisogna prendere certe precauzione se questi hanno un valore legale. Il documento digitale può assumere diversi formati: può trattarsi di un semplice testo, di una immagine, di un documento di tipo audio oppure video, e molto impiego sta avendo anche in ambiti bancari che vogliono sfruttare a pieno l’evoluzione tecnologica. Infatti le operazioni bancarie diventano sempre più digitali e un ordine di pagamento (bonifico bancario) effettuato tramite il terminale di gestione del conto corrente potrebbe essere assimilato ad un vero e proprio "assegno digitale" o quantomeno è la cosa che più gli si avvicina.
Tuttavia se da una parte l'utilizzo di documenti elettronici significa bassi costi ed alte velocità, dall'altra la relativa facilità con cui un documento di tale tipo può subire manipolazioni, l'insicurezza intrinseca dei veicoli con cui viene trasmesso (si pensi ad Internet o comunque ai sistemi aperti in genere) diventano punti
fondamentali da risolvere per progettare un sistema che possa garantire agli utenti un certo livello di affidabilità e sicurezza; inoltre queste problematiche aumentano notevolmente se ai documenti gli si attribuisce valore legale. Nasce quindi l’esigenza di progettare meccanismi di sicurezza che assicurino:
− integrità: i servizi di integrità dei dati proteggono dai cosiddetti attacchi attivi1, finalizzati all'alterazione illegittima del valore di un dato. L'alterazione di un documento può comprendere la cancellazione, la modifica o il cambiamento dell'ordine dei dati;
− confidenzialità o segretezza: l'attributo di confidenzialità di una comunicazione implica l'impossibilità da parte di entità non autorizzate di venire a conoscenza dei messaggi riservati, scambiati in una comunicazione;
− autenticità: i servizi di autenticazione forniscono l'accertamento dell'identità; quando qualcuno o qualcosa si attribuisce una certa identità, i servizi di autenticazione forniscono lo strumento per verificare la correttezza di tale affermazione;
− non ripudio: i servizi di non ripudio hanno la finalità di impedire che un'entità riesca a rinnegare con successo la partecipazione ad una comunicazione o ad una transazione a cui in realtà ha preso parte. I servizi di non ripudio non impediscono il ripudio di una comunicazione, ma forniscono gli strumenti per dimostrare l'evidenza dei fatti in caso di contenzioso.
1
Si definisce attacco passivo un attacco con cui l’”uomo nel mezzo” intercetta semplicemente un flusso di informazioni, limitandosi ad osservarne il contenuto; con un attacco attivo, invece, l’”uomo nel mezzo” introduce alterazioni al flusso di dati che possono comprendere modifica del contenuto informativo, eliminazione integrale o parziale del messaggio o trattenimento del messaggio per poi replicarlo in tempi successivi.
L’insieme di tali requisiti è definito Trust Model [GDSEC] ed è un paradigma di base per la costruzione di sistemi sicuri in cui due utenti non si fidano l’uno dell’altro.
1.2.1
Crittografia a chiave pubblica
Il documento elettronico sta piano piano sostituendo l’ormai passato documento cartaceo e sono enormi le sue potenzialità se accompagnate da doti di autenticità, inegrità e sicurezza. Lo strumento universale per il raggiungimento dello scopo è la firma digitale.
La firma digitale è il risultato di una procedura informatica basata su sistemi a
chiave asimmetrica (o a chiave pubblica) che si basano su algoritmi crittografici
che necessitano di una coppia di chiavi distinte per cifrare e decifrare un determinato messaggio. La differenza tra una firma autografa e la firma digitale è che la prima è direttamente riconducibile alla persona che l’ha apposta, mentre la seconda per ovviare a questa mancanza deve ricorrere a una autorità di certificazione (Certification Authority) la quale deve stabilire, garantire e rendere nota l’associazione della firma digitale all’individuo che la utilizza (questo argomento verrà ripreso nel par. 5.2)
Ogni utente deve quindi poter possedere una coppia di chiavi: una definita pubblica e l'altra privata.
La chiave pubblica è a disposizione di tutti gli altri utenti del servizio mentre quella privata è segreta, e utilizzabile dall'unico proprietario.
Le due chiavi sono matematicamente correlate tra di loro in modo tale che un messaggio codificato con una delle due può essere decodificato solo con l'altra.
In più, dalla conoscenza della chiave pubblica non in alcun modo possibile risalire alla corrispondente privata.
La confidenzialità del documento è quindi assicurata cifrando il testo in oggetto con la chiave pubblica del destinatario. Il destinatario userà la propria chiave privata (corrispondente a quella pubblica utilizzata dal mittente) per decifrarlo. Data la biunivocità delle chiavi solo il destinatario, e nessun’altro, potrà decifrare il documento.
In questo modo non viene però garantita né l’integrità né l’autenticità del documento, perché chiunque potrebbe impossessarsi della chiave pubblica del destinatario e inviargli un documento cifrato attribuendosi un falso nome o utilizzando illegittimamente un nome altrui.
L’autenticità del documento e la sua integrità vengono quindi assicurate mediante un’applicazione della crittografia asimmetrica nota come firma digitale.
La firma digitale è una tecnica che si avvale di funzioni hash unidirezionali, ovvero funzioni che ricevono in ingresso documenti di lunghezza qualsiasi, li elaborano secondo l'algoritmo proprio di ogni funzione, e producono in uscita un valore costituito da un numero fisso di cifre. L'unidirezionalità garantisce che da tale valore sia computazionalmente complesso risalire al documento originario.
Il procedimento di firma digitale inizia con la creazione della hash del documento; tale hash viene poi cifrata con la chiave privata del mittente, accluso al documento integrale e spedito. Il destinatario riceve il documento con la firma del mittente allegata, calcola una nuova hash sul documento ricevuto quindi decifra con la chiave pubblica del firmatario la hash allegata al documento. Se il valore calcolato dal destinatario coincide con quello decodificato attraverso la chiave pubblica del firmatario il processo di verifica si conclude con successo.
Figura 1 - La firma digitale come applicazione della cifratura asimmetrica
L’integrità del contenuto del documento inviato viene garantita dall'utilizzo dell'algoritmo hash: il valore in uscita di tale funzione è un dato strettamente legato al contenuto del documento stesso. Le funzioni hash sono infatti dette
collision-free: dati due diversi messaggi M1 ed M2 in ingresso, in uscita si
ottengono valori diversi h(M1) ≠ h(M2). Quindi se la verifica va a buon fine, si ha la garanzia che il documento non abbia subito manipolazioni in fase di trasmissione.
L’autenticità viene fornita dal meccanismo di decifratura: se infatti la verifica della firma si conclude con successo, la chiave pubblica usata per la decodifica identifica in maniera univoca il firmatario del documento, assumendo unica l'associazione tra coppie di chiavi e rispettivi proprietari.
1.3 Concetto di token sicuro
Il progetto M-P@y è nato come soluzione alle varie problematiche legate al pagamento su Internet con dispositivi non fidati come potrebbero essere i normali Personal Computer. Il problema non è tanto legato alla riservatezza della comunicazione o nell’integrità dei dati che viaggiano nella rete in quanto sono utilizzate soluzioni adeguate a tal proposito, i protocolli Secure Socket Layer (SSL) [SSL], Secure Electronic Transfer (SET) sono degli esempi.
Il problema risiede nella non affidabilità del PC dell’aquirente. Immaginiamo ad esempio uno scenario in cui un utente che naviga da un PC di un Internet Point o un Internet Cafè voglia effettuare un acquisto attraverso il servizio messo a disposizione sul sito di un negozio virtuale. Con buona probabilità per effettuare il pagamento verrà richiesto l’inserimento di dati privati come il numero di carta di credito del cliente.
Un software malizioso, installato sul PC dell’utente, potrebbe essere capace di modificare l’output su schermo dei dati arrivati in maniera sicura da Internet e allo stesso modo, in fase di input da tastiera, il numero di carta di credito o le coordinate bancarie potrebbero essere intercettate e modificate prima di essere inviate sulla Rete, con le evidenti conseguenze. Il problema quindi risiede nel fatto che l’utente non ha l’assoluta certezza che i dati presentati sul video non siano stati localmente intercettati né modificati e che essi provengano realmente dal negozio virtuale. Allo stesso modo il negozio virtuale non può essere sicuro che le informazioni giunte da Internet provengano dal dispositivo di memorizzazione/elaborazione dell’utente e che queste a loro volta siano proprio quelle inserite dal cliente tramite il dispositivo di input.
La situazione è rappresentata in Figura 1:
Nasce quindi l’esigenza di utilizzare quello che viene definito un token sicuro, un dispositivo cioè con cui l’utente interagisce localmente e il server di commercio elettronico remotamente (attraverso Internet) e che possiede le seguenti caratteristiche:
− presenza di un componente di elaborazione/memorizzazione fidato e difficilmente attaccabile (tamper-proof);
− presenza di un dispositivo fidato di input/output dal lato utente; − presenza di un dispositivo fidato di input/output dal lato della Rete; − portabilità.
È possibile quindi identificare il Token sicuro come un dispositivo portatile che garantisce integrità e provenienza dei dati ad entrambi i partecipanti alla transazione.
Un elemento che soddisfa i requisiti di token sicuro è un telefono cellulare GSM (Mobile Equipment, ME) dotato di carta Java SIM Card multi-applicazione con modulo WIM (WIM Card).
Il ME di fatto fornisce solamente i dispositivi di input/output da entrambi i lati, ma la carta permette di realizzare gli altri requisiti:
− il processore di cui è dotata e la EEPROM forniscono un’unità di elaborazione/memorizzazione;
− il dispositivo può considerarsi tamper-proof: la carta possiede una propria interfaccia, per cui posso essere invocate solo operazioni predefinite con determinati parametri di input/output.
− Tali operazioni inoltre sono eseguibili solo quando la carta è inserita in un lettore collegato a un PC.
− Inoltre l’accesso ai dati è controllato attraveso l’aiuto di PIN (Personal Identy Number) consentendo solo al proprietario della carta di accedervi. − Possiamo concludere quindi che la Java SIM Card protegge dati
memorizzati, chiavi, etc…;
− i canali di comunicazione con utente e server di commercio elettronico sono fidati grazie alla presenza del modulo WIM che fornisce meccanismi crittografici in grado di garantire integrità e confidenzialità dei messaggi.
2 STANDARD
2.1 Introduzione agli standard
Negli ultimi anni varie compagnie e associazioni di interesse al mobile commerce sono state fautrici di alleanze e di discussioni che hanno poi conseguito a realizzare degli standard a riguardo della tecnologia delle smart card, e più in specifico delle SIM card sia per quanto riguarda l’architettura interna che per l’interfacciamento del Mobile Equipement alla rete GSM, prendendo in considerazione i vari aspetti di autenticazione, di sicurezza e memorizzazione dei dati, coesistenza e scaricamento di più applicazioni nelle carte. La preoccupazione da più tempo è cercare di trovare una certa interoperabilità nel complesso delle varie tecnologie che riguardano le smart card, i device, il GSM che non può che creare un maggior beneficio e innovazione nei diversi settori. Le più grandi industrie quali Gemplus, Schlumberger, Oberthur, Microsoft, Visa, Mastercard,
Europey e molte altre in collaborazione con i diversi gruppi di standardizzazione
sono implicate in diverse alleanze trasversali atte a intensificare la promozione di sistemi interoperabili, anche se poi c’è piena libertà nel creare soluzioni proprietarie adatte a sviluppare sistemi ad hoc.
Inizialmente l’ETSI (European Telecommunications Standards Institute) [rif. ETSI] era la sola organizzazione responsabile della definizione e del mantenimento degli standard internazionali di telefonia mobile, ora dal 1999 essa insieme all’associazione GSM (Global System for Mobile) cooperano per impegno congiunto nella continua evoluzione degli standard wireless visto che ormai
stiamo andando verso la direzione dei sistemi di Terza Generazione (3G o UMTS) garantendo comunque una transazione dalla seconda alla terza generazione nel modo più semplice possibile. L’alleanza che ne è scaturita ha prodotto dei gruppi di standarizzazione, e in specifico nel capo della comunicazione mobile si sono creati due gruppi: il 3GPP-T3 [3GPPT3]che sviluppa l’interfacciamento tra Mobile
Equipement e la SIM card e il 3GPP-T2 [3GPPT2]che sviluppa la comunicazione
a basso livello e i meccanismi di sicurezza. Il 3GPP (3rd Generation Partnership
Project) raccoglie le vecchie versioni degli standard GSM e fornisce le nuove
versioni in prospettiva che il SIM Application Toolkit e gli Short Message Service
(SMS) possano essere utilizzati con la nuova tecnologia di terza generazione UMTS conservando però la piena compatibilità dei vecchi standard GSM.
Per realizzare applicazioni che possano essere utilizzate nei dispositivi GSM è necessaria la conoscenza approfondita di alcune caratteristiche peculiari di questo sistema di comunicazione mobile. In particolare è necessario conoscere la struttura della SIM Card presente all’interno dei cellulari e conoscere le modalità con cui il Mobile Equipment si interfaccia con essa per cui è necessario lo studio degli standard che definiscono la comunicazione tra le due entità, e quelli che descrivono le metodologie di realizzazione delle applicazioni per SIM Card (SIM
Application Toolkit – SAT).
Non meno importanti saranno gli standard che specificano la formattazione dei messaggi SMS e l’infrastruttura di sicurezza che il GSM prevede per essi. Gli SMS, infatti, vengono considerati ancora oggi il principale mezzo di comunicazione utilizzato nei servizi mobili.
Dopo aver presentato queste specifiche, descriveremo lo standard riguardante l’interfaccia di programmazione ad alto livello (SIM API) per realizzare applicazioni funzionanti su una SIM card e i linguaggi utilizzabili.
2.2 3GPP TS 51.011
3rd Generation Partnership Project; Technical Specification Group Terminals; Specification of the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface (Release 5)
Questo standard definisce la struttura interna della SIM Card, specifica l’organizzazione e il contenuto dei file al suo interno e descrive il protocollo di comunicazione fra ME e SIM, sia a livello di segnali elettrici, sia a livello di comandi scambiati fra essi. Attraverso questi comandi il ME può prelevare dalla carta le informazioni utilizzate in fase di autenticazione sulla rete GSM. Lo standard ha lo scopo di assicurare l’interoperabilità tra SIM ed ME indipendentemente dai produttori di cellulari, dai distributori di SIM Card e dagli operatori di rete.
Nel documento sono definiti i seguenti aspetti:
− I requisiti delle caratteristiche fisiche della SIM, dei segnali elettrici e dei protocolli di comunicazione tra SIM e ME.
− Il modello che deve essere seguito come base per il progetto della struttura logica di una SIM.
− Alcuni aspetti di sicurezza che coinvolgono la SIM card come l’autenticazione della SIM sulla rete, la confidenzialità dei dati trasmessi sul canale radio e le condizioni di accesso ai file presenti all’interno della carta.
− Il contenuto dei file richiesti per il funzionamento dell’applicazione GSM. − Il protocollo fra SIM e ME. In particolare vengono definiti i vari comandi
utilizzabili per gestire i file (nel rispetto delle condizioni di accesso), per modificare e verificare i PIN e per effettuare operazioni di autenticazione a livello di rete GSM.
La SIM card specificata in questo standard ha le caratteristiche di base di una normale Smart Card con File System. La struttura ad albero del File System viene organizzata in Dedicated File (DF), gli equivalenti delle directory, ed Elementary
File (EF), ovvero i file contenuti all’interno di un DF. La radice dell’albero è
denominata Master File (MF). In Figura 3 viene mostata la struttura ad albero dei file sulla SIM.
MF DF EF EF EF EF DF EF EF DF EF
Figura 3 - Struttura interna di una Smart Card e di una SIM Card.
Ogni File è univocamente definito dal suo ID (come un pathname), per cui con degli appositi comandi è possibile selezionare dei file o crearne dei nuovi, spostarsi all’interno della struttura gerarchica o fare operazione di lettura e scrittura.
Per accedere alla struttura è necessario conoscere il PIN (Personal
Identification Number) che viene considerato come Card Holder Verification information (CHV), ovvero è una informazione di verifica del possessore della
il funzionamento della SIM card. Nei file MF/DFgsm/Efimsi e MF/Eficcid sono
memorizzati rispettivamente, lo IMSI (International Mobile Subscriber Identity) identificativo che viene associato alla carta e con il quale è possibile autenticarsi nella rete GSM, e la chiave affinche l’autenticazione avvenga in modo sicuro.
In determinati files le compagnie telefoniche possono memorizzare un certo numero di parametri per precisare quali servizi la SIM può supportare, oppure possono memorizzare degli schedari e molto più importante possono scaricare o modificare delle applicazioni (o Applet) attraverso il metodo Over-The-Air che più avanti si descriverà.
2.2.1
Protocollo di scambio
Nella fase 2 (sempre specificata nello standar 3GPP TS 51.011) il dialogo si svolge unicamente sull’iniziativa del ME. Il ME è sempre Master, cioè è sempre lui che inizia la comunicazione con la SIM e non c’è nessun meccanismo per cui avviene il viceversa: la comunicazione si dice che è asincrona.
Il ME comunica con la SIM usando il protocollo “ T=0 “, cioè lo scambio di dati è:
− half duplex asincrono − orientato ai byte.
Inoltre il protocollo supporta il meccanismo di rilevazione degli errori basato sul controllo di parità.
Vi è un’altro tipo di procollo (T= 1), entrambi sono specificati nello standard
ISO/IEC 7816-3. Il protocollo di scamdio tra la SIM card e il lettore avviene in
base ad un paradigma del tipo comando-risposta attraverso delle strutture dati chiamate APDU (Application Protocol Data Unit). Le strutture dati APDU sono definite nello standard ISO 7816-4.
Normalmente quando si ha a che fare con SIM non proattive o, più in generale, con comuni Smart Card esiste una Host Application che invia, tramite un reader, dei comandi alla carta (Command APDU). La carta è capace solo di rispondere
(Response APDU) a questi comandi inviando alla Host Application dei codici (Status Word) e, eventualmente, dei dati. Nel caso di applicazioni per PC, la Host
Application è rappresentata dal programma che gira sul computer e si interfaccia, attraverso un lettore, alla Smart Card, mentre in ambito GSM essa è rappresentata dal firmware del telefono cellulare. In entrambi i casi il comportamento della carta è quello di uno Slave che risponde ai comandi inviati da un Master per leggere e scrivere dei dati al suo interno, la carta non può prendere nessuna iniziativa.
Figura 4 - Paradigma del protocollo standard: Smart Card – Host Application
Command APDU Response APDU
2.3 3GPP TS 51.011
3rd Generation Partnership Project; Technical Specification Group Terminals;
Specification of Subscriber Identity Module - Mobile Equipment (SIM - ME) Interface for SIM Application Toolkit (Release 5)
Questo standard descrive il SIM Application Toolkit (SAT), il meccanismo che permette alle applicazioni presenti sulla SIM di interagire ed operare con un qualsiasi ME che supporti i comandi proattivi. La carta SIM classica (che funziona solo per le specifiche della fase 2) non presenta che un funzionamento da slave come desrcitto nel paragrafo precedente. Nella fase 2+ descritta da questo standard
la carta SIM, dette pro-activa, resta sempre slave rispetto al ME ma può intraprendere delle azioni in risposta al ME, inviandogli appunto dei comandi pro-activi.
Per emettere un comando pro-active la carta SIM deve attendere che il ME la interroghi; per cui quest’ultimo, o periodicamente interroga la SIM con un apposito comando STATUS così che essa possa segnalargli la volontà di emettere un comando pro-active, oppure a seguito di un Commnd APDU, la SIM oltre che rispondere al ME attraverso una Response APDU, lo informa che ha intenzione di inviargli un comando pro-active. Ciò è reso possibile da una Status Word apposita (codificata con SW “ 91 xx “, dove xx è la lunghezza in byte del comando proattivo) in aggiunta al Response APDU. Il ME a quel punto invia un comando
Fetch e riceve in risposta il Proactive Command. Quando ha eseguito il comando
informa la SIM dell’esito dell’operazione e le passa eventuali dati all’interno di una Terminal Response. La SIM chiude il protocollo inviando una Response
APDU finale.
Figura 5 - Paradigma SIM Application Toolkit: Proactive SIM – ME
Command APDU Fetch Proactive Command Response APDU + Proactive Terminal Response Command Ready Response APDU
2.4 Comandi APDU
Lo standard ISO 7816-4 definisce due tipi di strutture APDU: − command APDU
− response APDU
Come illustratto nella figura.. il command APDU comprende lo header obbligatorio e un body che è opzionale, ognuno dei quail è suddiviso in alcuni campi.
Lo header include i campi CLA, INS, P1, e P2 che hanno il seguente significato:
CLA (1 byte): identifica una specifica classe di istruzioni. Indica il formato e la
categoria del comando e della risposta APDU.
INS (1 byte): specifica l’istruzione nella classe dei comandi CLA;
P1 (1 byte) e P2 (1 byte): specificano eventuali parametri dell’istruzione
definita nei precedenti campi. Possono essere utilizzati anche come campo di input per i dati;
Lc (1 byte): indica la lunghezza in byte della parte dati;
Dati: contiene i dati da inviare alla carta e la loro lunghezza è specificata in Lc;
Le (1 byte): massima lunghezza in byte dei dati che saranno eventualmente
inviati in risposta.
Command APDU
Header Obbligatorio Body Opzionale
CLA INS P1 P2 Lc Dati Le
Il response APDU possiede un body opzionale ed un trailer obbligatorio. Il
body contiene i Dati di lunghezza variabile e determinata in byte dal campo Le del command APDU. Il trailer contiene lo stato di funzionamento della carta;
SW1 (1 byte): specifica lo status word 1; SW2 (1 byte): specifica lo status word 2.
SW1 e SW2 costituiscono una status word che codifica se il command APDU è
stato processato correttamente o meno.
Body Opzionali Trailer Obbligatorio
Dati SW1 SW2
Figura 7 – Struttura del Response APDU
Ci sono vari casi di scambio di command/response APDU tra ME e SIM card pro-active che vengono contemplati nello standard ISO 7816-4.
2.4.1
Comandi Terminal Profile, Envelope e Terminal
Response
Il ME può inviare dati ad una SIM proattiva attraverso tre comandi: Terminal
Profile, Envelope, Terminal Response.
Il comando Terminal Profile è utilizzato dal ME per comunicare alla SIM le sue capacità nell’ambito del SAT. Questo comando viene inviato durante la fase di inizializzazione della SAT (questa attività è compresa nella procedura di inizializzazione della SIM), non appena il ME ha rilevato la SIM Proattiva ed ha richiesto e verificato il PIN1 (CHV1 verification). Nel caso in cui il ME non invii questo comando, la SIM disabilita le sue funzionalità SAT, assumendo che il ME non sia compatibile con lo standard 3GPP TS 51.011.
Il comando Envelope viene utilizzato dal ME per inviare alla SIM i dati relativi ad eventi che si sono verificati e di cui la SIM deve essere informata. Sulla SIM, infatti, possono essere presenti applicazioni SAT che, in fase di installazione, si
sono registrate ad una lista di eventi. Il ME verifica se per il corrente evento ci sono delle applicazioni registrate e, in tal caso, invia l’evento alla SIM tramite il comando ENVELOPE. In particolare, il comando ENVELOPE può trasportare i dati relativi ai seguenti eventi, che possiamo considerare principali:
− SMS-PP DOWNLOAD: Quando il ME riceve un SMS può verificare (esiste un apposito header) se si tratta di un data download via SMS-PP, in tal caso, il messaggio viene inviato trasparentemente alla SIM, attraverso il comando ENVELOPE(SMS-PP DOWNLOAD). La SIM può rispondere con un comando proattivo e, eventualmente, fornire un acknowledgement da inviare al mittente dell’SMS. In Figura rappresentiamo un possibile scenario
− MENU SELECTION: Come vedremo meglio in seguito, applicazioni residenti sulla SIM hanno la possibilità di aggiungere dei nuovi “menu item” al normale menu presente sul ME e definito nel suo firmware. Nel caso venga selezionato uno di questi item, il ME avverte la SIM attraverso il comando ENVELOPE (MENU SELECTION). Nella Figura 6 rappresentiamo un possibile scenario in cui l’utente seleziona un menu item corrispondente ad un’applicazione SAT. La SIM risponde all’ENVELOPE con un comando proattivo che visualizza una stringa a video.
− TIMER EXPIRATION: La SIM può attivare dei timer sul ME attraverso un apposito comando proattivo. Questi timer sono molto utili per realizzare meccanismi di timeout, che la SIM non sarebbe in grado di realizzare altrimenti. Non appena un timer arriva a zero, il ME invia il comando ENVELOPE(TIMER EXPIRATION) per indicare alla SIM quale timer è appena spirato.
− Esiste poi una serie di altri eventi, che possiamo considerare secondari, che vengono comunicati alla SIM in maniera leggermente diversa. Nel caso ci
siano applicazioni registrate per tali eventi, viene utilizzato il comando ENVELOPE(EVENT DOWNLOAD – XX EVENT) per comunicare con la SIM.
− Come esempi di questo genere di eventi possiamo considerare: l’arrivo di una chiamata, la terminazione di una chiamata, la pressione di un tasto da parte dell’utente, il cambiamento della lingua dei menu.
− Il comando Terminal Response è utilizzato dal ME per rispondere ad un comando proattivo precedentemente inviato dalla SIM card. Ciascun comando proattivo impone al ME di inviare un particolare comando TERMINAL RESPONSE in risposta. All’interno di questo comando deve essere sempre specificato se il ME è stato o meno in grado di eseguire il comando proattivo inviatogli. Nel caso in cui il comando proattivo non sia stato eseguito correttamente, il ME deve comunicare alla SIM informazioni sintetiche sui problemi incontrati nell’esecuzione del comando. Ad esempio, se la SIM richiede l’invio di un SMS, il ME può rispondere che il comando non è eseguibile perché in quel momento non c’è abbastanza campo per effettuare la trasmissione. Quando il ME non riesce a portare correttamente a termine l’operazione richiesta, la responsabilità di effettuare un nuovo tentativo risiede tutta nell’applicazione SAT che deve effettuare una opportuna gestione degli errori.
Figura 8 - Invio di un ENVELOPE Data Download SMS-PP alla SIM.
2.4.2
Formato dei Comandi Proattivi, dei Comandi Envelope e
Terminal Response
I comandi proattivi, il comando ENVELOPE ed il comando TERMINAL RESPONSE sono costruiti secondo il formato BER-TLV Data Object (Basic
Encoding Rules–Tag Length Value) ed inseriti nel campo DATA di una Command/Response APDU. La codifica TLV prende il nome dagli elementi che la
compongono:
− Tag: Identifica il tipo dell’oggetto formattato come TLV.
− Length: Identifica la lunghezza in byte del campo Value dell’oggetto. − Value: Identifica il valore (o i valori) contenuto nell’oggetto.
Un singolo oggetto formattato TLV può contenere al suo interno altri oggetti, a loro volta in formato TLV.
Riportiamo in Figura 7 la struttura generale del formato BER-TLV utilizzato:
Tag Length Value: 1…n SIMPLE-TLV object
BER-TLV Data Object
Tag Length Value: 1…n elements
SIMPLE-TLV Data Object (da 1 a n elementi value)
Figura 9- Formato BER-TLV per Comandi Proattivi, ENVELOPE e TERMINAL RESPONSE
Il tag del BER-TLV Data Object è un valore costante, della lunghezza di un byte, che indica che si tratta di un comando del SAT. Il campo value dell’oggetto BER-TLV è composto da uno o più SIMPLE-TLV Data Object come mostrato in figura, i quali, a loro volta, possono avere il proprio campo value composto da uno o più elementi.
Lo standard 3GPP 51.011 definisce la struttura BER-TLV di ogni comando proattivo, di ogni comando ENVELOPE e di ogni comando TERMINAL RESPONSE.
2.5 Over-The-Air (OTA)
Over-The-Air (OTA) è una tecnologia usata per scaricare le applicazioni e
maneggiare la SIM card senza la necessità di avere dei collegamenti fisici con essa. Un operatore mobile in grado di usare questa tecnologia è capace di scaricare più applicazioni(o Applet), se la carta è multi-applicazione, o modificare il contenuto delle SIM card in modo estremamente efficiente, rapido e con un costo effettivo della comunicazione.
OTA è basata su una architettura client/server dove da una parte vi è applicatione server e dall’altra la SIM card. L’applicazione server manda una richiesta di servizio a un Gateway OTA il quale la trasforma in un Short Messages e attraverso il Short Message Service Centre (SMSC) la trasmette a una o più SIMs cards.
2.6 3GPP TS 23.040
3rd Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS); (Release 6)
Gli SMS sono ancora considerati il principale veicolo di comunicazione utilizzato nei Mobile Services. Lo standard 3GPP TS 23.040 definisce proprio il formato e le caratteristiche dei messaggi SMS.
Le dimensioni possibili per un SMS sono:
− 160 caratteri: nel caso di messaggi SMS testo che siano compatibili con il 7-bit default alphabet, l’alfabeto utilizzato dal GSM per la gestione delle stringhe di testo
− 140 byte: nel caso di messaggi SMS binari, come quelli utilizzati nel Data Download SMS-PP.
Gli SMS contengono molte informazioni riguardanti il mittente ed il destinatario del messaggio, esse sono utilizzate dall’infrastruttura di rete per recapitare correttamente l’SMS,.
Il formato del messaggio SMS è Tag-Length-Value (TLV), per in nostri scopi è interessante soltanto il campo User Data (TP-UD) contenuto, a sua volta nel campo Value del messaggio. Il campo User Data che può contenere le informazioni utili per le applicazioni residenti sulla carta o per il server remoto.
Per rendere sicuro il Servizio SMS ed utilizzarlo nell’ambito del trasferimento di informazioni tra Applicazioni Server ed Applicazioni SAT, è stato definito lo standard 3GPP TS 22.048 che descrive una sovrastruttura sicura da inserire in un normale messaggio SMS binario.
2.7 3GPP TS 22.048
3rd Generation Partnership Project; Technical Specification Group Terminals; Security mechanisms for the (U)SIM Application Toolkit;
Stage 1 (Release 5)
Il SAT permette agli operatori di creare specifiche applicazioni residenti sulla SIM. Tuttavia, se le applicazioni SAT richiedono particolari requisiti di sicurezza, è necessario dotare il GSM di una apposita sovrastruttura per evitare problemi nel trattamento di informazioni sensibili.
Un possibile scenario di applicazione per lo standard 3GPP TS 22.048 può essere sintetizzato dalla seguente figura:
Figura 10 - Scenario di utilizzo dei meccanismi di sicurezza dello standard 3GPP TS 22.048
In Figura 8 è rappresentata una Applicazione Server (ad esempio in esecuzione sui server di una banca) che ha bisogno di comunicare in maniera sicura con l’applicazione SAT residente su una SIM proattiva. L’Applicazione Server utilizza, per inviare e ricevere i dati sottoforma di SMS, un particolare server chiamato SMS-SC (Short Message Service – Service Centre).
Le estensioni di sicurezza di questo standard vengono applicate a livello di
SMS-SC e di SIM Proattiva, questi due componenti del sistema svolgono
contemporaneamente le funzioni di Sending Entity e Receiving Entity. Sending Application Sending Entry Receiving Entity Receiving Application SMS su rete GSM SIM Proattiva Applicazione SAT residente Server per l’invio degli SMS (SMS-SC) Sending Application Transport Mechanism SICUREZZA SICUREZZA Applicazione Server Transport Receiving Application Receiving Entity Sending Entry Mechanism SICUREZZA SICUREZZA
I messaggi scambiati a livello applicativo da queste due entità possono avere dimensioni maggiori di quelle consentite da un singolo SMS. Per questo motivo è possibile frammentare, a livello di applicazione, ciascun messaggio applicativo in più messaggi SMS che seguano lo standard 3GPP TS 22.048, ognuno di questi SMS viene chiamato Secured Packet.
Ciascun Secured Packet ha un Security Header ed è proprio all’interno di quest’ultimo che sono inserite le informazioni di sicurezza specificate da questo standard.
Le caratteristiche introdotte dallo standard 3GPP TS 22.048, in aggiunta alle normali proprietà degli SMS utilizzati nel Data Download SMS-PP, sono le seguenti:
Autenticazione Unilaterale:
lo standard prevede solo l’autenticazione della Sending Entity da parte della Receiving Entity. Lo standard stesso precisa che il motivo principale per cui non è possibile una autenticazione mutua (in cui sia la Sending Entity che la Receiving Entity forniscono una prova della loro identità) risiede nel fatto che il meccanismo di trasporto (gli SMS) è essenzialmente unidirezionale.
Il 3GPP TS 22.048 definisce due sistemi di autenticazione: il primo è basato su Firma Digitale, il secondo si basa su un Checksum Crittografico. Entrambi i sistemi di autenticazione sono basati su chiavi crittografiche definite a livello applicativo.
La firma digitale permette il non ripudio dei messaggi inviati, al contrario il checksum crittografico non lo consente, perché basato sulla cifratura simmetrica con chiave condivisa.
Il sistema di autenticazione utilizzato offre anche garanzie di Integrità, Riconoscimento di Sequenza e Prova di Ricevimento di un messaggio applicativo.
lo standard garantisce la ricezione integra del messaggio inviato dalla Sending Entity. Le informazioni inserite nel Security Header che consentono l’autenticazione unilaterale dell’entità che invia il messaggio (firma digitale e checksum crittografico) sono utilizzate per garantire l’integrità dei Secured Packet inviati.
Riconoscimento di SMS duplicati ed indicazione della sequenza:
il Security Heaader di ogni Secured Packet contiene un contatore che, a sua volta, è protetto dalla firma digitale o dal checksum crittografico utilizzati per l’autenticazione.
Attestato di ricevimento di un messagio applicativo:
il 3GPP TS 22.048 prevede la possibilità da parte della Sending Entity di richiedere alla Receiving Entity un attestato di ricevimento del messaggio a livello applicativo (quest’ultimo può essere composto da un certo numero di Secured Packet concatenati).
Questo acknowledgement viene inviato sottoforma di status code a cui si aggiunge una firma digitale o un checksum crittografico.
Confidenzialità:
nel caso in cui si voglia garantire la confidenzialità dei messaggi inviati, lo standard prevede la possibilità di cifrare i Secured Packet con algoritmi di cifratura che dipendono dall’implementazione.
E’importante sottolineare che quest’ultima caratteristica è opzionale e può essere utilizzata o meno in concomitanza con gli altri tre meccanismi.
Il 3GPP TS 22.048, come abbiamo visto, fornisce solo delle linee guida per la realizzazione di un sistema di comunicazione sicuro tra le due entità della comunicazione. L’implementazione vera e propria di queste caratteristiche viene descritta nello standard 3GPP TS 23.048.
2.8 3GPP TS 23.048
3rd Generation Partnership Project; Technical Specification Group Terminals; Security Mechanisms for the (U)SIM application toolkit; Stage 2 (Release 5)
Questa specifica descrive l’implementazione del precedente standard 3GPP TS 22.048.
Questo documento definisce nel dettaglio la struttura di un Secure Packet ed estende l’utilizzo di questi particolari SMS alla realizzazione di funzionalità di gestione remota dei file e di scaricamento dinamico di applicazioni su una SIM Proattiva.
I messaggi a livello applicativo che le due entità di scambiano vengono distinti in Command Packet, inviati dalla Sending Entity e Response Packet, inviati dalla
Response Entity (principalmente per attestare il ricevimento di un Command
Packet).
Come già anticipato, un messaggio a livello applicativo può essere frammentato in più Secured Packet, nel caso in cui la dimensione di un SMS non sia sufficiente a contenere sia i dati dell’applicazione che le informazioni di sicurezza.
Nella seguente Figura 9 diamo una rappresentazione di come viene frammentato un Command Packet (per quanto riguarda un Response Packet la struttura è praticamente identica):
CH Secured Data Padding
Figura 11 - Suddivisione di un Command Packet in più Secured Packet
CH
CH - Command Header. Questo campo contiene il Command Security
−
− tuale padding necessario per le
− po contiene le informazioni di
− di Secured Data contenuta nel
ttraverso i messaggi codificati in questa specifica è possibile anche gestire rem
ni sulla car
SIM Card. −
Header del Command Packet. Si tratta di un Security Header con
informazioni riguardanti l’intero messaggio applicativo, non frammentato.
Secured Data. Questo campo contiene le informazioni del messaggio
applicativo che sono state trattate con i meccanismi di sicurezza permessi dallo standard (cifratura, firma digitale etc.). Una porzione di queste informazioni verrà inserita in ciascun Secured Packet per permetterne la trasmissione sottoforma di SMS.
Padding. Questo campo contiene un even
operazioni crittografiche sui dati.
CCn – Concatenation Control. Questo cam
concatenazione dei Secured Packet componenti (ad esempio il numero del messaggio all’interno della sequenza originaria) necessarie per ricreare il messaggio applicativo di origine.
SDn. Questo campo contiene la porzione
singolo Secured Packet n-esimo.
A
otamente il File System di una SIM card compatibile con questo standard. Ciascun comando definito nel 3GPP TS 51.011 ha un proprio Command Packet equivalente, in questo modo una Applicazione Server è in grado di controllare il File System di una SIM Card nel rispetto dei corretti requisiti di sicurezza.
Per quanto riguarda la gestione remota dello scaricamento di applicazio
ta viene fatto riferimento allo standard Global Platform, specificando la struttura di ciascun messaggio. Grazie al supporto di Global Platform, lo standard 3GPP TS 23.048 costituisce il Common Loader utilizzato nell’ambito delle Java
2.9 3GPP TS 42.019
3rd Generation Partnership Project; minals;
rib ation Programming Interface (SIM API);
Stage 1 (Release 5)
n Programming Interface: SIM API) per un Open Operating System (Open OS – Sistema Operativo aperto) per la realizzazione di applicazioni
su SIM Proattiv
oni descritte negli standard 3GPP TS 51.011 e 3GPP TS 51.014, così che i servizi basati su SIM possono essere
ente e remotamente.
Il 3GPP TS 42.019 descrive in m
offrire e contiene i principali requisiti art
Card senza scendere nei dettagli implementativi. All’interno della specifica si considerano com
Technical Specification Group Ter
Subsc er Identity Module Applic
Nello standard in questione viene definite una interfaccia (Subscriber Identity
Module – Applicatio
e. Utilizzando il termine Open OS in questo documento, non viene specificato il sistema operativo della carta MASC da utilizzare. Non esiste un unico sistema operativo per carte SIM multi-applicazione (Java Card, Multos, e altri sistemi operativi proprietari), Open OS identifica semplicemente un generico sistema operativo per questo tipo di carte.
La SIM API definita ha i seguenti obiettivi: − Fornire un facile accesso alle funzi
sviluppati e caricati all’interno delle SIMs velocem
− Permettere l’interoperabilità a livello di SIM Application Toolkit.
aniera generale i servizi che l’interfaccia deve industriali richiesti ai produttori di Sm
e ugualmente possibili tutti i sistemi operativi presenti sul mercato delle Smart Card multi-applicazione. In Figura 10 sintetizziamo l’architettura della SIM API descritta da questo standard.
Figura 12 - Architettura della SIM API GSM SIM Kernel GSM File System Accesso ai File APDU (ad esempio: Comando ENVELOPE) … Accesso ai File Toolkit Toolkit Applet (1) Applet (2) Attivazion edella Toolkit Comandi Proattivi Risposte ai Comandi Proattivi Toolkit Applet (j)
SIM API Framework
Applet Triggering Gestione dei Comandi Proattivi Installazione Disinstallazione Applet Gestione della
Sicurezza Strutture Dati necessarie alla Gestione della Sicurezza Proactive Polling; Comandi: FETCH, TERMINAL RESPONSE Status Response 91 XX; Comandi Proattivi APDU Interfaccia verso il Mobile Equipment Normal Applet (i)
Diamo una breve descrizione delle varie componenti r ig
− Applet. Normale Smart Card Applet, caricata sulla carta e invisibile al SIM Application Toolkit, perché da esso non riconosciuta. A seconda del tipo di rd m azio a q Applet devono sottostare a inate regole.
− Toolkit Applet. Questo particolare tipo di Applet viene visto dal ME come
se f plicazio effetti. scopo di
permettere la realizzazione di Toolkit Applet in maniera semplice e rapida; con essa, infatti, si riescon ticamente i tempi di sviluppo che in precedenza erano necess nere appl
− SIM API Framework. Questo componente è una parte della SIM nsabile di ge plicazio per quanto riguarda la loro
(trigge il loro ca . Il SIM API Framework
n insiem i e stru utilizzabili p po
di applicazioni, m posizione un certo numero di primitive di sistema. Possiamo scomporr ework in cinque componenti: − Applet Triggering. Questo te è responsabile della attivazione
delle applet a seconda delle APDU ricevute. I comandi ENVELOPE (rif. par. 3.4.1)permettono l’attivazione di una particolare Applet.
− Installazione / Disinstallazione Applet. Questo componente permette di installare e disinstallare in maniera sicura le Applet sulla carta.
− Gestione della Sicure onent
integrata dei meccanism rodotti dallo standard 3GPP TS 23.048. In questo modo è possibile aggiungere caratteristiche di sicurezza
aff urate:
Smart Ca determ
ulti-applic ne utilizzat ueste
osse una ap ne SAT a tutti gli La SIM API ha lo
o a ridurre dras
ari per otte icazioni SAT.
respo stire le ap ni sia
ricamento
ring) che
e di funzion ettendo a dis attivazione
definisce u tture dati er lo svilup
e questo fram componen
zza. Questo comp
i di sicurezza int
sia allo scaricamento dinamico di Applet sulla carta che alla comunicazione tra applicazioni SAT e applicazioni Server.
2.10
3rd G Termin
(SIM API); Stage 1 (Release 5)
o standard 3GPP TS 43.019 definisce l’implementazione della SIM API su una v
API, b sezione
Sul stabilit
− Strutture Dati necessarie alla Gestione della Sicurezza. Questo componente costituisce la base di dati necessaria per implementare la Gestione della Sicurezza secondo quanto specificato dallo standard 3GPP TS 23.048.
3GPP TS 43.019
eneration Partnership Project;Technical Specification Group als; Subscriber Identity Module Application Programming Interface
L
Ja a SIM Card. Questa API è classificata come estensione della Java Card 2.1 asata sul Java Card 2.1 Runtime Environment. Si faccia riferimento alla
dedicata alle Java Card per avere un visione d’insieme di tale tecnologia. la base dell’architettura della SIM API definita dal 3GPP TS 42.019, viene a la struttura di una Java SIM così come rappresentato in Figura ….
Toolkit Applet (i) Loader GSM
Applet Applet (j) Applet
Figura 13 - Architettura di una Java SIM Card
Lo standard 3GPP TS 43.019 precisa alcuni dei concetti presentati nel GSM 3GPP TS 42.019 specificandoli facendo riferimento diretto all’ambiente Java Card:
− Applet. Il concetto di Applet è lo stesso dell’ambiente Java Card [rif. JCAPI, JCVM, JCRE].
− Toolkit Applet. Viene considerata Toolkit Applet una Java Card Applet che implementi anche l’interfaccia necessaria a comunicare con il SIM Toolkit Framework. A differenza di una normale Applet, Una Toolkit Applet non gestisce direttamente le APDU. Ad essa arrivano messaggi a più alto livello (trasmessi dal ME tramite i comandi ENVELOPE e interpretati dal SIM Toolkit Framework), inoltre l’esecuzione di un metodo
Toolkit Registry
SIM Toolkit Framework Toolkit Handler
File System
