IT201800006959A1 - Metodo e sistema per effettuare una transazione ad autenticazione forte e link dinamico - Google Patents

Description

Metodo e sistema per effettuare una transazione ad autenticazione forte e link dinamico

La presente invenzione riguarda un metodo e sistema per effettuare una transazione ad autenticazione forte e link dinamico.

Stato della tecnica

L’autenticazione forte è una tipologia di autenticazione a più fattori basata sull’utilizzo congiunto di metodi di autenticazione individuale, solitamente uno statico come la password e uno dinamico, come ad esempio un codice OTP o un dato biometrico.

Tra le soluzioni standard di Strong Authentication

che la Richiedente già offre ci sono le seguenti:

- l’utente riceve un SMS sul proprio cellulare

all’interno del quale è riportato il codice OTP; - l’utente riceve una telefonata al proprio

cellulare da uno specifico numero le cui ultime

quattro cifre corrispondono al codice OTP; - la tradizionale chiavetta con display che

fornisce il codice OTP a seguito di una sua

attivazione premendo l’apposito pulsante; - una App di generazione dei codici OTP compatibile

con tutti i cellulari e smartphone più diffusi

(iPhone, Android, BlackBerry, Windows Phone); e - una chiavetta UBS driverless che consente la generazione dei codici OTP e il loro automatico inserimento sul PC.

Queste soluzioni “tradizionali” differiscono essenzialmente per la modalità con cui viene fornito il codice dinamico OTP per effettuare la specifica operazione di autenticazione.

Rientrano nei Servizi di Strong Authentication anche altri strumenti informatici – fortemente promossi dalla Richiedente – come la Carta Nazionale dei Servizi (CNS) e il Sistema Pubblico di Identità Digitale (SPID), che permettono ai cittadini di accedere e consultare i servizi online offerti dalla Pubblica Amministrazione (INPS, Agenzia delle Entrate, Equitalia, Fascicolo Sanitario, etc.) e ai professionisti (avvocati, architetti, geometri, ingegneri, commercialisti, etc.) di autenticarsi ai punti di accesso telematici.

Recentemente, sono state introdotte nuove procedure di autenticazione dalla nuova direttiva sui servizi di pagamento e gli standard per l’identità digitale adottate dalla pubblica amministrazione e indirizzati dalle normative internazionali (eIDAS) e nazionali (SPID) che prevedono requisiti fra loro compatibili.

La PSD2 – acronimo di Payment Services Directive 2 – segna un altro importante passo in avanti sul percorso per i digital payment nel nostro paese. L’entrata in vigore della nuova direttiva sui servizi di pagamento introduce per esempio la possibilità di effettuare pagamenti o accedere alla rendicontazione bancaria attraverso software realizzati da terze parti autorizzate, aprendo il mercato a emergenti operatori con una forte spinta tecnologica. Allo scopo, la direttiva ha quali obiettivi: a) una maggior tutela del consumatore; b) lo sviluppo di nuove soluzioni di pagamento; c) la regolamentazione di nuovi attori sul mercato; d) l’uniformità delle tariffe applicate alle transazioni; e) l’uniformità di disciplina tra gli Stati Membri; f) la standardizzazione delle infrastrutture.

L’aumento di complessità nella catena del processo dei pagamenti, in termine di player, e l’esigenza di assicurare maggiore sicurezza ai pagatori sono alla base dei presidi che la Direttiva richiede di inserire. L’armonizzazione e il rafforzamento del processo di autenticazione diventa un requisito obbligatorio, che richiede l’accertamento dell’identità attraverso due o più strumenti di autenticazione, rafforzato dall’utilizzo di link dinamici che certifichino la correlazione tra il codice dinamico (OTP) ed i dati della specifica transazione.

Tali obiettivi vengono realizzati con diversi strumenti previsti nella direttiva. In particolare:

1) vengono istituzionalizzati i c.d. Third Parties Providers e previsti nuovi servizi;

2) è disciplinata in maniera analitica la responsabilità dei soggetti;

3) è prevista una standardizzazione delle regole di sicurezza informatica;

4) è uniformata l’applicazione dei costi e delle commissioni;

5) sono maggiormente specificati i casi di esclusione dall’applicazione delle regole.

Come sopra anticipato, la principale novità della PSD2 è l’istituzionalizzazione di nuovi soggetti (Third Parties Providers) che operano come istituti di pagamento o gestori di moneta elettronica. Ogni ASPSP (banca) dovrà rendere disponibili opportune interfacce di comunicazione, esaustivamente documentate sul proprio sito web, di conseguenza i nuovi operatori di terze parti (TPP) dovranno customizzare le proprie applicazioni per il colloquio con lo specifico ASPSP. L’inquadramento di questi nuovi soggetti e dei relativi scenari non è oggetto della presente introduzione.

La direttiva 2015/2366, prevedendo un ampliamento dei soggetti che possono operare quali Payment Service Provider, disciplina anche le responsabilità di tali soggetti. In particolare si ha una segmentazione della responsabilità cercando, in considerazione della pluralità di soggetti coinvolti, di far sì che ognuno risponda del proprio operato contemporaneamente tutelando il consumatore.

In particolare, e facendo riferimento alla Fig. 1, si concedono a vecchi soggetti nuovi servizi.

Nella Fig. 1(a), è illustrato il Payment Initiation Service Provider (PISP), ovvero un soggetto che provvede all’avvio di una operazione di pagamento 10: l’utente 11 dispone il pagamento, il PISP avvia il pagamento 12, la banca 13 dell’utente 11 o del pagatore trasferisce i fondi, la banca 14 del beneficiario riceve i fondi.

Nella Fig. 1(b), è illustrato l’Account Information Service Provider (AISP), in cui nel processo di richiesta di informazioni 20 l’utente 21 accede al suo conto online e richiede in 25 informazioni all’AISP 22, la quale richiede, tramite comunicazioni 26, le informazioni alle banche 23, le consolida e le mette a disposizione del cliente in 24.

In Fig. 1(c), il Card Issuer Service Provider (CISP) effettua il controllo fondi (funds checking) durante una transazione 30, dove l’utente 31 dispone il pagamento presso l’esercente tramite carta emessa da una banca a valere su più conti del pagatore anche presso altre banche; la banca del beneficiario 32 richiede al CISPla disponibilità dei fondi del pagatore, il CISP 33 verifica la disponibilità dei fondi e la banca 34 del pagatore conferma o meno la disponibilità.

Facendo riferimento alla Fig. 2, nel passato il sistema 40 permetteva agli utenti 41 di utilizzare l’app 42 della banca per disporre pagamenti presso la stessa banca 43. Con la PSD2, il sistema 50 permette ai nuovi player 54, se autorizzati, di operare sui conti correnti 53 degli utenti finali 51 che dispongono un pagamento con l’app 52, introducendo con tutta evidenza il rischio di disintermediazione tra le Banche e la propria clientela.

Al tema della responsabilità si ricollega necessariamente quello della sicurezza informatica e, in particolare, le novità introdotte in tema di autenticazione da parte dei soggetti coinvolti per l’accesso ai servizi di pagamento.

La direttiva demanda all’EBA (European Banking Authority) l’emanazione di regole tecniche relativamente agli standard da adottare. L’approccio generale è quello di far riferimento a standard tecnici già esistenti relativamente alla sicurezza per le comunicazioni tra i vari prestatori di servizi (non sarà definito centralmente uno standard unico e condiviso per il colloquio tra i vari soggetti coinvolti, ma si opererà in base agli standard internazionali già riconosciuti – ad es. ISO 27001, 20022, etc.).

D’altra parte, per specifiche materie, come la sicurezza per le transazioni effettuate dagli utenti, è prevista l’adozione di regole aggiuntive e di soluzioni tecnologiche che garantiscano riservatezza, autenticità e integrità dei dati e che facciano riferimento allo standard ISO 27001.

Con particolare riferimento al tema dell’autenticazione degli utenti l’art. 98 della PSD2 prevede l’adozione da parte dell’Autorità Bancaria Europea delle regole tecniche previste dall’art. 97 in tema di autenticazione forte e sicurezza. Tale art. 97 stabilisce che deve essere applicata l’autenticazione forte del cliente (SCA) quando:

a) accede al suo conto di pagamento on line;

b) dispone un’operazione di pagamento elettronico; e c) effettua qualsiasi azione, tramite un canale a distanza, che può comportare un rischio di frode nei pagamenti o altri abusi.

In particolare, e facendo riferimento alla Fig. 3, per i pagamenti elettronici a distanza 60 (bonifici, carte, etc.) l’autenticazione forte deve comprendere elementi (come il codice di autenticazione 61) che colleghino in maniera dinamica 64 (c.d. Dynamic linking) l’operazione a un preciso importo 63 e a un beneficiario

specifico 62.

Il 27 novembre 2017 la Commissione Europea ha adottato

il regolamento delegato inerente la versione finale

degli standard tecnici di EBA (RTS) previsto dall’art.

98 e relativo, appunto, alla disciplina della strong

authentication e la comunicazione sicura con i TPP che

prestano servizi di Payment Initiation e Account

Information:

http://ec.europa.eu/finance/docs/level-2-measures/psd2-

rts-2017-7782_en.pdf

Le regole tecniche di EBA entrano in vigore dopo un

periodo transitorio di 18 mesi, ossia (indicativamente)

a settembre 2019.

Nel dettaglio, e facendo anche riferimento alla Fig.

4, le norme PSD2 sulla strong authentication, e in

particolare le regole tecniche EBA 70, prevedono (art.

4) che l’autenticazione debba essere basata su minimo

due o più fattori:

- codici 71a attinenti la conoscenza personale 71b

del soggetto, categoria knowledge 71;

- codici 72a relativi a un elemento di possesso 72b,

categoria possession 72;

- codici 73a legati a caratteristiche individuali 73b

del singolo utente, categoria inherence 73.

- L’art. 5 delle regole tecniche disciplina poi il

dynamic linking, stabilendo che nel caso di

pagamenti elettronici (bonifici online, carte di

credito, etc.):

- il disponente abbia conoscenza dell’ammontare e del beneficiario;

- il codice di autenticazione generato sia specifico per l’ammontare e il beneficiario come indicato dal disponente all’inizio della transazione; e

- il codice di autenticazione accettato dal PSP corrisponda all’ammontare specifico della transazione di pagamento e al beneficiario indicato dal disponente; ogni modifica all’ammontare o al beneficiario deve comportare la non validità del codice di autenticazione generato.

Per completezza di esposizione si segnala che sono previste deroghe all’applicazione della strong authentication e del dynamic linking nelle seguenti ipotesi:

a) pagamenti fino a 50 Euro, purché non venga superato l’importo cumulativo di Euro 150,00 o siano stati effettuati 5 pagamenti consecutivi dall’ultima autenticazione;

b) pagamenti di trasporti e parcheggi presso terminali non presidiati;

c) pagamenti ricorsivi (mediante creazione di una lista);

d) beneficiari trusted (creazione o conferma di una serie di beneficiari predeterminati per cui il pagatore abbia dato il consenso) oppure una serie di pagamenti dello stesso importo allo stesso beneficiario;

e) applicazione della TRA (Transaction Risk Analysis), per pagamenti fino a 500,00 Euro. In queste ipotesi la banca, mediante sistemi di monitoraggio che tengano conto dei comportamenti dell’utente e della valutazione di una serie di fattori di rischio (abitudini di spesa, luogo in cui si trovano pagatore e beneficiario, evidenze di un eventuale uso abnorme dello strumento di pagamento), può valutare la possibilità di derogare alla regola di strong authentication e dynamic linking.

Infine, preme segnalare la previsione per le comunicazioni “server to server” tra i soggetti coinvolti (ASPSP – la banca utente, PSP – i prestatori di servizi di pagamento e TPP – i nuovi operatori) dell’obbligo di identificazione delle macchine tramite certificati eIDAS.

Con l’entrata in vigore della PSD2 la protezione dei dati sensibili di pagamento e delle informazioni personali degli utenti diventa di primaria importanza. I player dovranno adottare soluzioni tecnologiche che garantiscano riservatezza, autenticità e integrità dei dati e che siano conformi allo standard ISO 27001. Tuttavia a fronte di tale esigenza, i dati classificati come sensibili non sono stati ad oggi definiti. È comunque obbligatorio per le parti comunicanti adottare tecniche crittografiche ampiamente riconosciute per la protezione di dati e soluzioni che consentano il “dynamic linking” della transazione a uno specifico importo e beneficiario.

In particolare, le regole tecniche di EBA prevedono che:

a) non devono essere derivate informazioni relative alla strong authentication (possesso, conoscenza e caratteristiche) dal codice di autenticazione; b) non deve essere possibile generare un nuovo codice di autenticazione conoscendo il codice generato per una precedente transazione; e

c) il codice di autenticazione non può essere falsificato.

Devono essere inoltre adottate misure di sicurezza che garantiscano la confidenzialità, l’autenticità e

l’integrità:

- dell’ammontare e dell’identità del beneficiario per

tutte le fasi della transazione;

- delle informazioni visualizzate dal disponente per

tutte le fasi dell’autenticazione, inclusa la generazione, la trasmissione e l’uso del codice di autenticazione.

L’approccio della PSD2 verso la sicurezza dei servizi di pagamento elettronici si sviluppa su alcune direttrici principali, tra le quali, fondamentale in questa analisi, l’autenticazione forte del cliente (SCA) con l’introduzione del dynamic linking per le operazioni dispositive (e un certo numero di “esenzioni” puntuali). L’adozione dell’autenticazione forte del cliente (SCA) non è però circoscritta alla disposizione di un’operazione di pagamento elettronico ma è estesa (art.

97 della Direttiva) anche all’accesso al conto di pagamento online e, in generale, a qualsiasi azione, tramite un canale a distanza, che comporti un rischio di frode o altri abusi, casi in cui il collegamento dinamico non è strettamente applicabile.

Scopo e oggetto dell’invenzione

È scopo della presente invenzione fornire un procedimento ed un sistema in grado di offrire un’esperienza d’uso semplice e intuitiva garantendo allo stesso tempo il livello di sicurezza richiesto per i pagamenti online ed in generale per qualsiasi operazione informativa e/o dispositiva che richieda un meccanismo di autenticazione legato alla specifica operazione, ad esempio dei semplici accessi all’area utente.

È oggetto della presente invenzione un metodo ed un sistema secondo le allegate rivendicazioni.

Descrizione dettagliata di esempi di realizzazione dell’invenzione

Lista delle figure

L’invenzione verrà ora descritta a titolo illustrativo ma non limitativo, con particolare riferimento ai disegni delle figure allegate, in cui:

- la figura 1 mostra le funzioni dei nuovi Third Party Provider (a), (b) e (c) secondo la nuova direttiva PS2;

- la figura 2 mostra in (a) i rapporti tra utenti e banche secondo la tecnica anteriore, ed in (b) secondo la nuova direttiva PS2;

- la figura 3 mostra l’autenticazione forte per i pagamenti elettronici a distanza, secondo la direttiva PS2;

- la figura 4 mostra tre fattori secondo cui deve essere effettuata l’autenticazione forte secondo la direttiva PS2 e le regole dell’EBA;

- la figura 5 mostra una forma di realizzazione della soluzione secondo la presente descrizione; e

- la figura 6 mostra una fase di una forma di realizzazione del metodo secondo la presente descrizione.

Si specifica qui che elementi di forme di realizzazione differenti possono essere combinati insieme per fornire ulteriori forme di realizzazione senza limiti rispettando il concetto tecnico dell’invenzione, come il tecnico medio del ramo intende senza problemi da quanto descritto.

La presente descrizione inoltre fa riferimento alla tecnica nota per la sua implementazione, riguardo alle caratteristiche di dettaglio non descritte, come ad esempio elementi di minore importanza usualmente utilizzati nella tecnica nota in soluzioni dello stesso tipo.

Quando si introduce un elemento si intende sempre che può essere “almeno uno” o “uno o più”.

Quando si elenca una lista di elementi o di caratteristiche in questa descrizione si intende che il trovato secondo l’invenzione “comprende” oppure alternativamente “è composto di” tali elementi.

Forme di realizzazione

È qui subito da specificare che la soluzione della presente descrizione, sebbene ideata per rispondere a recenti requisiti di legge, può anche essere adatta a requisiti di future leggi o ad altri contesti, a seconda dei casi.

Per semplicità di esposizione, la soluzione secondo la presente descrizione sarà illustrata in termini di trattamento di due dati primari:

- Beneficiario (ad esempio, le ultime 4 cifre dell’IBAN);

- Importo.

Tuttavia, nel caso di più generali operazioni informative, i dati (o i messaggi) scambiati dalle parti possono discostarsi, in semantica e sintassi, dal destinatario e dall’ammontare (di un pagamento) e costituire, ad esempio, una nota informativa sulla tipologia di azione che necessita di essere autenticata. La struttura dati a supporto è stata quindi progettata in maniera flessibile e non vincolata.

Più in generale, parlando di modalità di funzionamento, è preferibile secondo gli Inventori prevedere o un’implementazione unica e autoconsistente per entrambe le classi di servizio oppure la possibilità, per il Cliente, di pilotare in autonomia il funzionamento della soluzione, caso per caso (per esempio con un flag “modalità di funzionamento” o con una specializzazione delle interfacce di integrazione). Di conseguenza, con il termine “transazione” si ricomprende anche un’azione informativa come sopra descritta, ad esempio per l’accesso ad un’area riservata del sistema informativo che mostra o gestisce informazioni sensibili che richiedano un meccanismo di autenticazione come quello secondo la presente descrizione.

Le Figure 5 e 6 illustrano uno schema di funzionamento della soluzione secondo la presente descrizione assumendo che l’utente finale si sia autenticato in maniera sicura, ad esempio con almeno username e password, al proprio sistema di home banking (o altro sistema di transazione) 120,130 e abbia avviato un’operazione di pagamento (o altra operazione informativa. L’autenticazione all’home banking avviene tramite una applicazione 120 sul dispositivo mobile 111 o su un dispositivo fisso, ad esempio attraverso browser.

Il metodo secondo la presente invenzione utilizza una One Time Password o “OTP”, generata attraverso una specifica applicazione 111a sul dispositivo mobile 111 sulla base del tempo (time-based) o di un contatore interno (event-based), ad esempio con un algoritmo conforme allo standard OATH e una lunghezza di almeno 6 cifre decimali. Il metodo si applica quando l’applicazione 111a è differente e separata dall’eventuale applicazione di home banking presente sul dispositivo mobile 111.

Il sistema di home banking è gestito da un server di transazione (o “di servizio” o “della banca”) 130 di un ente bancario o più in generale ente fornitore di servizi 131; con il simbolo di banconota con lucchetto indicato dal riferimento 132 si rappresenta che sui server della banca è presente la logica applicativa per la gestione e securizzazione della transazione.

Il server della banca 130 dialoga con un server di autenticazione 140 attraverso una rete di comunicazione, ad esempio Internet, 150. Il server di autenticazione può inviare notifiche push al dispositivo mobile 111 dell’utente 110.

Tutto ciò premesso, la soluzione secondo la presente descrizione comprende le seguenti fasi:

In una prima fase, l’utente 110 che vuole disporre un pagamento elettronico (o altra operazione informativa), dopo essersi autenticato in maniera sicura sul proprio sistema di home banking 120 (o da dispositivo fisso o da dispositivo mobile 111) ed aver avviato un’operazione di pagamento, si ritroverà una interfaccia grafica in cui saranno riportati i dati richiesti dal dynamic linking (beneficiario, importo della transazione) e potrà avviare la procedura di pagamento.

In una seconda fase, il server della banca 130 riceve i dati dell’operazione di pagamento attraverso le comunicazioni 151,152, e comunica al server di autenticazione 140 la espletanda transazione indicando un identificativo utente ed i dati della transazione, nel caso di un pagamento: beneficiario, importo, attraverso una comunicazione 152,153.

In una terza fase, 3) il server di autenticazione 140:

a. Opzionalmente, crea una sessione di autenticazione associata ai dati trasmessi;

b. Trasmette, tramite notifica push, i dati della transazione (ad esempio beneficiario, importo) ad una App di sicurezza 111a installata sul dispositivo mobile 111 dell’utente 110, la quale è configurata ed atta a generare un codice OTP, ; e

c. opzionalmente, ritorna un riferimento della sessione al server della banca 130;

A tal fine, per la protezione dei dati sensibili di pagamento, il meccanismo delle notifiche push può utilizzare l’infrastruttura di un terzo soggetto, per esempio Apple Push Notification Server per iOS o Google Cloud Messaging per Android (questa componente è omessa nelle figure per semplicità di rappresentazione). Inoltre, la soluzione secondo la presente descrizione può essere progettata per cifrare i dati della transazione dal server di autenticazione 140 all’App 111a; a tale scopo è auspicabile ma non obbligatorio prevedere l’installazione di un certificato digitale utente in fase di attivazione del servizio sull’App 111a a supporto dell’operazione di cifratura e decifratura dei dati scambiati.

In una quarta fase, l’utente 110 riceve una notifica push 170 dal server di autenticazione 140 sul proprio dispositivo mobile 111 e subito dopo:

a. l’App 111a mostra – con un testo personalizzabile oppure attraverso messaggio audio o altro – i dati dell’operazione (ad esempio di pagamento) e invita l’utente 110 a proseguire per la generazione di un codice OTP valido per la transazione in oggetto; b. l’App 111a calcola l’OTP per la specifica transazione (per esempio applicando un algoritmo HMAC), ad esempio sulla base dell’importo del pagamento e dell’IBAN del destinatario del pagamento (ad esempio le ultime 4 cifre) – come su alcune applicazioni (o token) che supportano il c.d. transaction signing;

c. l’utente 110 potrà autorizzare il pagamento inserendo l’OTP generato nella procedura di transazione, ovvero sull’interfaccia grafica 120 del sistema di home banking, che lo trasmette in 151,152, al server della banca 130 insieme eventualmente al riferimento di sessione di cui sopra.

In una quinta fase, una volta ricevuto l’OTP, il server della banca 130 lo comunica al server di autenticazione 140, opzionalmente insieme al riferimento della sessione, ovvero l’identificativo della sessione generato e restituito dallo stesso server 140 come sopra illustrato (in genere, ma non necessariamente, un identificativo numerico o alfanumerico);

In una sesta fase, il server di autenticazione 140 quindi:

a. calcola l’OTP per la specifica sessione/transazione; b. verifica l’OTP così generato con quello ricevuto dal server della banca 130; e

c. trasmette l’esito della verifica al server 130 della banca 131.

Il server di autenticazione 140 può eventualmente anche fare una verifica tra il riferimento di sessione da lui generato e quello ricevuto dall’utente attraverso il server di servizio 130. Simile verifica può essere fatta aggiuntivamente o alternativamente dal server di servizio 130.

A questo punto, la banca può effettuare la transazione e darne notizia all’utente 110 attraverso una comunicazione 152,151.

Ipotizzando un meccanismo “circolare” per la trasmissione, dal server della banca 130 all’App 111a, dei dati richiesti dal dynamic linking (nel caso di pagamento: beneficiario, importo) si è potuto trasporre nella soluzione la stessa esperienza d’uso dei meccanismi classici; per autorizzare la transazione l’utente è comunque ancora tenuto a inserire l’OTP ricevuto nella procedura di transazione, dopo aver ovviamente verificato i dati dell’operazione di transazione.

Di conseguenza, la soluzione secondo la presente descrizione può consentire di configurare sulla stessa app 111a sia utenti associati ai paradigmi della tecnica nota sia utenti associati allo schema di autenticazione della presente descrizione.

Secondo una variante della presente descrizione, viene opzionalmente assegnato all’App 111a un ruolo attivo anche nella trasmissione dell’OTP al server della banca 130 per la sua verifica, automatizzando tutte le fasi del processo.

Per l’automazione della comunicazione tra l’App 111a e il server 130 della banca 131 è necessario che:

a) il server della banca 130 comunichi al server di autenticazione 140 una cosiddetta callback url (ad esempio POST o API REST o altro indirizzo);

b) il server di autenticazione 140 comunichi tale callback url durante la notifica push all’App 111a, di cui sopra;

Ovviamente è preferibile adottare misure di sicurezza che garantiscano la confidenzialità, l’autenticità e l’integrità delle varie comunicazioni.

Sotto queste ipotesi si suppone un impatto di integrazione (automazione) medio per il cliente.

Secondo questo schema, le operazioni dispositive sul browser 120, per essere autorizzate, generano automaticamente una notifica push dal server 140, che l’utente 110 riceve sul suo smartphone 111 e che consente allo stesso di portare a termine l’operazione di transazione (pagamento) collegandosi in 160 alla callback url sul server 130, nel pieno rispetto delle previsioni della PSD2, con un solo semplice “click”.

Restano valide tutte le considerazioni sopra argomentate riguardo alle notifiche push.

In questa variante, riassumendo, il server 130 genera una callback url che passa al server di autenticazione 140 e poi alla App 111a, la quale comunica a tale url l’OTP che ha generato nel frattempo. In tal modo, si è automatizzato il processo circolare di cui sopra, in cui l’utente fornisce solo l’avvio e tutto il resto accade automaticamente tra i dispositivi coinvolti.

Vantaggi dell’invenzione

La soluzione secondo la presente descrizione può prevedere l’utilizzo di tecniche crittografiche e notifiche push per trasmettere i dati della transazione (nel caso di pagamenti: beneficiario, importo) all’App

– e quindi all’utente – in modo tale che:

● sia garantito il collegamento dinamico tra la

specifica transazione e la generazione del codice

di autenticazione;

● il disponente abbia conoscenza (leggasi

consapevolezza) dei dati di transazione (ad esempio dell’ammontare e del beneficiario) lungo tutte le fasi della transazione;

● l’App di generazione del codice non sia “istruita” manualmente dall’utente;

● l’esperienza d’uso resti, quindi, semplice e intuitiva.

Secondo questo schema, le operazioni dispositive e informative, per essere autorizzate, generano automaticamente una notifica push che l’utente riceve sul suo smartphone e che consente allo stesso di generare un codice dinamico OTP nel pieno rispetto delle previsioni della PSD2, e con un solo semplice “click”.

La soluzione della presente descrizione garantisce quindi:

● minimo impatto per quei clienti che hanno già distribuito dei dispositivi di autenticazione forte tradizionali;

● esperienza d’uso immutata per gli utenti finali. Tutto questo è ottenuto nella piena conformità alle regole sopra dettagliate – e previste dalla PSD2 e dai relativi RTS emanati dall’EBA – in quanto il presente processo di strong authentication assicura sia la sicurezza in termini di conoscenza e possesso sia, intrinsecamente nel meccanismo di generazione dei codici OTP quanto nella loro trasmissione e gestione sicura, il collegamento dinamico del codice alle informazioni previste dalla transazione (es. beneficiario e importo di un pagamento), assicurando quindi l’univoca riconducibilità alla specifica operazione.

In particolare, l’applicazione generatrice di OTP su dispositivo mobile presenta tutte le caratteristiche di sicurezza e facilità d’uso: coniuga infatti la sicurezza assoluta della One Time Password con la funzionalità degli smartphone, senza la necessità di gestire nessun componente hardware aggiuntivo.

Lista dei riferimenti e delle abbreviazioni

AgID Agenzia per l’Italia Digitale

ASPSP Account Servicing Payment Service Providers CE Comunità Europea

CNS Carta Nazionale dei Servizi

EBA European Banking Authority

electronic IDentification Authentication and eIDAS

Signature

ISO International Organization for Standardization MITM Man In The Middle

OOB out-of-band

OTP One-Time Password

PSD2 Payments Service Directive 2

PSP Payment Service Providers

RTS Regulatory Technical Standards

SCA Strong Customer Authentication

SMS Short Message Service

SPID Sistema Pubblico di Identità Digitale

TPP Third Party Providers

TRA Transaction Risk Analysis

UE Unione Europea

USB Universal Serial Bus

20 = processo di richiesta di informazioni

21 = utente

22 = AISP

23 = banche

24 = invio delle informazioni dall’AISP all’utente 21 25 = richiesta di informazioni dell’utente 21 all’AISP 22

26 = richiesta dell’AISP 22 alle banche 23

30 = transazione

31 = utente

32 = banca del beneficiario

33 = CISP

34 = banca

40 = sistema prima della direttiva PSD2

41 = utente

42 = app della banca

43 = banca

50 = sistema con la PSD2

51 = utente

52 = app della banca

53 = conti correnti/banca

54 = nuovi player

60 = pagamenti elettronici a distanza

61 = codice di autenticazione

62 = beneficiario

63 = importo

64 = Dynamic linking

110 = utente

111 = dispositivo mobile (smartphone) o app su tale dispositivo

112 = codice OTP

113 = dati transazione, ad esempio ID utente, beneficiario, importo

115 = schermo (dispositivo di visualizzazione)

120 = GUI o browser

130 = server di transazione (server della banca)

131 = banca

132 = il simbolo riproduce la banconota con il lucchetto a rappresentare che sui server della banca è presente la logica applicativa per la gestione e securizzazione della transazione

140 = server di autenticazione

141 = il simbolo riproduce un orologio che rappresenta la logica di calcolo dei codici OTP di tipo time based 150 = rete Internet o altra rete di comunicazione 151 = connessione browser 120 – rete internet 150 152 = connessione server banca 130 – rete internet 150 153 = connessione server di autenticazione 140 – rete internet 150

160 = callback

170 = notifica/comunicazione push

Bibliografia

[1] DIRETTIVA (UE) 2015/2366 DEL PARLAMENTO EUROPEO E DEL CONSIGLIO del 25 novembre 2015 relativa ai servizi di pagamento nel mercato interno, che modifica le direttive 2002/65/CE, 2009/110/CE e 2013/36/UE e il regolamento (UE) n. 1093/2010, e abroga la direttiva 2007/64/CE: http://eurlex.europa.eu/legalcontent/IT/TXT/PDF/?uri=CELEX:32015L2366&from=EN

[2] Regulatory Technical Standards for strong customer authentication and common and secure open standards of communication: http://ec.europa.eu/finance/docs/level-2-measures/psd2-rts-2017-7782_en.pdf

In quel che precede sono state descritte le preferite forme di realizzazione e sono state suggerite delle varianti della presente invenzione, ma è da intendersi che gli esperti del ramo potranno apportare modificazioni e cambiamenti senza con ciò uscire dal relativo ambito di protezione, come definito dalle rivendicazioni allegate.

Claims (9)

1. RIVENDICAZIONI 1) Metodo per effettuare una operazione informativa da parte di un utente (110) su un sistema informatico operativo (130) su una rete di telecomunicazioni (150), ad esempio una transazione, ad autenticazione forte e link dinamico, comprendente l’esecuzione delle seguenti fasi: A. autenticazione di detto utente (110) su un sistema informatico client (120) gestito da un server di servizio (130) di un ente fornitore di servizi (131); B. avvio, da parte di detto utente (110), di detta operazione informativa su detto sistema informatico client (120), l’utente (110) fornendo un insieme di dati di operazione informativa, che includono un codice ID utente, a detto sistema informatico client (120); C. comunicazione (151,152) attraverso detta rete di telecomunicazioni (150), dal sistema informatico client (120) a detto server di servizio (130), di detto insieme di dati di operazione informativa; D. comunicazione (152,153) attraverso detta rete di telecomunicazioni (150), da parte del server di servizio (130) ad un server di autenticazione (140), di detto insieme di dati di operazione informativa; E. trasmissione (152,151) attraverso detta rete di telecomunicazione (150) da parte del server di autenticazione (140), di detto insieme di dati di operazione informativa ad un’App di sicurezza (111a) installata su un dispositivo mobile (111) dell’utente (110) usando una notifica push (170); F. l’App di sicurezza (111a): a. mostra sul dispositivo mobile (111) detto insieme di dati di operazione informativa e invita l’utente (110) a proseguire per autorizzare l’operazione informativa; b. genera un codice OTP sulla base di detto insieme di dati di operazione informativa; G. l’utente (110) fornisce a detto server di servizio (130) detto codice OTP; H. il server di servizio (130) comunica il codice OTP al server di autenticazione (140); I. il server di autenticazione (140): a. genera un codice OTP per la transazione sulla base di detto insieme di dati di operazione informativa; b. verifica il codice OTP così generato con quello ricevuto dal server di servizio (130); c. trasmette (153,152) l’esito della verifica al server di servizio (130).
2. 2) Metodo secondo la rivendicazione 1, in cui detto ente fornitore di servizi (131) è una banca, il server di servizio (130) è un server di home banking, e detto insieme di dati di transazione include un identificativo di un beneficiario e un importo di pagamento.
3. 3) Metodo secondo la rivendicazione 1 o 2, in cui detta rete di telecomunicazione (150) è la rete Internet.
4. 4) Metodo secondo una o più delle rivendicazioni da 1 a 3, in cui nella fase F il codice OTP è calcolato applicando un algoritmo HMAC.
5. 5) Metodo secondo una o più delle rivendicazioni da 1 a 4, in cui: - nella fase D il server di servizio (130) comunica al server di autenticazione (140) una callback url; - nella fase E il server di autenticazione (140) comunica tramite notifica push detta callback url a detta App di sicurezza (111a); e - nella fase G detta App di sicurezza (111a) trasmette (151,152) attraverso detta rete di telecomunicazioni (150) detto codice OTP collegandosi a detta callback url.
6. 6) Metodo secondo la rivendicazione 5, in cui detta callback url è una POST o API REST.
7. 7) Metodo secondo una o più delle rivendicazioni da 1 a 6, in cui detto codice OTP è del tipo time-based o event-based e detto server di autenticazione (140) calcola detto codice OTP attraverso una logica di tipo time-based o event-based.
8. 8) Metodo secondo una o più delle rivendicazioni da 1 a 7, in cui detto server di autenticazione (140), nella fase E: a. crea una sessione di autenticazione associata a detto insieme di dati di operazione informativa; b. invia (153,152) un riferimento della sessione di autenticazione al server (130) della transazione; c. invia (153,151) detto riferimento a detta App di sicurezza (111a); in cui nella fase G l’utente (110) fornisce detto riferimento a detto server di servizio (130), il quale a sua volta nella fase H lo trasmette a detto server di autenticazione (140), il quale verifica che sia lo stesso riferimento da lui generato precedentemente per la sessione di autenticazione.
9. 9) Sistema (111,120,130,140) di disposizione ed esecuzione di operazioni informative su una rete di telecomunicazione (150) da parte di un utente (110), comprendente: - un server di servizio (130) di un ente fornitore di servizi (131), su cui sono installati uno o più programmi configurati per eseguire le fasi D, H del metodo secondo una o più delle rivendicazioni da 1 a 8; - un sistema informatico client con un’interfaccia utente (120) a cui è associata un’applicazione di sicurezza configurata per generare un codice OTP (112) e su cui sono installati uno o più programmi configurati per eseguire le fasi A, B, F del metodo secondo una o più delle rivendicazioni da 1 a 8; - un server di autenticazione (140) su cui sono installati uno o più programmi configurati per eseguire le fasi e ed I del metodo secondo una o più delle rivendicazioni da 1 a 8.