IT202100017279A1 - Immagine animata codificata e metodo per generare, visualizzare e leggere tale immagine animata codificata, in particolare per l’autorizzazione di operazioni su sevizi online - Google Patents

Immagine animata codificata e metodo per generare, visualizzare e leggere tale immagine animata codificata, in particolare per l’autorizzazione di operazioni su sevizi online Download PDF

Info

Publication number
IT202100017279A1
IT202100017279A1 IT102021000017279A IT202100017279A IT202100017279A1 IT 202100017279 A1 IT202100017279 A1 IT 202100017279A1 IT 102021000017279 A IT102021000017279 A IT 102021000017279A IT 202100017279 A IT202100017279 A IT 202100017279A IT 202100017279 A1 IT202100017279 A1 IT 202100017279A1
Authority
IT
Italy
Prior art keywords
client device
otp
function
animated image
frames
Prior art date
Application number
IT102021000017279A
Other languages
English (en)
Inventor
Adriano Luraschi
Original Assignee
Intesa Sanpaolo S P A
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 Intesa Sanpaolo S P A filed Critical Intesa Sanpaolo S P A
Priority to IT102021000017279A priority Critical patent/IT202100017279A1/it
Priority to IL309812A priority patent/IL309812A/en
Priority to EP22747117.4A priority patent/EP4364012A1/en
Priority to PCT/IB2022/056101 priority patent/WO2023275813A1/en
Publication of IT202100017279A1 publication Critical patent/IT202100017279A1/it

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/36—User authentication by graphic or iconic representation
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C5/00—Ciphering apparatus or methods not provided for in the preceding groups, e.g. involving the concealment or deformation of graphic data such as designs, written or printed messages
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0846—Network architectures or network communication protocols for network security for authentication of entities using passwords using time-dependent-passwords, e.g. periodically changing passwords
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • 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
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • 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/56—Financial cryptography, e.g. electronic payment or e-cash

Description

TITOLO: ?Immagine animata codificata e metodo per generare, visualizzare e leggere tale immagine animata codificata, in particolare per l?autorizzazione di operazioni su sevizi online?.
DESCRIZIONE
CAMPO DI APPLICAZIONE
La presente invenzione ha per oggetto un?immagine animata 1 codificata ed un metodo per generare, visualizzare e leggere un?immagine animata 1 codificata, specialmente per l?autorizzazione di operazioni su sevizi online di tipo finanziario. Descrizione della tecnica anteriore
Nella tecnica nota, l?esecuzione di operazioni dispositive sui canali digitali di una Banca, ad esempio la web application della Banca via Internet, viene tipicamente autorizzata dal richiedente attraverso un meccanismo che prevede una autenticazione a pi? fattori.
Il primo fattore di autenticazione ? costituito dall?uso delle credenziali, quali username e PIN o password, definite per l?utente sui sistemi bancari.
Nel corso degli anni vi ? vista una notevole evoluzione relativamente alla modalit? di comunicazione ed uso del secondo fattore di autenticazione, nel tentativo di coniugare un elevato standard di sicurezza con la semplicit? di utilizzo da parte dell?utente, e tenendo conto dei costi operativi della soluzione scelta.
Alcuni esempi di soluzioni utilizzate sono di seguito elencate:
1) Generazione e pre-condivisione con l?utente di una matrice di codici dispositivi da utilizzare on-demand e utilizzabili per una singola operazione;
2) Consegna all?utente di un token fisico per la generazione temporizzata di One Time Password/PIN, ossia OTP verificabili nel back-end;
3) Invio di OTP via SMS al telefono mobile dell?utente;
4) Invio di Notifiche Push ricevibili sull?app mobile della banca installata sul device dell?utente.
Per garantire elevati standard di sicurezza nell?autorizzazione di operazioni dispositive, ? fondamentale utilizzare un meccanismo di autenticazione ad almeno due fattori, che spaziano tra due delle seguenti caratteristiche:
- ?Qualcosa che sai?, provato dalla conoscenza di credenziali di tipo username e password o PIN;
- ?Qualcosa che hai?, provato dalla possibilit? di dimostrare disponibilit? di un oggetto fisico come smart card, token fisico e smartphone;
- ?Qualcosa che sei?, provato da qualche tipo di riconoscimento biometrico come impronta digitale, riconoscimento dell?iride e riconoscimento facciale.
Nel caso delle operazioni dispositive bancarie, il ?qualcosa che sai? ? utilizzato nel primo processo di autenticazione mediante la login basata su username e password per accedere all?applicazione web della banca, per aprire la sessione in cui si definisce e si richiede l?operazione. Il ?qualcosa che hai? ? utilizzato per una ulteriore fase di approvazione dell?operazione, dimostrando di aver ricevuto una OTP, o di possedere del materiale crittografico su un dispositivo fisico, ad esempio sullo smartphone. Il ?qualcosa che sei? pu? essere utilizzato per sbloccare l?accesso al materiale crittografico di un dispositivo mediante la lettura dell?impronta digitale sullo smartphone.
Problema della tecnica anteriore
Nella tecnica nota, sono state riscontrate diverse attivit? fraudolente che utilizzano astute combinazioni di phishing e social engineering per carpire la buona fede di ignari utenti ed aggirare i controlli di sicurezza a protezione delle operazioni dispositive bancarie.
Un utente non particolarmente attento e consapevole delle minacce cyber pu? essere indotto, attraverso e-mail di phishing e siti web che simulano il portale di una banca, a rivelare ai criminali informatici le proprie credenziali di accesso.
Attraverso l?inganno e l?uso malevolo della social engineering, un utente pu? essere indotto, ad esempio da un malintenzionato che si finge un proattivo operatore di banca, a comunicare in tempo reale un codice dispositivo o l?OTP, o a confermare la Notifica Push ricevuta sul proprio smartphone.
Come detto prima, il ?qualcosa che sei? pu? essere utilizzato per sbloccare l?accesso al materiale crittografico di un dispositivo mediante la lettura dell?impronta digitale sullo smartphone. Tuttavia, occorre qui rilevare che questo meccanismo viene utilizzato localmente al dispositivo dell?utente e, come rilevato prima, esso presenta delle criticit? quando ad esempio l?utente viene indotto a sboccare l??operazione con la sua impronta digitale in tempo reale sotto indicazione di un frodatore spacciatosi per funzionario della banca.
SOMMARIO DELL?INVENZIONE
Scopo dell?invenzione in oggetto ? quello di poter disporre di un sistema di identificazione sicuro, in grado di superare gli inconvenienti dei sistemi noti sopra descritti.
Ulteriore scopo dell?invenzione in oggetto ? quello di evitare truffe del tipo appena descritto, e di proteggere le operazioni dispositive ad alto rischio con un meccanismo che non preveda l?utilizzo di quantit? di sicurezza comunicabili a terzi verbalmente, per iscritto o tramite invio di foto o screenshot, e che garantisca che l?approvazione sia inequivocabilmente associata ad un?operazione che ? stata richiesta alla presenza dell?utente sul terminale utilizzato per stabilire la sessione.
Ulteriore scopo della presente invenzione ? quello di rendere pi? sicura l?esecuzione, attraverso i canali digitali di una banca, di operazioni bancarie ad elevato valore e rischio, contrastando possibili attivit? fraudolente, come ad esempio quelle perpetrate mediante phishing smishing e vishing.
Ulteriore scopo della presente invenzione ? quello di poter utilizzare il ?qualcosa che sei? per sbloccare l?accesso mediante verifica di autenticazione lato back-end.
Il compito tecnico precisato e gli scopi specificati sono sostanzialmente raggiunti da un?immagine animata 1 codificata e da un metodo per generare, visualizzare e leggere un?immagine animata 1 codificata, in accordo con una o pi? delle unite rivendicazioni.
Vantaggi dell?invenzione
Grazie ad una forma di realizzazione, ? possibile ottenere un?immagine animata 1 codificata da impiegarsi in alternativa alle tecniche di codificazione note prima descritte.
Grazie ad una forma di realizzazione, ? possibile realizzare un metodo per generare, visualizzare e leggere tale immagine animata 1 codificata, impiegabile specialmente per l?autorizzazione di operazioni su piattaforme online.
Grazie alla presente invenzione, il ?qualcosa che sei? pu? essere utilizzato per sbloccare l?accesso mediante verifica di autenticazione lato back-end.
BREVE DESCRIZIONE DEI DISEGNI
Le caratteristiche ed i vantaggi della presente invenzione risulteranno evidenti dalla seguente descrizione dettagliata di una possibile forma di realizzazione pratica, illustrata a titolo di esempio non limitativo nell?insieme dei disegni, in cui:
- la figura 1 mostra l?immagine animata codificata in accordo con una forma realizzativa della presente invenzione,
- la figura 2 mostra un primo esempio di una sequenza di fasi del metodo secondo la presente invenzione,
- la figura 3 mostra un secondo esempio di una sequenza di fasi del metodo secondo la presente invenzione,
- la figura 4 mostra un terzo esempio di una sequenza di fasi del metodo secondo la presente invenzione,
- la figura 5 mostra un quarto esempio di una sequenza di fasi del metodo secondo la presente invenzione.
DESCRIZIONE DETTAGLIATA
Anche qualora non esplicitamente evidenziato, le singole caratteristiche descritte in riferimento alle specifiche realizzazioni dovranno intendersi come accessorie e/o intercambiabili con altre caratteristiche, descritte in riferimento ad altri esempi di realizzazione.
La presente invenzione ha per oggetto un?immagine animata 1 codificata, riproducibile su un?interfaccia grafica. Nella presente descrizione l?immagine animata 1 verr? anche richiamata come logo dinamico.
L?immagine animata 1 codificata comprende una pluralit? di fotogrammi F configurati per essere visualizzati in sequenza su un?interfaccia grafica, Nell?ambito della presente invenzione, per immagine animata 1, o logo dinamico, si intende un?immagine dinamica, ossia in movimento in quando comprendente una serie di fotogrammi F riprodotti in successione, e quindi visualizzati in sequenza.
L?immagine animata 1 codificata comprende un codice OTP criptato, distribuito su almeno due fotogrammi F della pluralit? di fotogrammi F secondo una funzione di cifratura reversibile. Per codice OTP o One-time password (in acronimo OTP, in italiano, password valida una sola volta), nell'ambito della crittografia e della sicurezza informatica, si intende una password che resta valida solo per una singola sessione di accesso o una transazione finanziaria. Preferibilmente, un codice OTP comprende una password o PIN valida per un tempo limitato, pi? preferibilmente per meno di un minuto, e utilizzabile una sola volta e solo per una singola sessione di accesso o una transazione. L?utilizzo di un codice OTP, invece di una password statica, consente di poter contrastare i cosiddetti replay-attacks. Ci? significa che, anche se un potenziale attaccante riuscisse a intercettare un codice OTP che ? gi? stato utilizzato per accedere a un servizio o eseguire una transazione, non sarebbe comunque in grado di riutilizzarlo, in quanto lo stesso codice OTP non sarebbe pi? valido.
Nell?ambito della presente descrizione, per brevit? espositiva si far? riferimento ad una pluralit? di fotogrammi F visualizzabili in sequenza su di una interfaccia grafica per costruire l?immagine animata 1 della presente invenzione. Tuttavia, tale definizione non deve essere interpretata nel senso pi? limitante, ossia intesa come sequenza di fotogrammi F costituiti da immagini analogiche. Infatti, nell?ambito di applicazione della presente invenzione, ossia su dispositivi elettronici come smartphone, tablet e computer, la sequenza di fotogrammi F dell?immagine animata 1 viene preferibilmente ottenuta tramite un programma che ne determina la configurazione e visualizzazione in formato digitale.
In accordo con una soluzione preferita dell?invenzione illustrata in figura 1, ciascun fotogramma F della pluralit? di fotogrammi F dell?immagine animata 1 codificata comprende una pluralit? di stringhe alfanumeriche. Il codice OTP criptato ? diviso in almeno due parti distribuite su almeno una stringa di ciascuno dei due fotogrammi F della pluralit? di fotogrammi F, secondo la funzione di cifratura. In altre parole, ciascun fotogramma F comprende un certo numero di stringhe, ossia di righe formate da una sequenza di caratteri alfanumerici. Alcuni o tutti i caratteri sono modificati tra un fotogramma e il successivo. In questo contesto, il codice OTP criptato ? dunque suddiviso in almeno due porzioni, le quali sono a loro volta distribuite su una o pi? stringhe di due o pi? fotogrammi F. Tale suddivisione e distribuzione dell?OTP criptato viene eseguita per mezzo della funzione di cifratura. Tale funzione di cifratura ? reversibile, e dunque, applicando una funzione inversa in fase di lettura dell?immagine animata 1 codificata ? possibile ricostruire il codice OTP criptato originale.
Secondo una forma alternativa alla precedente, l?immagine animata 1 rappresenta una figura dinamica, definita da contorni ed opzionalmente a colori. Secondo questa forma preferita, il codice OTP criptato ? incorporato negli elementi grafici della figura rappresentata nei fotogrammi F con modalit? analoghe a quelle prima descritte. Ad esempio, elementi grafici dell?immagine animata 1, come i contorni della figura e/o i colori dell?immagine rappresentata in almeno due fotogrammi F, nascondono il codice OTP secondo la funzione di cifratura reversibile.
La presente invenzione ha altres? per oggetto un metodo per generare, visualizzare e leggere un?immagine animata 1 codificata mediante un servizio online. Per servizio online si intende un?applicazione web supportata in back-end da almeno un web server in cui gli utenti registrati ed autenticati possono richiedere operazioni. Inoltre, il web server ? associato ad almeno un database in cui sono memorizzati i dati degli utenti registrati. Nella presente descrizione si far? particolare riferimento, per brevit? espositiva, alla forma realizzativa preferita in cui il servizio online ? il servizio di online banking offerto da una banca.
Il metodo comprende la fase di fornire una funzione randomica per la generazione di codici OTP, una funzione di cifratura reversibile, ed una funzione di riconoscimento residenti ed eseguibili in un web server associato al servizio online. Preferibilmente, il web server ? parte di un sistema centrale di una banca ed ?, pi? preferibilmente, associato ad un database comprendente i dati degli utenti della banca.
Il metodo comprende inoltre la fase di fornire una funzione di lettura e decodifica ed una funzione di identificazione residenti ed eseguibili su di un dispositivo client associato ad un utente autenticato. Occorre qui precisare che il dispositivo client ? dotato di almeno una fotocamera ed ? posto in comunicazione con il web server per consentire uno scambio di dati, preferibilmente mediante connessione Web mobile.
Il metodo prevede di generare un codice OTP tramite la funzione randomica residente nel web server del servizio online. In altre parole, il codice OTP viene generato lato web server, ossia lato back-end. Il codice OTP ? almeno associato ad una sessione di navigazione autenticata del dispositivo client sul web server. Preferibilmente, la funzione randomica comprende l?algoritmo di Lamport per la generazione di codice OTP. Vantaggiosamente, risulta sostanzialmente impossibile per un attaccante indovinare il prossimo codice OTP a partire dall?analisi di una sequenza precedente di codici OTP generati dallo stesso algoritmo. Come detto prima, il metodo prevede che il codice OTP venga generato, lato back-end, in corrispondenza di ogni operazione da autorizzare che venga richiesta da un certo utente sul servizio online. In particolare, sul lato server che ? ad esempio il sistema centrale di una banca, viene invocata una componente, ossia la funzione randomica, per generare un codice OTP che viene associato su una apposita tabella di database ad una serie di informazioni, tra cui, preferibilmente, la scadenza del codice OTP, l?identificativo dell?utente richiedente, l?identificativo della sessione utente e, pi? preferibilmente, specifiche caratteristiche dell?operazione richiesta dall?utente.
Il metodo comprende la fase di generare un?immagine animata 1 codificata comprendente una pluralit? di fotogrammi F configurati per essere visualizzati in sequenza su un?interfaccia grafica, crittando il codice OTP, suddividendolo in ameno due parti e distribuendole su almeno due fotogrammi F della pluralit? di fotogrammi F tramite la funzione di cifratura reversibile. Questa fase di codifica del codice OTP per generare l?immagine animata viene eseguita sul back-end, ossia lato web server mediante la funzione di cifratura reversibile. Come gi? specificato in precedenza, nella forma preferita dell?invenzione, altres? descritta esemplificativamente per brevit? espositiva, il web server ? il server centrale di una banca. La funzione di cifratura reversibile, eseguita su un web server del sistema centrale della banca, usa una libreria custom per generare un certo numero di fotogrammi F, a partire da un contenuto informativo o payload, che nello specifico comprende il codice OTP generato nella fase precedente. Gli almeno due fotogrammi F sono legati tra loro e con il payload secondo la specifica funzione di cifratura reversibile, in modo che la loro combinazione consenta di recuperare il payload, come si vedr? pi? avanti, attraverso una funzione inversa di decodifica (detta funzione di lettura e decodifica). Con riferimento alla figura 1, traducendo in una formula quanto appena descritto, immagine animata 1 = {fotogramma_1 F1, fotogramma_2 F2, ?, fotogramma_n Fn} = f(payload),
dove:
- payload ? il contenuto informativo contenente il codice OTP che si vuole trasmettere attraverso l?immagine animata;
- l?output della funzione di cifratura reversibile ? un certo numero di fotogrammi (almeno due), preferibilmente immagini in formato PNG o JPEG ottenute in base al payload utilizzando appunto una funzione biunivoca ed invertibile.
In altre parole, dalla combinazione dei due o pi? fotogrammi F ? possibile ottenere una immagine animata, dinamica, che pu? essere decodificata, restituendo il payload originale, e dunque il codice OTP.
Il metodo comprende anche la fase di riprodurre la pluralit? di fotogrammi F in sequenza su un?interfaccia grafica in comunicazione con il web server, cos? da visualizzare l?immagine animata 1 codificata. Preferibilmente, il metodo prevede di fornire una funzione di visualizzazione residente ed eseguibile sul terminare utilizzato per visualizzare l?immagine animata. A seconda dello specifico use case, come risulter? evidente dalle forme preferite e dagli esempi descritti nel seguito ed illustrati nelle figure da 2 a 5, l?immagine animata in movimento viene visualizzata preferibilmente su uno dei seguenti sistemi software:
- su di un sistema ATM, nello use case della verifica/abilitazione di un dispositivo client presso ATM (figura 2, esempio 1);
- su di un sistema in uso ai bancari di filiale della banca, nello use case della verifica/abilitazione del dispositivo client presso uno sportello di filiale bancaria (figura 3, esempio 2);
- su App Mobile, nello use case della verifica/abilitazione transitiva di un nuovo/secondo dispositivo client (figura 4. Esempio 3);
- via web browser su una Web Application, preferibilmente di una banca, nello use case di operazione dispositiva ad alto rischio (Figura 5, esempio 4).
Per ciascuna delle suddette tipologie di sistemi per la visualizzazione dell?immagine animata viene creata una libreria software che implementa una funzione di visualizzazione che, ricevendo la serie di fotogrammi F che costituiscono l?oggetto immagine animata 1, visualizza l?immagine in movimento corrispondente al payload incapsulato nei suddetti fotogrammi F.
Il metodo prevede di leggere e decodificare il codice OTP criptato mediante la funzione di lettura e decodifica quando la fotocamera del dispositivo client inquadra l?immagine animata 1 codificata visualizzata sull?interfaccia grafica. La funzione di lettura e decodifica ? la funzione inversa della funzione di cifratura. Questa fase viene dunque eseguita lato client, ossia sul dispositivo client in cui risiede la funzione di lettura e decodifica. Nella forma preferita dell?invenzione, il dispositivo client ? uno smartphone o tablet e comprende una App mobile in cui risiede la funzione di lettura e decodifica dell?immagine animata Questa funzione viene pertanto eseguita sull?App mobile e, utilizzando una specifica libreria implementa la seguente funzione:
payload=f <-1>(immagine animata),
dove l?immagine animata viene ottenuta inquadrando con la fotocamera dello smartphone l?immagine visualizzata, estraendo un certo numero di fotogrammi F, maggiore di uno, ed applicando un opportuno algoritmo per effettuare la decodifica ed estrarre il payload che contiene il codice OTP.
Il metodo prevede di generare un codice identificativo elaborando il codice OTP criptato tramite la funzione di identificazione ed inviarlo al web server. Anche questa fase viene eseguita lato client, preferibilmente tramite la App mobile del dispositivo client in cui risiede la funzione di identificazione per il calcolo della ?response? da inviare al web server. Lato client, mediante lApp mobile, utilizzando la componente descritta nella fase precedente, ? possibile decodificare l?immagine animata, ottenendo il payload originale inviato dal web server, che contiene il codice OTP. Inoltre, sulla App mobile viene utilizzato un meccanismo per dimostrare che la response ? stata calcolata su uno specifico dispositivo client dell?utente, utilizzando appunto la funzione di identificazione. Nel prosieguo verranno descritte alcune forme realizzative preferite della funzione di identificazione.
Il metodo prevede, successivamente, di classificare il dispositivo client come legittimo quando il codice identificativo elaborato tramite la funzione di riconoscimento corrisponde a quello atteso per il codice OTP corrispondente, ossia quello originariamente generato dalla funzione randomica per la generazione di codici OTP.
Secondo una forma preferita, la fase di generare un codice identificativo elaborando il codice OTP criptato tramite la funzione di identificazione ed inviarlo al web server, comprende la sottofase di inviare il codice identificativo al web server utilizzando un protocollo criptato. Vantaggiosamente, tale procedura incrementa ulteriormente la sicurezza, fornendo una maggiore protezione da eventuali attacchi informatici.
Preferibilmente, la fase di generare un codice identificativo elaborando il codice OTP criptato tramite la funzione di identificazione ed inviarlo al web server, comprende la sottofase di firmare digitalmente il codice OTP criptato tramite la funzione di identificazione per generare il codice identificativo. Vantaggiosamente, tale procedura incrementa ulteriormente la sicurezza, fornendo una maggiore protezione da eventuali attacchi informatici.
Secondo una soluzione preferita alternativa alla precedente, la fase di generare un codice identificativo elaborando il codice OTP criptato tramite la funzione di identificazione ed inviarlo al web server, comprende la sottofase di generare un secondo codice OTP associato al codice OTP criptato mediante la funzione di identificazione per generare il codice identificativo. Vantaggiosamente, tale procedura incrementa ulteriormente la sicurezza, fornendo una maggiore protezione da eventuali attacchi informatici.
Secondo una forma preferita dell?invenzione, il metodo viene impiegato per autorizzare un?operazione sul servizio online richiesta dall?utente autenticato su un dispositivo elettronico dotato di un?interfaccia grafica. In questo contesto, la fase di generare un codice OTP tramite la funzione randomica, comprende la sottofase di associare il codice OTP all?operazione richiesta dall?utente autenticato sul servizio online. Inoltre, la fase di riprodurre la pluralit? di fotogrammi F in sequenza su un?interfaccia grafica in comunicazione con il web server, cos? da visualizzare l?immagine animata 1 codificata, comprende la sottofase di visualizzare l?immagine animata 1 codificata sull?interfaccia grafica del dispositivo elettronico. In aggiunta, il metodo comprende l?ulteriore fase di autorizzare l?operazione richiesta dall?utente autenticato sul servizio online quando il dispositivo client viene classificato come legittimo. Vantaggiosamente, il metodo viene impiegato per autenticare un utente per autorizzare un?operazione richiesta dallo stesso, al fine di aumentare il livello di sicurezza. Infatti, il metodo della presente invenzione pu? essere applicato per identificare l?identit? dell?utente che richiede e autorizza l?operazione con un elevato grado di sicurezza rispetto ai metodi di autenticazione e autorizzazione di operazioni noti. Tale metodo risulta particolarmente efficace e vantaggioso per l?autorizzazione di operazioni finanziarie, ad esempio mediante il servizio online offerto da un istituto bancario. Questa applicazione consente di prevenire e contrastare frodi, ad esempio legate ad attacchi informatici e non solo, come e-mail fraudolente nel caso di phishing, SMS fraudolenti nel caso di smishing e truffe telefoniche nel caso di vishing.
Preferibilmente, il metodo comprende inizialmente una fase in cui l?utente procede alla registrazione e, pi? preferibilmente all?autenticazione al servizio online, opzionalmente dopo aver scaricato e installato l?apposita App fornita sul servizio online quando viene utilizzato uno smartphone o tablet. Tale operazione viene definita di enrolment. In ogni successiva sessione tramite smartphone, l?utente potr? aprire la App per autenticarsi e richiedere un?operazione, ripetendo le altre fasi del metodo che conducono all?autorizzazione dell?operazione richiesta.
Come gi? sottolineato pi? volte, nella forma preferita dell?invenzione il dispositivo client ? uno smartphone. L?operazione richiesta dall?utente richiede di abilitare il dispositivo client per l?esecuzione di successive operazioni finanziarie. Sempre preferibilmente, la fase di autorizzare l?operazione richiesta dall?utente autenticato sul servizio online quando il dispositivo client viene classificato come legittimo, comprende la sottofase di abilitare il dispositivo client per l?esecuzione di successive operazioni, preferibilmente finanziarie. Vantaggiosamente, il dispositivo client risulta abilitato, mediante la procedura appena descritta detta anche di enforcement, per poter autorizzare successive operazioni finanziarie richieste dall?utente, sempre mediante il metodo della presente invenzione a partire dalle fasi che prevedono di generare e leggere l?immagine animata 1 contenente un codice OTP criptato.
Preferibilmente, la fase di abilitare il dispositivo client per l?esecuzione di successive operazioni prevede di fornire al dispositivo client la funzione di identificazione per firmare digitalmente il codice OTP, cos? da generare il codice identificativo per l?autorizzazione di successive operazioni richieste dall?utente. Vantaggiosamente, tale procedura incrementa ulteriormente la sicurezza della procedura, proteggendola ulteriormente da eventuali attacchi informatici. Preferibilmente, viene utilizzata una chiave privata salvata sul dispositivo client in modo protetto, al termine della fase di enrollment e successiva verifica/abilitazione, che viene utilizzata per firmare digitalmente il codice OTP da rimandare al web server. La funzione di identificazione pu? essere formulata come segue:
SignedOTP=sign(PrivKeyDevice, OTP)
Sempre preferibilmente, l?accesso alla chiave privata viene ulteriormente protetto da un sistema gi? presente nel dispositivo client, come ad esempio pin, impronta digitale, riconoscimento facciale.
In alternativa alla firma digitale, in accordo con quanto prima descritto, ? possibile generare un secondo codice OTP temporizzato localmente al dispositivo client. Tale secondo codice OTP ? basato su un seed specifico, salvato in modo protetto sul dispositivo client, che ? verificabile sul back-end, lato server. Tale seed viene fornito al dispositivo client al termine della fase di abilitazione dello stesso. Tale funzione di identificazione pu? essere formulata come segue:
SignedOTP=sign(generateLocalOTP(privateSeed), OTP)
Sempre preferibilmente, l?accesso al seed per la generazione della seconda OTP locale viene ulteriormente protetto da un sistema gi? presente nel dispositivo client, come ad esempio pin, impronta digitale, e riconoscimento facciale.
Ancora preferibilmente, l?OTP firmato, per maggiore sicurezza, pu? essere successivamente cifrato con la chiave pubblica della banca e reinviato al web server del sistema centrale per la verifica e l?approvazione dell?operazione. Tale successiva funzione pu? essere formulata come segue:
Response = encr(PubKeyBanca, SignedOTP)
Giova rilevare che, secondo una forma preferita, ? possibile estendere il contenuto informativo firmato da inviare nella response per aggiungere ulteriori criteri per la valutazione dell?autorizzazione, come ad esempio aggiungendo la geolocalizzazione del dispositivo client.
Inoltre, ? opportuno evidenziare che un protocollo di comunicazione su canale sicuro pu? essere utilizzato in alternativa alle ulteriori operazioni di cifratura appena descritte.
Per quanto concerne la verifica del codice OTP lato server mediante la funzione di riconoscimento, la risposta proveniente dal dispositivo client mobile deve essere prima di tutto decifrata lato server nel seguente modo:
SignedOTP=decr(PrivKeyBanca, Response)
Successivamente, viene verificata la corretta provenienza della response, ad esempio si verifica la firma applicata sulla OTP decodificata, ossia la validit? della firma digitale oppure la validit? della seconda OTP generata localmente al dispositivo client. Infine, si verifica che il codice OTP estratto dalla decodifica dell?immagine animata sia corretta ed anche valida, ossia non scaduta. All?esito positivo di tutti questi controlli, si pu? ritenere approvata l?operazione e viene sbloccata la sessione corrispondente.
Come riferimento a quanto prima descritto, l?enrolment dell?utente prevede l?installazione dell?App mobile sul dispositivo client e nella relativa associazione all?identificativo dell?utente che effettua l?autenticazione. Tuttavia, tale procedura non ? ritenuta sufficiente per abilitare il dispositivo client ad essere utilizzato per operazioni ad alto rischio, specialmente nel caso di operazioni bancarie. Invece, la fase di enforcement ? una fase di verifica che ha lo scopo di dimostrare in modo certo il possesso, da parte dell?utente stesso, del suddetto dispositivo client. Da un punto di vista operativo, al termine della fase di enforcement, un materiale crittografico viene installato e attivato in un?area protetta del dispositivo client. Per installazione in area protetta si intende l?utilizzo di soluzioni tecnologiche note nello stato dell?arte per garantire che il materiale crittografico caricato sul dispositivo client risulti non esportabile, non copiabile e non modificabile da un malintenzionato, anche nel caso in quest?ultimo avesse accesso fisico o telematico al dispositivo client. Secondo una forma preferita prima descritta, ? possibile utilizzare questo materiale crittografico per effettuare operazioni di firma digitale, oppure ? possibile utilizzare un generatore locale di OTP temporizzati, verificabili nel backend sul web server, per dimostrare che un messaggio provenga da uno specifico dispositivo client enrolled e verificato. Inoltre, sono ammissibili diverse modalit? per comprovare il possesso del dispositivo client da parte dell?utente. Ciascuna di esse ? caratterizzata da un processo di riconoscimento che comprenda pi? fattori di autenticazione, ritenuti sufficientemente sicuri. A titolo di esempio si possono considerare il possesso di una carta bancomat e la conoscenza del corrispondente PIN, ed il riconoscimento in presenza nella filiale di una banca con documento di identit?.
Vantaggiosamente, ? possibile che l?utente verifichi e quindi abiliti pi? dispositivi client per autorizzare successive operazioni richieste dall?utente sul servizio online. Tali dispositivi cliente, come ad esempio smartphone, possono essere associati all?account dell?utente effettuando per ciascun dispositivo client la fase di enrollment e verifica/enforcement prima descritti, oppure richiedendo l?estensione transitiva ad un secondo dispositivo client a partire da un primo dispositivo client gi? verificato ed abilitato, ripetendo il metodo dell?invenzione utilizzando il primo dispositivo autorizzato per autorizzare l?abilitazione del secondo dispositivo nella fase di enforcement.
Ancora preferibilmente, l?operazione richiesta dall?utente in una successiva sessione di navigazione sul servizio online comprende un?operazione finanziaria. La fase di autorizzare l?operazione richiesta dall?utente autenticato sul servizio online quando il dispositivo client viene classificato come legittimo, comprende la sottofase di autorizzare l?operazione finanziaria solo se il dispositivo client ? abilitato per l?esecuzione di operazioni finanziarie. Preferibilmente, il processo di approvazione di una certa operazione prevede pertanto che l?operazione venga richiesta in una sessione autenticata dell?utente, ad esempio tramite il servizio online di una banca accessibile via web application, previa autenticazione con username e password. Vantaggiosamente, l?operazione richiesta nella suddetta sessione viene sbloccata ed autorizzata mediante un?azione che, attraverso il metodo dell?invenzione che impiega l?immagine animata, ed il materiale crittografico acquisito durante la fase di enrollment e successiva verifica, coinvolga un dispositivo client personale verificato (ad es., smartphone), associato all?utente che sta richiedendo l?operazione. Tale azione, nell?ambito del metodo dell?invenzione, trova compimento nella lettura dell?immagine animata 1 tramite il dispositivo client abilitato, con conseguente conferma ed autorizzazione dell?operazione richiesta dall?utente.
Preferibilmente, il dispositivo elettronico ? un computer, un tablet, uno smartphone o uno sportello ATM.
Vantaggiosamente, quando viene richiesta una certa operazione per cui ? necessaria una esplicita autorizzazione sicura da parte dell?utente, sul terminale utilizzato per richiedere l?operazione viene mostrata un?immagine animata, altres? identificabile come un logo dinamico, cio? un?immagine dinamica in movimento, alternativa ad es. all?ormai noto QR code, che nasconde un payload, ossia il codice OTP. Il payload nascosto nell?immagine animata non risulta leggibile all?utente, che pertanto non pu? comunicarlo verbalmente a terzi. Inoltre, in virt? della sua dinamicit?, l?immagine animata ha la caratteristica di non poter essere ritrasmesso tramite fotografia o come immagine statica, essendo il codice OTP criptato e distribuito su almeno due fotogrammi. L?immagine animata pu? essere decodificata dal dispositivo dell?utente, nella forma preferita utilizzando un?apposita funzionalit? dell?app mobile della banca, che, ottenuto il payload, pu? utilizzare il materiale crittografico che ha a bordo per calcolare la corrispondente response (o risposta, altres? indicata come codice identificativo) da inviare ai sistemi di back-end del web server della banca, per confermare l?autorizzazione e sbloccare la corrispondente sessione. La verifica della corrispondenza tra payload e response pu? essere effettuata in back-end lato web server. La prova dell?autorizzazione dell?operazione richiesta dall?utente ? dovuta al fatto che solo chi ? in possesso del materiale crittografico associato ad un dispositivo client dell?utente richiedente pu? calcolare correttamente la response corrispondente al payload.
Vantaggiosamente, il metodo che impiega l?immagine animata consente di dimostrare che l?approvazione dell?operazione dispositiva ? stata confermata da un dispositivo in possesso dell?utente mediante operazioni crittografiche che impiegano chiavi di sicurezza ospitate in modo protetto sul dispositivo, oppure mediante sistemi per la generazione locale di OTP temporizzate verificabili nel back-end, lato web server. Tuttavia, il vantaggio pi? rilevante risiede nel poter ridurre le quantit? di sicurezza trasmissibili, grazie all?impiego di quantit? di sicurezza difficili da duplicare o consegnare ad un potenziale frodatore.
Come si ? gi? descritto, l?immagine automatica prevede l?utilizzo di un meccanismo di tipo payload/response per la verifica del ?qualcosa che hai?. Il sistema autenticatore invia all?utente un payload, ossia una stringa contenente una OTP con una certa casualit?, al quale l?utente deve rispondere con una ben precisa e corrispondente response, che egli solo pu? calcolare in virt? della propria conoscenza di un secret, ossia del materiale crittografico presente sul suo dispositivo client.
All?atto della generazione della OTP/payload, lato web server, essa viene associata all?identificativo dell?utente, alla specifica operazione dispositiva ed alla specifica sessione. Vantaggiosamente, si noti che se per un certo utente dovessero essere attive pi? sessioni contemporaneamente, sarebbe sempre possibile individuare a quale sessione ? associata una certa OTP e quindi la relativa response attesa. La funzione di calcolo della response ? biunivoca e coinvolge un meccanismo tale da dimostrare che la response stessa ? stata creata da uno specifico dispositivo appartenente all?utente, ad esempio il materiale crittografico ospitato in un?area protetta della memoria dello smartphone verificato dell?utente. Nel caso pi? semplice la response ? l?OTP ricevuta, quindi letta dall?immagine dinamica, e poi restituita con la firma digitale calcolata con una chiave privata del dispositivo client abilitato/verificato dell?utente. In alternativa, come gi? accennato, ? possibile utilizzare una funzione di calcolo della response pi? elaborata, che aggiunge del contenuto informativo, come ad esempio la geo-localizzazione del dispositivo client. In alternativa, sempre per dimostrare che la response ? stata creata da uno specifico dispositivo appartenente all?utente, ? possibile impiegare un sistema di generazione locale, ossia sul dispositivo client, di OTP temporizzate verificabili lato back-end. Preferibilmente, per maggior sicurezza, l?accesso al materiale crittografico protetto, sia esso una chiave privata o il seed usato per la generazione locale dell?OTP sul dispositivo client dell?utente, deve essere sbloccato previa una ulteriore esplicita autenticazione sullo smartphone, come ad esempio con impronta digitale, riconoscimento facciale o in subordine il PIN del device. Il payload che il sistema autenticatore invia all?utente viene comunicato attraverso la codifica in una immagine animata, dinamica, che nasconde un contenuto informativo. La OTP generata lato server, ad esempio una stringa di 6 caratteri numerici, viene codificata in una serie di fotogrammi, che vengono alternati in modo da costruire una immagine in movimento. Questa immagine in movimento ?, appunto, l?immagine animata, altres? definita come logo dinamico. Il logo dinamico, basato sui fotogrammi creati lato server ed associati alla richiesta di operazione, viene mostrato sul terminale, ossia sul browser che naviga la web application, sul display dell?ATM, sul tablet in uso ai bancari in filiale, o sull?app mobile, usato per richiedere quella specifica operazione. L?utente che ha creato la richiesta dovr? inquadrare il logo dinamico con il suo smartphone verificato. Un software integrato nell?app mobile, ad esempio App della banca, user? dei filtri ottimizzati per ridurre il rumore introdotto dai micromovimenti della mano che impugna lo smartphone e da potenziali condizioni non uniformi nell?illuminazione ed applicher? un algoritmo per decodificare il payload. Giova rilevare che, affinch? l?operazione di decodifica venga completata correttamente, l?algoritmo ha bisogno di elaborare pi? di un fotogramma, nello specifico almeno due fotogrammi, che comprendono il payload di cui si ? parlato sin qui. Il meccanismo di pauload/response ? basato su operazioni crittografiche e grazie all?integrazione con la codifica dell?OTP nel logo dinamico, la sua trasmissione e la sua decodifica con un dispositivo verificato costituisce una significativa innovazione nel settore.
Nel seguito vengono descritti alcuni esempi di implementazione del metodo della presente invenzione. Nello specifico, gli esempi da 1 a 3, rispettivamente illustrati nelle figure da 2 a 4, sono riferiti al processo di enforcement e verifica dello smartphone dell?utente, per essere abilitato all?autorizzazione di successive operazioni richieste dall?utente sempre mediante il metodo dell?invenzione. Mentre, nell?esempio 4, illustrato in figura 5, ? descritto appunto il processo di autorizzazione di una operazione utilizzando uno smartphone abilitato, ad esempio secondo uno degli esempi da 1 a 3.
Prima che un dispositivo client possa essere utilizzato per approvare tramite il meccanismo dell?immagine animata delle operazioni bancarie ad alto valore e rischio, esso deve superare le fasi di enrollment e verifica. Nella fase di enrollment l?utente installa l?app della banca ed effettua l?associazione con il proprio account. La fase di verifica, o enforcement del dispositivo, pu? essere effettuata dall?utente recandosi di persona all?ATM o in una filiale della banca, oppure utilizzando un altro dispositivo gi? verificato dell?utente in questione.
ESEMPIO 1
Questo esempio, mostrato in figura 2, descrive l?applicazione del metodo dell?invenzione per eseguire l?enforcement dello smartphone all?ATM. In figura 2 viene indicato con A lo sportello ATM, con S lo smartphone dell?utente e con B il back-end, ossia il web server della banca. Nello specifico, viene di seguito descritto il processo di verifica di un dispositivo client, cha ha gi? superato la fase di enrollment, effettuato presso un ATM del circuito della banca ed utilizzando la propria carta bancomat.
Il metodo comprende le seguenti fasi:
2.1. Avvio processo di enforcement da parte dell?utente tramite lo sportello ATM A.
2.2. Richiesta immagine animata da visualizzare al back-end B con invio del Codice Fiscale e identificativo ATM.
2.3. Identificazione dell?utente con informazioni ricevute dall?ATM (CF) e recupero dell?identificativo utente (BT) e della sua email.
2.4. Generazione di un ID operazione (OperationID) sul back-end B.
2.5. Generazione OTP sul back end B.
2.6. Generazione sul back-end B dell?immagine animata 1 basata su OTP e OperationID.
2.7. Salvataggio in cache di OperationID, BT, CF, email, ID ATM, timestamp, operationType=ATM, counter=0, status=PENDING.
2.8. Invio all?ATM A dell'immagine animata 1 da visualizzare e OperationID.
2.9. Visualizzazione dell'immagine animata 1 sull?ATM A in attesa che lo smartphone S la inquadri.
2.10. Esito visualizzazione e attesa response (non c?? uno scambio reale di dati, freccia tratteggiata).
2.11. Recupero del DeviceID non certificato associato al BT ed invio notifica push allo smartphone S.
2.12. Avvio operazione di enforcement da parte dell?utente e recupero della quantit? di sicurezza per identificare il device DeviceID/device fingerprint.
2.13. Ripresa tramite fotocamera dello smartphone S dell'immagine animata 1 visualizzata sull?ATM A.
2.14. Decodifica dell'immagine animata 1, ottenendo la OTP e l?OperationID.
2.15. Calcolo della Response cifrando, con la quantit? di sicurezza per identificare il dispositivo client, la OTP estratta dall?immagine animata, concatenata all?OpaerationID.
2.16. Invio della response al back-end B, ossia BT, encr(OTP|OperationID, DeviceID/deviceFingerprint).
2.17. Recupero del DeviceID/device fingerprint a partire dal BT (potrebbero essercene pi? di uno) e decifra della response.
2.18. Verifica dell?OTP e verifica con quanto salvato al punto 2.7.
2.19. Aggiornamento cache immagine animata con status in attesa di conferma.
2.20. Esito processo di verifica immagine animata (ok/ko).
2.21. L?app sullo smartphone S chiede all?utente di inserire il PIN per conferma mediante generazione OTP_PIN.
2.22. L?app invoca un servizio remoto per confermare l?enforcement trasmettendo OTP_PIN, BT, OperationID e deviceFingerprint.
2.23. Verifica OTP_PIN sul back-end B.
2.24. Verifica in cache ed aggiornamento finale.
2.25. Aggiornamento status enforced del dispositivo smartphone S dell?utente.
2.26. Invio email di notifica enforcement all?utente.
2.27. Esito processo di enforcement (ok/ko).
2.28. Esito processo di enforcement (ok/ko/timeout), che rappresenta la risposta alla chiamata del punto 2.10.
ESEMPIO 2
Con riferimento alla figura 3, il processo di verifica effettuato in Filiale ? simile a quello via ATM di cui all?esempio 1, salvo che il riconoscimento pu? essere effettuato di persona dall?utente, ad esempio utilizzando un documento di identit? invece che tramite la carta bancomat, e l?immagine dinamica viene mostrata con l?apposita applicazione (o App) sul tablet utilizzato dal bancario invece che dell?ATM. In figura 3 viene indicato con T il tablet del bancario in filiale, con S lo smartphone dell?utente e con B il back-end, ossia il web server della banca.
Il metodo comprende le seguenti fasi:
3.1. Identificazione utente e avvio processo di enforcement da parte del bancario via tablet T.
3.2. Richiesta immagine animata da visualizzare e invio al back-end B di BT e ID filiale.
3.3. Generazione di un ID operazione (OperationID).
3.4. Generazione OTP sul back-end B.
3.5. Generazione dell?immagine animata sul back-end B basata su OTP e OperationID.
3.6. Salvataggio in cache di OperationID, BT, id filiale, timestamp, operationType=FILIALE, counter=0, status=PENDING.
6b. Individuazione del dispositivo non verificato per quel BT, InvioPush(idOperazione).
3.7. Invio dell?immagine animata da visualizzare e OperationID.
3.8. Visualizzazione dell?immagine animata in attesa che lo smartphone S dell?utente da certificare la inquadri.
3.9. Polling periodico per verifica esito operazione (OperationID, non c?? uno scambio reale di dati, freccia tratteggiata). L?ABC sul tablet T esegue un polling periodico verso il back-end B per l?eventuale refresh dell?immagine animata che avverr? per un massimo di 3 volte, incrementando sulla cache il valore del campo counter, o per uscire dalla fase di visualizzazione con ok/ko (si veda la fase 3.26).
3.10. Avvio operazione di enforcement da parte dell?utente.
3.11. Recupero della quantit? di sicurezza per identificare il dispositivo smartphone S (DeviceID/device fingerprint).
3.12. Ripresa tramite fotocamera dello smartphone S dell?immagine animata visualizzata sul tablet T (sign pad).
3.13. Decodifica dell?immagine animata, ottenendo la OTP e l?OperationID. 3.14. Calcolo della Response cifrando, con la quantit? di sicurezza per identificare lo smartphone S, la OTP estratta dall?immagine animata, concatenata all?OpaerationID.
3.15. Invio al back-end B della response contenente BT, encr(OTP|OperationID, DeviceID/deviceFingerprint).
3.16. Recupero del DeviceID/deviceFingerprint a partire dal BT (potrebbero essercene pi? di uno) e decifra della response lato back-end B.
3.17. Verifica dell?OTP e verifica con quanto salvato al punto 3.6.
3.18. Aggiornamento cache immagine animata (status in attesa di conferma).
3.19. Esito processo di verifica dell?immagine animata (ok/ko).
3.20. L?app chiede all?utente di inserire il PIN sullo smartphone S per conferma, con generazione OTP_PIN.
3.21. L?app invoca un servizio remoto per confermare l?enforcement passando OTP_PIN, BT, OperationID e deviceFingerprint.
3.22. Verifica OTP_PIN.
3.23. Verifica in cache ed aggiornamento finale.
3.24. Aggiornamento status Enforced dello smartphone S.
3.25. Invio email di conferma enforcement all?utente.
3.26. Esito processo di enforcement (ok/ko).
3.27. Output del polling (ok/ko/noOp/timeoutRefresh), che rappresenta la risposta alla chiamata di polling.
In caso di timeout del codice OTP viene fatto un refresh, restituendo anche una nuova immagine animata da visualizzare
ESEMPIO 3
Questo esempio, illustrato in figura 4, descrive un metodo di verifica di un nuovo dispositivo client personale, a partire da un dispositivo client personale gi? verificato, ad esempio, come negli esempi 1 e 2. Il nuovo dispositivo client personale, ossia lo smartphone da verificare S, pu? essere verificato in aggiunta o in sostituzione dello smartphone gi? verificato Sv. Il seguente metodo descrive dunque l?enforcement di un secondo smartphone S mediante un primo smartphone gi? certificato Sv, e comprende le seguenti fasi:
4.1. Login dell?utente sullo smartphone da verificare S.
4.2. Richiesta avvio enforcement transitivo con invio al back-end B di BT, deviceID, deviceFingerprint.
4.3. Generazione di un ID operazione.
4.4. Individuazione del dispositivo smartphone gi? verificato Sv per quel BT, con notifica push, InvioPush(idOperazione).
4.5. Tap su notifica push o apertura app.
4.6. Richiesta immagine animata, altres? detta logo dinamico, getLogoDinamicoSimulation(idOperazione).
4.7. Generazione TechPayload con richiesta di OTPV.
4.8. Richiesta PIN.
4.9. getLogoDinamico(BT, deviceID, deviceFingerprint, idOperazione, OTPV).
4.10. Verifica OTPV.
4.11. Generazione OTP.
4.12. Generazione dell?immagine animata basata su OTP e operationID.
4.13. Salvataggio in cache di OperationID, BT , deviceID_oldDevice, timestamp, operationType=ENF_DEV, counter=0, status=PENDING.
4.14. Invio dell?immagine animata da visualizzare (logoDinamico, operationID).
4.15. Visualizzazione dell?immagine animata sullo smartphone verificato Sv in attesa che lo smartphone da verificare S lo inquadri.
4.16. Polling periodico per verifica esito operazione (operationID). L?App esegue un polling periodico verso il back-end B per l?eventuale refresh dell?immagine animata alla scadenza dell?OTP o per uscire dalla fase di visualizzazione con ok/ko. Da notare che non vi ? scambio reale di dati, linea tratteggiata.
4.17. Recupero della quantit? di sicurezza per identificare lo smartphone (DeviceID/device fingerprint)
4.18. Ripresa tramite fotocamera dello smartphone S del logo dinamico visualizzato sello smartphone Sv gi? enforced.
4.19. Decodifica dell?immagine animata, ottenendo la OTP e l?OperationID 4.20. Calcolo della Response cifrando, con la quantit? di sicurezza per identificare il device, la OTP estratta dal logo, concatenata all?OpaerationID.
4.21. Invio al back-emd B della response contenente BT, encr(OTP|OperationID, DeviceID/deviceFingerprint).
4.22. Recupero del DeviceID/deviceFingerprint a partire dal BT (potrebbero essercene pi? di uno) e decifra della response.
4.23. Verifica dell?OTP e verifica con quanto salvato al punto 4.13.
4.24. Aggiornamento cache immagine animata (in attesa di conferma).
4.25. Esito processo di verifica dell?immagine animata (ok/ko).
4.26. L?app chiede all?utente di inserire il PIN per conferma (generazione OTP_PIN).
4.27. L?app invoca un servizio remoto per confermare l?enforcement passando OTP_PIN, BT, OperationID e deviceFingerprint.
4.28. Verifica OTP_PIN .
4.29. Verifica in cache ed aggiornamento finale.
4.30. Aggiornamento status Enforced del device.
4.31. Invio email di conferma enforcement all?utente.
4.32. Esito processo di enforcement (ok/ko).
4.33. Output del polling (ok/ko/noOp/timeoutRefresh), che rappresenta la risposta alla chiamata di polling. In caso di timeoutRefresh, viene restituito anche il nuovo logo da mostrare
ESEMPIO 4
Quest?ultimo esempio, mostrato in figura 5, descrive un processo di autorizzazione di un?operazione dispositiva ad alto rischio creata su web application. Il metodo di approvazione con smartphone verificato S di una operazione dispositiva creata tramite web browser con la web application W della banca comprende le fasi elencate nel seguito. Occorre precisare che il flusso delle fasi elencate parte dalla risposta RBA gi? ricevuta e conseguente necessit? di autorizzare dispositiva mediante immagine animata/logo dinamico.
5.1. Richiesta autorizzazione dispositiva al back-end B.
5.2. Richiesta logo dinamico da visualizzare con invio BT, transactionID, sessionID.
5.3. Generazione di un operationID dedicato al logo dinamico, distinto dal transactionID.
5.4. Generazione OTP.
5.5. Generazione del logo dinamico basato su OTP e operationID.
5.6. Salvataggio in cache di operationID, BT, transactionID, sessionID, timestamp, operationType=DISP, counter=0, status=PENDING).
5.7. Individuazione deilo smartphone S enforced associato a quel BT, InvioPush(idOperazione.
5.8. Invio del logo dinamico da visualizzare (logoDinamico, operationID). 5.9. Visualizzazione del logo dinamico in attesa che lo smartphone verificato S lo inquadri.
5.10. Polling periodico per verifica esito operazione (operationID). La Web App esegue un polling periodico verso il back-end B per l?eventuale refresh del logo dinamico alla scadenza del codice OTP o per uscire dalla fase di visualizzazione con ok/ko. Da notare che non c?? scambio reale di dati, linea tratteggiata.
5.11. Avvio operazione di autorizzazione da parte del cliente.
5.12. Recupero della quantit? di sicurezza per identificare lo smartphone S (DeviceID/device fingerprint).
5.13. Ripresa tramite fotocamera del logo dinamico (i.e., immagine animata) visualizzato sul browser (web application).
5.14. Decodifica del logo dinamico, ottenendo OTP ed operationID.
5.15. Calcolo della Response cifrando, con la quantit? di sicurezza per identificare il device, la OTP estratta dal logo, conactenata all?operationID.
5.16. Invio al back-emd B della response comprendente BT, encr(OTP|operationID, DeviceID/deviceFingerprint).
5.17. Recupero del DeviceID/deviceFingerprint a partire dal BT(potrebbero essercene pi? di uno) e decifra della response.
5.18. Verifica dell?OTP e verifica con quanto salvato al punto 5.6.
5.19. Aggiornamento cache LogoDinamico (status in attesa di conferma). 5.20. Esito processo di verifica logo dinamico (ok/ko).
5.21. Richiesta summary dell?operazione (operationID).
5.22. Recupero summary operazione da cache (operationID? transactionID?Summary).
5.23. Visualizzazione summary operazione e richiesta conferma.
5.24. Richiesta inserimento PIN, impronta digitale o FaceID e generazione locale di OTP (OTP_PIN).
5.25. Invio conferma e richiesta verifica OTP_PIN.
5.26. Verifica OTP_PIN.
5.27. Esecuzione Operazione Dispositiva ed aggiornamento cache Operazioni Dispositive.
5.28: Aggiornamento cache logo dinamico (status confirmed).
5.29. Conferma esito Operazione.
5.30. Visualizzazione esito operazione.
5.31. Output del polling (ok/ko/noOp/timeoutRefresh), che rappresenta la risposta alla chiamata di polling. In caso di timeoutRefresh, viene restituito anche il nuovo logo dinamico da mostrare.

Claims (10)

RIVENDICAZIONI
1. Immagine animata (1) codificata comprendente:
- una pluralit? di fotogrammi (F) configurati per essere visualizzati in sequenza su un?interfaccia grafica,
caratterizzata dal fatto di comprendere
- un codice OTP criptato, distribuito su almeno due fotogrammi (F) della pluralit? di fotogrammi (F) secondo una funzione di cifratura reversibile.
2. Immagine animata (1) codificata secondo la rivendicazione 1, in cui
- ciascun fotogramma (F) della pluralit? di fotogrammi (F) comprende una pluralit? di stringhe alfanumeriche;
- detto codice OTP criptato, essendo diviso in almeno due parti distribuite su almeno una stringa di ciascuno dei due fotogrammi (F) della pluralit? di fotogrammi (F), secondo la funzione di cifratura.
3. Metodo per generare, visualizzare e leggere un?immagine animata (1) codificata in accordo con le rivendicazioni 1 o 2 mediante un servizio online, comprendente le seguenti fasi:
- fornire una funzione randomica per la generazione di codici OTP, una funzione di cifratura reversibile, ed una funzione di riconoscimento residenti ed eseguibili in un web server associato al servizio online;
- fornire una funzione di lettura e decodifica ed una funzione di identificazione residenti ed eseguibili su di un dispositivo client associato ad un utente autenticato, il dispositivo client essendo dotato di fotocamera ed essendo in comunicazione con il web server;
- generare un codice OTP tramite la funzione randomica, il codice OTP essendo almeno associato ad una sessione di navigazione autenticata del dispositivo client sul web server;
- generare l?immagine animata (1) codificata comprendente una pluralit? di fotogrammi (F) configurati per essere visualizzati in sequenza su un?interfaccia grafica, crittando il codice OTP, suddividendolo in ameno due parti e distribuendole su almeno due fotogrammi (F) della pluralit? di fotogrammi (F) tramite la funzione di cifratura reversibile;
- riprodurre la pluralit? di fotogrammi (F) in sequenza su un?interfaccia grafica in comunicazione con il web server, cos? da visualizzare l?immagine animata (1) codificata;
- leggere e decodificare il codice OTP criptato mediante la funzione di lettura e decodifica quando la fotocamera del dispositivo client inquadra l?immagine animata 1 codificata visualizzata sull?interfaccia grafica;
- generare un codice identificativo elaborando il codice OTP criptato tramite la funzione di identificazione ed inviarlo al web server;
- classificare il dispositivo client come legittimo quando il codice identificativo elaborato tramite la funzione di riconoscimento corrisponde a quello atteso per il codice OTP corrispondente.
4. Metodo secondo la rivendicazione 3, in cui la fase di generare un codice identificativo elaborando il codice OTP criptato tramite la funzione di identificazione ed inviarlo al web server, comprende la sottofase di:
- inviare il codice identificativo al web server utilizzando un protocollo criptato.
5. Metodo secondo la rivendicazione 3 o 4, in cui la fase di generare un codice identificativo elaborando il codice OTP criptato tramite la funzione di identificazione ed inviarlo al web server, comprende la sottofase di:
- firmare digitalmente il codice OTP criptato tramite la funzione di identificazione per generare il codice identificativo.
6. Metodo secondo la rivendicazione 3 o 4, in cui la fase di generare un codice identificativo elaborando il codice OTP criptato tramite la funzione di identificazione ed inviarlo al web server, comprende la sottofase di:
- generare un secondo codice OTP associato al codice OTP criptato mediante la funzione di identificazione per generare il codice identificativo.
7. Metodo secondo una qualsiasi delle rivendicazioni da 3 a 6, impiegato per autorizzare un?operazione sul servizio online richiesta dall?utente autenticato su un dispositivo elettronico dotato di un?interfaccia grafica, in cui
- la fase di generare un codice OTP tramite la funzione randomica, comprende la sottofase di associare il codice OTP all?operazione richiesta dall?utente autenticato sul servizio online;
- la fase di riprodurre la pluralit? di fotogrammi (F) in sequenza su un?interfaccia grafica in comunicazione con il web server, cos? da visualizzare l?immagine animata (1) codificata, comprende la sottofase di visualizzare l?immagine animata (1) codificata sull?interfaccia grafica del dispositivo elettronico;
comprendente l?ulteriore fase di:
- autorizzare l?operazione richiesta dall?utente autenticato sul servizio online quando il dispositivo client viene classificato come legittimo.
8. Metodo secondo la rivendicazione 7, in cui
- il dispositivo client ? uno smartphone;
- l?operazione richiesta dall?utente richiede di abilitare il dispositivo client per l?esecuzione di successive operazioni finanziarie.
- la fase di autorizzare l?operazione richiesta dall?utente autenticato sul servizio online quando il dispositivo client viene classificato come legittimo, comprende la sottofase di abilitare il dispositivo client per l?esecuzione di successive operazioni finanziarie.
9. Metodo secondo la rivendicazione 8, in cui
- l?operazione richiesta dall?utente in una successiva sessione di navigazione sul servizio online comprende un?operazione finanziaria;
- la fase di autorizzare l?operazione richiesta dall?utente autenticato sul servizio online quando il dispositivo client viene classificato come legittimo, comprende la sottofase di autorizzare l?operazione finanziaria solo se il dispositivo client ? abilitato per l?esecuzione di operazioni finanziarie.
10. Metodo secondo una qualsiasi delle rivendicazioni da 7 a 9, in cui
- il dispositivo elettronico ? un computer, un tablet, uno smartphone o uno sportello ATM.
IT102021000017279A 2021-06-30 2021-06-30 Immagine animata codificata e metodo per generare, visualizzare e leggere tale immagine animata codificata, in particolare per l’autorizzazione di operazioni su sevizi online IT202100017279A1 (it)

Priority Applications (4)

Application Number Priority Date Filing Date Title
IT102021000017279A IT202100017279A1 (it) 2021-06-30 2021-06-30 Immagine animata codificata e metodo per generare, visualizzare e leggere tale immagine animata codificata, in particolare per l’autorizzazione di operazioni su sevizi online
IL309812A IL309812A (en) 2021-06-30 2022-06-30 Coded animation image and method of creating, displaying and reading such coded animation image, in particular for the purpose of confirming operations in online services
EP22747117.4A EP4364012A1 (en) 2021-06-30 2022-06-30 An encoded animated image and a method of generating, displaying and reading such encoded animated image, in particular for authorizing operations on online services
PCT/IB2022/056101 WO2023275813A1 (en) 2021-06-30 2022-06-30 An encoded animated image and a method of generating, displaying and reading such encoded animated image, in particular for authorizing operations on online services

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IT102021000017279A IT202100017279A1 (it) 2021-06-30 2021-06-30 Immagine animata codificata e metodo per generare, visualizzare e leggere tale immagine animata codificata, in particolare per l’autorizzazione di operazioni su sevizi online

Publications (1)

Publication Number Publication Date
IT202100017279A1 true IT202100017279A1 (it) 2022-12-30

Family

ID=78049561

Family Applications (1)

Application Number Title Priority Date Filing Date
IT102021000017279A IT202100017279A1 (it) 2021-06-30 2021-06-30 Immagine animata codificata e metodo per generare, visualizzare e leggere tale immagine animata codificata, in particolare per l’autorizzazione di operazioni su sevizi online

Country Status (4)

Country Link
EP (1) EP4364012A1 (it)
IL (1) IL309812A (it)
IT (1) IT202100017279A1 (it)
WO (1) WO2023275813A1 (it)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090249077A1 (en) * 2008-03-31 2009-10-01 International Business Machines Corporation Method and system for authenticating users with a one time password using an image reader
US20190026446A1 (en) * 2017-07-21 2019-01-24 Identitrade Ab Method and system for creating a strong authentication for a user using a portable electronic device

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4693171B2 (ja) * 2006-03-17 2011-06-01 株式会社日立ソリューションズ 認証システム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090249077A1 (en) * 2008-03-31 2009-10-01 International Business Machines Corporation Method and system for authenticating users with a one time password using an image reader
US20190026446A1 (en) * 2017-07-21 2019-01-24 Identitrade Ab Method and system for creating a strong authentication for a user using a portable electronic device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MITXELA.COM: "Human-readable 2D Barcode", 20 March 2020 (2020-03-20), XP055897775, Retrieved from the Internet <URL:https://mitxela.com/projects/hr_code> [retrieved on 20220304] *

Also Published As

Publication number Publication date
WO2023275813A1 (en) 2023-01-05
EP4364012A1 (en) 2024-05-08
IL309812A (en) 2024-02-01

Similar Documents

Publication Publication Date Title
US11722301B2 (en) Blockchain ID connect
US11323272B2 (en) Electronic identification verification methods and systems with storage of certification records to a side chain
US11405380B2 (en) Systems and methods for using imaging to authenticate online users
TWI667585B (zh) 一種基於生物特徵的安全認證方法及裝置
US8079082B2 (en) Verification of software application authenticity
CA2591968C (en) Authentication device and/or method
EP2652688B1 (en) Authenticating transactions using a mobile device identifier
US9218493B2 (en) Key camouflaging using a machine identifier
US9800574B2 (en) Method and apparatus for providing client-side score-based authentication
WO2018145127A1 (en) Electronic identification verification methods and systems with storage of certification records to a side chain
US10045210B2 (en) Method, server and system for authentication of a person
US9055061B2 (en) Process of authentication for an access to a web site
CN108684041A (zh) 登录认证的系统和方法
US20200196143A1 (en) Public key-based service authentication method and system
WO2014141263A1 (en) Asymmetric otp authentication system
US20090220075A1 (en) Multifactor authentication system and methodology
JP2018502410A (ja) 共通識別データ置換システムおよび方法
Hassan et al. A secure multi factor user authentication framework for electronic payment system
US20230006844A1 (en) Dynamic value appended to cookie data for fraud detection and step-up authentication
US20230198751A1 (en) Authentication and validation procedure for improved security in communications systems
KR102284876B1 (ko) 생체 인식 기반의 통합 인증 시스템 및 방법
US20220286289A1 (en) Username-less and password-less one-time identification and authentication code method and system
Kaur et al. A comparative analysis of various multistep login authentication mechanisms
IT202100017279A1 (it) Immagine animata codificata e metodo per generare, visualizzare e leggere tale immagine animata codificata, in particolare per l’autorizzazione di operazioni su sevizi online
KR20170042137A (ko) 인증 서버 및 방법