ITMI20102473A1 - Metodo e sistema di controllo di una comunicazione tra una carta universale a circuito integrato ed una applicazione esterna - Google Patents

Metodo e sistema di controllo di una comunicazione tra una carta universale a circuito integrato ed una applicazione esterna Download PDF

Info

Publication number
ITMI20102473A1
ITMI20102473A1 IT002473A ITMI20102473A ITMI20102473A1 IT MI20102473 A1 ITMI20102473 A1 IT MI20102473A1 IT 002473 A IT002473 A IT 002473A IT MI20102473 A ITMI20102473 A IT MI20102473A IT MI20102473 A1 ITMI20102473 A1 IT MI20102473A1
Authority
IT
Italy
Prior art keywords
uicc
portable device
external
communication
attribute
Prior art date
Application number
IT002473A
Other languages
English (en)
Inventor
Angelo Castaldo
Francesco Varone
Amedeo Veneroso
Original Assignee
Incard Sa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Incard Sa filed Critical Incard Sa
Priority to ITMI2010A002473A priority Critical patent/IT1404159B1/it
Priority to US13/339,819 priority patent/US9143922B2/en
Publication of ITMI20102473A1 publication Critical patent/ITMI20102473A1/it
Application granted granted Critical
Publication of IT1404159B1 publication Critical patent/IT1404159B1/it

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications

Description

DESCRIZIONE
Campo di applicazione
La presente invenzione riguarda un metodo di controllo di una comunicazione tra una UICC e un dispositivo esterno comprendente le fasi di: accensione della UICC da parte di un dispositivo portatile comprendente la UICC; esecuzione di una prima procedura di inizializzazione da parte del dispositivo portatile, per stabilire una prima sessione di comunicazione tra il dispositivo portatile e la UICC; invio di una richiesta di connessione al dispositivo portatile da parte del dispositivo esterno o viceversa, per stabilire una seconda sessione di comunicazione tra la UICC e il dispositivo esterno; ed esecuzione di una seconda procedura di inizializzazione tra il dispositivo esterno e la UICC. L’invenzione riguarda inoltre un sistema di controllo di una comunicazione tra una UICC e un dispositivo esterno.
Arte nota
Come noto, un metodo di controllo di una comunicazione tra una UICC e un dispositivo esterno prevede che un dispositivo portatile comprendente la UICC esegua alcune fasi per pilotare la connessione tra la UICC e il dispositivo esterno. Con riferimento alla figura 1, viene rappresentato schematicamente un ambiente di comunicazione tra una UICC 10 ed un dispositivo esterno 14, per esempio un PC 14, via Bluetooth. La UICC 10 à ̈ inserita nel dispositivo portatile 12. Il PC 14 à ̈ collegato ad un server 16 via internet o altri tipi di connessioni di rete. Nel PC 14 o nel server 16 si trova un’applicazione esterna, per comunicare con la UICC 10. Il dispositivo portatile 12 à ̈ collegato al PC 14 via Bluetooth 18. Il profilo di accesso alla SIM via Bluetooth (SAP) può essere utilizzato per la comunicazione tra UICC 10 e PC 14.
Quando il dispositivo portatile 12 si trova nel campo di un dispositivo che supporta il Bluetooth SAP, vale a dire PC 14, probabilmente essi si collegano. La connessione può essere automatica o condizionata da una risposta positiva del possessore del dispositivo portatile 12, che viene sollecitato con un messaggio di notifica sul display del dispositivo portatile 12. Quando il dispositivo portatile 12 e il PC 14 sono collegati, il dispositivo portatile 12 smette di inviare APDU generate da sé alla UICC 10. Inizia piuttosto a inviare alla UICC 10 le APDUs ricevute dal dispositivo esterno 14. Viene inviato qualsiasi tipo di APDU. Per esempio, se il dispositivo esterno abilitato Bluetooth SAP 14 comprende capacità di telecomunicazione, esso opera come un telefono mobile utilizzando il numero mobile e le credenziali di autenticazione di rete relative alla UICC 10, mentre questa à ̈ ancora inserita nel dispositivo portatile 12. Questa à ̈ una situazione comune, poiché molti dispositivi SAP attuali sono kit per auto per utilizzatori che parlino a mani libere. In questo caso, la UICC 10 non sa a quale dispositivo, dispositivo portatile 12 o dispositivo esterno 14, sta accedendo ad essa in un dato momento.
Più in particolare, le fasi sopra descritte con riferimento alla figura 1 comprendono: accensione della UICC da parte di un dispositivo portatile comprendente la UICC; esecuzione di una prima procedura di inizializzazione da parte del dispositivo portatile, per stabilire una prima sessione di comunicazione tra il dispositivo portatile e la UICC; invio di una richiesta di connessione al dispositivo portatile da parte del dispositivo esterno o viceversa, per stabilire una seconda sessione di comunicazione tra la UICC e il dispositivo esterno; ed esecuzione di una seconda procedura di inizializzazione tra il dispositivo esterno e la UICC.
La seconda procedura di inizializzazione à ̈ necessaria poiché la UICC e il dispositivo esterno devono scambiare informazioni circa le loro rispettive caratteristiche per operare correttamente. In particolare, i dispositivi esterni potrebbero avere caratteristiche diverse rispetto al dispositivo portatile.
Possono verificarsi svariati problemi nella comunicazione tra la UICC e il dispositivo esterno descritti sopra. Un primo problema potrebbe verificarsi dopo una autentica corretta del PIN del dispositivo esterno, per esempio poiché un’applicazione di tale dispositivo esterno accede ai dati personali dell’utente mentre finge di fornire un certo servizio o dati. Altrimenti, l’applicazione può modificare i dati personali memorizzati nella UICC 10 senza autorità. Un altro problema può verificarsi poiché l’operatività della UICC viene interrotta, per esempio poiché il dispositivo esterno 14 esegue una verifica del PIN con un PIN sbagliato: dopo solo pochi tentativi, la UICC 10 à ̈ bloccata a causa del’inserimento del PIN sbagliato; ciò blocca tutti gli altri accessi da altre applicazioni finché il titolare della UICC 10 non re-imposta il dispositivo portatile 12 e inserisce il numero corretto di sblocco (PUK) per la UICC. Ciononostante, l’operatività della UICC à ̈ definitivamente compromessa se il dispositivo esterno 14 esegue una piccola serie di sblocchi del PIN con un numero PUK sbagliato. In tutti questi casi, la UICC 10 non può rilevare se à ̈ connessa dal dispositivo portatile 12 o dall'applicazione esterna di una terza parte, cioà ̈ dal dispositivo esterno, e così risponde semplicemente alle richieste come arrivano dal dispositivo portatile.
In svariati ambienti di applicazione, compresa una interazione della UICC con ambienti orientati verso internet, quali un protocollo USB, un server Smart Card Web, W-LAN e GBA, sarebbe molto utile utilizzare le informazioni credenziali altamente confidenziali sulla UICC per autenticare l’utente; ciò permetterebbe di lanciare modelli di business con terze parti e operatori commerciali su Web fornendo servizi di autenticazione basati su UICC, con l'operatore di rete in grado di identificare e fornire garanzie circa l'identità dell'utente, per esempio per vendere su internet con le credenziali dell’utente autenticate dalla UICC.
Tuttavia, mentre la comunicazione diretta tra un dispositivo esterno, quale un PC, e una UICC offre una grande comodità all’utente, ciò può minacciare la sicurezza e la privacy del possessore del dispositivo portatile, poiché la UICC 10 non à ̈ in grado di rilevare se à ̈ collegata logicamente al dispositivo portatile o all’applicazione esterna della terza parte funzionante sul dispositivo esterno, e risponde semplicemente alle richieste quando arrivano dal dispositivo portatile. Così, un software non autorizzato può accedere ad alcune informazioni private contenute nella UICC senza concessione di un permesso da parte del possessore della UICC; software pericolosi possono agire come un virus per l’intero sistema.
Vale la pena notare che un dispositivo esterno, quale un PC, abilitato a comunicare con una UICC utilizzando un protocollo senza fili à ̈ più critico di un dispositivo portatile personale dal punto di vista della sicurezza. Infatti il dispositivo esterno non potrebbe né essere mantenuto né posseduto dal possessore della UICC, poiché potrebbe essere un servizio offerto in un ambiente pubblico (bar, cinema, museo, stazione di trasporti); pertanto il possessore della UICC non à ̈ in grado di garantire la sua sicurezza; inoltre un PC à ̈ più vulnerabile ai virus e ai software maligni rispetto ai dispositivi mobili tipici, a causa del maggior grado di programmabilità. Ciononostante, gli stessi problemi potrebbero influire anche su un dispositivo portatile personale.
Il problema tecnico del metodo descritto sopra à ̈ che la UICC 10 à ̈ esposta ad applicazioni maligne o malfunzionanti, poiché la UICC 10 garantisce un accesso completo ad applicazioni e dispositivi esterni sconosciuti di terze parti quando le applicazioni e i dispositivi esterni sconosciuti di terze parti collegano il dispositivo portatile 12.
Sommario dellinvenzione
L’idea di soluzione alla base della presente invenzione à ̈ quella di prevedere che la UICC abbia mezzi tecnici per distinguere una sessione di comunicazione con un dispositivo esterno rispetto ad una sessione di comunicazione con un dispositivo portatile.
Secondo questa idea di soluzione, il problema à ̈ risolto da un metodo di controllo di una comunicazione tra una UICC, un dispositivo portatile comprendente la UICC ed un dispositivo esterno associato ad una applicazione esterna funzionante fuori dal dispositivo portatile, comprendete le fasi di:
-accensione della UICC da parte del dispositivo portatile, -esecuzione di una prima procedura di inizializzazione da parte del dispositivo portatile per stabilire una sessione di comunicazione tra il dispositivo portatile e la UICC,
-scambio di una richiesta di connessione tra il dispositivo portatile e il dispositivo esterno, per stabilire una seconda sessione di comunicazione tra la UICC e il dispositivo esterno, e
-esecuzione di una seconda procedura di inizializzazione tra il dispositivo esterno e la UICC,
caratterizzato dal fatto di comprendere le fasi di:
-recupero di un attributo del dispositivo portatile da parte della UICC dopo detta fase di esecuzione della prima procedura di inizializzazione,
-recupero di un attributo del dispositivo esterno tramite il dispositivo portatile da parte della UICC dopo detta fase di esecuzione della seconda procedura di inizializzazione, e
- confronto dell’attributo del dispositivo portatile con l’attributo del dispositivo esterno per distinguere la seconda sessione di comunicazione dalla prima sessione di comunicazione.
Vantaggiosamente, secondo il metodo dell’invenzione, la UICC distingue la sessione di comunicazione con l’applicazione esterna dalla sessione di comunicazione con il dispositivo portatile; così la UICC sa dove sono generati i pacchetti APDU, cioà ̈ nel dispositivo portatile o nel dispositivo esterno, ed à ̈ in grado di gestire diversi diritti di accesso per le risorse e applicazioni della UICC, a seconda degli autori dei pacchetti APDU.
Il metodo può essere applicato per tutti i protocolli in cui dovrebbe essere rilevata l’origine dell’istruzione ricevuta dalla UICC. Preferibilmente, la seconda sessione di comunicazione può essere una sessione Bluetooth SAP con il dispositivo esterno.
Secondo un aspetto della presente invenzione, l’attributo del dispositivo portatile à ̈ llnternational Mobile Equipment Identity (IMEI) del dispositivo portatile. L’IMEI à ̈ un numero identificativo dei telefoni mobile attivi in una rete quale GSM, WCDMA, e iDEN, cosi come alcune reti satellitari. L’applicazione esterna dovrebbe avere una sola IMEI assegnata da un ente autorizzato e la fornisce alla UICC, quando la UICC la richiede per il rilevamento. Il numero IMEI fornito dall’applicazione esterna à ̈ diverso dal numero IMEI del dispositivo portatile; pertanto, la UICC distingue con quale dispositivo sta comunicando.
Un’applicazione esterna non standard può generare un numero IMEI arbitrario a caso o memorizzare uno specifico numero IMEI ma à ̈ improbabile che sia adatto per lΊΜΕΙ del dispositivo portatile.
Un’applicazione esterna maligna potrebbe tentare di indovinare il dispositivo portatile IMEI ma à ̈ quasi improbabile che tale applicazione riesca a fare ciò, poiché la IMEI à ̈ un numero molto lungo, difficile da rilevare registrando l’attività di un altro dispositivo portatile utilizzando solo un hardware convenzionale.
In un altro aspetto della presente invenzione, l’attributo del dispositivo portatile à ̈ il profilo del terminale del dispositivo portatile. Il profilo del terminale à ̈ una stringa che codifica l’insieme delle caratteristiche del dispositivo portatile, per esempio può essere una lista a mappa di bit delle caratteristiche del dispositivo portatile. L’applicazione esterna può generare un profilo arbitrario del terminale a caso o memorizzare un profilo specifico del terminale e fornirlo alla UICC, quando la UICC lo richiede. Il profilo del terminale per l’applicazione esterna può avere lo stesso format del dispositivo portatile.
In un altro aspetto della presente invenzione, le istruzioni APDU disponibili per un’applicazione esterna sono limitate ad uno specifico sottoinsieme di istruzioni accettate dalla UICC, per fornire un servizio corrispondente previsto dall’applicazione esterna, dopo che à ̈ stata stabilita la sessione di comunicazione. Ciascun servizio previsto dall’applicazione esterna può avere diversi requisiti per la UICC, così se la UICC può identificare l’applicazione esterna (vale a dire controllare se lΙMEI del dispositivo esterno si trova in un dato campo o ha una data struttura, osservare il tipo di APDUs ricevute ecc.), può limitare le istruzioni APDU disponibili ad uno specifico sottoinsieme a seconda del servizio. In alternativa, può limitare le istruzioni APDU disponibili a prescindere dal servizio.
In un altro aspetto della presente invenzione, APDU o i dati APDU vengono fatti comunicare attraverso un protocollo predeterminato tra la UICC e l’applicazione esterna, dopo che viene stabilita la seconda sessione di comunicazione. Il protocollo predeterminato può essere un protocollo segreto noto solo alla UICC e all’applicazione esterna. Ciò garantisce la confidenzialità tra la UICC e l’applicazione esterna e rende più difficile ad un’applicazione maligna origliare la comunicazione della UICC con l’applicazione esterna.
In un altro aspetto della presente invenzione, la UICC restituisce i dati invalidi alla richiesta di autenticazione dall’applicazione esterna e disabilita l’accesso PIN dopo che à ̈ stata stabilita la seconda sessione di comunicazione. In tal modo, la UICC non à ̈ bloccata dal malfunzionamento dell’applicazione esterna, anche se l’applicazione esterna invia la richiesta della APDU circa la verifica del PIN con un numero PIN sbagliato. Restituendo dati non validi alla richiesta di autenticazione dall’applicazione esterna, la UICC aumenta la protezione dei dati personali, e allo stesso modo assicura il corretto funzionamento del dispositivo esterno memorizzando l’applicazione esterna. Al contrario, se la UICC non rispondesse alla richiesta della APDU circa l’autenticazione dall’applicazione esterna, potrebbe indurre il dispositivo esterno a comportarsi in maniera imprevedibile.
Ulteriori vantaggi e caratteristiche del metodo e delle carte a circuito integrato secondo la presente invenzione risulteranno dalla seguente descrizione data a titolo esemplificativo e non limitativo dell’ambito inventivo della presente invenzione.
Breve descrizione dei disegni
La Figura 1 mostra schematicamente i dispositivi implicati in un metodo di controllo della comunicazione tra una UICC ed una applicazione esterna, secondo un metodo noto.
La Figura 2 mostra lo schema del procedimento di inizializzazione tra UICC, dispositivo portatile, e dispositivo esterno, secondo la presente invenzione.
La Figura 3 mostra lo schema del procedimento di inizializzazione tra UICC, dispositivo portatile, e dispositivo esterno utilizzando la verifica IMEI, secondo la presente invenzione.
Descrizione dettagliata
Con riferimento alla figura 2, sono rappresentate schematicamente le fasi del metodo di controllo di una comunicazione tra una UICC 10, un dispositivo portatile 12 comprendente la UICC 10, ed un dispositivo esterno 14 secondo la presente invenzione. Il dispositivo esterno 14 Ã ̈ associato ad una applicazione esterna funzionante fuori dal dispositivo portatile 12.
Più in particolare, solo a fini esemplificativi, la comunicazione tra il dispositivo esterno e il dispositivo portatile può essere una sessione Bluetooth SAP comprendente le seguenti fasi: il dispositivo portatile 12 accende e alimenta la UICC 10, ovvero opera una reimpostazione a freddo. Il dispositivo portatile 12 completa la sequenza di inizializzazione. Il dispositivo esterno, per esempio un PC 14, si collega via Bluetooth e richiede la sessione Bluetooth SAP. Il dispositivo portatile 12 termina la vecchia sessione e inizia una nuova sessione, vale a dire opera una re-impostazione a caldo. Da ora in avanti, il PC 14 à ̈ responsabile dell’invio di una sequenza di inizializzazione.
Con riferimento alla configurazione hardware di una rete di applicazione, il dispositivo portatile 12 può collegarsi ad un dispositivo separato (non mostrato) adattato a collegarsi al PC 14 tramite svariati mezzi, che comprendono, ma non si limitano a, USB. Alternativamente, il PC 14 può comprendere mezzi per la comunicazione Bluetooth internamente. Inoltre, il PC 14 può accedere ad un server 16 via internet o tra reti. L’applicazione esterna funziona sul PC 14 solamente o può funzionare sul server 16 scambiando richiesta e risposta con il PC 14 in rete. Può essere utilizzata una chiamata di procedura remota per la comunicazione tra il PC 14 e il server 16. Alternativamente, svariati moduli compresi dall’applicazione esterna possono esistere sia sul PC 14 che sul server 16. Configurazioni hardware specifiche non limitano l’ambito di applicazione della presente invenzione.
La re-impostazione a caldo à ̈ un metodo implementato nel dispositivo portatile per ricominciare la sessione UICC 10, ad esempio accensione tra 2G e 3G o in caso di errore della UICC. Secondo la presente invenzione, la UICC 10 distingue la re-impostazione a caldo provocata da un dispositivo portatile che richiede il re-inizio della sessione UICC, dalla re-impostazione a caldo provocata da un’applicazione esterna nel PC 14 per l’apertura di una nuova sessione Bluetooth SAP, Nel frattempo, la re-impostazione a freddo à ̈ eseguita quando l’energia à ̈ applicata al dispositivo portatile 12 ancora dopo che il dispositivo portatile 12 à ̈ stato spento. L’hardware UICC à ̈ reso capace di rilevare il tipo di re-impostazione.
La figura 2 rappresenta schematicamente il diagramma del processo di inizializzazione tra UICC, dispositivo portatile, e dispositivo esterno secondo la sessione Bluetooth SAP.
In fase 20, il dispositivo portatile 12 accende e alimenta la UICC. In fase 21, il dispositivo portatile 12 invia una sequenza di inizializzazione alla UICC 10 e completa il processo di inizializzazione. Se il dispositivo esterno 14 desidera accedere alla UICC concessa dal dispositivo portatile 12 (secondo le preferenze del possessore del dispositivo portatile) e il dispositivo portatile 12 si trova nel campo del Bluetooth SAP, il dispositivo esterno 14 invia una richiesta di connessione Bluetooth SAP al dispositivo portatile 12, in fase 22. In fase 23, dopo che il dispositivo portatile 12 riceve la richiesta di connessione dal dispositivo esterno 14, il dispositivo portatile 12 invia una richiesta di re-impostazione a caldo 23 alla UICC 10. Come menzionato in precedenza, la re-impostazione a caldo può essere usata per passare da 2G a 3G, nel caso di errore della UICC o in altri casi di aggiornamento via cavo della UICC affinché la UICC e il terminale siano sincronizzati. In tal caso, si esegue la re-impostazione a caldo per stimolare la seconda inizializzazione. Pertanto, la UICC 10 non sa perché à ̈ stata richiesta la re-impostazione a caldo.
Dopo la re-impostazione a caldo in fase 23, tutti i comandi APDU generati dal dispositivo esterno 14 sono trasmessi alla UICC 10 dal dispositivo portatile 12. Il dispositivo portatile non controlla i contenuti specifici del pacchetto di dati APDU, ma semplicemente trasmette il pacchetto di dati alla UICC 10. Il dispositivo esterno 14 richiede la procedura di inizializzazione in fase 24 e il dispositivo portatile 12 la trasmette alla UICC 25. In fase 26, il dispositivo esterno 14 invia una richiesta APDU e il dispositivo portatile 12 la trasmette alla UICC (fase 27).
Secondo un aspetto dell’invenzione, per distinguere a quale dispositivo si sta accedendo, la UICC 10 utilizza il comando Provide Locai Information - IMEI Proactive come specificato in ETSI TS 102 223. Questo commando recupera ΠΜΕΙ del dispositivo portatile, vale a dire un unico numero dal dispositivo portatile al dispositivo portatile.
Durante la prima inizializzazione della UICC, la UICC 10 legge 1ΊΜΕΙ del dispositivo portatile. Dopo una re-impostazione a caldo, la UICC 10 legge ancora 1ΊΜΕΙ.
Se à ̈ come prima, la UICC 10 può stabilire che la reimpostazione a caldo à ̈ stata provocata dal dispositivo portatile 12;
Se à ̈ diversa dalla precedente, la UICC 10 rileva che à ̈ cominciata una sessione Bluetooth SAP
I due scenari sono così descritti per mostrare i diversi comportamenti.
La re- impostazione a caldo a causa della richiesta del dispositivo portatile di re-inizializzazione à ̈ come segue.
II dispositivo portatile 12 accende e alimenta la UICC (reimpostazione a freddo).
Il dispositivo portatile 12 completa la sequenza di inizializzazione.
La UICC 10 recupera lΙΜΕΙ del dispositivo portatile.
Il dispositivo portatile 12 esegue una re-impostazione a caldo. Il dispositivo portatile 12 completa la sequenza di inizializzazione.
La UICC 10 recupera l IMEI del dispositivo portatile.
La re-impostazione a caldo dovuta a Bluetooth SAP Ã ̈ come segue.
Il dispositivo portatile 12 accende e alimenta la UICC (reimpostazione a freddo).
II dispositivo portatile 12 completa la sequenza di inizializzazio ne .
La UICC 10 recupera il dispositivo portatile IMEI.
Il dispositivo esterno, vale a dire il PC 14 Ã ̈ collegato via Bluetooth e richiede la sessione Bluetooth SAP.
II dispositivo portatile 12 termina la vecchia sessione e inizia una nuova sessione (re-impostazione a caldo).
Il PC 14 esegue la sequenza di inizializzazione.
La UICC 10 recupera IΜΕΙ del PC; poiché lΊΜΕΙ del PC non à ̈ codificata, ciò potrebbe anche non avere senso o la risposta del PC 14 potrebbe risultare in un errore o il PC non supporta il recupero dell ’IMEI, ma il PC 14 non à ̈ tuttavia in grado di inviare IΜΕΙ inviato dal dispositivo portatile, e lasciare che la UICC 10 distingua tra le due sessioni.
La figura 3 mostra il diagramma di processo di inizializzazione tra UICC, dispositivo portatile, e dispositivo esterno secondo la sessione Bluetooth SAP che utilizza la verifica dell' IMEI .
Più in particolare, una situazione esemplificativa in cui l’applicazione esterna accede alla UICC via Bluetooth SAP à ̈ spiegata qui di seguito dettagliatamente. In fase 30, il dispositivo portatile 12 accende e alimenta la UICC 10. In fase 31, il dispositivo portatile 12 invia una sequenza di inizializzazione alla UICC 10 e completa il processo di inizializzazione. Poi, in fase 32, la UICC 10 emette il comando Provide Locai Information al dispositivo portatile 12 per recuperare lΙΜΕΙ del dispositivo portatile 12. In fase 33, rispondendo al commando Provide Locai Information della UICC 10, il dispositivo portatile 12 invia la sua informazione IMEI alla UICC 10. La UICC può memorizzare questa informazione nella sua memoria, per esempio, memoria non-volatile.
Quando il dispositivo portatile 12 si trova nel campo del collegamento Bluetooth del dispositivo esterno 14, e il dispositivo portatile 12 e/o la UICC 10 sono configurati per comunicare il dispositivo esterno 14, il dispositivo esterno 14 invia una richiesta di connessione al dispositivo portatile 12 in fase 34. Ricevendo la richiesta di connessione dal dispositivo esterno 14, il dispositivo portatile 12 invia un comando di re-impostazione a caldo alla UICC 10 in fase 35. Poi, la UICC à ̈ re-impostata e attende una nuova sequenza di inizializzazione dal dispositivo portatile 12. Dalla fase 35, poiché à ̈ stabilita la sessione Bluetooth SAP, il dispositivo portatile 12 semplicemente trasmette tutti i messaggi ricevuti o dal dispositivo esterno 14 o dalla UICC 10 all’altra entità.
In fase 36 e 37, il dispositivo esterno 14 emette una sequenza di inizializzazione al dispositivo portatile 12 e il dispositivo portatile 12 la trasmette alla UICC 10. Dopo aver risposto alla sequenza di inizializzazione, in fase 38 la UICC emette un comando Provide Local Information al dispositivo portatile 12 e il dispositivo portatile 12 in questo momento non replica il suo IMEI alla UICC 10 ma trasmette il comando Provide Locai Information al dispositivo esterno 14 in fase 39.
Poi, in fase 40, il dispositivo esterno 14 invia un numero al dispositivo portatile 12. Il numero viene confrontato con l ΜΕΙ del dispositivo portatile 12 dalla UICC 10. Il numero può essere generato a caso dal dispositivo esterno 14 in qualunque momento venga richiesto, o può essere un valore predeterminato poiché l’applicazione era stata inizialmente prodotta, per esempio un numero assegnato dall’Autorità competente. Alternativamente, il numero può essere cambiato periodicamente. Il numero può essere usato per la UICC per confermare che la sessione Bluetooth SAP à ̈ stabilita e il pacchetto di dati APDU viene da altri dispositivi, non dal dispositivo portatile 12. In fase 41, il dispositivo portatile 12 trasmette il numero alla UICC 10.
In fase 42, il dispositivo esterno 14 può inviare APDU generiche al dispositivo portatile 12, e il dispositivo portatile 12 può trasmetterle alla UICC in fase 43. La APDU generica può comprendere richieste quali una richiesta di verifica PIN o una richiesta di dati personali, per esempio, messaggio SMS o rubrica telefonica. In fase 43, la APDU generica à ̈ trasmessa alla UICC 10, ma la UICC 10 restringe questo tipo di accesso. Pertanto, la UICC può restituire un record vuoto in fase 44 e il dispositivo portatile 12 lo trasmette al dispositivo esterno 14 in fase 45. Per la UICC 10 à ̈ possible non restituire alcun valore. Tuttavia, preferibilmente, à ̈ meglio restituire un record vuoto, poiché se la UICC 10 non invia alcuna risposta, l’applicazione esterna può avere una fine anormale.
Invece di adottare lΜΕΙ, il profilo del terminale del dispositivo portatile può essere usato per rilevare l’inizio di una sessione SAP. Il profilo del terminale à ̈ una lista a mappa di bit delle caratteristiche del dispositivo portatile. Nonostante analoghi, quasi tutti i modelli di dispositivi mobili hanno profili leggermente diversi.
Dopo avere rilevato quando sono originati i pacchetti APDU, la UICC può adottare misure di sicurezza aggiuntive per proteggere le sue informazioni, per esempio da virus o Trojan. La UICC può fare rispettare una procedura di autenticazione, per esempio codifica, per risposta e richiesta della APDU con l’applicazione esterna. Alternativamente, la UICC può iniziare una sessione di comunicazione separata dopo il rilevamento.
Quando la sessione SAP à ̈ rilevata, la UICC può applicare svariate misure di sicurezza. Può limitare le istruzioni APDU disponibili ad uno specifico sottoinsieme, quelle strettamente necessarie per la fornitura di un dato servizio da parte dell’applicazione esterna. Alternativamente, può consentire alle APDUs di essere portate su protocolli di sicurezza concordati dalla emittente UICC e dal fornitore di servizi. Inoltre, può disabilitare l’ingresso del PIN dall’applicazione esterna, e ancora negare l’accesso ai dati personali, così come un SMS e una rubrica telefonica.
Specificatamente, per compatibilità, l’accesso a tali file à ̈ preferibilmente concesso poiché un errore di condizione di accesso mentre il PIN à ̈ disabilitato potrebbe dare luogo ad un comportamento imprevedibile da parte del dispositivo esterno. In tal caso, i dati personali possono essere ancora protetti restituendo record dalla UICC anziché record comprensivi dei dati memorizzati. Una misura simile può essere applicata allaggiornament, in ciò i dati da scrivere sono realmente memorizzati nella memoria, restituendo ancora una risposta soddisfacente. In ogni caso, il dispositivo esterno non dovrebbe compromettere o danneggiare i dati personali.
Dopo che la comunicazione tra lapplicazione esterna e la UICC à ̈ cominciata, preferibilmente la UICC non restituisce dati validi in richieste di autenticazione, per esempio sfida di autenticazione. Ciò può impedire al dispositivo esterno non autorizzato ad usare le credenziali dell'utente, di avviate chiamate e protegge anche dagli attacchi alla sicurezza delle chiavi di autenticazione della UICC.
Dopo che la comunicazione tra l’applicazione esterna e la UICC à ̈ iniziata e anche una procedura di autenticazione esterna à ̈ iniziata con successo, la UICC può esporre al dispositivo esterno tutte le caratteristiche disponibili ad un normale dispositivo portatile senza dette limitazioni e/o esporre caratteristiche dedicate solo disponibili per dispositivi esterni autenticati.
L’invenzione, che à ̈ stata descritta con riferimento alla connessione Bluetooth, non si limita a tale connessione e può essere applicata a tutti i protocolli in cui la UICC dovrebbe rilevare l’origine della sessione di comunicazione e le istruzioni ricevute.
Vantaggiosamente, il metodo della presente invenzione permette alla UICC di distinguere una sessione di comunicazione con l’applicazione esterna da una sessione di comunicazione con il dispositivo portatile, e ciò per distinguere pacchetti APDU generati dall’applicazione esterna da pacchetti APDU generati dal dispositivo portatile; così, la UICC può restringere un accesso alle sue risorse e servizi da parte dell’applicazione esterna; inoltre la UICC può prevedere servizi dedicati adatti ad un’applicazione esterna fidata.

Claims (16)

  1. RIVENDICAZIONI 1. Metodo di controllo di una comunicazione tra una UICC (10), un dispositivo portatile (12) comprendente la UICC (10) ed un dispositivo esterno (14) associato ad una applicazione esterna funzionante fuori dal dispositivo portatile (12), comprendente le fasi di: accensione della UICC (10) da parte del dispositivo portatile (12); esecuzione di una prima procedura di inizializzazione da parte del dispositivo portatile (12) per stabilire una prima sessione di comunicazione tra il dispositivo portatile (12) e la UICC (10); scambio di una richiesta di connessione tra il dispositivo portatile (12) e il dispositivo esterno (14), per stabilire una seconda sessione di comunicazione tra la UICC (10) e il dispositivo esterno (14); e esecuzione di una seconda procedura di inizializzazione tra il dispositivo esterno (14) e la UICC (10), caratterizzato dal fatto di comprendere la fase di: recupero di un attributo del dispositivo portatile (12) da parte della UICC (10) dopo detto completamento della prima procedura di inizializzazione; recupero di un attributo del dispositivo esterno (14) tramite il dispositivo portatile (12) da parte della UICC (10) dopo detto completamento della seconda procedura di inizializzazione; e confronto tra l’attributo del dispositivo portatile (12) e l’attributo del dispositivo esterno (14) per distinguere la seconda sessione di comunicazione dalla prima sessione di comunicazione.
  2. 2. Metodo di controllo di una comunicazione secondo la rivendicazione 1, caratterizzato dal fatto che l’attributo del dispositivo portatile (12) à ̈ 1 International Mobile Equipment Identity (IMEI) del dispositivo portatile (12).
  3. 3. Metodo di controllo di una comunicazione secondo la rivendicazione 1, caratterizzato dal fatto che l’attributo del dispositivo portatile (12) à ̈ il profilo del terminale del dispositivo portatile (12).
  4. 4. Metodo di controllo di una comunicazione secondo la rivendicazione 2 e la rivendicazione 3, caratterizzato dal fatto che l’attributo del dispositivo esterno (14) à ̈ un valore predeterminato o à ̈ generato dall’applicazione esterna nel dispositivo esterno (14).
  5. 5. Metodo di controllo di una comunicazione secondo una qualunque delle precedenti rivendicazioni, caratterizzato dal fatto che la seconda sessione di comunicazione à ̈ una sessione Bluetooth SAP.
  6. 6. Metodo di controllo di una comunicazione secondo una qualunque delle precedenti rivendicazioni, caratterizzato dal fatto che un’istruzione disponibile APDU à ̈ limitata ad uno specifico sottogruppo di fornitura di un servizio fornito dall’applicazione esterna dopo che à ̈ stabilita la seconda sessione di comunicazione.
  7. 7. Metodo di controllo di una comunicazione secondo una qualunque delle precedenti rivendicazioni, caratterizzato dal fatto che le APDU sono messe in comunicazione attraverso un protocollo predeterminato tra la UICC (10) e l’applicazione esterna dopo che à ̈ stabilita la seconda sessione di comunicazione.
  8. 8. Metodo di controllo di una comunicazione secondo una qualunque delle precedenti rivendicazioni, caratterizzato dal fatto che la UICC (10) restituisce dati non validi alla richiesta di autenticazione dall’applicazione esterna.
  9. 9. Metodo di controllo di una comunicazione secondo una qualunque delle precedenti rivendicazioni, caratterizzato dal fatto che la UICC disabilita l’accesso PIN dopo che à ̈ stabilita la seconda sessione di comunicazione.
  10. 10. Una UICC comprendente una UICC (10), operativa per essere inserita in un dispositivo portatile (12) che comunica con un dispositivo esterno (14) associato ad una applicazione esterna funzionante fuori dal dispositivo portatile (12), in cui il dispositivo portatile (12) accende la UICC (10), esegue una prima procedura di inizializzazione per stabilire una prima sessione di comunicazione tra il dispositivo portatile (12) e la UICC (10), scambia una richiesta di connessione con il dispositivo esterno (14) per stabilire una seconda sessione di comunicazione tra la UICC (10) e il dispositivo esterno (14), ed esegue una seconda procedura di inizializzazione tra il dispositivo esterno (14) e la UICC (10), caratterizzato dal fatto che la UICC (10) recupera un attributo del dispositivo portatile (12) da parte della UICC (10) dopo che il dispositivo portatile (12) completa la prima procedura di inizializzazione, e recupera un attributo del dispositivo esterno (14) tramite il dispositivo portatile (12) dopo che il dispositivo esterno (14) completa la seconda procedura di inizializzazione, e la UICC (10) confronta l’attributo del dispositivo portatile (12) con l’attributo del dispositivo esterno (14) per distinguere la seconda sessione di comunicazione dalla prima sessione di comunicazione.
  11. 11. La UICC secondo la rivendicazione 9, caratterizzata dal fatto che l’attributo del dispositivo portatile (12) à ̈ 1 International Mobile Equipment Identity (IMEI) del dispositivo portatile (12).
  12. 12. La UICC secondo la rivendicazione 9, caratterizzata dal fatto che l’attributo del dispositivo portatile (12) à ̈ il profilo del terminale del dispositivo portatile (12).
  13. 13. La UICC secondo la rivendicazione 10 e 11 caratterizzata dal fatto che l’attributo del dispositivo esterno (14) à ̈ un valore predeterminato o à ̈ generato dall’applicazione esterna nel dispositivo esterno (14).
  14. 14. La UICC secondo una qualunque delle rivendicazioni da 9 a 12, caratterizzata dal fatto che la seconda sessione di comunicazione à ̈ una sessione Bluetooth SAP.
  15. 15. La UICC secondo una qualunque delle rivendicazioni da 9 a 13, caratterizzata dal fatto che una istruzione disponibile APDU à ̈ limitata ad uno specifico sottogruppo di fornitura di un il servizio fornito dall’applicazione esterna dopo che à ̈ stabilita la seconda sessione di comunicazione .
  16. 16. La UICC secondo una qualunque delle rivendicazioni da 9 a 14, caratterizzata dal fatto che le APDU vengono fatte comunicare tramite un protocollo predeterminato tra la UICC (10) e l’applicazione esterna dopo che à ̈ stabilita la seconda sessione di comunicazione.
ITMI2010A002473A 2010-12-30 2010-12-30 Metodo e sistema di controllo di una comunicazione tra una carta universale a circuito integrato ed una applicazione esterna IT1404159B1 (it)

Priority Applications (2)

Application Number Priority Date Filing Date Title
ITMI2010A002473A IT1404159B1 (it) 2010-12-30 2010-12-30 Metodo e sistema di controllo di una comunicazione tra una carta universale a circuito integrato ed una applicazione esterna
US13/339,819 US9143922B2 (en) 2010-12-30 2011-12-29 Method and system for controlling communication between an UICC and an external application

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ITMI2010A002473A IT1404159B1 (it) 2010-12-30 2010-12-30 Metodo e sistema di controllo di una comunicazione tra una carta universale a circuito integrato ed una applicazione esterna

Publications (2)

Publication Number Publication Date
ITMI20102473A1 true ITMI20102473A1 (it) 2012-07-01
IT1404159B1 IT1404159B1 (it) 2013-11-15

Family

ID=43737125

Family Applications (1)

Application Number Title Priority Date Filing Date
ITMI2010A002473A IT1404159B1 (it) 2010-12-30 2010-12-30 Metodo e sistema di controllo di una comunicazione tra una carta universale a circuito integrato ed una applicazione esterna

Country Status (2)

Country Link
US (1) US9143922B2 (it)
IT (1) IT1404159B1 (it)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102122803B1 (ko) * 2012-05-24 2020-06-15 삼성전자주식회사 ｅＵＩＣＣ에 ＳＩＭ 프로파일을 제공하는 방법 및 장치
US10111092B2 (en) * 2012-11-06 2018-10-23 Kt Corporation Terminal device having subscriber identity device and method for selecting profile thereof
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
EP3005765A4 (en) * 2013-05-29 2016-06-29 Visa Int Service Ass VERIFICATION SYSTEMS AND METHODS EXECUTED AT A SECURE ELEMENT
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
FR3013479B1 (fr) 2013-11-21 2015-12-18 Oberthur Technologies Procede de notification a des fins de configuration d'un element securise
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
CN105228125A (zh) * 2014-05-27 2016-01-06 中兴通讯股份有限公司 一种智能卡动态绑定方法、设备和系统
US10003959B2 (en) * 2015-07-30 2018-06-19 Qualcomm Incorporated Subscriber identity module (SIM) access profile (SAP)
EP3270620A1 (en) * 2016-07-13 2018-01-17 Gemalto Sa Method and devices for managing a secure element
US10856142B2 (en) * 2016-07-14 2020-12-01 Huawei Technologies Co., Ltd. Method and device for performing communication by using virtual subscriber identity module
CN106993266B (zh) * 2017-03-31 2020-04-03 东信和平科技股份有限公司 一种蓝牙sim卡配对连接的方法
CN110719581A (zh) * 2018-07-12 2020-01-21 中兴通讯股份有限公司 一种终端应用的控制方法、装置及系统
GB2574902A (en) * 2018-07-25 2019-12-25 Eckoh Uk Ltd Contact centre user authentication
EP3737128B1 (en) * 2019-05-10 2024-04-17 Nxp B.V. Common data and clock signal lines
CN111901793B (zh) * 2020-09-08 2022-08-23 中国联合网络通信集团有限公司 一种uicc应用设置信息管理方法、系统、uicc智能卡及终端
CN112911577B (zh) * 2021-01-15 2022-09-27 中国联合网络通信集团有限公司 异常情况处理方法及装置、移动设备、用户设备、系统
US11647392B1 (en) 2021-12-16 2023-05-09 Bank Of America Corporation Systems and methods for context-aware mobile application session protection

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2466390C (en) * 1998-07-03 2009-10-06 Nokia Mobile Phones Ltd. Secure session set up based on the wireless application protocol
GB2370659A (en) * 2000-12-29 2002-07-03 Nokia Mobile Phones Ltd Method of controlling access to a data file held by a smart card
DE10108487A1 (de) * 2001-02-22 2002-09-12 Giesecke & Devrient Gmbh Verfahren und System zur verteilten Erstellung eines Programms für einen programmierbaren, tragbaren Datenträger
AU2002302956A1 (en) * 2001-05-16 2002-11-25 Adjungo Networks Ltd. Access to plmn networks for non-plmn devices
FR2825869B1 (fr) * 2001-06-08 2003-10-03 France Telecom Procede d'authentification entre un objet de telecommunication portable et une borne d'acces public
US7738896B2 (en) * 2002-05-24 2010-06-15 Kodiak Networks, Inc. Subscriber identity module (SIM) enabling advanced voice services (AVS) including push-to-talk, push-to-conference and push-to-message on wireless handsets and networks
US7475244B2 (en) * 2002-11-05 2009-01-06 Kabushiki Kaisha Toshiba Wireless communication device, portable terminal, communication control program and communication system
US7957729B2 (en) * 2002-12-20 2011-06-07 Nokia Corporation Communication system and method for operating such a system
US7940932B2 (en) * 2004-04-08 2011-05-10 Texas Instruments Incorporated Methods, apparatus, and systems for securing SIM (subscriber identity module) personalization and other data on a first processor and secure communication of the SIM data to a second processor
US20050259673A1 (en) * 2004-05-18 2005-11-24 Axalto Inc. Method and system for end-to-end communication between a universal integrated circuit card and a remote entity over an IP-based wireless wide area network and the internet
KR100725767B1 (ko) * 2005-11-24 2007-06-08 삼성전자주식회사 다중인터페이스를 가진 통합 단말기의 위치등록을 위한장치 및 방법
US7395973B2 (en) * 2005-12-08 2008-07-08 Chun-Hsin Ho Smart card
US20080092149A1 (en) * 2006-10-05 2008-04-17 Rowbotham Graham D Modular architecture for a device interface component
US20080250328A1 (en) * 2007-04-03 2008-10-09 Nokia Corporation Systems, methods, devices, and computer program products for arranging a user's media files
WO2009057147A2 (en) * 2007-11-04 2009-05-07 Rajendra Kumar Khare Method and system for user authentication
US8701197B2 (en) * 2007-12-20 2014-04-15 Nokia Corporation Method, apparatus and computer program product for secure software installation
JP2011524099A (ja) * 2008-04-07 2011-08-25 インターデイジタル パテント ホールディングス インコーポレイテッド セキュリティ保護されたセッション鍵生成
GB2473400B (en) * 2008-06-13 2013-02-13 Shourabh Shrivastav Real time authentication of payment cards
CN102027495A (zh) * 2008-06-24 2011-04-20 国际商业机器公司 用于认证电子支付请求的方法和系统
US8903390B2 (en) * 2009-05-13 2014-12-02 Qualcomm Incorporated Provisioning single-mode and multimode system selection parameters and service management
US8213990B2 (en) * 2009-06-05 2012-07-03 Mediatek Inc. System for providing remote subscriber identity card to mobile station and methods thereof
US9497632B2 (en) * 2009-10-01 2016-11-15 T-Mobile Usa, Inc. System and method for pairing a UICC card with a particular mobile communications device
KR101684753B1 (ko) * 2010-02-09 2016-12-08 인터디지탈 패튼 홀딩스, 인크 신뢰적인 연합 아이덴티티를 위한 방법 및 장치
US8819447B2 (en) * 2010-03-10 2014-08-26 Sprint Communications Company L.P. Secure storage of protected data in a wireless communication device
US20110252172A1 (en) * 2010-04-09 2011-10-13 Jun Sun System and method for concurrent operation of dual interfaces between uicc and mobile device
WO2011163611A1 (en) * 2010-06-24 2011-12-29 Battlefield Telecommunications Systems, Llc Data extraction system and device
US8509431B2 (en) * 2010-09-20 2013-08-13 Interdigital Patent Holdings, Inc. Identity management on a wireless device

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Universal Subscriber Identity Module (USIM) Application Toolkit (USAT) (Release 10)", 3GPP STANDARD; 3GPP TS 31.111, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V10.0.0, 2 October 2010 (2010-10-02), pages 1 - 109, XP050442456 *
"SIM Access Profile", 3GPP DRAFT; ATT2_S3-030251_SIM_ACCESS_PROFILE_095VD_F_TRACKED_BAR_UIC C_UPDATES1, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Berlin; 20030430, 30 April 2003 (2003-04-30), XP050273582 *
"Smart Cards; Card Application Toolkit (CAT) (Release 9)", TECHNICAL SPECIFICATION, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, vol. SCP TEC, no. V9.1.0, 1 April 2010 (2010-04-01), XP014046327 *
ERICSSON: "SIM access via 'SIM Access Profile' and Bluetooth link", 3GPP DRAFT; S3-030436_S3-030251_SIM_ACCESS_PROFILE, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. San Francisco, USA; 20030721, 21 July 2003 (2003-07-21), XP050274040 *
ST-ERICSSON ET AL: "USAT over AT", 3GPP DRAFT; C1-103202, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG1, no. Xian; 20100823, 16 August 2010 (2010-08-16), XP050443939 *

Also Published As

Publication number Publication date
IT1404159B1 (it) 2013-11-15
US9143922B2 (en) 2015-09-22
US20120172016A1 (en) 2012-07-05

Similar Documents

Publication Publication Date Title
ITMI20102473A1 (it) Metodo e sistema di controllo di una comunicazione tra una carta universale a circuito integrato ed una applicazione esterna
EP3198789B1 (en) Securely pairing computing devices
US9626520B2 (en) Policy based techniques for managing access control
US7580701B2 (en) Dynamic passing of wireless configuration parameters
JP5643303B2 (ja) 記憶装置のリモートアクセス制御
EP2827629B1 (en) Apparatus and methods for storing electronic access clients
KR20160123604A (ko) 비콘 장치를 관리하는 방법 및 이를 위한 장치
US20170238235A1 (en) Wireless router and router management system
CN106465108A (zh) 蜂窝网络认证控制
WO2017219748A1 (zh) 访问权限的确定、页面的访问方法及装置
KR101281099B1 (ko) 스마트폰 분실 및 도난의 피해 방지를 위한 인증방법
BR112021003460A2 (pt) dispositivo sem identidade de assinante, dispositivo de identidade do assinante, método para uso em um dispositivo sem identidade de assinante, método para uso em um dispositivo com identidade de assinante e produto de programa de computador
JP2006279321A (ja) 移動端末のためのセキュリティソフトウェア及びセキュリティ通信システム
WO2013185701A1 (zh) 一种利用用户识别卡对终端进行加密的方法和系统
Vahidian Evolution of the SIM to eSIM
CN106878989A (zh) 一种接入控制方法及装置
KR101365889B1 (ko) 이동통신 단말기의 모바일 네트워크 보안 방법, 시스템 및 그 프로그램을 기록한 기록매체
JP5545433B2 (ja) 携帯電子装置および携帯電子装置の動作制御方法
ES2865293T3 (es) Dispositivo electrónico que comprende un módulo seguro que soporta un modo de gestión local de configurar de un perfil de abonado
KR101480706B1 (ko) 인트라넷에 보안성을 제공하는 네트워크 시스템 및 이동통신 네트워크의 보안 게이트웨이를 이용하여 인트라넷에 보안성을 제공하는 방법
KR101343872B1 (ko) 비인가된 무선 AP(Access Point) 연결을 검출 및 제어하는 방법
JP2011120123A (ja) 認証システムおよび認証方法
PT106561A (pt) Método implementado em computador para acesso seguro a redes wlan, mais concretamente wi-fi