IT201600079563A1 - Metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale con biforcazione della trasmissione di un mezzo di autenticazione - Google Patents
Metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale con biforcazione della trasmissione di un mezzo di autenticazioneInfo
- Publication number
- IT201600079563A1 IT201600079563A1 IT102016000079563A IT201600079563A IT201600079563A1 IT 201600079563 A1 IT201600079563 A1 IT 201600079563A1 IT 102016000079563 A IT102016000079563 A IT 102016000079563A IT 201600079563 A IT201600079563 A IT 201600079563A IT 201600079563 A1 IT201600079563 A1 IT 201600079563A1
- Authority
- IT
- Italy
- Prior art keywords
- user
- authentication
- otp
- personal device
- biometric data
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 59
- 230000005540 biological transmission Effects 0.000 title description 5
- 238000013475 authorization Methods 0.000 claims description 17
- 238000012795 verification Methods 0.000 claims description 12
- 230000000295 complement effect Effects 0.000 claims description 5
- 238000007726 management method Methods 0.000 description 28
- 230000008569 process Effects 0.000 description 18
- 238000004891 communication Methods 0.000 description 7
- 230000003993 interaction Effects 0.000 description 6
- 230000004913 activation Effects 0.000 description 5
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
- H04L9/3231—Biological data, e.g. fingerprint, voice or retina
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
- H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/46—Secure multiparty computation, e.g. millionaire problem
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- General Health & Medical Sciences (AREA)
- Biodiversity & Conservation Biology (AREA)
- Life Sciences & Earth Sciences (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
- Lock And Its Accessories (AREA)
Description
"METODO DI AUTENTICAZIONE SICURA DI UNA RICHIESTA RIVOLTA AD UN FORNITORE REMOTO E GENERATA IN UN DISPOSITIVO PERSONALE CON BIFORCAZIONE DELLA TRASMISSIONE DI UN MEZZO DI AUTENTICAZIONE"
SETTORE DELLA TECNICA
La presente invenzione è relativa ad un metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale. ARTE ANTERIORE
Sempre più di frequente, i dispositivi personali (telefoni cellulari, computer tablet, computer portatili, computer fissi, televisioni intelligenti...) vengono utilizzati per ordinare beni o servizi ad un fornitore remoto normalmente comportando un corrispondente pagamento. Ovvero, utilizzando un dispositivo personale un utente genera una richiesta di fornitura di un bene o di un servizio rivolta ad un fornitore remoto; tale richiesta viene automaticamente inoltrata ad un server di gestione del fornitore remoto attraverso Internet in modo tale che il fornitore remoto, fatti i dovuti accertamenti e ricevuto il pagamento, possa procedere all'erogazione del bene o del servizio.
Essendo coinvolto (direttamente o indirettamente) un pagamento, è necessario che la richiesta proveniente dal dispositivo personale dell'utente venga autenticata in modo sicuro per evitare frodi da parte di terze parti che si spacciano fraudolentemente per l'utente.
Il metodo di autenticazione più semplice, ma anche meno sicuro, è fornire all'utente una password permanente (o statica) che l'utente deve inserire nel momento in cui genera una richiesta; questo metodo di autenticazione è teoricamente molto semplice per l'utente (la complicazione deriva dal fatto che al giorno d'oggi le persone attive in Internet sono costrette a conoscere un numero di password estremamente elevato, ad esempio anche diverse decine di password), ma intrinsecamente poco sicuro in quanto una password permanente pone il problema della sua conservazione " sicura " lato utente (ad esempio può venire scritta su un post-it attaccato al computer), una password permanente è indovinabile (dovendo memorizzare molte password permanenti generalmente gli utenti scelgono password permanenti molto semplici), ed una password permanente è leggibile durante la trasmissione da un terzo che riesca ad inserirsi nella comunicazione.
Un metodo di autenticazione più complesso e più sicuro prevede l'utilizzo di una password monouso o password temporanea ("ΟΓΡ - One Time Password") che viene generata ed utilizza per una unica transazione (quindi anche se venisse intercettata da un terzo che riesce ad inserirsi nella comunicazione sarebbe del tutto inutile). D'altra parte, una password monouso non può essere memorizzata da un utente e quindi la generazione di una password monouso richiede da parte dell'utente il possesso di una tecnologia supplementare, ovvero di un token per la sicurezza (chiamato anche token hardware, token per l'autenticazione, token crittografico, o semplicemente token). In altre parole, il token per la sicurezza è un dispositivo (generalmente fisico ma potrebbe anche essere virtuale ovvero implementato unicamente mediante un software) necessario per effettuare un'autenticazione (tipicamente una autenticazione a due fattori).
Un token per la sicurezza si presenta spesso sotto forma di dispositivo elettronico portatile di piccole dimensioni, alimentato a batteria con autonomia nell'ordine di qualche anno, dotato di uno schermo e talvolta di una tastiera numerica. Un token per la sicurezza è tipicamente un generatore di numeri pseudocasuali ad intervalli regolari (nell'ordine di poche decine di secondi) secondo un algoritmo che, tra i vari fattori, tiene conto del trascorrere del tempo grazie ad un orologio interno; altri fattori che influenzano l'algoritmo possono essere il numero di serie del token per la sicurezza, o altri codici numerici associati al possessore all'atto della consegna del token per la sicurezza. Lo stesso algoritmo è anche implementato su di un server di autenticazione, che è stato inizialmente sincronizzato con il token per la sicurezza e che, quindi, genera la stessa sequenza di numeri pseudocasuali del token per la sicurezza negli stessi momenti, pur non essendoci alcuna comunicazione tra i due oggetti. Tale numero, casuale e transitorio, viene combinato con un PIN noto all'utente ed al sistema di autenticazione per generare una password monouso che può essere usata per effettuare l'autenticazione entro la scadenza dell'intervallo temporale; la password monouso è quindi formata da un PIN (fisso) in possesso dell'utente e da un numero (temporaneo) visualizzato dal token per la sicurezza.
L'autenticazione a due fattori è data dal fatto che per generare la password monouso corretta è necessario possedere lo specifico token per la sicurezza che, in un dato istante, genera lo stesso numero pseudocasuale generato dal server di autenticazione e, nello stesso tempo, è necessario conoscere il PIN con cui il numero va combinato. Considerato che la password monouso scade dopo poche decine di secondi, chi volesse violare la sicurezza dovrebbe non solo indovinare la password monouso valida per il particolare istante, ma dovrebbe anche usarla prima che essa scada; per questo motivo, un token per la sicurezza eleva notevolmente gli standard di sicurezza. Infatti, se il violatore volesse avere più tempo per violare la sicurezza dovrebbe scoprire l'algoritmo di generazione dei numeri pseudocasuali, che gli permetterebbe di poter continuamente rigenerare la password temporanea; tuttavia, questi algoritmi di generazione dei numeri pseudocasuali hanno un livello di complessità molto elevata da rendere difficile la decrittazione anche ai computer più potenti al mondo.
L'utilizzo di un token per la sicurezza permette di elevare notevolmente gli standard di sicurezza rispetto all'utilizzo di una semplice password permanente (o statica); tuttavia, anche l'utilizzo di un token per la sicurezza non consente di arrivare a standard di sicurezza elevatissimi, in quanto è sempre possibile che un terzo riesca ad intercettare la password monouso inserendosi nella comunicazione tra il dispositivo mobile dell'utente ed il server di gestione e quindi ad utilizzare in modo fraudolento la password monouso nel breve lasso di tempo prima della sua scadenza (a tale proposito è importare osservare che un software pirata è in grado di creare una falsa richiesta in poche frazioni di secondo una volta venuto a conoscenza della password monouso). In caso di intercettazione della password monouso il rischio di frode per l'utente e/o per il fornitore remoto può essere anche molto elevato, in quanto la stessa password monouso è utilizzabile per autenticare tutte le richieste a cui l'utente ha diritto in base al suo contratto con il fornitore remoto; ad esempio la stessa password monouso può autenticare una transazione avente valore economico di pochi centesimi di Euro, oppure una transazione avente valore economico di centinaia o migliaia di Euro.
DESCRIZIONE DELLA INVENZIONE
Scopo della presente invenzione è di fornire un metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale, il quale metodo di autenticazione permetta di aumentare la sicurezza della transazione implementazione senza appesantire l'esperienza d utilizzo ed in modalità sostanzialmente trasparente all'utente finale.
Secondo la presente invenzione viene fornito un metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale, secondo quanto rivendicato dalle rivendicazioni allegate.
BREVE DESCRIZIONE DEI DISEGNI
La presente invenzione verrà ora descritta con riferimento ai disegni annessi, che ne illustrano un esempio di attuazione non limitativi, in cui:
• la figura 1 è una vista schematica di un sistema di interazione che permette ad un utente di inviare in modo sicuro una richiesta rivolta ad un fornitore remoto; e
• le figure 2-11 sono altrettante viste schematiche del sistema di interazione della figura 1 in successive fasi di autenticazione della richiesta inviata dall'utente .
FORME DI ATTUAZIONE PREFERITE DELL'INVENZIONE
Nella figura 1, con il numero 1 è indicato nel suo complesso un sistema di interazione che permette ad un utente di inviare in modo sicuro una richiesta R rivolta ad un fornitore remoto (un negozio fisico o virtuale, una banca, un albergo, una agenzia viaggi, una compagnia di trasporto...).
Il sistema 1 di interazione comprende un server 2 di gestione appartenente al fornitore remoto e mediante il quale il fornitore remoto processa la richiesta R inviata dall'utente. Inoltre, il sistema 1 di interazione comprende un server 3 di autenticazione che è diverso e separato dal server 2 di gestione ed appartiene ad un soggetto terzo che opera da garante tra l'utente ed il fornitore remoto. Infine, il sistema 1 di interazione comprende un dispositivo 4 personale (un telefono cellulare, un computer tablet, un computer portatile, un computer fisso, un televisore intelligente...) che appartiene all'utente (o è comunque nelle disponibilità dell'utente) e che viene utilizzato dall'utente stesso per generare ed inviare (ovvero autorizzare) la richiesta R.
Secondo una preferita (ma non vincolante) forma di attuazione, l'utente esegue una registrazione (" enrollmet" ) presso il server 3 di autenticazione (ovvero presso il soggetto terzo che opera da garante) durante la quale fornisce al server 3 di autenticazione sia un proprio codice UIDidentificativo (ovvero un codice UiDidentificativo dell'utente), sia un codice FP identificativo del dispositivo 4 personale (conosciuto anche con il termine "Fingerprint") ; il server 3 di autenticazione memorizza in un proprio database il codice UIDidentificativo dell'utente ed il codice FP identificativo del corrispondente dispositivo 4 personale (una preferita forma di attuazione del processo di registrazione è descritta in seguito). È importante precisare che normalmente il processo di registrazione coinvolge tutti e tre gli attori, ovvero coinvolge l'utente che impiega il proprio dispositivo 4 personale, il server 3 di autenticazione ed anche il server 2 di gestione (in qualità di fornitore di servizi o " Service provider" ) ; in altre parole, durante il processo di registrazione l'utente attiva una propria utenza sia nel server 2 di gestione, sia nel server 3 di autenticazione. Durante il processo di registrazione, l'utente, tra le altre cose, sceglie un proprio codice PIN (" Personal Identification Number" ) autorizzativo eventualmente modificabile in seguito. Come meglio descritto in seguito, in questa fase di registrazione presso il server 3 di autenticazione l'utente potrebbe anche fornire al server 3 di autenticazione un proprio dato biometrico che viene memorizzato nel database del server 3 di autenticazione.
Secondo una preferita (ma non vincolante) forma di attuazione, il codice FP identificativo del dispositivo 4 personale comprende sia un codice identificativo di un hardware del dispositivo 4 personale, sia un codice identificativo di un software S installato nel dispositivo 4 personale (ed utilizzato, ad esempio, per generare la richiesta R); in alternativa, il codice FP identificativo del dispositivo 4 personale comprende solo un codice identificativo di un hardware del dispositivo 4 personale oppure solo un codice identificativo di un software S installato nel dispositivo 4 personale. Secondo una preferita forma di attuazione, il codice FP identificativo del dispositivo 4 personale viene memorizzato in una area sicura del dispositivo 4 personale e criptato utilizzando il codice PIN autorizzativo scelto dall'utente all'atto del processo di registrazione.
Nel dispositivo 4 personale è installato un software S (ovvero un " App " denominata " Integrating App") che è stato fornito dal fornitore remoto, ed è stato preventivamente registrato nel server 2 di gestione in modo tale da potere operare con il server 2 di gestione stesso; all'interno di tale software S è presente un modulo SDK di autenticazione che è stato fornito al fornitore remoto dal gestore del server 3 di autenticazione e si interfaccia con il resto del software S come una " scatola nera" (" black box" ) durante le operazioni di autenticazione descritte in seguito. In altre parole, la gestione commerciale della richiesta R rivolta ad un fornitore remoto viene completamente fatta dal software S senza l'intervento del modulo SDK di autenticazione, mentre l'autenticazione della richiesta R è demandata completamente al modulo SDK di autenticazione che opera in autonomia (ovvero il modulo SDK di autenticazione viene attivato dal software S da cui riceve gli estremi della richiesta R per gestire l'autenticazione della richiesta R senza ulteriori interventi del restante software S).
Secondo quanto illustrato nella figura 2, il processo inizia con la generazione della richiesta R per il fornitore remoto nel dispositivo 4 personale ad opera dell'utente; generalmente, l'utente genera la richiesta R utilizzando il software S che è stato installato nel dispositivo 4 personale, è stato fornito dal fornitore remoto, ed è stato preventivamente registrato nel server 2 di gestione in modo tale da potere operare con il server 2 di gestione stesso. Per generare la richiesta R, il modulo SDK di autenticazione richiede all'utente di digitare il proprio codice PIN autorizzativo che viene utilizzato per decrittare i dati rilevanti che sono stati preventivamente memorizzati in una area sicura del dispositivo 4 personale e criptati utilizzando il codice PIN autorizzativo. A titolo di esempio, la richiesta R potrebbe contenere un ordine di acquisto di un bene o servizio che il fornitore remoto invia (fisicamente o digitalmente) all'utente dietro il pagamento di un corrispettivo economico (ad esempio addebitando l'importo in una carta di credito, in una carta prepagata o in un conto bancario dell'utente).
Successivamente e come illustrato nella figura 3, il dispositivo 4 personale (attraverso il modulo SDK di autenticazione del software S) genera una password OTP monouso (ovvero una password temporanea) utilizzando un algoritmo generatore di numeri pseudo-casuali (" PRNG -Pseudo-Random Numbers Generator" ) atto a produrre una sequenza con approssimativamente le stesse proprietà statistiche di una sequenza di numeri generata da un processo casuale. Prima di venire usato, il generatore di numeri pseudo-casuali deve essere inizializzato assegnando un opportuno valore ad almeno un parametro numerico che viene chiamato seme ("seed") ed ogni volta che si usa lo stesso seme, si otterrà sempre la stessa identica sequenza (il periodo di un generatore di numeri pseudo-casuali non può quindi superare il numero dei possibili valori del seme); in particolare, il seme del generatore di numeri pseudo-casuali (o almeno parte del seme come viene detto subito dopo) viene fornito al dispositivo 4 personale dal server 3 di autenticazione durante il processo di registrazione (come verrà meglio spiegato in seguito). Secondo una preferita forma di attuazione, anche il seme del generatore di numeri pseudo-casuali viene memorizzato in una area sicura del dispositivo 4 personale e criptato utilizzando il codice PIN autorizzativo scelto dall'utente all'atto del processo di registrazione.
Secondo una preferita (ma non vincolante) forma di attuazione, la password OTP monouso viene generata utilizzando almeno un dato significativo della richiesta R; un dato significativo della richiesta R utilizzato nel processo di generazione della password OTP monouso potrebbe essere il valore economico della transazione collegata alla richiesta R (ovvero quanto l'utente deve pagare al fornitore remoto per il soddisfacimento della richiesta R) oppure un codice identificativo (o parte di esso) di un bene o servizio che viene ordinato attraverso la richiesta R. In altre parole, la password OTP monouso viene generata utilizzano un generatore di codici alfanumerici pseudocasuali secondo un algoritmo che, tra i vari fattori, presenta come variabili di ingresso il trascorrere del tempo grazie ad un orologio interno ed un dato significativo della richiesta R. In alternativa, un dato significativo della richiesta R potrebbe diventare parte del seme con cui viene inizializzato il generatore di numeri pseudo-casuali che produce la password OTP monouso; in questo caso il seme cui viene inizializzato il generatore di numeri pseudo-casuali che produce la password OTP monouso è formato in parte (ad esempio i primi 24 caratteri ASCII) da un seme fornito dal server 3 di autenticazione ed in parte (ad esempio gli ultimi 8 caratteri ASCII) dal valore economico della richiesta R.
Secondo una preferita, ma non vincolante, forma di attuazione, il modulo SDK di autenticazione riceve dal software S una stringa di descrizione alfanumerica (ad esempio composto da un numero variabile di caratteri ASCII non superiore a 256) che descrive la richiesta R (ad esempio tale stringa potrebbe essere copia dell'ordine contenete 1'identificativo del bene/servizio desiderato ed il valore economico della transazione (ovvero il prezzo pattuito) e genera un sunto ( '"digest") della stringa alfanumerica di dimensione predefinita e costante (ad esempio una stringa di 32 caratteri ASCII) attraverso un algoritmo di hashing (a titolo di esempio utilizzando l'algoritmo di hashing SHA256). Il sunto della stringa di descrizione è in sostanza una impronta statisticamente (non matematicamente) univoca della stringa di descrizione che presenta una dimensione predefinita e costante (generalmente minore della dimensione della stringa di descrizione) indipendentemente dalla dimensione effettiva della stringa di descrizione. E' importante osservare che anche variando di poco (ad esempio di un solo carattere su 256) la stringa di descrizione si verificano variazioni molto più rilevanti sul corrispondente sunto per effetto dell'azione dell'algoritmo di hashing. Quindi, la stringa di descrizione della richiesta R contiene al suo interno tutti i dati significativi della richiesta R e di conseguenza il sunto della stringa di descrizione è una diretta emanazione dei dati significativi della richiesta R venendo generata direttamente dalla stringa di descrizione.
Una volta ottenuto il sunto della stringa di descrizione della richiesta R, il modulo SDK di autenticazione del software S esegue un operazione logica (ad esempio una operazione logica XOR ma potrebbero venire utilizzate altre operazioni logiche) tra il seme del generatore di numeri pseudo-casuali ed il sunto della stringa di descrizione in modo tale da ottenere un seme modificato che incorpora al suo interno sia il seme fornito dal server 3 di autenticazione, sia il sunto della stringa di descrizione. A questo punto, il modulo SDK di autenticazione del software S inizializza il generatore di numeri pseudo-casuali che produce la password OTP monouso utilizzando il seme modificato e l'informazione temporale. Preferibilmente (ma non obbligatoriamente), sia il sunto della stringa di descrizione della richiesta R, sia il seme presentano la stessa dimensione (32 caratteri ASCII, ovvero 32 byte, nell'esempio fatto in precedenza) in modo tale da semplificare l'operazione logica tra il seme del generatore di numeri pseudo-casuali ed il sunto della stringa di descrizione.
L'operazione logica XOR (detta anche "OR ESCLUSIVO", "EX-OR", o " SOMMA MODULO 2") ricordata in precedenza è la cosiddetta differenza simmetrica e restituisce 1 se e solo se il numero degli operandi uguali a 1 è dispari (cioè se i due operandi sono diversi), mentre restituisce 0 in tutti gli altri casi (cioè se i due operando sono uguali).A questo punto e come illustrato nella figura 4, il dispositivo 4 personale (attraverso il modulo SDK di autenticazione del software S) suddivide la password OTP monouso in una prima parte OTPi_i6ed in una seconda parte OTP17-32tra loro complementari; in sostanza, il dispositivo 4 personale suddivide in due metà (OTPi-16e OTP17-32) la password OTP monouso. A titolo di esempio, la password OTP monouso potrebbe essere costituita da una sequenza alfanumerica composta da 32 byte (ciascuno dei quali è composto da 8 bit e quindi può assumere 256 valori diversi compresi tra 0 e 255): la prima parte OTPi_i6è costituita dai primi sedici byte della password OTP monouso e la seconda parte OTP17-32è costituita dagli ultimi sedici byte della password OTP monouso.
A questo punto e come illustrato nella figura 5, il dispositivo 4 personale (attraverso il modulo SDK di autenticazione del software S) invia attraverso Internet (ed utilizzando un protocollo di comunicazione sicuro, ovvero criptato) la richiesta R, la prima parte OTPi_i6della password OTP monouso (ma non la seconda parte OTPi7_32)ed il codice UiDidentificativo dell'utente al server 2 di gestione appartenente al fornitore remoto per autenticare la richiesta R (e quindi dare corso alla richiesta R stessa). Nello stesso tempo, il dispositivo 4 personale (attraverso il modulo SDK di autenticazione del software S) invia attraverso Internet (ed utilizzando un protocollo di comunicazione sicuro, ovvero criptato) la richiesta R, la seconda parte OTPi7-32della password OTP monouso (ma non la prima parte OTPi_i6)ed il codice FP identificativo del dispositivo 4 personale al server 3 di autenticazione appartenente al soggetto terzo che opera da garante tra l'utente ed il fornitore remoto.
A questo punto e come illustrato nella figura 6, il server 2 di gestione invia al server 3 di autenticazione la richiesta R, la prima parte OTP1-16della password OTP monouso ed il codice UiDidentificativo dell'utente appena ricevuti dal dispositivo 4 personale.
A questo punto e come illustrato nella figura 7, il server 3 di autenticazione ricompone la password OTP monouso combinando la prima parte OTPi_i6della password OTP monouso ricevuta dal server 2 di gestione con la seconda parte OTP17-32della password OTP monouso ricevuta dal dispositivo 4 personale. Una volta ricomposta la password OTP monouso ricevuta (in parte direttamente ed in parte indirettamente) dal dispositivo 4 personale, il server 3 di autenticazione verifica la correttezza della password OTP monouso stessa. Per verifica la correttezza della password OTP monouso ricevuta (in parte direttamente ed in parte indirettamente) dal dispositivo 4 personale, il server 3 di autenticazione genera una ulteriore password OTP monouso di controllo con le stesse modalità con cui è stata generata (o meglio sarebbe dovuta essere stata generata) la password OTP monouso nel dispositivo 4 personale e quindi il server 3 di autenticazione verifica se la password OTP monouso ricevuta (in parte direttamente ed in parte indirettamente) dal dispositivo 4 personale è corrispondente (tipicamente, ma non obbligatoriamente, identica) alla password OTP monouso di controllo generata internamente al server 3 di autenticazione .
Secondo una preferita (ma non limitante) forma di attuazione illustrata nella figura 8, il server 3 di autenticazione verifica anche che la richiesta R ricevuta dal dispositivo 4 personale sia identica alla richiesta R ricevuta dal server 2 di gestione. Il server 3 di autenticazione considera sempre negativa (cioè fallita) la verifica della password OTP monouso se il la richiesta R ricevuta dal dispositivo 4 personale non corrisponde alla richiesta R ricevuta dal server 2 di gestione.
Secondo una preferita (ma non limitante) forma di attuazione illustrata nella figura 9, il server 3 di autenticazione 8 verifica che il codice UiDidentificativo dell'utente ricevuto dal server 2 di gestione corrisponda al codice FP identificativo del dispositivo 4 personale ricevuto dal dispositivo 4 personale; tale verifica viene eseguita utilizzando la registrazione preventiva che l'utente ha eseguito nel server 2 di autenticazione e durante la quale l'utente ha fornito al server 2 di autenticazione il proprio codice UlD identificativo dell'utente e il codice FP identificativo del dispositivo 4 personale. Il server 3 di autenticazione considera sempre negativa (cioè fallita) la verifica della password OTP monouso se il codice UiDidentificativo dell'utente ricevuto dal server 2 di gestione non corrisponde al codice FP identificativo del dispositivo 4 personale ricevuto dal dispositivo 4 personale.
A questo punto e come illustrato nella figura 10, il server 3 di autenticazione invia al server 2 di gestione il risultato della verifica della password OTP monouso: questo risultato può essere positivo (ovvero la richiesta R è autentica e quindi può venire processata) oppure negativo (ovvero la richiesta R non è autentica e quindi non deve venire processata).
Infine e come illustrato nella figura 11, il server 2 di gestione invia al dispositivo 4 personale il risultato della richiesta R (diretta conseguenza della verifica della password OTP monouso ricevuta dal server 3 di autenticazione) . Ovviamente, per dare regolare corso alla richiesta R il server 2 di gestione necessita preliminarmente della autenticazione della richiesta R (ovvero di una verifica positiva della password OTP monouso ricevuta dal server 3 di autenticazione) e successivamente verifica che non siano presenti altre condizioni ostative (ad esempio la mancata disponibilità del bene o servizio richiesto oppure l'insufficienza di fondi nel sistema di pagamento scelto dall'utente).
Secondo quanto sopra descritto, come mezzo di autenticazione della richiesta R viene utilizzata una password OTP monouso che viene generata all'interno del dispositivo 4 personale e viene inviata frazionata al server 3 di autenticazione. Per generare la password OTP monouso, come detto in precedenza, all'utente è richiesto di digitare il proprio codice PIN autorizzativo che viene utilizzato dal modulo SDK di autenticazione del software S installato nel dispositivo 4 personale per decriptare i dati rilevanti (ad esempio il codice FP identificativo del dispositivo 4 personale) che sono stati preventivamente memorizzati in una area sicura del dispositivo 4 personale e criptati utilizzando il codice PIN autorizzativo.
Viene di seguito descritta una preferita forma di attuazione del processo di registrazione del primo dispositivo 4 personale dell'utente (ovvero la prima registrazione eseguita in assoluto dall'utente attraverso il proprio dispositivo 4 personale) presso il server 3 di autenticazione. Preliminarmente, l'utente deve accreditarsi presso il server 3 di autenticazione per ricevere dal server 3 di autenticazione un identificativo utente (denominato comunemente " UserID ") ed un codice di attivazione che verrà successivamente utilizzato. Una volta concluso il processo di accreditamento presso il server 3 di autenticazione, l'utente deve installare nel proprio dispositivo 4 personale il software S (ovvero la " Integrating App" contenente il modulo SDK di autenticazione) necessario per interagire con il server 3 di autenticazione. Quindi, attraverso il software S (" Integrating App" contenente il modulo SDK di autenticazione) installato nel dispositivo 4 personale, l'utente deve scegliere un codice PIN autorizzativo e deve inserire il proprio identificativo utente ("UserID" ) ed il proprio codice di attivazione (forniti in precedenza dal server 3 di autenticazione al momento dell'accreditamento presso il server 3 di autenticazione stesso).
A questo punto, il software S (" Integrating App" contenente il modulo SDK di autenticazione) installato nel dispositivo 4 personale calcola una coppia di chiavi associate all'utente: una prima chiave denominata PUKey ed una seconda chiave denominata PRKey; inoltre, il software S (" Integrating App" contenente il modulo SDK di autenticazione) installato nel dispositivo 4 personale esegue una crittografia (preferibilmente attraverso un algoritmo SHA-2, ovvero "Secure Hash Algorithm 2") dell'identificativo utente ("UserID") e del codice di attivazione ed invia al server 3 di autenticazione la chiave PUKey e 1'identificativo utente e codice di attivazione crittografati insieme. A questo punto, il server 3 di autenticazione decritta 1'identificativo utente ("UserID" ) ed il codice di attivazione ricevuti dal dispositivo 4 personale e verifica che corrispondano esattamente a quanto comunicato all'utente al momento dell'accreditamento dell'utente stesso; in caso di verifica positiva, il server 3 di autenticazione crittografa, utilizzando la chiave PUkey, il seme che dovrà venire utilizzato dal dispositivo 4 personale per inizializzare il generatore di numeri pseudo-casuali che produce la password OTP monouso ed invia il seme crittografato al dispositivo 4 personale.
Il dispositivo 4 personale riceve il seme crittografato dal server 3 di autenticazione, decritta il seme del generatore di numeri pseudo-casuali utilizzando la chiave PUkey e quindi memorizza il seme del generatore di numeri pseudo-casuali in una area sicura: preferibilmente, il seme viene criptato utilizzando il codice PIN autorizzativo scelto dall'utente all'atto del processo di registrazione in modo tale che sia accessibile (ovvero utilizzabile) sono inserendo preventivamente il codice PIN autorizzativo.
A questo punto, il dispositivo 4 personale genera una password OTP monouso (ovvero una password temporanea) utilizzando il algoritmo generatore di numeri pseudo-casuali ed il seme appena ricevuto dal server 3 di autenticazione; quindi, il dispositivo 4 personale crittografa la password OTP monouso utilizzando la chiave PUkey ed invia la password OTP monouso crittata al server 3 di autenticazione. Infine, il server 3 di autenticazione decritta la password OTP monouso crittata utilizzando la chiave PUkey e verifica che la password OTP monouso sia corretta (ovvero corrisponda ad una password OTP monouso di controllo generata all'interno del server 3 di autenticazione mediante un proprio algoritmo generatore di numeri pseudo-casuali); se la password OTP monouso ricevuta dal server 3 di autenticazione è corretta, il processo di registrazione viene concluso positivamente.
Secondo una alternativa, e perfettamente equivalente, forma di attuazione, il codice PIN autorizzativo potrebbe venire sostituito da un dato biometrico (una impronta digitale, una immagine dell'iride, una fotografia del viso...) dell'utente che viene rilevato dal dispositivo 4 personale al momento del processo di registrazione e viene successivamente rilevato dal dispositivo 4 personale quando viene generata la richiesta R utilizzando 1 ' " Integrating App"; in particolare, il dato biometrico dell'utente o una informazione ricavata dal dato biometrico dell'utente vengono utilizzati per criptare/decriptare (criptare in fase di registrazione, decriptare in fase di generazione della richiesta R) i dati rilevanti (ad esempio il codice FP identificativo del dispositivo 4 personale) memorizzati in una area sicura del dispositivo 4 personale.
Secondo una possibile forma di attuazione, il dato biometrico dell'utente o una informazione ricavata dal dato biometrico dell'utente potrebbero venire utilizzati nel processo di generazione della password OTP monouso, ovvero la password OTP monouso è anche funzione del dato biometrico dell'utente o di una informazione ricavata dal dato biometrico dell'utente.
Secondo una alternativa e perfettamente equivalente forma di attuazione, come mezzo di autenticazione della richiesta R viene utilizzato un dato biometrico (una impronta digitale, una immagine dell'iride, una fotografia del viso...) dell'utente o una informazione ricavata dal dato biometrico dell'utente che viene generato all'interno del dispositivo 4 personale e viene inviato frazionato al server 3 di autenticazione secondo le stesse identiche modalità descritte in precedenza relativamente alla password OTP monouso; in altre parole, il dato biometrico dell'utente o una informazione ricavata dal dato biometrico dell'utente sostituiscono la password OTP monouso. È anche possibile che come mezzo di autenticazione della richiesta R vengano utilizzati contemporaneamente sia una password OTP monouso sia un dato biometrico dell'utente o una informazione ricavata dal dato biometrico dell'utente.
Per la gestione del dato biometrico dell'utente o di una informazione ricavata dal dato biometrico dell'utente, durante la procedura di registrazione dell'utente nel server 3 di autenticazione il server 3 di autenticazione stesso memorizza il dato biometrico dell'utente o l'informazione ricavata dal dato biometrico dell'utente. Quando viene generata la richiesta R nel dispositivo 4 personale viene generato nuovamente nel dispositivo 4 personale stesso il dato biometrico dell'utente (in questo modo si ha la certezza che è proprio l'utente che sta utilizzando il dispositivo 4 personale); nel dispositivo 4 personale, il dato biometrico o l'informazione ricavata dal dato biometrico dell'utente vengono suddivisi in una prima parte ed in una seconda parte tra loro complementari e quindi il dispositivo 4 personale invia unicamente la prima parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente al server 2 di gestione ed invia unicamente la seconda parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente al server 3 di autenticazione. Quindi, il server 2 di gestione invia la prima parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente al server 3 di autenticazione che ricompone il dato biometrico dell'utente o l'informazione ricavata dal dato biometrico dell'utente combinando la prima parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente ricevuta dal dispositivo 4 personale attraverso il server 2 di gestione con la seconda parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente ricevuta direttamente dal dispositivo 4 personale. Infine, il server 3 di autenticazione verifica la correttezza del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente ricevuti (in parte direttamente ed in parte indirettamente) dal dispositivo 4 personale mediante un confronto con il dato biometrico dell'utente o con l'informazione ricavata dal dato biometrico dell'utente memorizzati nel server 3 di autenticazione durante la fase di registrazione.
Il metodo di autenticazione sopra descritto presenta numerosi vantaggi.
In primo luogo, il metodo di autenticazione sopra descritto permette di eseguire una autenticazione estremamente sicura della richiesta R dell'utente, in quanto il mezzo di autenticazione (password OTP monouso e/o eventualmente dato biometrico dell'utente) generato nel dispositivo 4 personale per autenticare la richiesta R viene inviato frazionato attraverso connessioni sicure su Internet seguendo due canali diversi e completamente indipendenti. Infatti la prima parte del mezzo di autenticazione viene inviata dal dispositivo 4 personale al server 2 di gestione (e, successivamente dal server 2 di gestione al server 3 di autenticazione) mentre la seconda parte del mezzo di autenticazione viene inviata dal dispositivo 4 personale al server 3 di autenticazione; di conseguenza, in nessun momento lungo uno stesso canale di comunicazione viene inviato il mezzo di autenticazione completo. Quindi, per venire a conoscenza del mezzo di autenticazione completo un soggetto terzo dovrebbe essere in grado di intercettare e decodificare nello stesso momento due trasmissioni sicure tra loro separate ed indipendenti; tale intercettazione multipla è estremamente complessa e di difficilissima realizzazione.
Inoltre, il metodo di autenticazione sopra descritto presenta delle ulteriori robustezze, in quanto oltre a conoscere il mezzo di autenticazione (password OTP monouso o dato biometrico dell'utente) completo è necessario conoscere sia il codice UiDidentificativo dell'utente, sia il codice FP identificativo del dispositivo 4 personale (entrambi questi codici vengono tra loro confrontati nel server 3 di autenticazione); è importante osservare che il codice UIDidentificativo dell'utente ed il codice FP identificativo del dispositivo 4 personale viaggiano in Internet seguendo due canali diversi e completamente indipendenti. Infatti il codice Umidentificativo dell'utente viene inviato dal dispositivo 4 personale al server 2 di gestione (e, successivamente dal server 2 di gestione al server 3 di autenticazione) mentre il codice FP identificativo del dispositivo 4 personale viene inviato dal dispositivo 4 personale al server 3 di autenticazione; di conseguenza, in nessun momento lungo uno stesso canale di comunicazione vengono inviati insieme il codice Umidentificativo dell'utente ed il codice FP identificativo del dispositivo 4 personale. Quindi, per venire a conoscenza di entrambi i codici 3⁄4>e FP identificativi un soggetto terzo dovrebbe essere in grado di intercettare e decodificare nello stesso momento due trasmissioni sicure tra loro separate ed indipendenti; come detto in precedenza, tale intercettazione multipla è estremamente complessa e di difficilissima realizzazione.
Infine, il metodo di autenticazione sopra descritto fornisce una elevata garanzia nei confronti dell'utente in quanto la password OTP monouso è legata alla richiesta R, ovvero la password OTP monouso è utilizzabile per identificare solo ed unicamente la richiesta R utilizzata nella fase di generazione della password OTP monouso stessa, in quanto la password OTP monouso viene generata utilizzando almeno un dato significativo della richiesta R (quindi variando la richiesta R varia inevitabilmente anche la password OTP monouso).
Claims (17)
- R IV E N D I C A Z I O N I 1) Metodo di autenticazione sicura di una richiesta (R) rivolta ad un fornitore remoto e generata in un dispositivo (4) personale utilizzato da un utente; il metodo di autenticazione comprende le fasi di: generare, nel dispositivo (4) personale, la richiesta (R) rivolta al fornitore remoto; generare, nel dispositivo (4) personale, un mezzo (OTP) di autenticazione; ed inviare la richiesta (R) ed almeno parte del mezzo (OTP) di autenticazione dal dispositivo (4) personale ad un server (2) di gestione appartenente al fornitore remoto per autenticare la richiesta (R) stessa; il metodo di autenticazione è caratterizzato dal fatto di comprendere le ulteriori fasi di: suddividere, nel dispositivo (4) personale, il mezzo (OTP) di autenticazione in una prima parte (OTPi_i6)ed in una seconda parte (OTPi7-32)tra loro complementari; inviare unicamente la prima parte (ΟΤΡι-ι6)del mezzo (OTP) di autenticazione dal dispositivo (4) personale al server (2) di gestione; inviare unicamente la seconda parte (OTPi7-32)del mezzo (OTP) di autenticazione dal dispositivo (4) personale ad un server (3) di autenticazione diverso e separato dal server (2) di gestione; inviare la prima parte (OTPi_i6)del mezzo (OTP) di autenticazione dal server (2) di gestione al server (3) di autenticazione; ricomporre, nel server (3) di autenticazione, il mezzo (OTP) di autenticazione combinando la prima parte (OTPi_i6)del mezzo (OTP) di autenticazione con la seconda parte (OTP17-32)del mezzo (OTP) di autenticazione; verificare, nel server (3) di autenticazione, la correttezza del mezzo (OTP) di autenticazione; ed inviare dal server (3) di autenticazione al server (2) di gestione il risultato, positivo o negativo, della verifica della correttezza del mezzo (OTP) di autenticazione.
- 2) Metodo di autenticazione secondo la rivendicazione 1, in cui il mezzo (OTP) di autenticazione è una password (OTP) monouso.
- 3) Metodo di autenticazione secondo la rivendicazione 2, in cui la fase di verificare, nel server (3) di autenticazione, la correttezza della password (OTP) monouso comprende le ulteriori fasi di: generare una ulteriore password (OTP) monouso di controllo; e verificare se la password (OTP) monouso ricevuta è corrispondente alla password (OTP) monouso di controllo.
- 4) Metodo di autenticazione secondo la rivendicazione 2 o 3, in cui: la password (OTP) monouso viene generata utilizzando almeno un dato significativo della richiesta (R); ed il dato significativo della richiesta (R) viene trasmesso al server (3) di autenticazione.
- 5) Metodo di autenticazione secondo la rivendicazione 4, in cui il dato significativo della richiesta (R) viene trasmesso dal dispositivo (4) personale al server (3) di autenticazione assieme alla seconda parte (OTPi7-32)della password (OTP) monouso.
- 6) Metodo di autenticazione secondo la rivendicazione 4, in cui il dato significativo della richiesta (R) viene trasmesso dal server (2) di gestione al server (3) di autenticazione assieme alla prima parte (OTPi_i6)della password (OTP) monouso.
- 7) Metodo di autenticazione secondo la rivendicazione 1, in cui il mezzo (OTP) di autenticazione è un dato biometrico dell'utente o una informazione ricavata dal dato biometrico dell'utente.
- 8) Metodo di autenticazione secondo la rivendicazione 7 e comprendente le ulteriori fasi di: memorizzare il dato biometrico dell'utente o una informazione ricavata dal dato biometrico dell'utente nel server (3) di autenticazione durante una procedura di registrazione dell'utente stesso; generare nuovamente nel dispositivo (4) personale il dato biometrico dell'utente; e verificare, nel server (3) di autenticazione, la correttezza del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente ricevuti dal dispositivo (4) personale mediante un confronto con il dato biometrico dell'utente o con l'informazione ricavata dal dato biometrico dell'utente memorizzato nel server (3) di autenticazione.
- 9) Metodo di autenticazione secondo una delle rivendicazioni da 1 a 8 e comprendente l'ulteriore fase di memorizzare, preventivamente durante una procedura di registrazione dell'utente, un codice (UiD)identificativo dell'utente abbinato ad un codice (FP) identificativo del dispositivo (4) personale nel server (3) di autenticazione.
- 10) Metodo di autenticazione secondo la rivendicazione 9 e comprendente le ulteriori fasi di: inviare, assieme alla prima parte (OTPi_i6)del mezzo (OTP) di autenticazione, dal dispositivo (4) personale al server (2) di gestione il codice (UiD)identificativo dell'utente; inviare, assieme alla prima parte (OTPi_i6)del mezzo (OTP) di autenticazione, dal server (2) di gestione al server (3) di autenticazione il codice (UiD)identificativo dell'utente; inviare, assieme alla seconda parte (OTPi7-32)del mezzo (OTP) di autenticazione, dal dispositivo (4) personale al server (3) di autenticazione il codice (FP) identificativo del dispositivo (4) personale; verificare, nel server (3) di autenticazione, che il codice (UiD)identificativo dell'utente ricevuto dal server (2) di gestione corrisponda al codice (FP) identificativo del dispositivo (4) personale ricevuto dal dispositivo (4) personale; e considerare sempre negativa la verifica del mezzo (OTP) di autenticazione se il codice (UiD)identificativo dell'utente ricevuto dal server (2) di gestione non corrisponde al codice (FP) identificativo del dispositivo (4) personale ricevuto dal dispositivo (4) personale.
- 11) Metodo di autenticazione secondo la rivendicazione 9 o 10, in cui il codice (FP) identificativo del dispositivo (4) personale è un codice identificativo di un hardware del dispositivo (4) personale e/o è un codice identificativo di un software (S) installato nel dispositivo (4) personale.
- 12) Metodo di autenticazione secondo una delle rivendicazioni da 1 a 11 e comprendente le ulteriori fasi di: inviare la richiesta (R) dal server (2) di gestione al server (3) di autenticazione assieme alla prima parte (OTPi_i6)del mezzo (OTP) di autenticazione; inviare la richiesta (R) dal dispositivo (4) personale al server (3) di autenticazione assieme alla seconda parte (OTP17-32)del mezzo (OTP) di autenticazione; verificare, nel server (3) di autenticazione, che la richiesta (R) ricevuta dal server (2) di gestione corrisponda alla richiesta (R) ricevuta dal dispositivo (4) personale; e considerare sempre negativa la verifica del mezzo (OTP) di autenticazione se la richiesta (R) ricevuta dal server (2) di gestione non corrisponde alla richiesta (R) ricevuta dal dispositivo (4) personale.
- 13) Metodo di autenticazione secondo una delle rivendicazioni da 1 a 12 e comprendente le ulteriori fasi di: memorizzare almeno una informazione necessaria alla generazione del mezzo (OTP) di autenticazione in una area sicura del dispositivo (4) personale; criptare l'informazione necessaria alla generazione del mezzo (OTP) di autenticazione mediante un mezzo di autorizzazione nella disponibilità dell'utente; e richiedere all'utente di inserire, nel dispositivo (4) personale, il mezzo di autorizzazione al momento della generazione della richiesta (R) rivolta al fornitore remoto per potere decriptare l'informazione necessaria alla generazione del mezzo (OTP) di autenticazione mediante il mezzo di autorizzazione stesso.
- 14) Metodo di autenticazione secondo la rivendicazione 13, in cui il mezzo di autorizzazione è costituito da un codice PIN autorizzativo noto all'utente.
- 15) Metodo di autenticazione secondo la rivendicazione 13, in cui il mezzo di autorizzazione è costituito da un dato biometrico dell'utente o da una informazione ricavata dal dato biometrico dell'utente.
- 16) Metodo di autenticazione sicura di una richiesta (R) rivolta ad un fornitore remoto e generata in un dispositivo (4) personale utilizzato da un utente; il metodo di autenticazione comprende le fasi di: generare, nel dispositivo (4) personale, la richiesta (R) rivolta al fornitore remoto; generare, nel dispositivo (4) personale, una password (OTP) monouso; ed inviare la richiesta (R) ed almeno parte della password (OTP) monouso dal dispositivo (4) personale ad un server (2) di gestione appartenente al fornitore remoto per autenticare la richiesta (R) stessa; il metodo di autenticazione è caratterizzato dal fatto di comprendere le ulteriori fasi di: suddividere, nel dispositivo (4) personale, la password (OTP) monouso in una prima parte (OTPi_i6)ed in una seconda parte (OTPi7-32)tra loro complementari; inviare unicamente la prima parte (OTPi_i6)della password (OTP) monouso dal dispositivo (4) personale al server (2) di gestione; inviare unicamente la seconda parte (OTPi7-32)della password (OTP) monouso dal dispositivo (4) personale ad un server (3) di autenticazione diverso e separato dal server (2) di gestione; inviare la prima parte (OTPi_i6)della password (OTP) monouso dal server (2) di gestione al server (3) di autenticazione; ricomporre, nel server (3) di autenticazione, la password (OTP) monouso combinando la prima parte (OTPi_i6)della password (OTP) monouso con la seconda parte (OTPi7-32)della password (OTP) monouso; verificare, nel server (3) di autenticazione, la correttezza della password (OTP) monouso; ed inviare dal server (3) di autenticazione al server (2) di gestione il risultato, positivo o negativo, della verifica della correttezza della password (OTP) monouso.
- 17) Metodo di autenticazione sicura di una richiesta (R) rivolta ad un fornitore remoto e generata in un dispositivo (4) personale utilizzato da un utente; il metodo di autenticazione comprende le fasi di: memorizzare un dato biometrico dell'utente o una informazione ricavata dal dato biometrico dell'utente in un server (3) di autenticazione durante una procedura di registrazione dell'utente stesso; generare nuovamente nel dispositivo (4) personale il dato biometrico dell'utente; suddividere, nel dispositivo (4) personale, il dato biometrico dell'utente o l'informazione ricavata dal dato biometrico dell'utente in una prima parte ed in una seconda parte tra loro complementari; inviare unicamente la prima parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente dal dispositivo (4) personale ad un server (2) di gestione diverso e separato dal server (3) di autenticazione; inviare unicamente la seconda parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente dal dispositivo (4) personale al server (3) di autenticazione; inviare la prima parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente dal server (2) di gestione al server (3) di autenticazione; ricomporre, nel server (3) di autenticazione, il dato biometrico dell'utente o l'informazione ricavata dal dato biometrico dell'utente combinando la prima parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente con la seconda parte del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente; verificare, nel server (3) di autenticazione, la correttezza del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente ricevuti dal dispositivo (4) personale mediante un confronto con il dato biometrico dell'utente o con l'informazione ricavata dal dato biometrico dell'utente memorizzati nel server (3) di autenticazione; ed inviare dal server (3) di autenticazione al server (2) di gestione il risultato, positivo o negativo, della verifica del dato biometrico dell'utente o dell'informazione ricavata dal dato biometrico dell'utente.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IT102016000079563A IT201600079563A1 (it) | 2016-07-28 | 2016-07-28 | Metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale con biforcazione della trasmissione di un mezzo di autenticazione |
| EP17183739.6A EP3276878A1 (en) | 2016-07-28 | 2017-07-28 | Method for the safe authentication of a request made to a remote provider and generated in a personal device with bifurcation of the transmission of an authentication means |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IT102016000079563A IT201600079563A1 (it) | 2016-07-28 | 2016-07-28 | Metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale con biforcazione della trasmissione di un mezzo di autenticazione |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| IT201600079563A1 true IT201600079563A1 (it) | 2018-01-28 |
Family
ID=57610216
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| IT102016000079563A IT201600079563A1 (it) | 2016-07-28 | 2016-07-28 | Metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale con biforcazione della trasmissione di un mezzo di autenticazione |
Country Status (2)
| Country | Link |
|---|---|
| EP (1) | EP3276878A1 (it) |
| IT (1) | IT201600079563A1 (it) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110032414B (zh) * | 2019-03-06 | 2023-06-06 | 联想企业解决方案(新加坡)有限公司 | 远程控制台模式下安全的用户认证的装置和方法 |
| CN117688566A (zh) * | 2022-09-02 | 2024-03-12 | 华为技术有限公司 | 一种数据保护方法及电子设备 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008127309A2 (en) * | 2006-11-07 | 2008-10-23 | Security First Corporation | Systems and methods for distributing and securing data |
| WO2014108835A2 (en) * | 2013-01-08 | 2014-07-17 | Bar-Ilan University | A method for providing security using secure computation |
| FR3021777A1 (fr) * | 2014-06-03 | 2015-12-04 | Morpho | Stockage distribue securise par calcul multipartite |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101803272B (zh) * | 2007-06-26 | 2013-08-14 | 豌豆制造技术有限公司 | 认证系统和方法 |
-
2016
- 2016-07-28 IT IT102016000079563A patent/IT201600079563A1/it unknown
-
2017
- 2017-07-28 EP EP17183739.6A patent/EP3276878A1/en not_active Withdrawn
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008127309A2 (en) * | 2006-11-07 | 2008-10-23 | Security First Corporation | Systems and methods for distributing and securing data |
| WO2014108835A2 (en) * | 2013-01-08 | 2014-07-17 | Bar-Ilan University | A method for providing security using secure computation |
| FR3021777A1 (fr) * | 2014-06-03 | 2015-12-04 | Morpho | Stockage distribue securise par calcul multipartite |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3276878A1 (en) | 2018-01-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20200372503A1 (en) | Transaction messaging | |
| RU2710897C2 (ru) | Способы безопасного генерирования криптограмм | |
| US9218493B2 (en) | Key camouflaging using a machine identifier | |
| US20180144114A1 (en) | Securing Blockchain Transactions Against Cyberattacks | |
| DK2995039T3 (en) | SYSTEMS AND PROCEDURES FOR SECURE COMMUNICATION. | |
| US20200358614A1 (en) | Securing Transactions with a Blockchain Network | |
| CN101765996B (zh) | 用于远程认证和交易签名的装置和方法 | |
| US8572394B2 (en) | OTP generation using a camouflaged key | |
| ES2779750T3 (es) | Sistema de firma electrónica para un documento electrónico que utiliza un circuito de autenticación de terceros | |
| WO2016045520A1 (zh) | 一种基于标记的移动支付方法及移动支付系统 | |
| CN103095456A (zh) | 交易报文的处理方法和系统 | |
| US11949785B1 (en) | Biometric authenticated biometric enrollment | |
| EP2758922A2 (en) | Securing transactions against cyberattacks | |
| CN106027252A (zh) | 一种身份证认证系统中的云认证平台 | |
| IT201600079563A1 (it) | Metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale con biforcazione della trasmissione di un mezzo di autenticazione | |
| IT201600079574A1 (it) | Metodo di autenticazione sicura di una richiesta rivolta ad un fornitore remoto e generata in un dispositivo personale mediante l'utilizzo di una password monouso dipendente anche dalla richiesta | |
| EP3320664A1 (en) | Method of authenticating communication of an authentication device and at least one authentication server using local factor | |
| TWI679603B (zh) | 用於幫助持卡人首次設定金融卡密碼之系統及其方法 | |
| ITRM20120376A1 (it) | Metodo per securizzare tramite un dispositivo client una operazione dispositiva o di acquisto | |
| ITRM20130364A1 (it) | Sistema di firma elettronica di un documento elettronico mediante utilizzo di carta di pagamento |