ITTO20110902A1 - Sistema di firma elettronica qualificata, relativo procedimento e apparecchio terminale per la firma elettronica qualificata - Google Patents
Sistema di firma elettronica qualificata, relativo procedimento e apparecchio terminale per la firma elettronica qualificata Download PDFInfo
- Publication number
- ITTO20110902A1 ITTO20110902A1 IT000902A ITTO20110902A ITTO20110902A1 IT TO20110902 A1 ITTO20110902 A1 IT TO20110902A1 IT 000902 A IT000902 A IT 000902A IT TO20110902 A ITTO20110902 A IT TO20110902A IT TO20110902 A1 ITTO20110902 A1 IT TO20110902A1
- Authority
- IT
- Italy
- Prior art keywords
- request
- electronic signature
- recipient
- message
- qualified electronic
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 43
- 230000015654 memory Effects 0.000 claims description 53
- 238000012790 confirmation Methods 0.000 claims description 47
- 238000012545 processing Methods 0.000 claims description 31
- 238000004891 communication Methods 0.000 claims description 22
- 230000008569 process Effects 0.000 claims description 17
- 238000005192 partition Methods 0.000 claims description 6
- 230000006870 function Effects 0.000 claims description 4
- 238000010200 validation analysis Methods 0.000 claims description 3
- 230000000875 corresponding effect Effects 0.000 description 36
- 230000004044 response Effects 0.000 description 31
- 238000012795 verification Methods 0.000 description 17
- 238000004422 calculation algorithm Methods 0.000 description 11
- 230000005540 biological transmission Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 9
- 238000013475 authorization Methods 0.000 description 8
- 238000004364 calculation method Methods 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 238000000605 extraction Methods 0.000 description 4
- 239000000725 suspension Substances 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- WJCNZQLZVWNLKY-UHFFFAOYSA-N thiabendazole Chemical compound S1C=NC(C=2NC3=CC=CC=C3N=2)=C1 WJCNZQLZVWNLKY-UHFFFAOYSA-N 0.000 description 4
- 230000003213 activating effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000002085 persistent effect Effects 0.000 description 3
- ZLSSXLNNHMPGJW-UHFFFAOYSA-N [1-hydroxy-4-[methyl(pentyl)amino]-1-phosphonobutyl]phosphonic acid Chemical compound CCCCCN(C)CCCC(O)(P(O)(O)=O)P(O)(O)=O ZLSSXLNNHMPGJW-UHFFFAOYSA-N 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 239000000969 carrier Substances 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 1
- 101100202428 Neopyropia yezoensis atps gene Proteins 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000003449 preventive effect Effects 0.000 description 1
- 230000001172 regenerating effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—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 involving digital signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
- G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- 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/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/10—Integrity
-
- 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/80—Wireless
-
- 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/61—Time-dependent
Description
“Sistema di firma elettronica qualificata, relativo procedimento e apparecchio terminale per la firma elettronica qualificataâ€
TESTO DELLA DESCRIZIONE
La presente invenzione si riferisce a un sistema per la firma elettronica qualificata o Qualified Electronic Signature (QES) configurato per scambiare dati con primi mezzi di elaborazione del richiedente configurati per permettere a un richiedente di generare richieste richiedenti una firma elettronica qualificata attraverso detto sistema a un destinatario, detto sistema comprendendo secondi mezzi di elaborazione del destinatario configurati per permettere al destinatario della richiesta di apporre propria firma elettronica qualificata, detti secondi mezzi di elaborazione comprendendo un apparecchio terminale telefonico per la firma elettronica qualificata di tipo mobile, atto a scambiare comunicazioni a base testo su reti di telecomunicazioni mobili in base a un identificativo del destinatario abbonato al servizio telefonico mobile compreso in un Subscriber Identity Module cui à ̈ associato.
L‟identità viene comunemente certificata attraverso l‟apposizione di firme autografe su documenti cartacei. Per ragioni di efficienza e praticità à ̈ spesso oggi preferibile operare sulla rete, in particolare la rete Internet, in modo digitale; occorre però identificare in maniera certa l‟utente al fine di permettere l‟accesso a dati sensibili e a servizi sulla rete, disposizioni di pagamento, autorizzazioni e sottoscrizioni in formato elettronico.
Tipicamente l‟accesso ai servizi di rete avviene mediante l‟utilizzo di una coppia di parametri di identificazione digitale, quali user e password, noti all‟utente al quale tali parametri identificativi sono stati assegnati. Tali parametri identificativi sono inoltre presenti in un database del relativo servizio a cui l‟utente accede. Tale soluzione à ̈ vulnerabile in termini di sicurezza per via della relativa facilità con cui tali parametri sono intercettabili sulla rete al fine di sostituirsi all‟utente fisico autorizzato. La presenza inoltre di tali parametri all‟interno di un database li espone ad una copia effettuata attraverso attacco informatico, o attacco hacker, con conseguente furto e utilizzo dell‟identità digitale. Il sempre maggiore utilizzo di servizi in rete moltiplica inoltre per ogni utente i parametri identificativi da ricordare, rappresentando questo un problema di usabilità non trascurabile.
Una forma più avanzata di identificazione digitale à ̈ rappresentata dall‟utilizzo di dispositivi OTP (One Time Password). In questo caso, tipicamente oltre allo user e password, l‟utente à ̈ in possesso di un dispositivo che, a seguito di interrogazione, fornisce un codice da aggiungere come password aggiuntiva e temporanea valida solo per quella operazione e con una scadenza breve. Il dispositivo calcola tale codice attraverso un algoritmo basato sul tempo corrente e su una chiave alfanumerica (seed) salvata sul dispositivo, ma anche in un database centrale, con conseguente rischio di attacco hacker.
L‟utilizzo dei dispositivi OTP soddisfa solo parzialmente un requisito espresso tipicamente dal mondo bancario secondo cui, per una maggiore sicurezza, l‟utente dovrebbe essere autenticato sia attraverso informazioni che questi conosce (quali user e password), sia attraverso un dispositivo che l‟utente possiede. Infatti il dispositivo OTP non corrisponde in realtà a qualcosa di univoco effettivamente posseduto dall‟utente, in quanto l‟informazione (la password temporanea appunto) legata a tale dispositivo à ̈ in realtà una informazione replicabile. I sistemi home banking più diffusi oggi fanno uso di tale tecnologia.
Un‟altra forma di autenticazione dell‟identità digitale nell‟ambito dei pagamenti elettronici à ̈ rappresentata dai codici delle carte di credito. Tali codici sono relativamente facili da copiare da parte di hacker esperti o più semplicemente presso i punti vendita. Per sopperire a questa vulnerabilità , à ̈ previsto in alcuni circuiti di e-commerce di utilizzare una ulteriore password e richiedere la risposta ad ulteriori domande su informazioni aggiuntive dell‟utente, al fine di poter operare una autorizzazione di pagamento. L‟esperienza utente, o user experience, risulta dunque meno snella e anche in questo caso occorre ricordare una nuova password, senza escludere tuttavia i rischi di copia delle informazioni da parte di hacker.
Un‟altra forma di autenticazione dell‟identità digitale à ̈ rappresentata dall‟utilizzo della tecnologia PKI (Public Key Infrastructure) e di firme elettroniche basate su chiavi private non protette. In tali soluzioni la chiave privata à ̈ depositata su un‟area, quale il file system del client, che usualmente à ̈ poco protetta, in particolare non certificata contro l‟estrazione della chiave privata, per cui à ̈ possibile eseguire copie della chiave privata stessa. In letteratura le firme apposte attraverso tale tecnologia sono denominate firme elettroniche e talvolta firme digitali. Anche in questo caso la possibilità di effettuare copia della chiave privata mina la sicurezza della soluzione. La chiave privata infatti viene utilizzata per eseguire l‟algoritmo di firma, e se copiata, pregiudica la sicurezza della soluzione.
Altre forme di autenticazione dell‟identità digitale utilizzano la firma elettronica qualificata, come definita ad esempio nel Codice dell‟amministrazione digitale (D. Leg. 30 dicembre 2010, n. 235) e nella Direttiva Europea 1999/99/CE usualmente attraverso l‟utilizzo di computer client ove tipicamente à ̈ necessario installare dispositivi di tipo token USB o smartcard con relativo lettore. Tali dispositivi sono certificati secondo i livelli di sicurezza nazionali ed internazionali richiesti al fine di garantire l‟impossibilità della copia della chiave privata. Tali dispositivi garantiscono l‟autenticazione dell‟identità digitale ad un elevato grado di sicurezza tramite la realizzazione di una firma elettronica qualificata. L‟algoritmo utilizzato à ̈ di tipo asimmetrico, in modo da garantire un elevato livello di sicurezza. Per contro i token USB e smartcard con relativo lettore devono essere installati su un computer client e necessitano di manutenzione. Inoltre in tal caso l‟autenticazione dell‟identità richiede solitamente l‟utilizzo di un elaboratore di tipo personal computer che, seppure possa essere portatile, limita l‟uso in mobilità .
Sono note anche forme di autenticazione che usano i telefoni mobili o i cosiddetti „smartphone‟ quale mezzo per assicurare l‟identità digitale in mobilità .
Alcune di tali soluzioni si basano su chiavi private o certificati digitali depositati su repository, ossia moduli di immagazzinamento, non certificati contro l‟estrazione della chiave privata.
Alcune soluzioni mobili utilizzano chiavi simmetriche per l‟identificazione, la firma e la criptazione e pertanto hanno un livello di sicurezza ridotto.
Altre soluzioni mobili sono basate sull‟utilizzo di un Security o Secure Element incorporato nel telefono mobile o smartphone che limita l‟utilizzo a particolari modelli, senza garantire l‟utilizzo di repository certificati contro la copia della chiave privata.
In alcune soluzioni, le informazioni presenti nel Secure Element non corrispondono alla chiave privata, ma il numero di carta di credito o l‟equivalente in denaro disponibile per pagamenti da dispositivo mobile.
In alcuni casi il processo di firma elettronica avviene remotamente e tipicamente attraverso dei dispositivi di firma server certificati Hardware Security Module (HSM); in tal caso per attivare il processo di firma occorre inviare un PIN (Personal Identification Number) di attivazione attraverso il cellulare e/o un dispositivo OTP; per quanto sicuro sia il canale di invio del PIN, esso viaggia sulla rete, riducendo la sicurezza della soluzione.
Alcune soluzioni sono basate sull‟utilizzo della SIM come dispositivo certificato per la firma elettronica qualificata, ma in tal caso occorre che il carrier telefonico e le banche trovino un accordo su modalità , protocolli e revenue. Questo perché chi gestisce la SIM di fatto à ̈ l‟owner, usualmente il carrier telefonico.
Tale soluzione risulta difficilmente attuabile poiché per una user experience soddisfacente à ̈ necessario che la banca che offra servizi di pagamento all‟utente generico si sia accordata con il carrier dell‟utente stesso, perché difficilmente questi cambia carrier o viceversa cambia banca. Tale processo non à ̈ di semplice avvio sul mercato per la molteplicità dei soggetti coinvolti, sia lato banche, sia lato carrier.
Alcune soluzioni mobili, non basate sulla firma elettronica qualificata, escludono le banche, limitando i pagamenti nei casi in cui i carrier telefonici possano operare autonomamente, come ad esempio nel caso di acquisto di contenuti digitali, tipicamente andando a scalare dal credito telefonico.
La presente invenzione si prefigge lo scopo di fornire un sistema che permetta al destinatario di una richiesta di pagamento o di una richiesta di sottoscrizione tramite firma o di accesso sicuro a servizi in rete, di operare in maniera sicura attraverso una firma elettronica qualificata tramite il proprio telefono mobile.
Secondo la presente invenzione, tale scopo viene raggiunto grazie ad un sistema di firma elettronica qualificata avente le caratteristiche richiamate in modo specifico nelle rivendicazioni che seguono.
L‟invenzione riguarda anche un corrispondente procedimento di firma elettronica qualificata, nonché un apparato terminale operante in tale sistema secondo l‟invenzione.
In breve, tale invenzione riguarda un sistema di firma elettronica qualificata con certificazione dell‟identità digitale, effettuata su un apparato telefonico per operare la firma elettronica qualificata da parte di un destinatario di una richiesta da firmare digitalmente.
Tale apparato telefonico per operare la firma elettronica qualificata à ̈ un telefono mobile dotato di sistema operativo, in particolare uno smartphone, che prevede di impiegare una memoria certificata e una applicazione, installata su tale telefono mobile o su tale memoria certificata installata, configurata per operare con tale memoria certificata. La memoria certificata à ̈ installata su un supporto rimovibile, che permette di alloggiarla in modo amovibile nel telefono mobile in modo da poter effettuare, in particolare tramite detta applicazione, le operazioni di firma elettronica qualificata. Il telefono mobile à ̈ configurato per essere connesso, preferibilmente via SMS (Short Message Service) ad una rete di comunicazione per la firma elettronica qualificata, o rete dedicata, comprendente una determinata architettura di componenti server.
Sulla rete per la firma elettronica qualificata sono abilitati sia gli utenti richiedenti richieste da firmare in modo elettronico qualificato, ciascuna delle quali può essere implementata da una o più richieste operative in successione, sia gli utenti destinatari di richieste operative da firmare in modo elettronico qualificato. A fronte di una o più richieste operative generate dalla stessa richiesta originaria di firma da parte del richiedente, solo una richiesta operativa raggiungerà , previa modifica, il destinatario per la conferma a mezzo firma elettronica qualificata.
L‟utente destinatario, abilitato all‟uso di tale rete per la firma elettronica qualificata tramite il telefono mobile, può utilizzare tale telefono mobile, eventualmente in associazione con un eventuale elaboratore di supporto che può essere dotato di più ampio display. L‟operazione di identificazione del destinatario avviene comunque attraverso il telefono mobile, in particolare smartphone, che, in virtù delle sue dimensioni tipicamente palmari si presta a operare come strumento di identificazione in mobilità , per processi autorizzativi che hanno inizio su altri dispositivi o sullo stesso smartphone.
L‟utente destinatario à ̈ raggiunto tramite messaggi sulla rete telefonica mobile, preferibilmente, via SMS, da richieste provenienti da tale rete dedicata in base al proprio numero di telefono mobile, associato a un modulo SIM alloggiato nello smartphone.
Secondo un aspetto importante dell‟invenzione, à ̈ previsto che un utente destinatario possa anche procedere in maniera attiva a effettuare richieste che richiedono la propria firma elettronica qualificata, tali richieste essendo dirette a sé stesso; l‟utente destinatario può effettuare tali richieste attraverso il telefono mobile abilitato all‟uso della rete per la firma elettronica qualificata o tramite eventuali elaboratori di supporto. La conferma alle richieste avviene da parte dell‟utente sempre attraverso detto telefono mobile.
L‟utente richiedente può essere abilitato anche come destinatario per l‟uso della rete dedicata, ma può anche essere non abilitato a ciò, operando in questo caso comunque attraverso i servizi messi a disposizione da detta rete come le richieste di pagamenti e di sottoscrizioni indirizzate a destinatari terzi. Le richieste di accesso sono effettuate solo dagli stessi destinatari.
Le richieste che richiedono firma elettronica qualificata sono effettuabili ad esempio attraverso un‟applicazione software sul telefono mobile, in particolare la stessa applicazione che gestisce la firma certificata, oppure ad esempio attraverso il browser di un personal computer.
L‟applicazione software sul telefono mobile à ̈ configurata in generale per gestire la conferma a mezzo firma elettronica qualificata dei messaggi di richiesta operativa che giungono previa modifica al destinatario, ricevuti a seguito dell‟invio di una richiesta effettuata da terzi o dallo stesso utente destinatario.
Le richieste originarie dell‟utente richiedente vengono scomposte in una o più richieste operative inviate in successione, gestite e inoltrate a un server di front-end della rete dedicata, ossia lo stadio iniziale rispetto all‟arrivo di dette richieste, che:
- provvede ad assegnare a ciascuna singola richiesta operativa un identificativo univoco di richiesta ed una marca temporale, o un timestamp indicante almeno data, ora, minuti, secondi, ed
- interroga un proprio database utenti registrati all‟interno del quale sono censiti gli utenti destinatari che sono registrati per l‟uso della rete dedicata in base al loro numero di telefono o di un rispettivo codice identificativo, ossia di registrazione, nel sistema di firma elettronica qualificata per verificarne i diritti rispetto all‟uso della rete dedicata;
- in base all‟utente identificato estrae dal database utenti informazioni dell‟utente quali un indirizzo e-mail e i riferimenti di indirizzo di uno o più server applicativi a cui il server di front-end instrada le richieste operative in base alla tipologia delle richieste stesse.
Il server di front-end à ̈ inoltre configurato per effettuare una verifica sul corretto formato della richiesta operativa e sulla presenza del numero di telefono o identificativo presente nella richiesta operativa stessa. Sul server di front-end e sui server applicativi à ̈ installato un layer software di connessione alla rete dedicata.
Il server applicativo coinvolto in base all‟utente destinatario e alla tipologia della richiesta operativa à ̈ installato presso un ente, ad esempio una banca, a cui il destinatario firmatario della rete dedicata à ̈ registrato. Il server applicativo provvede a validare ulteriormente le richieste in base al formato specifico e cercare in un proprio database utenti la presenza dell‟utente censito con l‟informazione ricevuta quale l‟identificativo all‟interno della rete dedicata o il numero di telefono. Nel caso la verifica abbia esito positivo e nel caso la richiesta operativa necessiti firma da parte del destinatario, il server applicativo invia un messaggio di richiesta a base testo ricavato dalla corrispondente richiesta operativa al telefono mobile dell‟utente destinatario, inviando in particolare un messaggio SMS al numero di telefono censito.
Alla ricezione del messaggio di richiesta a base testo che richiede di essere firmato, l‟applicazione sul telefono mobile provvede a visualizzare automaticamente sul display dello stesso telefono mobile un‟interfaccia grafica affinché l‟utente possa confermare o meno tale richiesta, attraverso l‟apposizione di una firma elettronica qualificata dell‟utente destinatario; tale firma viene apposta su dati specifici ricevuti per mezzo del messaggio a base testo, tipicamente SMS, corrispondente al messaggio di richiesta operativa sopramenzionato.
L‟utente destinatario provvede a inserire un codice PIN di firma per confermare l‟apposizione della firma elettronica qualificata attivando la memoria certificata. Tale codice PIN di firma non viene trasmesso sulla rete dedicata, ma serve solo ad attivare localmente la firma.
Il sistema per la firma elettronica qualificata permette di sottoscrivere digitalmente tramite il telefono mobile dotato di memoria certificata, le seguenti richieste di firma a base testo, ciascuna mediante la gestione del corrispondente messaggio di richiesta operativa ricevuto necessitante firma:
- pagamento
- sottoscrizione di documenti
- accesso a siti web e servizi di rete.
L‟utente destinatario può tramite il telefono mobile applicare una firma elettronica qualificata con la chiave privata.
Il telefono mobile à ̈ altresì in grado di visualizzare notifiche e inviare conferma di ricezione della notifica e preferibilmente à ̈ anche configurato per permettere di effettuare attivamente richieste per le suddette tipologie di operazioni.
E‟ previsto che la firma elettronica qualificata sia applicata sull‟informazione da sottoscrivere, in particolare applicando una cifratura attraverso la chiave privata su una stringa di hashing calcolato sul messaggio a base testo della richiesta ricevuta sul dispositivo mobile o sullo hashing contenuto in esso. Nel caso di pagamenti e accessi, l‟informazione da sottoscrivere à ̈ resa ogni volta differente dalle precedenti poiché associata ad almeno una parte variabile univoca aggiunta dal server di front-end della rete dedicata a cui i richiedenti inviano le richieste; la parte variabile contempla, almeno, un identificativo univoco e l‟indicazione del timestamp, o marca temporale, di effettuazione della richiesta. Il fatto che la firma richiesta debba essere sempre differente evita problemi in caso di copia della stessa da parte di hacker; essa non potrà confermare un‟altra richiesta. Nel caso di sottoscrizione di documenti si sfrutta invece il fatto che in generale i documenti sono diversi di volta in volta quantomeno per un dato utente destinatario e quindi varia anche l‟informazione da sottoscrivere. In caso di sostituzione della firma elettronica qualificata con quella di un altro soggetto, il sistema di verifica della firma, di cui il server applicativo à ̈ dotato, rileverebbe che detta firma à ̈ stata apposta da un soggetto diverso dal corretto destinatario.
Grazie all‟utilizzo della memoria certificata la chiave privata à ̈ protetta contro la copia e l‟estrazione.
L‟algoritmo di cifratura utilizzato per la firma elettronica qualificata à ̈ l‟algoritmo RSA che à ̈ di tipo asimmetrico; la firma elettronica qualificata à ̈ la firma elettronica ritenuta presentare un elevato grado di sicurezza, tale da essere equiparata legalmente alla firma autografa in molte legislazioni nazionali.
L‟identificazione dell‟utente abilitato sulla rete dedicata, in risposta ad un messaggio di richiesta operativa che richiede firma, avviene attraverso l‟invio dal telefono mobile di una firma elettronica qualificata in forma detached, separata dai certificati e, nella maggior parte delle forme implementative, separata dal messaggio in chiaro cui si riferisce.
L‟utente destinatario della rete dedicata può accedere con la propria identità in modo esclusivo alle operazioni effettuabili attraverso l‟applicazione di firma elettronica qualificata sul telefono mobile poiché la firma elettronica qualificata che le attiva à ̈ effettuabile esclusivamente attraverso la memoria certificata associata al telefono mobile, dove risiede la chiave privata protetta di tale utente, unica in tale rete, poiché relativa ad una chiave pubblica unica all‟interno di tale rete e ivi censita insieme al certificato qualificato riportante detta chiave pubblica. Inoltre il codice PIN di attivazione della firma à ̈ noto al solo utente possessore della chiave privata e non à ̈ una informazione replicata all‟interno del sistema. Il codice PIN di attivazione della firma à ̈ interpretabile solo dalla memoria certificata, ma non à ̈ da questa desumibile. Pertanto, alla password o alla molteplicità di password inviate in rete, utilizzate solitamente per l‟accesso ai servizio/enti specifici, si sostituisce l‟utilizzo di un unico codice PIN nello smartphone, non trasmesso sulla rete.
Secondo un ulteriore aspetto, il server applicativo, inviato il messaggio SMS con il messaggio di richiesta a base testo al telefono mobile, resta in attesa entro un tempo configurabile per ricevere la firma elettronica qualificata dal telefono mobile; nel caso tale tempo non sia scaduto, all‟arrivo del messaggio riportante detta firma elettronica qualificata, il server applicativo procede alla verifica della firma. Il server applicativo in base alla tipologia della richiesta firmata effettua operazioni dispositive integrandosi con altri servizi dell‟ente che ospita il server applicativo; ad esempio nel caso dei pagamenti esso à ̈ tipicamente ospitato presso la banca dell‟utente. In questo modo le informazioni sensibili dell‟utente per effettuare il pagamento (ad esempio, il numero di carta di credito) sono tipicamente presenti solo all‟interno della banca, a vantaggio della sicurezza. Più in generale l‟adozione del sistema da parte di un ente/servizio, attraverso l‟utilizzo tipicamente interno del layer del server applicativo, consente all‟ente e ai suoi clienti di certificare l‟identità dell‟utente senza far transitare sulla rete esterna dati sensibili dell‟utente stesso.
Il server applicativo secondo un ulteriore aspetto dell‟invenzione riceve dai servizi dell‟ente il feedback dell‟operazione dispositiva e lo invia al telefono mobile dell‟utente destinatario, nonché aggiorna lo stato dell‟operazione sul server di front-end in base all‟identificativo univoco di ogni richiesta operativa, essendo legate le eventuali diverse richieste operative originate a partire da una stessa richiesta originaria, attraverso la presenza dell‟identificativo della richiesta operativa precedente nella richiesta operativa successiva; l‟esito raggiunge il richiedente attraverso i mezzi elaborativi da questo utilizzati per la richiesta. La rete per la firma digitale attraverso tale server di front-end invia notifica al richiedente via e-mail, se il corrispondente indirizzo à ̈ presente nei dati di richiesta. Se il richiedente à ̈ registrato nella rete dedicata e ha fornito nella richiesta il suo identificativo univoco all‟interno della rete dedicata à ̈ raggiunto da messaggio di notifica sul proprio telefono mobile abilitato sull‟esito dell‟operazione.
Secondo un ulteriore aspetto dell‟invenzione, per ogni richiesta originaria à ̈ inviata all‟utente raggiunto da messaggio di richiesta a base testo, oltre ad un SMS, anche una e-mail di notifica.
Secondo un ulteriore aspetto dell‟invenzione, dal lato del server di frontend, le firme elettroniche qualificate validate vengono imbustate insieme alle informazioni in chiaro, al certificato di firma e al certificato della Autorità di Certificazione che ha emesso il certificato di firma. Nel caso il documento sia una fattura di vendita si realizza perciò attraverso la firma una fattura elettronica. E‟ previsto che i documenti e i messaggi di richiesta sottoscritti vengano conservati digitalmente su server di conservazione della rete dedicata secondo il processo di archiviazione digitale legale del Paese di utilizzo, denominata ad esempio in Italia Conservazione Sostitutiva. Preferibilmente à ̈ associata a tali firme una marca temporale a valore legale. Tali documenti sono consultabili, verificabili e visualizzabili dall‟utente attraverso apposito servizio della rete dedicata.
Ulteriori caratteristiche e vantaggi dell‟invenzione risulteranno dalla descrizione che segue con riferimento ai disegni annessi, forniti a puro titolo di esempio non limitativo, in cui:
- la figura 1 rappresenta un apparato terminale telefonico mobile convenzionale;
- in figura 2 à ̈ rappresentato un apparato terminale telefonico mobile secondo l‟invenzione;
- in figura 3a à ̈ rappresentata schematicamente una prima architettura del sistema per la firma elettronica qualificata secondo l‟invenzione;
- in figura 3b à ̈ rappresentata schematicamente una seconda architettura del sistema per la firma elettronica qualificata secondo l‟invenzione;
- in figura 4 à ̈ rappresentata schematicamente una terza architettura del sistema per la firma elettronica qualificata secondo l‟invenzione;
- in figura 5 à ̈ rappresentata schematicamente una quarta architettura del sistema per la firma elettronica qualificata secondo l‟invenzione.
- in figura 6 à ̈ rappresentata schematicamente una quinta architettura del sistema per la firma elettronica qualificata secondo l‟invenzione;
- in figura 7 à ̈ rappresentata schematicamente una sesta architettura del sistema per la firma elettronica qualificata secondo l‟invenzione.
Viene ora descritto più in dettaglio il sistema per la firma elettronica qualificata secondo l‟invenzione.
In figura 1 à ̈ descritto un apparecchio terminale telefonico mobile, in particolare uno smartphone, 100, ossia un telefono mobile dotato di capacità di operare come terminale utente in una rete telefonica mobile e di un sistema operativo per l‟esecuzione di applicazioni software, dotato di un display 110, una tastiera 115, una scheda di memoria 105 del tipo microSD (micro Secure Digital) alloggiata in un corrispondente lettore dello smartphone 100, un modulo di connessione wireless alla rete telefonica 125 per invio/ricezione SMS, un modulo SIM (Subscriber Identity Module) 120, e un modulo opzionale, utilizzato solo in alcuni esempi implementativi, di connessione wireless 121 di prossimità (come ad esempio NFC, Bluetooth, Wi-Fi) e/o di traffico dati Internet, inclusivo della possibilità di inviare e ricevere e-mail utilizzabili in luogo degli SMS. La disposizione degli elementi che compongono lo smartphone 100 dipende dal modello.
La figura 2 rappresenta uno smartphone 210, analogo allo smartphone 100, configurato per operare la firma nel sistema di firma elettronica qualificata secondo l‟invenzione. In tale smartphone 210 per firma elettronica qualificata, in luogo della scheda di memoria 105 à ̈ prevista una memoria certificata 200. Inoltre lo smartphone 210 per firma elettronica qualificata à ̈ configurata per interagire, in lettura e eventualmente in scrittura, con tale memoria certificata 200 tramite una specifica applicazione per firma elettronica qualificata 220, implementata ad esempio come programma software adatto a essere eseguito in associazione al sistema operativo del telefono mobile, che configura lo smartphone 210 per operare la firma elettronica qualificata in accordo al sistema e procedimento secondo l‟invenzione. Tale applicazione per la firma elettronica qualificata 220 à ̈ preferibilmente multifunzionale, con la possibilità di trattare quindi tutte o parte delle diverse tipologie di messaggi testuali di richiesta pagamento, sottoscrizione documenti, accessi web o servizi in rete. Tale applicazione per la firma elettronica qualificata 220 può essere caricata, come in figura 2, nello smartphone 210 per firma elettronica qualificata, ma à ̈ installabile anche sulla memoria certificata 200 stessa o essere già installata sopra questa, pronta per l‟utilizzo da parte dell‟utente. Lo smartphone 210 per firma elettronica qualificata viene quindi impiegato per la firma elettronica qualificata e conseguente identificazione dell‟utente nell‟ambito del sistema di firma elettronica qualificata secondo l‟invenzione.
Gli smartphone 210 per firma elettronica qualificata corrispondono in generale a smartphone convenzionali come lo smartphone 100, nei quali tuttavia à ̈ provvista una memoria certificata 200, preferibilmente in modo rimovibile in un corrispondente lettore di memorie microSD (Micro Secure Digital), che, oltre a permettere di memorizzare in generale dati comuni, quali ad esempio fotografie o musica, comprende inoltre una partizione certificata secondo i livelli di sicurezza richiesti dalle disposizioni nazionali ed internazionali per la firma elettronica qualificata e per la protezione di una chiave privata 201 memorizzata in tale partizione. Ad esempio per i Paesi dell‟Unione Europea tale livello di certificazione richiesto à ̈ basilarmente il Common Criteria EAL4+ (o superiori) secondo i cosiddetti profili di protezione richiesti.
Tali memorie certificate differiscono dalle carte SIM ad esempio per il fatto che sono indipendenti dal carrier telefonico e hanno forma e dimensioni differenti. Una smart card o una carta SIM memorizzano una ridotta quantità di dati, ha forma e dimensioni differenti dalla memoria certificata, e non à ̈ alloggiabile in un lettore di microSD. Una memoria certificata oltre ad essere alloggiabile in tale lettore e ad avere le dimensioni di una microSD, oltre ad avere una notevole capacità , ad esempio 2GB, à ̈ adatta a contenere una partizione sicura per l‟esecuzione della firma elettronica qualificata e per la conservazione della chiave privata 201. La memoria certificata può quindi adempiere sia alle normali funzioni di una comune scheda microSD per la memorizzazione di notevoli quantità di dati (mappe per navigatori, fotografie o altri dati), sia a funzionalità legate alla firma elettronica qualificata.
Una simile memoria certificata, denominata Mobile Security Card, Ã ̈ stata messa in produzione in tempi recenti dal produttore Giesecke & Devrient.
E‟ importante notare che la memoria certificata 220 à ̈ utilizzata in abbinamento ad un numero di telefono (o un identificativo dell‟abbonato) codificato nel modulo SIM 120. Poiché la SIM 120 e la memoria certificata 220 sono rimovibili, l‟utente può utilizzare tali elementi insieme su altri smartphone 210. Il fatto che si inviino gli SMS verso un dato modulo SIM corrispondente al numero di telefono censito per quell‟utente nel sistema di firma elettronica qualificata, aumenta il livello di sicurezza, già comunque garantita dalla firma elettronica qualificata in quanto la firma elettronica qualificata apposta dall‟utente adoperando la memoria certificata à ̈ in ogni caso verificabile, consentendo di controllare a posteriori se il messaggio SMS sia stato firmato dalla chiave privata 201 abbinata, anche se sconosciuta, al certificato corrispondente all‟utente destinatario e, in aggiunta, a quel numero di telefono. Nel caso l‟utente cambi numero di telefono può aggiornare la propria registrazione nella rete dedicata.
Un altro requisito per la firma elettronica qualificata risiede nell‟utilizzo di un certificato di firma che contiene la chiave pubblica e che sia rilasciato da una Certification Authority (CA), o Autorità di Certificazione o Ente Certificatore che sia un ente governativo o che sia da questo riconosciuto. All‟interno del sistema per la firma elettronica qualificata sono utilizzati certificati digitali di tale tipo per la firma elettronica qualificata. Per l‟ottenimento di un certificato di questo tipo à ̈ necessaria normalmente una fase di riconoscimento de visu dell‟utente a cui rilasciare il certificato da parte di un responsabile (operatore di registrazione) autorizzato dalla Certification Authority (attraverso una Registration Authority), in modo da assicurarne anche legalmente l‟identità .
Sono altresì utilizzabili certificati digitali tecnologicamente equivalenti, ma rilasciati da enti appartenenti alla rete dedicata stessa che non rilascino certificati di firma elettronica qualificata. In quest‟ultimo caso vengono comunque garantiti i medesimi requisiti di processo e tecnologici sia in merito alle certificazioni sui livelli di sicurezza richiesti sul processo, sia sui dispositivi di firma e di protezione della chiave privata 201. In quest‟ultimo caso la firma effettuata non à ̈ propriamente una firma elettronica qualificata, ma una firma qui definita come firma elettronica qualificata assimilata. In base alla difficoltà o opportunità di rilascio del certificato di firma qualificata in senso stretto, l‟utente può optare o meno per un certificato di firma elettronica qualificata assimilata, che comunque dal punto di vista della sicurezza à ̈ in pratica equivalente, quindi soddisfa gli stessi requisiti tecnologici di sicurezza richiesti dalle disposizioni internazionali per la firma elettronica qualificata. Nel caso in cui l‟utente necessiti di una validità opponibile con pieno valore legale deve optare per la firma elettronica qualificata in senso stretto. Nel prosieguo si indica con firma elettronica qualificata in maniera estensiva anche la firma elettronica qualificata assimilata, nel caso l‟utente opti per questa. All‟interno del sistema di firma elettronica qualificata secondo l‟invenzione sono utilizzati certificati rilasciati da diverse Autorità di Certificazione, anche di diversi Paesi. Nella fase di registrazione dell‟utente alla rete dedicata, viene controllato che la chiave pubblica del certificato sia unica all‟interno del sistema di firma elettronica qualificata secondo l‟invenzione. In caso contrario à ̈ necessario per l‟utente avere rilasciato un nuovo certificato, rigenerando una nuova chiave privata 201.
La firma sulla memoria certificata à ̈ attivabile mediante un rispettivo codice PIN che abilita la firma attraverso la chiave privata 201, mentre la chiave pubblica e il certificato qualificato corrispondente possono risiedere anche in un‟area non protetta della memoria certificata. Il codice PIN di firma à ̈ esclusivamente utilizzato sul terminale dall‟utente per eseguire firme elettroniche qualificate o, opzionalmente, criptazioni asimmetriche, senza che tale codice PIN venga inviato sulla rete dedicata o altra rete. L‟operazione di cambiamento del codice PIN à ̈ disponibile in ogni momento all‟utente e coinvolge esclusivamente l‟utente stesso, attraverso l‟utilizzo della applicazione per la firma elettronica qualificata 220 o i driver di base della memoria certificata.
L‟utente registrato nel sistema di firma elettronica qualificata proposto à ̈ dotato di uno smartphone 210 per firma elettronica qualificata con chiave privata 201 protetta presente nella memoria certificata 200, essendo la chiave privata 201 abbinata a un certificato qualificato di firma relativo all‟utente stesso e al relativo certificato di firma della Autorità di Certificazione che ha emesso tale certificato. L‟utente à ̈ registrato nel sistema di firma elettronica qualificata ad esempio indicando in fase di registrazione il proprio numero di telefono od eventuale codice identificativo all‟interno di tale sistema di firma elettronica qualificata, un indirizzo/riferimento di un server applicativo per ogni tipologia di richieste che l‟utente intende gestire (pagamento, sottoscrizione, accesso) ed eventualmente l‟indirizzo e-mail; tali informazioni sono registrate nel server di front-end 310 o in un database connesso a questo. Altra informazione necessaria per la registrazione dell‟utente presso un server applicativo 315 à ̈ il certificato di firma qualificata e il certificato della Certification Authority che lo ha emesso; in ogni server applicativo i cui servizi sono utilizzati dall‟utente, tali certificati vengono registrati in relazione al numero di telefono dell‟utente, eventuale sua e-mail, ed eventuale codice identificativo all‟interno della rete dedicata. Il server di front-end 310 e il server applicativo 315 sono descritti con riferimento agli schemi nelle figure 3a, 3b, 4, 5, 6 e 7 che esemplificano forme realizzative dell‟architettura secondo l‟invenzione.
Diverse forme realizzative del sistema per firma elettronica qualificata secondo l‟invenzione sono rappresentate tramite i flussi esemplificati nei diagrammi schematici delle figure 3a, 3b, 4, 5, 6, 7. In tali diagrammi schematici componenti comuni del sistema di firma elettronica qualificata proposto sono indicati con il medesimo numero di riferimento, ove ricorrano. Rappresentano ad esempio componenti comuni un server di interfaccia 302, il server di frontend 310, il server applicativo 315 del destinatario e un server ente del destinatario 330. Tali server possono risiedere ognuno su un diverso server fisico o possono essere allocati su un numero diverso di server fisici o virtuali. Ad esempio tutte le componenti potrebbero risiedere su un solo server, mentre ciascuno dei server anzidetti potrebbe corrispondere in realtà a un cluster di server. I messaggi scambiati fra i server sulla rete che forma il sistema di firma elettronica qualificata secondo l‟invenzione sono preferibilmente codificati con codifica base64 o formato esadecimale o tramite altra modalità che eviti perdita o alterazione di informazione nella trasmissione.
Le comunicazioni tra i diversi server non sono operate necessariamente tramite una rete di comunicazione wireless; lo stesso dicasi per la comunicazione tra il server di interfaccia 302, ove presente negli esempi implementativi descritti, e il client del richiedente se il dispositivo del richiedente non sia uno smartphone 100 o 210. In caso di trasmissione in cui ad un messaggio ne corrisponde un altro di risposta, pur non limitando a questo tipo di trasmissione le presenti forme realizzative, a seguito di un messaggio inviato ad un server, l‟agente (il client del richiedente o uno dei server) che lo ha inviato rimane in attesa di un messaggio di risposta entro un timeout configurato; la risposta può essere di tipo sincrono (ad es. TCP/IP), ma anche asincrono aggiungendo un identificativo nel messaggio di risposta per farlo correlare all‟agente chiamante al messaggio da questo precedentemente inviato. Le forme realizzative qui descritte si riferiscono preferibilmente, in maniera non limitativa, al caso sincrono per tali messaggi.
I messaggi scambiati da uno smartphone 100 con il server d‟interfaccia 302 e da uno smartphone 210 con il server di front-end 310 sono dunque, a titolo di esempio non limitativo, wireless asincroni di tipo SMS (Short Message System) o, in caso di utilizzo del modulo opzionale di connessione wireless 121, possono essere ad esempio trasmissioni con traffico dati Internet generico. Analogamente, sempre in maniera non limitativa, si considerano asincroni (di tipo SMS) i messaggi scambiati dallo smartphone 210 per firma elettronica qualificata con il server applicativo 315, ove presenti. Ad esempio sono preferibilmente messaggi SMS di tipo asincrono, con riferimento alle figure 3a, 3b, 4, 5, dei messaggi di richiesta a base testo 340, ricevuti da tale smartphone 210, dei messaggi di conferma 345 da esso inviati, per questi ultimi la risposta del server essendo di tipo esito destinatario 360. E‟ altresì possibile considerare ad esempio che i messaggi di conferma 345 siano delle chiamate effettuate attraverso il modulo opzionale di connessione wireless 121 non di prossimità , ad esempio e-mail inviate attraverso il campo e-mail del destinatario nel database degli utenti del server applicativo 315, o che siano delle chiamate traffico dati Internet a web service esposti dal server applicativo 315 con risposta da parte di questo di tipo esito destinatario 360.
Nel caso in cui lo smartphone 210 sia dotato di modulo opzionale di connessione wireless 121, l‟SMS inviato per il messaggio di richiesta a base testo 340 può essere sostituito ad esempio da analogo messaggio di richiesta a base testo 340 trasmesso via Wi-Fi o traffico dati Internet; in questo contesto lo smartphone 210 può essere messo in ascolto ad esempio su una certa porta, attraverso l‟applicazione 220, degli eventuali messaggi di richiesta suddetti. Terminata la ricezione di un messaggio, l‟applicazione 220 invia al server applicativo un messaggio aggiuntivo di ricezione nel caso in cui il modello dei messaggi lo richieda.
Per quanto riguarda i messaggi di richiesta client 351 e conferma client 352 rispettivamente ricevuti e inviati dallo smartphone 210 all‟interno dei flussi mostrati in figura 7 si considera preferibile, ma non obbligatorio, l‟impiego di comunicazione effettuata con trasmissione di prossimità attraverso il modulo opzionale di connessione wireless 121, ad esempio bluetooth o NFC o TCP/IP su Wi-Fi.
Dei messaggi di richiesta operativa 305 inviati per mezzo dell‟applicazione per la firma elettronica qualificata 220 al server di front-end 310 nello schema di figura 5 e 6, e il messaggio di risposta esito richiedente 370 possono essere asincroni (ad esempio SMS) o ad esempio sincroni in modalità wireless nel caso di utilizzo del modulo opzionale di connessione wireless 121.
Vengono nel seguito in generale descritte operazioni di richiesta: tali operazioni di richiesta prevedono che vi siano operazioni di richiesta originaria del richiedente che possono corrispondere a più messaggi di richiesta operativa inviati al server di front-end, alcuni dei quali non giungono sino al dispositivo telefonico mobile per la firma elettronica del destinatario, ma contribuiscono comunque all‟esecuzione dell‟operazione complessiva.
In generale, nel caso le risposte attese dai server non pervengano, Ã ̈ previsto lo scattare di un tempo di timeout che fa considerare la richiesta inevasa.
Il primo esempio implementativo descritto riguarda la tipologia di richiesta di tipo pagamento, ad esempio pagamento tramite bonifico o carta di debito o carta di credito effettuati attraverso la rete del sistema per firma elettronica qualificata, nel caso di un utente richiedente il pagamento distinto dall‟utente destinatario, ove quindi almeno il destinatario sia registrato nel sistema; il destinatario opera attraverso lo smartphone 210 per firma elettronica qualificata secondo l‟invenzione ed à ̈ presente in esso almeno un server applicativo che gestisca la tipologia di messaggi di tipo pagamento per la banca del destinatario, anch‟essa interfacciata al sistema per la firma elettronica qualificata proposto, attraverso tale server applicativo. Per una richiesta originaria di pagamento consegue una sola richiesta operativa 305.
Per il primo esempio implementativo ci si riferisce allo schema delle figure 3a e 3b.
In figura 3a à ̈ indicato con 300 un richiedente distinto dal destinatario; il richiedente à ̈ il beneficiario della transazione, o opera per conto del beneficiario, per effettuare richieste di pagamento. Il richiedente 300 può essere ad esempio un merchant o una società di servizi o pubblica amministrazione che richieda un pagamento a un utente della rete dedicata destinatario 365, che à ̈ per l‟appunto un utente del sistema per firma elettronica qualificata proposto.
In figura 3a il richiedente distinto dal destinatario 300 à ̈ connesso per mezzo di un elaboratore 303, ossia ad esempio un personal computer. In figura à ̈ indicato tale elaboratore 303, che può essere tuttavia anche uno smartphone convenzionale 100, per il caso ad esempio di commercio ambulante, al fine di effettuare richieste di pagamento attraverso un server di interfaccia 302, come ad esempio un sito web. Tale server di interfaccia 302 à ̈ configurato per effettuare conseguentemente una richiesta originaria che si traduce in una sola richiesta operativa 305, specificamente una richiesta di pagamento, in modalità automatica o interattiva verso il server di front-end 310.
Tale server di interfaccia 302 può essere ad esempio un sito web da cui effettuare richieste attraverso un browser. La comunicazione tra il server di interfaccia 302 e l‟elaboratore 303 o lo smartphone convenzionale 100 può essere implementata secondo una delle modalità note ai tecnici del settore, purché essa consenta comunque di far tradurre al server d‟interfaccia 302 le richieste originarie del richiedente 300 in richieste operative 305 che possano essere trattate dal server di front-end 310, secondo quanto meglio dettagliato nel seguito, e di interpretare dei messaggi esito richiedente 370 ricevuti dal server di interfaccia 302 stesso provenienti dal server di front-end 310 in informazioni intellegibili per il richiedente 300.
In figura 3b à ̈ indicato invece un caso in cui anche il richiedente distinto dal destinatario 300 à ̈ connesso per mezzo di un rispettivo smartphone 210 per firma elettronica qualificata, che à ̈ configurato per effettuare direttamente richieste operative 305 al server di front-end 310 tramite l‟uso da parte del richiedente 300 di un‟applicazione software che coincide con l‟applicazione per la firma elettronica qualificata 220, ed interpretare attraverso questa i messaggi esito richiedente 370 ricevuti in informazioni intellegibili per l‟utente richiedente 300. La connessione dello smartphone 210 per firma elettronica qualificata al server di front-end 310 à ̈ effettuabile tramite l‟invio di SMS sulla rete telefonica mobile o invio dati sulla rete in altra modalità wireless. Stante la sopra esposta differenza tra schema 3a e 3b, ci si riferirà allo schema 3a per semplicità ove non specificato, senza perdere di generalità .
La richiesta operativa 305 inviata al server di front-end 310 comprende dati di richiesta che comprendono
- l‟indicazione della tipologia di richiesta di tipo pagamento,
- un dato identificativo del destinatario della rete dedicata 365, che può comprende il numero di telefono mobile del destinatario della rete dedicata 365 o un suo identificativo all‟interno del sistema per firma elettronica qualificata associato a tale numero di telefono mobile,
- dati della transazione economica; tali dati della transazione economica comprendono uno o più dati quali l‟ammontare totale in denaro della somma richiesta per il pagamento, la relativa divisa, la modalità di pagamento scelta (ad esempio bonifico o carta di credito o debito), il relativo riferimento per il pagamento, ad esempio rispettivamente il codice IBAN del richiedente o il suo numero di carta di credito o debito, il nome del titolare beneficiario, causale, località , un eventuale indirizzo e-mail del richiedente e/o del beneficiario, un eventuale identificativo univoco nella rete dedicata o numero di telefono del richiedente o beneficiario se appartenente alla rete dedicata; possono essere in generale presenti altre informazioni accessorie in base alla modalità di pagamento.
Il server di front-end 310 provvede ad assegnare alla singola richiesta operativa 305 un identificativo di richiesta univoco ed un timestamp, effettua una verifica sul corretto formato della richiesta e sulla presenza nel proprio database utenti registrati dell‟utente destinatario della richiesta 365, in base al dato identificativo, ossia il suo numero di telefono o identificativo nel sistema di firma elettronica qualificata, presente nella richiesta operativa 305 stessa. In caso tale dato identificativo non venga riscontrato nel database utenti registrati del server 310 o vi siano incompletezza o errori nei dati ricevuti nel messaggio di richiesta operativa 305, viene inviato da tale server di front-end 310 al server di interfaccia 302 un messaggio di esito del richiedente 370 completo dell‟identificativo univoco della richiesta e del timestamp precedentemente assegnati; il messaggio di esito del richiedente 370 in questo caso, segnala un errore. Nel caso invece la verifica abbia esito positivo, il server di front-end 310 interroga tale database utenti registrati, ricercando per l‟utente della rete dedicata destinatario 365 un riferimento di indirizzo del server applicativo 315 (ad esempio il suo URL, Uniform Resource Locator, per una connessione via Internet) a cui il server di front-end 310 deve instradare la richiesta operativa 305 in base alla tipologia della richiesta in essa indicata, in questo caso una richiesta di pagamento.
Altri server applicativi connessi con il server di front-end 310, per altre tipologie di richiesta, rappresentate in figura 3a per semplicità dal solo server applicativo n-esimo 325, non sono interessati dal processo.
In caso di assenza del riferimento di indirizzo, viene inviato dal server di front-end 310 il messaggio di esito del richiedente 370 completo di identificativo univoco e timestamp precedentemente assegnati, riportante l‟errore occorso.
In caso invece di presenza del riferimento di indirizzo il server di frontend 310 provvede a inviare una richiesta inoltrata 308, al server applicativo destinatario 315, ossia un messaggio completo delle informazioni della richiesta operativa 305, cui aggiunge l‟identificativo univoco e timestamp precedentemente assegnati dal server di front-end 310 alla corrispondente richiesta operativa 305.
Il server applicativo 315 valida ulteriormente la richiesta 308 in base al formato specifico e cercando in un proprio database degli utenti registrati la presenza di un utente associato all‟informazione ricevuta quale dato identificativo, ossia l‟identificativo all‟interno del sistema di firma elettronica qualificata o il numero di telefono. Ai server applicativi à ̈ inoltre disponibile come informazione il certificato di firma elettronica qualificata associato ad ogni utente e il relativo certificato della certification authority che lo ha emesso. Il server applicativo 315 controlla lo stato di validità dell‟utente (come più avanti descritto) e del certificato in base a quanto presente nella ultima lista di revoca e sospensione disponibile di detta Certification Authority scaricata dal server applicativo 315 periodicamente e quindi già disponibile. Tale controllo à ̈ poi ripetuto, una volta ricevuta la firma elettronica qualificata, basandosi su una lista di revoca e sospensione aggiornate successivamente al momento di effettuazione della firma, poiché sino al momento della firma potrebbe esservi un aggiornamento di tali liste presso la Certification Authority rispetto a quelle utilizzate nel primo controllo. Il controllo preventivo consente di evitare l‟invio di messaggi a utenti non validi in base alle liste disponibili.
Nel caso che uno di tali controlli sia negativo viene inviato un messaggio di inoltro esito 366 con responso negativo dal server applicativo 315 al server di front-end 310 in risposta alla precedente richiesta inoltrata 308, al che il server di front-end 310 invia un corrispondente messaggio esito richiedente 370 negativo, in risposta al precedente messaggio richiesta operativa 305. Il messaggio esito richiedente 370 raggiunge il richiedente 300 attraverso un programma client sull‟elaboratore 303 o 100 che elabora l‟esito ricevuto dal server d‟interfaccia 302. Il messaggio esito richiedente 370 à ̈ completo dell‟identificativo della richiesta e del timestamp assegnati dal server di frontend 310 alla richiesta operativa 305 e conseguentemente presenti nel messaggio di richiesta inoltrata 308 precedente.
In caso invece di esito positivo dei predetti controlli, il server applicativo 315 invia un messaggio di richiesta a base testo 340 lato destinatario allo smartphone 210, inviando un messaggio SMS al numero di telefono memorizzato nel database utenti del server applicativo 315 per il dato utente destinatario 365 stesso. Il server applicativo 315 utilizza per l‟invio, come identificativo del mittente, il numero di telefono del destinatario 365.
Il messaggio di richiesta a base testo 340 inviato al destinatario concatena in un messaggio di testo SMS le informazioni della richiesta inoltrata 308, includendo l‟identificativo della tipologia di richiesta relativa al pagamento. Per concatenazione si intende la disposizione in sequenza di informazioni in forma testuale, eventualmente divise da separatori o secondo uno schema condiviso, in modo che il ricevente possa, se richiesto, riconoscere ed interpretare le diverse informazioni nel messaggio stesso. Il messaggio di richiesta a base testo 340 à ̈ formulato in modo da rappresentare una chiara autorizzazione di pagamento in linguaggio naturale, come ad esempio “Autorizzo il pagamento di 321,00 euro a IBAN IT96R0123454321000000012345 di Giochi e Giocattoli S.r.l, Milano via Salici 32, ore 16:43:54, identificativo richiesta 23456789â€
Il messaggio di richiesta a base testo 340 viene archiviato su apposite aree persistenti, ad esempio una memoria di massa, connesse al server applicativo 315; all‟interno di un database di detto server 315 viene mantenuto il riferimento di indirizzo al file corrispondente al messaggio di richiesta a base testo 340 archiviato, insieme all‟identificativo della richiesta che à ̈ stato assegnato dal server di front-end 310 alla richiesta operativa 305 e quindi presente nella richiesta inoltrata 308 e nel messaggio di richiesta a base testo 340; tali dati vengono mantenuti correlati all‟identificativo della richiesta operativa 305 insieme al timestamp della richiesta stessa e insieme all‟utente destinatario 365, nonché agli altri dati del messaggio di richiesta a base testo 340. Il timestamp consente di valutare se sia scaduto il timeout configurato a sistema per considerare scadute le richieste.
Il server applicativo 315 invia l‟SMS del messaggio di richiesta a base testo 340 al numero di telefono ricavato dal database connesso al server stesso. In generale lo smartphone 210 per firma elettronica qualificata del destinatario 365, attraverso l‟applicazione per la firma elettronica qualificata 220 di cui à ̈ dotato, effettua un parsing degli SMS ricevuti. L‟applicazione per la firma elettronica qualificata 220 distingue in base al formato e al numero di telefono del mittente se il generico SMS à ̈ stato inviato attraverso il protocollo della rete del sistema per firma elettronica qualificata o no.
Nel caso in cui lo smartphone 210 risulti spento o comunque l‟applicazione per la firma elettronica qualificata 220 disattivata, il messaggio di richiesta a base testo 340 viene ricevuto e trattato alla riaccensione o al riavvio dell‟applicazione per la firma elettronica qualificata 220; nel caso sia scaduto il timeout della richiesta, il messaggio di richiesta a base testo 340 à ̈ considerato rifiutato dal server applicativo 315. Nel caso giungano altri messaggi di richiesta a base testo 340, il loro trattamento da parte dell‟applicazione per la firma elettronica qualificata 220 à ̈ sospeso sino a che non sia evaso il primo messaggio di richiesta a base testo 340. Successivamente vengono trattati i susseguenti messaggi di richiesta a base testo 340 in ordine di arrivo.
Quando l‟applicazione per la firma elettronica qualificata 220 riconosce che il messaggio SMS ricevuto à ̈ un messaggio di richiesta a base testo 340, l‟applicazione per la firma elettronica qualificata 220 à ̈ configurata per far apparire automaticamente sul display 110 dello smartphone 210 un‟interfaccia grafica configurata secondo la tipologia di richiesta indicata nel messaggio 340, ossia richiesta di pagamento, sottoscrizione di documenti, oppure accesso a servizi in rete.
L‟applicazione per la firma elettronica qualificata 220 nel caso di richiesta di pagamento provvede a calcolare lo hashing del messaggio di richiesta a base testo 340 e a mostrarlo sull‟interfaccia 110 insieme al messaggio di richiesta a base testo 340. Poiché lo hashing può contenere caratteri non visualizzabili, esso viene codificato con notazione esadecimale o in base64 o altra formattazione sul display 110. E‟ inoltre configurabile il sistema in modo che il messaggio di richiesta a base testo 340 includa già tale hashing, precalcolato dal server applicativo 315. In tal caso l‟applicazione multifunzionale 220 calcola ugualmente lo hashing del messaggio 340 e lo confronta con quello ricevuto, visualizzando l‟esito sul display 110. La lunghezza dei messaggi di richiesta a base testo 340 à ̈ breve e pertanto il calcolo dello hashing sullo smartphone 210 non presenta problemi di performance.
Lo hashing del messaggio 340, poiché questo à ̈ visualizzato in chiaro sullo smartphone 210 e l‟algoritmo di calcolo dello hashing à ̈ di tipo standard, può essere anche ricalcolato dall‟utente autonomamente per verifica aggiuntiva, ad esempio attraverso software di calcolo disponibili sulla rete Internet.
La scelta dell‟algoritmo di hashing à ̈ dettata dalla normativa di riferimento del Paese di utilizzo nel caso di aderenza stretta alla firma elettronica di tipo qualificato. Ad esempio in Italia viene utilizzato l‟algoritmo SHA-256. In base alla legislazione del Paese di utilizzo, lo hashing, prima della firma, deve eventualmente essere arricchito di eventuali informazioni aggiuntive richieste dalla normativa, come ad esempio il padding pkcs#1 versione 2.1. La stringa di hashing à ̈ visualizzabile sul display 110; nel caso in cui lo hashing viene calcolato anche dal server applicativo 315, esso deve essere presente nel messaggio di richiesta a base testo 340 per poter far eseguire il controllo all‟applicazione 220.
L‟utente destinatario può non confermare la richiesta. In caso non desideri confermare, può operare, in particolare tramite selezione di un‟opzione dall‟applicazione per la firma elettronica qualificata 220 in modo da poter processare altri eventuali messaggi di richiesta a base testo 340; la selezione di tale opzione fa sì che non venga inviato il messaggio di conferma 345 entro il timeout configurato, sicché la rete di firma elettronica qualificata ritiene la richiesta operativa 305 negata. E‟ altresì possibile configurare il sistema in modo che il diniego sia esplicito, inviando dallo smartphone 210 attraverso l‟applicazione per la firma elettronica qualificata 220 un messaggio di conferma 345 negativa non firmata riportante l‟identificativo richiesta della precedente richiesta operativa 305 assegnato dal server di front-end 310 e quindi presente nel messaggio di richiesta inoltrata 308. Il messaggio di conferma 345 negativa à ̈ interpretato dal server applicativo che risponde con un messaggio di esito destinatario 360 di avvenuta ricezione; il server applicativo 315 invia il contenuto del messaggio di conferma 345 al server di front-end 310 attraverso un messaggio di inoltro esito 366 in risposta alla precedente richiesta inoltrata 308, sempre riportante l‟identificativo della corrispondente richiesta operativa 305. Il server di front-end 310 interpreta il messaggio e lo invia al richiedente come messaggio di esito richiedente 370 negativo in risposta alla relativa richiesta operativa 305 iniziale.
Nel caso invece l‟utente della rete dedicata destinatario 365 desideri confermare, ossia firmare digitalmente la richiesta, questi adopera la tastiera 115 per introdurre il codice PIN richiesto dall‟applicazione per la firma elettronica qualificata 220 ed effettua la firma elettronica qualificata sulla stringa di hashing anzidetta. In particolare, viene applicata la cifratura RSA attraverso la chiave privata 201 sullo hashing (decodificato ad esempio dal formato base64 o esadecimale, utile in questo contesto solo alla visualizzazione o trasmissione) attivata attraverso la digitazione del codice PIN di firma richiesto dall‟applicazione per la firma elettronica qualificata 220.
Nel caso in cui il codice PIN di firma digitato sia errato l‟applicazione per la firma elettronica qualificata 220 a causa dell‟errore ricevuto dalla memoria certificata 200 fa visualizzare l‟errore sul display 110. Secondo una schema di per sé noto, qualora si ecceda un numero di tentativi erronei permessi, configurato sulla memoria certificata 200 e eventualmente anche sull‟applicazione per la firma elettronica qualificata 220, occorre intervenire a sbloccare la memoria certificata 200 attraverso il codice PUK (Personal Unblocking Code) utilizzando l‟applicazione per la firma elettronica qualificata 220 o i driver di base della memoria certificata 200 stessa, eventualmente per reimpostare il codice PIN stesso. Una volta sbloccata la memoria certificata 200, à ̈ possibile continuare l‟operazione inserendo il codice PIN corretto. Nel caso nel frattempo scatti il tempo di timeout configurato, la richiesta operativa 305 à ̈ considerata negata. Alternativamente, anche in situazione di codice PIN bloccato, à ̈ possibile esplicitare e gestire il diniego esplicito come sopra descritto, poiché esso non necessita di firma.
Nel caso di digitazione del codice PIN corretto, a bordo della memoria certificata 200 dello smartphone 210 viene eseguita la firma elettronica qualificata sullo hashing a partire dal messaggio di richiesta a base testo 340, attraverso l‟applicazione per la firma elettronica qualificata 220 che opera sulla memoria certificata 200. Tale codice PIN di firma non viene trasmesso sulla rete dedicata né al di fuori di essa, ma serve solo ad attivare localmente la firma sullo smartphone 210.
Al fine di permettere la verifica e l‟identificazione, una firma elettronica qualificata detached viene inviata dallo smartphone 210 al server applicativo 315 attraverso un messaggio di conferma 345, che contiene l‟identificativo univoco della richiesta operativa 305 associata. Tale firma elettronica qualificata detached, detta anche firma elettronica separata, à ̈ priva sia del messaggio in chiaro a cui lo hashing si riferisce, sia del certificato di firma associato, sia del certificato della Certification Authority che ha emesso il certificato di firma. In caso contrario, essa à ̈ detta firma elettronica qualificata attached. Il messaggio di conferma 345 raggiunge il server applicativo 315. Esso effettua una prima verifica di formattazione del messaggio di conferma 345 e, in caso positivo, verifica la firma contenuta nel messaggio di conferma 345 in base al messaggio di richiesta a base testo 340, privato dell‟eventuale hashing di controllo in esso presente come testo, che così à ̈ da considerarsi il documento in chiaro rispetto alla firma, precedentemente archiviato in base all‟identificativo univoco associato dal server di front-end 310 alla richiesta operativa 305; la verifica della firma à ̈ condotta anche in base al certificato di firma associato al numero di telefono nel database, e al certificato della Certification Authority che ha emesso il certificato di firma.
In generale, il server applicativo 315 effettua uno scarico periodico dai server che recano le liste di revoca e sospensione o CRL-CSL (Certificate Revocation List – Certificate Suspension List) dalle Certification Authority che rilasciano i certificati di firma presenti nel suo rispettivo database, registrando per ogni scarico di tali liste il timestamp corrispondente all‟effettuazione della richiesta di scarico. Nel caso un certificato del sistema per la firma elettronica qualificata risulti revocato o sospeso o scaduto, lo stato dell‟utente corrispondente à ̈ considerato non abilitato dal server applicativo 315 ad eventuali richieste a lui indirizzate con timestamp successivo od uguale al momento in cui il certificato non risulta più valido; tale momento à ̈ presente nella CRL-CSL corrispondente. Analogamente nel caso in cui un utente della rete dedicata dia disdetta all‟adesione al sistema per la firma elettronica qualificata. L‟informazione sulla disabilitazione dell‟utente, sulla validità del certificato, sul timestamp a partire da cui il certificato sia invalido,il timestamp di scarico della lista CRL-CSL con cui la verifica di validità à ̈ stata condotta, à ̈ disponibile nel database del server applicativo 315.
Specificamente, il server applicativo 315 confronta il timestamp di scarico della lista CRL-CSL della Certification Authority relativa all‟utente identificato da quel numero di telefono, con il timestamp a cui viene ricevuta la firma. Nel caso il timestamp di richiesta di download sia successivo temporalmente al timestamp della ricezione della firma, il server applicativo 315, si basa sull‟ultima lista CRL-CSL per validare il certificato, altrimenti il server applicativo 315 promuove uno scarico anticipato rispetto alla cadenza fissa di download di detta lista CRL-CSL aggiornata e registra un nuovo timestamp corrispondente al momento di effettuazione della richiesta di download, che à ̈ valido per considerare lo stato del certificato perché successivo alla ricezione della firma. Nel caso risulti che il certificato legato nel database al numero di telefono sia stato revocato o sospeso o scaduto al tempo coincidente con il timestamp corrispondente alla ricezione della firma, oppure nel caso fallisca l‟operazione di verifica della firma contenuta nel messaggio di conferma 345, allora il messaggio 345 non viene validato. Ciò può essere dovuto ad esempio alla effettuazione della firma dopo la revoca del certificato oppure se la firma viene effettuata da un utente diverso rispetto a quello designato poiché ha utilizzato una chiave privata 201 diversa da quella abbinata alla chiave pubblica relativa al certificato con cui l‟utente à ̈ censito nel server applicativo 315. Se l‟SMS di messaggio richiesta a base testo 340 ha raggiunto la corretta SIM 120 legata al numero di telefono in base a quanto registrato nel database, e soprattutto se la firma à ̈ stata eseguita con la corretta chiave privata 201 relativa al corretto certificato censito nel database, à ̈ possibile validare la firma effettuata.
Il server applicativo 315 inoltre confronta il tempo corrente con il timestamp della richiesta operativa 305 assegnato dal server di front-end 310 e presente tra i metadati relativi al messaggio di richiesta a base testo 340 disponibile al server applicativo 315; se la differenza à ̈ superiore al timeout configurato nel sistema per la particolare tipologia di richiesta, la verifica fallisce.
In caso di fallimento della verifica del messaggio di conferma 345 a livello del server applicativo 315, viene inviato allo smartphone 210 un messaggio di esito destinatario 360 d‟errore in risposta al precedente messaggio di conferma 345, e successivamente un inoltro esito 366 d‟errore al server di front-end in risposta al precedente messaggio di richiesta inoltrata 308; il server di front-end 310 invia un esito richiedente 370 d‟errore, in risposta all‟iniziale richiesta operativa 305; il messaggio esito richiedente 370 à ̈ completo del timestamp e dell‟identificativo univoco assegnato alla richiesta operativa 305 (e quindi ai messaggi originati per la gestione di questa richiesta) dal server di front-end 310. Il messaggio esito richiedente 370 viene interpretato e reso disponibile al richiedente distinto dal destinatario 300 attraverso interpretazione del server di interfaccia 302 e successiva visualizzazione o aggiornamento sull‟elaboratore 303 o sullo smartphone 100.
Il server applicativo 315 nel caso di richieste di pagamento à ̈ tipicamente installato presso la banca dell‟utente destinatario 365; in caso di successo dell‟operazione di verifica della firma e delle altre verifiche, il server applicativo 315 invia una richiesta di disposizione 350 di pagamento al server della banca 330 connesso alla rete del sistema di firma elettronica qualificata proposto; la richiesta di disposizione 350 contiene i dati presenti nel messaggio di richiesta a base testo 340 ed ulteriori dati eventualmente richiesti dalla banca e disponibili presso il server applicativo 315 o il suo database.
Il server della banca 330 comprende, attraverso un proprio database interno alla rete della banca, un‟associazione tra i propri clienti e gli utenti del sistema di firma elettronica qualificata, in base agli identificativi e numeri di telefono con i quali sono registrati nel sistema di firma elettronica qualificata. Il server della banca 330 può in base a tale associazione attribuire il corretto conto corrente o ad esempio la corretta carta di credito/debito corrispondente all‟utente 365 da cui effettuare il pagamento.
In caso di mancata disponibilità di denaro sul conto corrispondente, o in caso di dati non congruenti o non correttamente formattati, viene emesso un messaggio di feedback della disposizione 355 in risposta alla richiesta di disposizione 350, di tenore negativo, trasmesso al server applicativo 315, che provvede a inviare un rispettivo messaggio esito destinatario d‟errore 360 allo smartphone 210 in risposta al precedente messaggio di conferma 345. Il server applicativo 315 invia inoltre un messaggio di inoltro esito 366 d‟errore specifico al server di front-end 310, in risposta al precedente messaggio di richiesta inoltrata 308. Il server di front-end 310 invia quindi un esito richiedente 370 d‟errore al richiedente, in risposta al precedente messaggio di richiesta operativa 305 iniziale. Il messaggio esito richiedente 370 viene gestito come negli altri casi succitati.
In caso di convalida da parte del server dell‟ente del destinatario 330, esso invia un messaggio di feedback disposizione 355 positivo al server applicativo 315, in risposta al precedente messaggio richiesta di disposizione 350. Il server applicativo 315 invia a sua volta un messaggio esito destinatario 360 positivo allo smartphone 210 in risposta al messaggio conferma 345 precedentemente ricevuto, e un messaggio di inoltro esito 366 positivo al server di front-end 310, in risposta al precedente messaggio di richiesta inoltrata 308. Il server di front-end 310 invia un messaggio positivo di esito richiedente 370 al richiedente 300, in risposta all‟iniziale richiesta operativa 305. Il messaggio esito richiedente 370 viene gestito come nei casi precedenti, facendo giungere al richiedente distinto dal destinatario 300 il messaggio di esito positivo.
Nel caso in cui il messaggio di richiesta operativa 305 sia completo di indirizzo e-mail del richiedente 300 e/o del beneficiario, il server di front-end 310 invia agli/allo indirizzi/o e-mail corrispondenti/e l‟e-mail che traduce in linguaggio naturale il messaggio esito richiedente 370, sia in caso di esito positivo della transazione, sia in caso negativo.
In caso positivo, se nella richiesta operativa 305 era presente l‟identificativo nella rete dedicata o il numero di telefono del richiedente o beneficiario appartenente alla rete dedicata, il server di front-end 310 gestisce una notifica a tale utente che giunge sullo smartphone 210 del richiedente/beneficiario.
Per ogni SMS di messaggio di richiesta a base testo 340 à ̈ inviata dal server applicativo 315 all‟utente 365 anche una e-mail con il medesimo contenuto, se tale informazione à ̈ stata fornita in fase di registrazione utente alla rete dedicata
Il server di front-end 310 aggiorna lo stato dell‟operazione avviata con l‟iniziale richiesta operativa 305, in base al messaggio inoltro esito 366 ricevuto, in modo da poter controllare anche successivamente l‟esito della transazione, identificata con l‟identificativo univoco assegnato dal server di front-end 310 stesso che lo connota come sopra riportato anche con un timestamp.
Attraverso il metodo di pagamento configurato mediante il sistema di firma della richiesta di pagamento descritto, non viene inviato in rete il numero di carta di credito dell‟utente appartenente al rete dedicata 365, né altre sue informazioni sensibili come ad esempio la password. Le informazioni sensibili dell‟utente della rete dedicata 365 sono gestite internamente alla banca, a vantaggio della sicurezza.
Nel caso in cui la banca del beneficiario impostata dal richiedente 300 distinto dal destinatario sia la stessa del destinatario 365, può essere previsto di evitare nella richiesta operativa 305 di assegnare come parametro il riferimento di conto beneficiario (ad esempio, numero di carta di credito del beneficiario) legato alla modalità di pagamento impostata dal richiedente, aumentando la confidenzialità per il beneficiario, e assegnando invece l‟identificativo o numero di telefono interno al sistema di firma dedicato secondo l‟invenzione anche relativamente al beneficiario nella richiesta operativa 305. Infatti in tal caso la banca ha i dati di entrambi, destinatario e beneficiario.
Qualora l‟ente che utilizza il server applicativo 315 sia un ente di intermediazione che dispone di dati sensibili sia del beneficiario impostato dal richiedente 300, sia del destinatario 365 con le rispettive informazioni relative ad esempio alle rispettive carte di credito o altre modalità di pagamento, e li rende disponibili come database accessibile al server 315, à ̈ possibile evitare di inserire nella richiesta operativa 305 dati sensibili (ad esempio il numero di carta di credito) anche relativamente al beneficiario. Più in generale nel caso in cui le banche dei destinatari 365 dotate di server applicativi 315, attraverso rete sicura e dedicata richiedano i dati sensibili per il pagamento alle banche dei beneficiari attraverso i server applicativi 315 di queste ultime, si raggiunge una maggiore confidenzialità per i beneficiari, poiché anche in questo caso le richieste operative 305 sono prive di dati sensibili dei beneficiari stessi.
Il server applicativo 315 può inviare ad un server di conservazione elettronica i messaggi di richiesta a base testo 340 di pagamento, con la firma, il certificato di firma e della Certification Authority che ha emesso il certificato di firma. Tipicamente à ̈ associata a tali firme almeno una marca temporale a valore legale. Tali elementi sono consultabili dall‟utente firmatario 365 e dal richiedente, se appartenente al sistema di firma proposto. E‟ inoltre disponibile la funzionalità di verifica della firma.
Dunque, in definitiva nei sistemi delle figure 3a e 3b sopra descritti, la richiesta operativa 305 viene validata e elaborata dal server di front-end 310 del sistema per la firma elettronica qualificata, diventando una richiesta inoltrata 308 verso il server applicativo 315, che provvede a sua volta a inoltrare tale richiesta come comunicazione a base testo 340 verso il terminale utente, ossia lo smartphone 210, dove viene apposta la firma elettronica qualificata in base a tale comunicazione a base testo inviata sulla rete telefonica mobile o parti di essa.
In figura 4 à ̈ mostrato uno schema di una variante relativa a un‟ulteriore procedura di pagamento nella quale con 400 à ̈ indicato un utente destinatario della richiesta di pagamento 305 che corrisponde anche al richiedente che effettua detta richiesta operativa 305.
Lo schema di figura 4 rispetto a quanto mostrato in figura 3a presenta la differenza sopra riportata.
Infatti l‟utente 400 impiega lo smartphone 210 per gestire la conferma attraverso firma elettronica qualificata, e cioà ̈ il trattamento del messaggio di richiesta a base testo 340, del messaggio di conferma 345 e di esito destinatario 360. Tuttavia, in questo caso à ̈ lo stesso destinatario 400 che effettua anche la richiesta operativa 305, preferibilmente attraverso un altro elaboratore, cioà ̈ l‟elaboratore di supporto 303, come mostrato in figura 4, ma tale elaborante può anche in una variante essere lo smartphone convenzionale 100, che sia distinto dallo smartphone 210 utilizzato nel sistema per la firma elettronica qualificata proposto. Naturalmente lo stesso smartphone 210 che gestisce la conferma può essere utilizzato anche come smartphone convenzionale 100 per effettuare anche la richiesta impiegando funzionalità che non utilizzano la memoria certificata 200 e l‟applicazione per la firma elettronica qualificata 220, per l‟effettuazione della sola richiesta. Ad esempio l‟utente 400 potrebbe utilizzare il browser di detto smartphone 210 per effettuare le richieste operative 305.
L‟utente 400 del sistema di firma elettronica qualificata può corrispondere ad esempio a un utente che opera su un sito di e-commerce associato a tale sistema di firma elettronica qualificata; il sito corrisponde al server di interfaccia 302, e l‟utente ad esempio può intendere effettuare attivamente un acquisto o inviare denaro attraverso la rete del sistema di firma elettronica qualificata attraverso il server di interfaccia 302 a favore di un beneficiario. L‟utente 400 introduce, ad esempio, al posto dei dati della propria carta di credito, il proprio numero di telefono o identificativo interno alla rete dedicata.
Analogamente a quanto descritto con riferimento all‟architettura di figura 3a, le informazioni digitate ad esempio tramite un elaboratore 303, ad esempio un elaboratore laptop connesso al sito di e-commerce o altro server di interfaccia 302, ad esempio per il pagamento di parcheggi o multe, comporta comunque una conferma via smartphone della rete dedicata 210 e l‟utente tramite lo smartphone 210 può autorizzare il pagamento via firma elettronica qualificata come nel caso della forma realizzativa descritta con riferimento alla figura 3a.
In figura 5 à ̈ rappresentata un‟ulteriore forma realizzativa, dove, rispetto a figura 4, l‟interfaccia utente dell‟utente 400 che à ̈ richiedente e destinatario allo stesso tempo à ̈ rappresentata unicamente dallo smartphone 210 sia per effettuare la richiesta, sia per gestire la conferma. In tal caso, a differenza della forma realizzativa relativa alla figura 4, l‟applicazione per la firma elettronica qualificata 220 invia direttamente la richiesta operativa 305 al server di frontend 310, senza interfacciarsi con il server di interfaccia 302.
In tale architettura, il messaggio esito destinatario 360 restituisce solo la notifica di avvenuta ricezione della conferma 345 all‟applicazione per la firma elettronica qualificata 220, poiché lo smartphone 210 per firma elettronica qualificata riceve comunque l‟esito finale della richiesta esito richiedente 370.
In figura 6 à ̈ rappresentata una ulteriore architettura implementante il sistema secondo l‟invenzione, dove l‟utente 400, richiedente il pagamento e destinatario della richiesta di pagamento, utilizza solamente lo smartphone 210 per firma elettronica qualificata per connettersi direttamente al server di frontend 310; in questa forma realizzativa à ̈ previsto inoltre che la richiesta operativa 305 associata a una data transazione sia già completa di firma elettronica qualificata, che viene eseguita prima della fase di richiesta stessa. Lo smartphone 210 attraverso l‟applicativo 220 propone un identificativo univoco della transazione (cioà ̈ della richiesta operativa 305 e successivi messaggi) e un timestamp, che sono poi sottoposti a validazione da parte del server di frontend 310 anziché essere generati da questo come nelle precedenti forme realizzative. Preferibilmente, tale identificativo univoco della transazione à ̈ la stringa di hashing calcolata sulla concatenazione dell‟informazione da firmare, di informazioni pseudo casuali ad opera della applicazione per la firma elettronica qualificata 220; nel caso il server di front-end 310 rifiuti la richiesta operativa 305 con un messaggio esito richiedente 370 riportante ad esempio come motivo l‟errato identificativo, perché esso à ̈ già presente a sistema o riportante ad esempio come motivo l‟errato timestamp della richiesta poiché esso differisce da quello rilevato - al momento della ricezione della richiesta operativa 305 - dal server di front-end oltre una tolleranza configurata, l‟applicazione per la firma elettronica qualificata 220 riesegue automaticamente il calcolo della richiesta operativa 305, dell‟identificativo e del timestamp che cambiano e sono utilizzati in una ulteriore richiesta operativa 305 . Poiché il messaggio da sottoscrivere risulta differente, data la modifica delle informazioni suindicate, deve essere rieseguita anche la firma, richiedendo il codice PIN di firma all‟utente.
In caso di richiesta operativa 305 validata dal server di front-end 310, il server applicativo 315 riceve la firma elettronica qualificata all‟interno della richiesta inoltrata 308, poiché la firma viene ricevuta dal server di front-end 310 all‟interno della richiesta operativa 305 e il server di front-end 310 la inoltra al server applicativo 315.
Il server applicativo 315 non scambia in questo caso messaggi con lo smartphone 210, a differenza di quanto accade ad esempio nel primo esempio implementativo descritto con riferimento a figura 3a, poiché la firma à ̈ già nota al server applicativo stesso. Il server applicativo 315 effettua tuttavia la verifica della firma come descritto con riferimento a figura 3a.
Come nei casi precedenti, poi, al termine delle operazioni il feedback di disposizione 355 viene inoltrato dal server che effettua il pagamento al server applicativo 315 che invia l‟inoltro esito 366 al server di front-end 310 che invia l‟esito richiedente 370 che giunge allo smartphone 210 e viene così mostrato l‟esito dell‟operazione. In questa forma realizzativa la firma viene inviata con anche le informazioni in chiaro nel messaggio di richiesta operativa 305.
Un‟ulteriore forma di implementazione riguarda la tipologia di richiesta di sottoscrizione di documenti, che non sono necessariamente autorizzazioni a pagamenti ma documenti di ogni tipo, attraverso firma elettronica qualificata, dove il richiedente la firma à ̈ differente dal sottoscrittore o destinatario, come negli schemi delle figure 3a e 3b. Anche in questo caso la differenza del processo relativo alla figura 3b rispetto alla 3a consiste nel fatto che nel caso 3b la comunicazione tra smartphone 210 e server di front-end 310 avviene senza intermediazione del server d‟interfaccia 302. Stante questa differenza, nel proseguo ci riferiremo per semplicità allo schema 3a, senza perdere di generalità . Il richiedente distinto dal destinatario 300 può tramite tali architetture effettuare richieste per far sottoscrivere un documento al destinatario 365. Una richiesta originaria di questa tipologia si compone normalmente di due richieste operative 305 in successione: la prima di upload del documento, la seconda di sottoscrizione vera e propria, anche se ad esempio la forma implementativa basata su figura 6, più avanti discussa, presenta una sola richiesta operativa 305 che contempla sia informazioni di upload, sia di sottoscrizione. Ritornando allo schema di figura 3a, L‟utente della rete dedicata destinatario 365 à ̈ registrato nel sistema per firma elettronica qualificata secondo l‟invenzione, presso un server applicativo 315 che gestisce la tipologia di messaggi di richiesta originaria di tipo sottoscrizione documenti.
Nel caso di sottoscrizione documenti, ad esempio nel caso di un‟assicurazione che richieda la sottoscrizione di un contratto all‟utente del sistema per firma elettronica qualificata 365 destinatario si invia la prima richiesta operativa 305 di upload documento verso il server 310, che non raggiunge l‟utente destinatario 365; tale richiesta di upload à ̈ completa di metadati per la ricerca successiva del documento. Il server di front-end 310 invia una richiesta inoltrata 308 al server applicativo 315 che archivia le informazioni ricevute assegnando al documento un rispettivo identificativo univoco del documento tramite il quale lo archivia su memoria persistente insieme all‟informazione dell‟identificativo della richiesta operativa 305 di upload; in risposta il server applicativo 315 fornisce nel messaggio inoltro esito 366 l‟identificativo documento, che viene inviato dal server di front-end 310 attraverso l‟esito richiedente 370, in risposta alla richiesta operativa 305 di upload, all‟elaboratore 303 con cui il richiedente ha operato, come riportato con riferimento allo schema di figura 3a; in alternativa all‟elaboratore 303 questi può operare attraverso lo smartphone 100.
Successivamente sempre attraverso un elaboratore 303 o smartphone 100 viene inviata dallo stesso richiedente 300 o da un altro richiedente una richiesta operativa 305 di sottoscrizione del documento precedentemente archiviato, che, come le richieste di pagamento già descritte, prevede l‟indicazione della tipologia di richiesta operativa, specificamente di tipo sottoscrizione documento, il numero di telefono mobile del destinatario registrato nella rete dedicata 365 o l‟identificativo del sistema per firma elettronica qualificata associato a tale numero, l‟identificativo univoco del documento e/o della precedente richiesta operativa 305 di upload, e l‟indirizzo e-mail del richiedente oppure un identificativo del richiedente nel sistema di firma elettronica qualificata.
All‟interno del database del server applicativo 315 viene mantenuto un riferimento d‟indirizzo al corrispondente identificativo documento, insieme all‟identificativo della relativa richiesta operativa di sottoscrizione, del relativo timestamp e dell‟utente destinatario.
Viene dunque inviato un messaggio di richiesta a base testo 340 allo smartphone 210; il messaggio contiene l‟identificativo della richiesta operativa 305 di sottoscrizione, la stringa di hashing del documento e il riferimento di indirizzo (ad es. URL) del documento nel frattempo pubblicato ad opera del server applicativo 315 su un‟area raggiungibile dall‟utente 365. Il messaggio di richiesta a base testo 340 include l‟identificativo della tipologia di richiesta relativa alla sottoscrizione ed eventualmente l‟identificativo del documento, il timestamp assegnato dal front-end 310 alla richiesta operativa 305 di sottoscrizione, secondo quanto indicato relativamente al funzionamento di tale server con riferimento a figura 3a.
Il messaggio di richiesta a base testo 340 à ̈ interpretato dall‟applicazione per la firma elettronica qualificata 220 e visualizzato sul display 110 in modo da rappresentare una chiara richiesta di sottoscrizione del documento in linguaggio naturale. All‟interno del display à ̈ possibile leggere chiaramente il riferimento di indirizz 0 € <0•_òà s |0•_òà s @ @ À @ nga di hashing del documento, calcolata dal server applicativo 315 ed inviata allo smartphone 210, poiché il documento potrebbe essere di notevoli dimensioni e il calcolo dello hashing a bordo dello smartphone 210 potrebbe essere problematico. Poiché la stringa di hashing può contenere caratteri non visualizzabili essa viene codificata con notazione esadecimale o in base64, o altra formattazione sul display 110. Anche in questo caso à ̈ possibile scegliere l‟opzione dell‟applicazione 220 che consente il ricalcolo dello hashing sullo smartphone 210 e verifica di quello ricevuto o il ricalcolo eventuale di tale hashing può essere effettuato attraverso altri software su un elaboratore di supporto, effettuando prima il download del documento al riferimento d‟indirizzo indicato nel messaggio.
E‟ previsto che l‟utente 365, se in fase di registrazione ha fornito un proprio indirizzo e-mail, sia anche raggiunto contestualmente da un messaggio e-mail contenente lo stesso messaggio visualizzato sullo smartphone 210 e inviato dal server applicativo 315; in tal modo, ad esempio il destinatario 365 può ricevere l‟e-mail consultando la casella di posta elettronica su un elaboratore di supporto e cliccando sul riferimento d‟indirizzo del documento, presente nella e-mail, visualizzarlo su un display più ampio. Il nome file presente in tale riferimento, o reference, può essere rappresentato dallo hashing stesso in modo da consentire un ulteriore controllo disponibile all‟utente.
Con tale operatività l‟utente della rete dedicata destinatario 365 può effettuare un download del file documento e sottoporlo a ricalcolo dello hashing attraverso altri strumenti, ad esempio presenti su Internet.
E‟ previsto comunque di poter visualizzare il documento sul display 110 dello smartphone 210 attraverso scelta di una corrispondente opzione sull‟applicazione per la firma elettronica qualificata 220.
La stringa di hashing viene calcolata dal server applicativo 315, secondo quanto già descritto rispetto alla forma di figura 3a, dove il messaggio di conferma 345 di fatto à ̈ costituito dall‟identificativo richiesta operativa di sottoscrizione 305, dalla firma elettronica qualificata detached effettuata sullo hashing del documento, ed eventualmente dall‟identificativo univoco del documento. La firma corrisponde alla cifratura RSA attraverso chiave privata dello hashing, una volta che sia decodificato dal formato di presentazione come il base64 o esadecimale. Anche in questo caso, in base alla normativa adottata nel Paese di utilizzo, à ̈ obbligatorio o meno aggiungere altre informazioni allo hashing prima della firma.
Il server applicativo 315 verifica la firma contenuta nel messaggio di conferma 345 recuperando il file documento, il certificato di firma associato al numero di telefono nel database relativo all‟utente a cui era stata inviata la richiesta operativa 305 per la sottoscrizione documenti non essendo necessario effettuare una richiesta di disposizione 350 al server 330.
Anche qui, come nelle forme descritte con riferimento a figura 3a, nel caso in cui il messaggio di richiesta operativa 305 di sottoscrizione sia completo di indirizzo e-mail del richiedente il server di front-end 310 invia agli/allo indirizzi/o e-mail corrispondenti/e l‟e-mail che traduce in linguaggio naturale il messaggio esito richiedente 370, sia in caso di esito positivo della transazione, sia in caso negativo. L‟e-mail inviata riporta come allegata la firma del documento eventualmente in modalità attached, cioà ̈ avendo imbustato con la firma, ossia allegato ad essa, anche il documento, il certificato di firma e il certificato dell‟Autorità di Certificazione correlato; all‟interno della e-mail sono presenti anche gli estremi della richiesta operativa 305 di sottoscrizione e l‟identificativo del documento. Analoga e-mail può essere spedita all‟indirizzo email dell‟utente 365.
Se nella richiesta operativa 305 di sottoscrizione era presente l‟identificativo del richiedente nella rete dedicata o il numero di telefono del richiedente, il server di front-end 310 invia a questi una notifica al relativo smartphone 210 del richiedente attraverso il suo numero di telefono censito nella rete dedicata.
In generale, valgono poi gli ulteriori aspetti dei flussi descritti con riferimento a figura 3a, dove si consideri il documento in luogo del messaggio di richiesta a base testo 340.
Attraverso tale metodo di firma, l‟utente 365 può sottoscrivere documenti in mobilità attraverso il proprio smartphone 210 per firma elettronica qualificata, a seguito di richiesta da parte di terzi, conservar tali documenti sottoscritti nel tempo e farli pervenire al richiedente.
Nel caso il documento sia una fattura o una ricevuta questo processo consente la sua sottoscrizione digitale e la realizzazione quindi di una fattura o ricevuta elettronica. Tale gestione può essere combinata con il pagamento elettronico della stessa da parte del cliente registrato nel sistema di firma elettronica qualificata: se tra i metadati della fattura o ricevuta caricata in upload à ̈ presente l‟identificativo unico del cliente o suo numero di telefono all‟interno del rete dedicata e le informazioni per una richiesta di pagamento, al termine della gestione del messaggio 305 di sottoscrizione della fattura da parte del venditore, può essere generata in automatico dal server di interfaccia 302 nel caso implementativo di figura 3a o, nel caso implementativo di figura 3b può essere generato dall‟applicazione 220 sullo smartphone 210, una richiesta operativa 305 di pagamento indirizzata al cliente che può effettuare il pagamento via smartphone 210. Un‟ulteriore forma implementativa di sistema per la sottoscrizione di documenti può operare con l‟architettura di figura 4, come descritta in precedenza, dove l‟utente 400 che à ̈ richiedente e destinatario opera ad esempio su un sistema documentale o di contabilità associato alla rete dedicata di firma elettronica qualificata; il sistema documentale o di contabilità o altro servizio à ̈ rappresentato da un sito web o server di interfaccia alla rete dedicata di certificazione 302, attraverso il quale à ̈ possibile per l‟utente 400 effettuare la firma di fatture elettroniche o documenti anche di notevoli dimensioni attraverso lo smartphone 210 e si può utilizzare il campo e-mail del richiedente con un indirizzo e-mail a cui l‟utente 400 intende inviare il documento firmato.
Un‟ulteriore forma implementativa di sistema per la sottoscrizione di documenti può operare con l‟architettura di figura 5, come descritta in precedenza, dove l‟interfaccia utente à ̈ rappresentata unicamente dallo smartphone 210 che si interfaccia direttamente al server di front-end 310 senza intermediazione del server applicativo 302, sia per effettuare la richiesta, sia per gestire la sottoscrizione dei documenti. In questo flusso il messaggio esito destinatario 360 restituisce solo la notifica di avvenuta ricezione della conferma 345 all‟applicazione per la firma elettronica qualificata 220, poiché lo smartphone 210 comunque riceve l‟esito finale della richiesta esito richiedente 370.
Un‟ulteriore forma implementativa di sistema per la sottoscrizione di documenti può operare con l‟architettura di figura 6, come descritta in precedenza, dove lo hashing à ̈ tuttavia calcolato sempre dall‟applicazione per la firma elettronica qualificata 220, e quindi permette di operare nel caso di documenti non di grandi dimensioni, come ad esempio gli SMS o messaggi di testo digitati sullo smartphone 210, che vengono quindi firmati. In tal caso il documento à ̈ inviato via messaggio di richiesta operativa 305 di sottoscrizione, contestualmente agli eventuali metadati per una ricerca successiva sui sistemi di archiviazione della rete dedicata, e contestualmente alla firma elettronica qualificata del documento; il documento può essere digitato con la tastiera 115 dello smartphone 210 o essere recuperato come file.
L‟utente 400 può utilizzare il campo e-mail del richiedente con un indirizzo e-mail a cui intende inviare il documento firmato. In alternativa può utilizzare il campo aggiuntivo nella richiesta che corrisponde all‟identificativo univoco o numero di telefono di un utente della rete dedicata a cui inviare il documento firmato. In tal caso alla ricezione dell‟esito richiedente 370 positivo, l‟applicazione per la firma elettronica qualificata 220 presente sullo smartphone della rete dedicata 210, notifica l‟avvenuta operazione all‟utente 400; la rete dedicata inoltre invia una notifica allo smartphone 210 dell‟utente della rete dedicata designato dal firmatario; il ricevente la notifica può leggere, attraverso la applicazione 220, il documento dal proprio smartphone 210, avendo la certificazione della identità del mittente data dalla rete dedicata.
Un‟ulteriore forma realizzativa riguarda l‟accesso sicuro e certificato a servizi di rete integrati con la rete dedicata, come ad esempio possono essere i siti web, tra cui i siti di home banking e della pubblica amministrazione. Tale ulteriore forma realizzativa di accesso sicuro e certificato può operare con l‟architettura di figura 4 in cui l‟utente della rete dedicata 400 à ̈ registrato alla rete dedicata con un server applicativo 315 che abilita gli accessi al server d‟interfaccia 302 ed à ̈ connesso alla rete dedicata per effettuare una richiesta. di accesso ad un server di interfaccia 302 attraverso l‟elaboratore di supporto 303 con display o eventualmente lo smartphone convenzionale 100, includendo in questo caso lo stesso smartphone 210 utilizzato poi nella fase di conferma, che non utilizzi però per la fase di richiesta l‟applicazione per la firma elettronica qualificata 220 e la memoria certificata 200. La richiesta di accesso normalmente à ̈ composta da due richieste operative 305 in successione. Il server di interfaccia 302 à ̈ rappresentato dal servizio o sito web su cui l‟utente 400 vuole autenticarsi. Il richiedente l‟accesso e l‟utente che lo conferma in questo caso sono lo stesso utente 400, il quale opera, come richiedente, in maniera analoga al richiedente 300 descritto con riferimento all‟architettura di figura 3a. Il server di interfaccia 302 può quindi ad esempio implementare un sito web a cui l‟utente 400 effettua richieste attraverso un browser dell‟elaboratore 303 o dello smartphone 100 secondo protocolli di per sé noti, che consentono di far tradurre al server d‟interfaccia 302 le richieste dell‟utente 400 in richieste operative 305 e di interpretare i messaggi esito richiedente 370 ricevuti dal server di interfaccia 302 stesso in informazioni intellegibili per l‟utente 400 nel ruolo di richiedente.
Secondo un ulteriore aspetto dell‟invenzione, il generico servizio/sito web 302 appartenente al sistema di comunicazione con firma certificata richiede di inserire in appositi campi informazioni secondo lo schema user/password, dove in questo caso però la password à ̈ una password temporanea arbitraria, o ATP (Any Temporary Password).
Il codice user à ̈ riferito all‟utente 400 e può essere il suo numero di telefono o il suo identificativo univoco all‟interno del sistema secondo l‟invenzione o un suo identificativo univoco all‟interno dello specifico servizio/sito 302. In questo ultimo caso all‟interno del servizio/sito 302 à ̈ presente l‟associazione con uno dei due sopramenzionati identificativi.
La password ATP rappresenta un codice alfanumerico arbitrario deciso dall‟utente nel momento in cui lo digita, ossia nel momento in cui gli viene richiesto di inserire una password per una certa transazione, come ad esempio il login o l‟autorizzazione a una disposizione. La prima richiesta operativa 305 comprende l‟indicazione della tipologia di richiesta di tipo accesso, il numero di telefono mobile del destinatario della rete dedicata 400 o identificativo del rete dedicata associato a tale numero, l‟identificativo della sessione utente sul servizio/sito 302, la password ATP ed eventualmente la reference (per esempio URL) del servizio a cui si intende accedere. La richiesta operativa 305 viene inviata al server di front-end 310.
L‟utente 400 in veste di destinatario opera sostanzialmente in modo analogo a quanto descritto per il destinatario 365 con riferimento a figura 3a, tuttavia prima di inviare all‟utente 400 come destinatario sullo smartphone 210 il messaggio di richiesta a base testo 340, il server applicativo 315 effettua ulteriori controlli specifici; infatti il server applicativo 315 conserva lo storico delle ultime n password ATP utilizzate dall‟utente, dove n à ̈ un numero intero configurabile. Nel caso di una richiesta con password ATP uguale ad una presente nello storico, la richiesta fallisce. Viceversa, il server applicativo 315 prepara una stringa definita qui come stringa base; la stringa base à ̈ una stringa di caratteri che costituisce parte del messaggio di richiesta a base testo 340.
La stringa base può rappresentare un‟informazione in chiaro o essere lo hashing di tale informazione in chiaro, in base alla configurazione del sistema. L‟informazione in chiaro sopramenzionata à ̈ una stringa di caratteri ottenuta dalla concatenazione di informazioni presenti nella richiesta inoltrata 308, tra cui la password ATP, l‟identificativo univoco della richiesta operativa 305 eventualmente insieme al timestamp dal server di front-end 310, eventualmente l‟identificativo di sessione, ed eventualmente la reference del servizio oltre ad altri eventuali dati opzionali. Quindi la stringa base coincide con tale stringa complessiva o con il suo hashing, a seconda della configurazione. L‟informazione sulla sessione à ̈ conosciuta dal server d‟interfaccia 302 ed à ̈ presente nel server 315 legata all‟identificativo della richiesta operativa 305 corrispondente. Tale legame à ̈ inoltre noto in seguito anche al server di interfaccia 302, attraverso il messaggio esito richiedente 370 corrispondente alla prima richiesta operativa 305. Il messaggio esito richiedente 370 riporta tra i dati la stringa base in caso di esito positivo, ed in ogni caso l‟identificativo di sessione e di prima richiesta operativa 305, in modo che il server d‟interfaccia 302 possa metterli in relazione, oltre a ricevere le informazioni sull‟esito della richiesta operativa e della stringa base per la sessione indicata. A livello del messaggio 340 l‟informazione sulla sessione potrebbe essere omessa, poiché la conferma eseguita dallo smartphone 210 comprendente come informazione l‟identificativo della prima richiesta operativa 305, verrebbe associata dal server applicativo 315 ad una conferma per la sessione legata a tale richiesta operativa 305.
Se la stringa base à ̈ in chiaro essa contiene in chiaro almeno la password ATP e l‟identificativo della prima richiesta operativa 305, e il messaggio di richiesta a base testo 340 si compone di stringa base e identificativo del tipo di richiesta (richiesta di tipo accesso); altrimenti, se la stringa base à ̈ lo hashing sopramenzionato, esso à ̈ costituito dalla concatenazione di tipo di richiesta, stringa base, ATP e identificativo della prima richiesta operativa 305, eventualmente l‟identificativo di sessione ed altre informazioni opzionali presenti eventualmente nell‟informazione in chiaro su cui à ̈ calcolato lo hashing anzidetto.
Il server applicativo 315, dopo aver ricevuto la password ATP nella richiesta inoltrata 308, se essa non à ̈ valida in base ai controlli sopramenzionati invia al server di front-end 310 attraverso messaggio inoltro esito 366 l‟indicazione che la password ATP digitata à ̈ non valida, oppure, se essa à ̈ valida invia messaggio di inoltro esito 366 di tenore positivo. Tale messaggio di inoltro 366 contiene l‟identificativo della richiesta operativa 305, la stringa base e la sessione, . Il server di front-end 310 inoltra poi un corrispondente messaggio esito richiedente 370 con le stesse informazioni, eventualmente includendo tutte le informazioni presenti nel messaggio di richiesta inoltrata 308, al server di interfaccia 302 che per la sessione coincidente a quella ricevuta aggiorna l‟indicazione di password ATP errata, sessione e identificativo della prima richiesta operativa 305 oppure, in caso positivo, il valore della stringa base e dell‟identificativo di richiesta operativa 305 ricevuto, associato alla sessione eventualmente insieme a informazioni opzionali ricevute. L‟interfaccia grafica presente sull‟elaboratore 303 o smartphone 100 viene aggiornata automaticamente o su richiesta dell‟utente 400 e viene ivi visualizzato il messaggio di errore o in caso positivo la stringa base.
Se la stringa base à ̈ in chiaro la password ATP in essa contenuta può non essere visualizzato. Se la stringa base à ̈ un hashing, eventualmente le informazioni sono presentate in modo che l‟utente possa calcolare tale hashing autonomamente con altri strumenti, sulla concatenazione delle informazioni visualizzate sul dispositivo di richiesta, in modo da poter confrontare tale hashing con quello visualizzato, conoscendo le regole con cui le informazioni presenti sull‟interfaccia grafica vengono concatenate al fine di calcolare lo hashing. Tali regole possono essere esplicitate anche sull‟interfaccia grafica del sito d‟interfaccia 302 come nota informativa. Anche in questo caso, se lo hashing à ̈ presente, viene preferibilmente codificato con notazione esadecimale o in base64.
Con l‟invio del messaggio esito richiedente 370 correlato al precedente messaggio di richiesta operativa 305 le operazioni non sono tuttavia terminate; il server 315 conserva i dati della prima richiesta operativa 305, del messaggio 308 e 340. Inoltre viene creato automaticamente un ulteriore messaggio di richiesta operativa 305 dal server d‟interfaccia 302, sotto richiesta automatica da parte dell‟elaboratore 303 o dello smartphone 100 del richiedente, al fine di terminare le attività . Tale messaggio di richiesta operativa 305 riporta tra i dati il tipo di richiesta, l‟identificativo del precedente messaggio di richiesta operativa 305 ottenuto dal precedente messaggio esito richiedente 370, e l‟identificativo di sessione recuperato runtime che deve coincidere con il precedente, pena l‟invalidità della nuova richiesta.
Al nuovo messaggio di richiesta operativa 305 attraverso il server di front-end 310 viene assegnato un timestamp ed un nuovo identificativo. Il server di front-end 310 invia il contenuto del nuovo messaggio di richiesta operativa 305, completo di identificativo richiesta e timestamp, attraverso il messaggio di richiesta inoltrata 308 al server applicativo 315 dove il primo messaggio di richiesta 305 era stato registrato, contraddistinto dal suo identificativo, insieme ai suoi dati con uno stato della operazione complessiva del tipo „in attesa‟. Il nuovo messaggio di richiesta inoltrata 308 e il suo identificativo vengono, a livello del server applicativo 315, a questo punto correlati agli analoghi parametri della precedente richiesta, grazie all‟identificativo della prima richiesta operativa 305 presente nel nuovo messaggio; il server applicativo inoltre effettua un controllo di uguaglianza tra l‟identificativo di sessione contenuto nel primo e nel secondo messaggio di richiesta. Parallelamente all‟invio del primo messaggio inoltro esito 366, il server applicativo 315 in caso esso abbia validato positivamente la password ATP, ha preparato nel frattempo il messaggio di richiesta a base testo 340 che viene inviato allo smartphone 210, con i contenuti sopra descritti. Il messaggio di richiesta a base testo 340 riporta l‟identificativo del corrispondente messaggio di richiesta operativa 305, cioà ̈ il primo, e viene archiviato su apposite aree persistenti, ad esempio memorie di massa connesse al server applicativo 315; all‟interno del database di detto server 315 viene mantenuto un riferimento al file corrispondente, insieme all‟identificativo della richiesta, del timestamp e dell‟utente destinatario rappresentato dal suo numero di telefono o identificativo univoco, nonché gli altri dati del messaggio di richiesta a base testo 340, inclusa informazione in chiaro corrispondente allo hashing nel caso in cui la stringa base sia in forma di hashing.
Il server applicativo 315 invia il messaggio di richiesta a base testo 340 in base al numero di telefono del destinatario ricevuto nel primo messaggio di richiesta inoltrata 308 o desunto dal proprio database in base all‟identificativo univoco dell‟utente 400 ricevuto nel primo messaggio di richiesta inoltrata 308. In generale le modalità di invio del messaggio 340 riflettono quanto già descritto rispetto al caso generale di figura 3a.
Il messaggio di richiesta 340 corrisponde tipicamente ad una chiara richiesta di accesso in linguaggio naturale riportante i dati presenti nel messaggio stesso, visualizzata sul display 110 dello smartphone 210; se la stringa base à ̈ in forma di hashing viene mostrato il valore di hashing, sempre codificato preferibilmente in esadecimale o base64. L‟applicazione per la firma elettronica qualificata 220 richiede di apporre firma elettronica qualificata sulla stringa base qualora sia un hashing, altrimenti sullo hashing dell‟intero messaggio 340, essendo calcolato tale hashing dalla applicazione 220; cioà ̈ a seconda dei casi o sullo hashing coincidente con la stringa base visualizzato sul display 110 previa decodifica dal formato di visualizzazione tipicamente esadecimale/base64, o in caso di stringa base in chiaro, viene calcolato lo hashing dall‟applicazione 220 sul messaggio 340 in chiaro visualizzato sul display 110. La firma consiste nella cifratura RSA dello hashing attraverso chiave privata 201. Prima della firma, l‟utente 400 può confrontare nel caso di stringa base coincidente con lo hashing, la password ATP e lo hashing mostrati dall‟applicazione multifunzionale 220 rispettivamente con la password ATP da lui digitata e lo hashing mostrato per mezzo dell‟elaboratore di supporto 303 o smartphone 100, oltre ad altri eventuali parametri opzionali.
Nel caso di stringa base in chiaro l‟utente 400 può confrontare la password ATP e l‟identificativo della richiesta operativa 305 mostrati dall‟applicazione multifunzionale 220 rispettivamente con la password ATP da lui digitato sul dispositivo richiedente 303 o 100 e l‟identificativo della richiesta operativa 305 mostrato sempre per mezzo dell‟elaboratore di supporto 303 o smartphone 100, oltre ad altri eventuali parametri opzionali. Nel caso di presenza di ulteriori informazioni nel messaggio di richiesta a base testo 340 e quindi sul display 110 dello smartphone 210, esse sono comunque presenti anche sull‟interfaccia grafica dell‟elaboratore 303 o smartphone 100 di richiesta, consentendo quindi all‟operatore il controllo che le informazioni presenti sul mezzo di richiesta e di conferma siano congruenti. In caso di congruenza tra i dati, l‟utente può procedere alla firma elettronica qualificata detached.
Per quanto riguarda le modalità di calcolo dello hashing vale quanto già descritto con riferimento a figura 3a, in particolare riferendosi sulla eventuale necessità di aggiungere altre informazioni allo hashing prima della firma, seguendo eventuali requisiti aggiuntivi per la firma elettronica qualificata nel Paese di utilizzo. Il messaggio di conferma 345 à ̈ rappresentato qui dalla firma elettronica qualificata detached effettuata sullo hashing anzidetto coincidente con la stringa base se essa à ̈ in forma di hashing o, in caso contrario, sullo hashing calcolato dall‟applicazione 220 sul messaggio 340. La firma à ̈ accompagnata dall‟identificativo univoco della prima richiesta di sottoscrizione 305 assegnato precedentemente dal server di front-end 310.
Il server applicativo 315 verifica la firma contenuta nel messaggio di conferma 345 recuperando l‟informazione in chiaro corrispondente precedentemente registrata: l‟informazione in chiaro da cui era stato calcolato lo hashing nel caso in cui esso era la stringa base; viceversa viene recuperato l‟intero messaggio 340. Viene recuperato inoltre il certificato di firma associato al numero di telefono nel database relativo all‟utente a cui era stata inviata la prima richiesta operativa 305 ,e il relativo certificato della Certification Authority.
In caso di fallimento della verifica della firma o di altri controlli il server applicativo 315 invia messaggio esito destinatario d‟errore specifico 360 allo smartphone 210 e il messaggio di inoltro esito 366 d‟errore specifico al server di front-end 310, in risposta al secondo messaggio di richiesta inoltrata 308. Questo invia esito richiedente 370 d‟errore al richiedente, in risposta al secondo messaggio di richiesta operativa 305
Nel presente esempio applicativo non à ̈ necessario effettuare una richiesta di disposizione 350 al server 330. Per quanto riguarda il secondo esito richiedente 370 vale in generale quanto già descritto con riferimento a figura 3a essendo l‟utente 400 in veste di destinatario corrispondente al richiedente e considerando che nella seconda richiesta operativa 305 non à ̈ però normalmente presente l‟indirizzo e-mail del richiedente/destinatario. In caso di verifiche positive, il messaggio esito richiedente 370 contiene l‟indicazione per il server d‟interfaccia 302 di considerare autenticato l‟utente sulla sessione inizialmente indicata nella prima e seconda richiesta operativa 305; pertanto l‟utente 400 può visualizzare o accedere a dati sensibili perché la sua sessione sul server di interfaccia 302 viene autorizzata a ciò. In sostanza l‟utente 400 ha effettuato con successo il login.
Una ulteriore informazione gestibile dal server d‟interfaccia 302 consiste nello specificare nelle richieste operative 305 una particolare informazione o autorizzazione interna alla corrente sessione; in tal modo può essere effettuata una specifica doppia richiesta operativa 305 come nel caso sopraesposto; tali richieste operative 305 della tipologia accesso servono per permettere ulteriormente l‟accesso a tale specifica informazione o per confermare una disposizione. Ad esempio il valore della sessione impostato dal server di interfaccia 302, nella richiesta operativa 305, può contenere l‟identificativo della particolare azione da autorizzare o informazione a cui accedere; in tal caso viene gestita una doppia richiesta operativa 305 simile a quella sopraesposta, dove il codice user per la fase di richiesta opzionalmente non viene più richiesto all‟utente perché noto al server di interfaccia 302; dall‟interfaccia grafica utente viene tipicamente richiesta sola una password ATP.
Per gli altri aspetti non descritti qui, il sistema opera in maniera analoga a quanto descritto per il sistema operante con l‟architettura di figura 3a.
E‟ altresì possibile utilizzare la stessa procedura qui descritta senza utilizzare la password ATP. La modalità di securizzazione tramite password arbitraria temporanea può essere impiegata per l‟accesso all‟home o mobile banking, oltre che per l‟accesso a qualsiasi servizio/sito. Nel caso di homemobile banking il server applicativo 315 tipicamente à ̈ installato all‟interno della rete della banca. Il confronto fra password arbitrarie e le altre informazioni presenti sia lato richiedente, sia lato destinatario à ̈ eseguito preferibilmente dall‟utente 400. E‟ naturalmente possibile, in particolare, che l‟utente 400 impieghi come terminale per la richiesta e per la firma uno stesso smartphone 210 per firma elettronica qualificata, utilizzando per la fase di richiesta le sue funzionalità di uno smartphone 100; in tal caso si può effettuare il suddetto confronto in maniera automatica tramite un‟applicazione software specifica o l‟applicazione 220 medesima.
E‟ altresì possibile integrare la richiesta all‟interno dell‟applicazione 220 medesima, e in tal senso à ̈ possibile estendere allo smartphone 210 l‟effettuazione della richiesta attraverso il server d‟interfaccia 302. L‟applicazione software, nel caso la visualizzazione avvenga su due elaboratori diversi, può sfruttare ad esempio un canale di comunicazione a corto raggio, ad esempio Bluetooth, attraverso l‟utilizzo sullo smartphone 210 del modulo opzionale di connessione wireless 121 o similare nel caso di elaboratori 303 o smartphone 100, come quelli usati dai messaggi client 351 e 352 descritti nel seguito, in questo caso per il confronto automatico.
Sempre ai fini di effettuare il login ad un servizio in rete o autorizzare una disposizione, à ̈ altresì inoltre possibile visualizzare inizialmente sul dispositivo 303 o 100 già l‟identificativo di sessione ad opera del colloquio con il server d‟interfaccia e promuovere su di esso una richiesta operativa 305 senza riferimento allo user coinvolto; in tal caso lo smartphone 210 viene utilizzato da subito in maniera attiva senza utilizzo del messaggio a base testo 340, inserendo da parte dell‟utente 400 sull‟applicazione 220 l‟identificativo di sessione e operando su di esso la firma attached, inviandola con un messaggio di conferma 345 al server applicativo 315; il messaggio à ̈ completo eventualmente di identificativo dell‟utente nella rete dedicata o serial number del certificato con relativo identificativo del certificato della Certification Authority che lo ha emesso, oppure alla ricezione del messaggio di conferma 345 l‟utente à ̈ desunto dal numero di telefono in caso si tratti di SMS. Il server applicativo 315, effettuata la verifica della firma utilizzando i certificati presenti nel suo database associati all‟utente, invia l‟identificativo del firmatario o numero di telefono con la sessione attraverso un messaggio di inoltro esito 366 al server d‟interfaccia 302; il server d‟interfaccia 302 con messaggio esito richiedente 370 riceve l‟identificativo o numero di telefono dell‟utente e vede perfezionarsi il login o la disposizione richiesta sul dispositivo 303 o 100. E‟ inoltre possibile aggiungere lo username o numero di telefono o identificativo della rete dedicata nella fase iniziale sul dispositivo 303 o 100; in tal caso l‟informazione sull‟utente per la sessione indicata à ̈ presente sul messaggio 305 sino a giungere al server applicativo 315: con il vincolo che non sia possibile per un dato utente attivare più login diversi simultaneamente, il messaggio 345 può non contenere l‟informazione in chiaro sulla sessione poiché già presente associata all‟utente sul server 315, e recare con sé la firma detached ed eventualmente l‟identificativo utente nella rete dedicata o le informazioni anzidette sui certificati oppure ancora il numero di telefono utente à ̈ desunto dal server applicativo 315 in caso sia un SMS. In tale utilizzo della rete dedicata per l‟accesso o le disposizioni à ̈ inoltre possibile aggiungere sul dispositivo 303 o 100 l‟ATP ad inizio procedimento, inducendo un ricalcolo dell‟identificativo sessione che compare sul relativo display; eventualmente l‟informazione dell‟ATP giunge sino al server applicativo 315 a cui l‟utente invia un primo messaggio 345 con l‟indicazione della sessione visualizzata sul dispositivo 303 o 100 e riceve l‟ATP in risposta con un messaggio esito destinatario 360; in caso i due ATP siano uguali promuove un ulteriore messaggio 345 di firma come sopra riportato.
Si noti che il procedimento con password arbitraria temporanea sopra descritto può eventualmente anche essere impiegato in sistemi di firma elettronica qualificata che facciano uso di una chiave privata 201 che non sia tuttavia memorizzata in una memoria certificata 200.
Inoltre, il procedimento di firma tramite l‟uso di una password temporanea ATP descritto con riferimento ai sistemi oggetto della presente invenzione, può essere impiegato anche con sistemi diversi, configurando un procedimento di firma elettronica o firma elettronica qualificata secondo cui a seguito della visualizzazione di un identificativo di sessione sui primi mezzi di elaborazione, l‟utente richiedente e destinatario 400 digita tale identificativo sull‟applicazione 220 del secondo mezzo di elaborazione 210 e appone su di esso firma attraverso l‟applicazione 220, inviandola mediante un messaggio di conferma 345 in modo che il server applicativo 315 possa individuare l‟utente firmatario basandosi sulla verifica della firma, fornire tale informazione mediante messaggio inoltro esito 366 sino al server di interfaccia 302 che comunica con il primo mezzo di elaborazione 303 (o 100 o 210) in modo da consentire all‟utente, se censito sul server d‟interfaccia 315 l‟effettuazione di una disposizione o l‟accesso ad un‟ulteriore pagina sui primi mezzi di elaborazione, potendo inoltre ricevere sul secondo mezzo di elaborazione 210 prima di detta firma tale password temporanea ATP se precedentemente digitata sui primi mezzi di elaborazione 303 (o 100 o 210).
Un‟ulteriore forma realizzativa à ̈ relativa a pagamenti e sottoscrizioni effettuati secondo una delle architetture nelle figure 3a, 3b, 4 e accessi secondo l‟architettura in figura 4, secondo quanto illustrato con riferimento all‟architettura di figura 7. Il messaggio esito destinatario 360 à ̈ disegnato tratteggiato perché potrebbe essere assente e sostituito da altro messaggio, come indicato nel prosieguo. In questa forma realizzativa, il messaggio di richiesta a base testo 340 può essere sostituito da un messaggio inviato dal client elaboratore 303, come raffigurato in figura 7, che può alternativamente essere sostituito da uno smartphone 100 o 210, e diretto allo smartphone 210 del sottoscrittore. Il richiedente 300 in figura 7 può essere sostituito dal richiedente coincidente con il destinatario 400, e il destinatario 365 in figura 7 può essere sostituito anch‟esso con il richiedente coincidente con il destinatario 400.
Il server d‟interfaccia 302 à ̈ tratteggiato poiché può non essere presente nel caso in cui la richiesta venga effettuata dallo smartphone 210. In questo contesto ciascuno dei messaggi del tipo richiesta operativa 305 di pagamento, richiesta operativa 305 di sottoscrizione successiva all‟upload, e il primo dei due messaggi di richiesta operativa 305 di tipo accesso, viene sostituito ora da due nuovi messaggi di richiesta operativa 305 in successione. I due nuovi messaggi di richiesta operativa 305, ciascuno col proprio identificativo, sono in generale legati in modo che nel secondo viene riportato tra i dati l‟identificativo del primo. Nel caso degli accessi segue un‟ulteriore richiesta operativa 305 come nella forma realizzativa esposta in precedenza. Il primo nuovo tipo di messaggio di richiesta operativa 305 attraverso i messaggi e i server presentati nelle precedenti forme realizzative, oltre ad essere trattato come nei casi precedenti, può contenere eventuale indicazione del dispositivo richiedente 303 o 100 o 210 tramite un identificativo se possibile univoco. La richiesta operativa 305, una volta raggiunto il server applicativo 315, sortisce anche l‟effetto di far inviare dal server applicativo 315 le stesse informazioni che sarebbero state contenute nel messaggio di richiesta a base testo 340, con l‟indicazione del numero di telefono del destinatario ed eventualmente dell‟identificativo del dispositivo richiedente, attraverso il messaggio inoltro esito 366 che attraverso il messaggio esito richiedente 370 giunge all‟elaboratore 303 o smartphone 100. In tal caso il server applicativo 315 resta in attesa comunque del messaggio contenente la firma, associata alla prima richiesta. Il messaggio esito richiedente 370 fa aggiornare lo stato di attesa della firma del sottoscrittore sul dispositivo 303 o 100 0 210 che ha effettuato la richiesta; nel caso che la richiesta effettuata sia di tipo accesso vengono desunti dal messaggio esito richiedente 370 i dati per l‟aggiornamento dell‟interfaccia grafica dell‟elaboratore 303 o 100 come presentato in precedenza. In generale il messaggio 370 contiene le informazioni dirette allo smartphone 210 del destinatario e pertanto esse o parte di esse, transitando per il dispositivo di richiesta 303 o 100 o 210 possono essere visualizzate sulla relativa interfaccia grafica del dispositivo di richiesta alla ricezione del messaggio 370. Ad esempio lo hashing da sottoscrivere può essere presentato su tale interfaccia grafica anche per pagamenti o sottoscrizioni, in modo da consentire un ulteriore controllo da parte dell‟utente.
L‟elaboratore 303 o lo smartphone 100 o 210 di richiesta invia inoltre le informazioni ricevute allo smartphone 210 del destinatario affinché questi possa apporre la propria firma. La trasmissione tra elaboratore 303 o smartphone 100 e smartphone 210 avviene tipicamente attraverso tecnologie alternative all‟SMS, come ad esempio Bluetooth o NFC o Wi-Fi o traffico dati Internet o altre abilitate dal modulo di connessione network opzionale 121, in questo contesto tipicamente utilizzato. In presenza di identificativo del dispositivo di richiesta nella richiesta operativa 305, tale indicazione à ̈ presente anche tra i dati del messaggio 351 e quindi eventualmente controllabile dall‟applicazione 220 dello smartphone del destinatario 210, in base al mittente rilevato per il messaggio 351. Lo smartphone 210 del destinatario per essere individuato dal dispositivo del richiedente 303, 100 o 210, può essere identificato attraverso ad esempio l‟identificativo del destinatario all‟interno della rete dedicata o il suo numero di telefono o altro identificativo presente nel database del server applicativo 315, contenuto nel messaggio inoltro esito 366 e quindi nel messaggio esito richiedente 370 il cui contenuto diventa quindi disponibile al dispositivo richiedente. Viene dunque inviato un messaggio richiesta client 351 allo smartphone 210 dal dispositivo richiedente 303, 100 o 210. Parimenti l‟elaboratore 303 o smartphone 100 o 210 deve essere abilitato a tale ricezione/trasmissione.
La firma attraverso lo smartphone 210 avviene secondo quanto già descritto nei precedenti casi e il messaggio di conferma 345 può essere sostituito da analogo messaggio conferma client 352, inviato all‟elaboratore 303 o smartphone 100 0 210 che aveva effettuato la richiesta, tipicamente attraverso il modulo di connessione network opzionale 121. In questo contesto l‟elaboratore 303 o lo smartphone 100 0 210 invia il messaggio ricevuto attraverso una seconda richiesta operativa 305, atta ad inviare la firma sino al server applicativo 315 in sostituzione del messaggio di conferma 345; la seconda richiesta operativa 305 presenta tra i dati l‟identificativo della prima richiesta operativa 305 sopra descritta. La seconda richiesta operativa 305 comporta un analogo messaggio di richiesta inoltrata 308, ricevuto dal server applicativo 315. Grazie alla presenza, tra i dati di detto messaggio, anche dell‟identificativo della prima richiesta, il server applicativo 315 associa il secondo messaggio al primo che à ̈ in attesa di conferma e i cui dati erano stati registrati, e il processo prosegue come nelle altre forme realizzative. Il messaggio esito destinatario 360 può essere inviato dal server applicativo 315 o sostituito da analogo messaggio inviato attraverso il modulo di connessione wireless opzionale 121 dall‟elaboratore 303 o smartphone 100 o 210, alla ricezione del messaggio esito richiedente 370 relativo alla seconda richiesta operativa 305. In caso di trasmissione sincrona, lo smartphone 210 invia il messaggio di avvenuta ricezione al dispositivo richiedente 303 o 100 o 210. E‟ possibile aggiungere la password ATP anche per pagamenti e sottoscrizioni e può essere digitato sull‟elaboratore 303 o smartphone 100 o 210 insieme agli altri dati della richiesta e confrontato dall‟utente con quello riportato attraverso il messaggio richiesta client 351 sullo smartphone 210.
Inoltre lo smartphone 100 da cui si può effettuare la richiesta può fisicamente coincidere con lo stesso smartphone 210 del destinatario, ma non utilizza direttamente per la fase di richiesta le funzionalità messe a disposizione dalla memoria certificata 200 e dall‟applicazione per la firma elettronica qualificata 220, e interroga l‟applicazione per la firma elettronica qualificata 220 per opera di un‟altra applicazione; in questo contesto i messaggi 351 e 352 possono essere rappresentati ad esempio da trasmissione TCP/IP dove l‟applicazione richiedente invia messaggi 351 all‟applicazione per la firma elettronica qualificata 220 che risponde con i messaggi 352.
Una ulteriore variante alla forma realizzativa sopra descritta prevede, rispetto a quest‟ultima, la possibilità di effettuare in altro modo il calcolo dei dati ottenuti dalla prima richiesta operativa 305 attraverso la risposta esito richiedente 370; l‟alternativa consiste nel non effettuare la prima richiesta operativa 305, e nell‟effettuare tale calcolo ad opera dello smartphone 210 o elaboratore 303 o smartphone 100 del richiedente, attraverso l‟applicazione 220 nel primo caso e attraverso una applicazione differente nel caso di elaboratore 303 o smartphone 100. Nel caso di richiesta d‟accesso, sull‟interfaccia grafica del dispositivo di richiesta à ̈ presente l‟informazione relativa all‟identificativo di sessione eventualmente combinata all‟identificativo di un‟azione da autorizzare e tale informazione à ̈ disponibile al dispositivo stesso ed à ̈ inclusa nell‟informazione in chiaro coincidente con la stringa base o a partire dalla quale calcolare lo hashing da porre uguale alla stringa base.
Tipicamente viene utilizzato il modulo di connessione wireless opzionale 121. In questo contesto per tutti i tipi di richieste l‟identificativo della richiesta operativa 305 e il timestamp vengono definiti dalla applicazione che invia la richiesta, dovendo poi essere validati dal server di front-end 310, come descritto in precedenza nelle altre forme realizzative. In caso di richiesta d‟accesso viene visualizzato sull‟interfaccia grafica del richiedente l‟identificativo della richiesta operativa 305 calcolato. Il dispositivo di richiesta 303 o 100 o 210 richiede la firma sullo smartphone 210 del destinatario attraverso il messaggio 351, riportando nel caso degli accessi tipicamente anche l‟identificativo della sessione. In generale, non solo per gli accessi, in risposta lo smartphone 210 del destinatario invia un messaggio 352 contenente la firma elettronica qualificata, secondo quanto già presentato precedentemente. Il dispositivo di richiesta 303 o 100 o 210 invia dunque una richiesta operativa 305, completa della firma elettronica qualificata ottenuta. Il processo segue quanto già precedentemente esposto, considerando che la firma à ̈ già disponibile al server applicativo 315 col giungere del messaggio di richiesta inoltrata 308, senza necessità di ottenerla attraverso altri messaggi.
Un‟ulteriore forma realizzativa può prevedere la creazione della chiave privata 201 a bordo della memoria certificata 200 e del certificato, prima della fase di sottoscrizione di un contratto da parte di un cliente presso un dealer, in modo da sottoscrivere già tale contratto con firma elettronica qualificata ed evitare al dealer e alla organizzazione per cui lavora la gestione del cartaceo per il contratto stesso e per i documenti successivi scambiati col cliente. Questo può essere l‟ambito di dealer che operano sia come operatori di registrazione per una Autorità di Certificazione sia per conto di un operatore telefonico per il rilascio delle SIM o operano per l‟apertura di un conto corrente bancario per conto di una banca; in ogni caso il cliente può essere il sottoscrittore digitale con firma elettronica qualificata del contratto e di altri eventuali documenti.
Nelle forme realizzative finora descritte à ̈ stato considerato un unico server applicativo 315 per una data tipologia di richiesta e utente appartenente al sistema secondo l‟invenzione. E‟ possibile tuttavia avere più server applicativi per tipologia di richiesta e utente appartenente al sistema secondo l‟invenzione.
Il sistema secondo l‟invenzione prevede normalmente un solo servizio di server di front-end 310, ma potrebbero esservene più d‟uno.
Ad esempio, si può avere un servizio del server di front-end 310 e l‟utente destinatario delle richieste à ̈ ivi registrato. Il server di interfaccia 302 a cui à ̈ collegato il richiedente 300 o il richiedente coincidente con il destinatario 400, à ̈ connesso a tale server di front-end 310. L‟utente destinatario 365 o il destinatario coincidente con il richiedente 400 del sistema secondo l‟invenzione che riceve le richieste à ̈ registrato sul server di front-end 310 con il proprio numero di telefono o identificativo unico e gli indirizzi dei server applicativi a cui l‟utente destinatario à ̈ registrato per ciascuna tipologia di richiesta.
Il server di interfaccia 302, a seguito di una richiesta proveniente dal richiedente (distinto o meno dal destinatario), si può connettere con il server di front-end 310 specificando il server applicativo 315 dell‟utente destinatario da considerare per la transazione, se tale informazione à ̈ nota al server di interfaccia 302 stesso o al richiedente che ha aggiunto tale informazione nella richiesta. Ad esempio, se il server d‟interfaccia à ̈ un sito di home banking, esso conosce l‟indirizzo/reference del server applicativo su cui la banca si basa per gestire ad esempio le richieste di accesso all‟home banking stesso. Se tale informazione non à ̈ nota al richiedente 300 o al server di interfaccia 302, vi sono due possibilità :
- Ã ̈ possibile per il richiedente 300 o il server di interfaccia 302 inviare una richiesta di una tipologia di richiesta operativa 305 particolare di tipo infolista attraverso il server di interfaccia 302 per conoscere la lista dei server applicativi abilitati, conoscendo tale informazione mediante il messaggio esito richiedente 370. La gestione di tali messaggi interessa solo il server di front-end 310 e non si propaga agli altri nodi della rete. Con una successiva richiesta il richiedente e il server di interfaccia possono impostare il server applicativo nella richiesta stessa da inviare al destinatario.
- oppure l‟utente richiedente e il server di interfaccia 302 inviano la richiesta al server di front-end 310 non specificando tale informazione.
Se l‟utente destinatario à ̈ registrato sul server di front-end per più server applicativi per la tipologia di richiesta, viene considerato dal server di front-end il server applicativo 315 contrassegnato, sul server di front-end, come il server applicativo di default relativamente alla tipologia di richiesta considerata e all‟utente considerato. L‟utente, con procedura di registrazione alla rete dedicata può indicare per ogni tipologia di richiesta quale sia il server applicativo di default. Nel caso il server applicativo sia uno solo per la particolare tipologia, esso à ̈ considerato di default.
Nel caso di effettuazione di richieste dalla applicazione per la firma elettronica qualificata 220 con richiedente coincidente con il destinatario, come illustrato ad esempio in figura 5 e 6 Ã ̈ inoltre possibile salvare in locale sulla applicazione multifunzionale 220 stessa la lista dei server applicativi per tipologia, in modo da poter specificare il server applicativo nella richiesta.
Nel caso dei pagamenti eseguiti da richiedente distinto dal destinatario, tipicamente il richiedente 300 non conosce l‟istituto bancario del destinatario 365, né la relativa reference del/dei server applicativo/i 315, ma ne conosce solo il numero di telefono o l‟identificativo all‟interno del sistema secondo l‟invenzione. Pertanto in tal caso tipicamente la richiesta operativa 305 di pagamento non contiene l‟indicazione del server applicativo del destinatario. Il destinatario 365, quindi viene raggiunto da un messaggio di richiesta a base testo 340 relativa al servizio applicativo 315 di default, ossia tipicamente dal servizio applicativo di una delle banche di cui à ̈ cliente.
Nel caso dei pagamenti eseguiti da un utente 400 che à ̈ richiedente e destinatario, come descritto ad esempio con riferimento alle figure 4, 5, 6 e 7, questi può agevolmente specificare il server applicativo 315 da considerare nella richiesta. In tal modo può eseguire il pagamento richiedendo di fatto di operare attraverso una specifica banca, tra le eventuali diverse con cui si à ̈ registrato alla rete dedicata, potendo specificare il server applicativo 315 nella richiesta operativa 305. In caso contrario opera attraverso il server applicativo 315 di default.
Nelle forme realizzative riguardanti la sottoscrizione di documenti, se la richiesta operativa 305 da firmare digitalmente di sottoscrizione di documenti à ̈ effettuata da un richiedente 300 attraverso un server di interfaccia 302 che offre anche il servizio del server applicativo 315, si può facilmente specificare il riferimento del server applicativo 315 nella richiesta di sottoscrizione ad opera del server di interfaccia 302. Ad esempio questo può essere il caso di una richiesta effettuata da un‟azienda ad un proprio responsabile, come destinatario 365, invitato a sottoscrivere una autorizzazione formale e che nel contempo dispone del server applicativo 315. Qualora sia l‟utente destinatario che effettua anche la richiesta facilmente à ̈ a conoscenza della reference del server applicativo 315 o tale reference può essere aggiunta dal server di interfaccia 302. Anche in tal caso ovviamente in assenza di informazioni sul server applicativo à ̈ utilizzato quello di default.
Negli esempi implementativi riguardanti l‟accesso a servizi di rete, l‟utente 400 che à ̈ richiedente e destinatario allo stesso tempo, allo stesso modo facilmente conosce la reference del server applicativo 315 da immettere nella richiesta operativa 305. Più semplicemente, il server di interfaccia 302 che à ̈ specifico di un certo servizio, ricevuta la richiesta generica da parte dell‟utente 400, aggiunge il dato riguardante il server applicativo 315 nella richiesta operativa 305 al server di front-end. Nel caso degli accessi ai servizi di rete, à ̈ possibile rimuovere il concetto di default, nel caso in cui i server applicativi registrati per l‟utente siano più d‟uno nel server di front-end.
I messaggi SMS utilizzati possono essere inviati attraverso Internet in maniera indipendente dai carrier telefonici, ad esempio utilizzando il sistema SKEBBY, oppure possono essere inviati attraverso le loro reti. E‟ comunque necessaria una scheda SIM, corrispondente al numero di telefono dell‟utente, per ricevere i messaggi di richiesta sullo smartphone.
L‟utilizzo di messaggi SMS consente di ricevere una richiesta di conferma sullo smartphone senza dover restare in attesa da parte dell‟utente con possibile traffico dati a pagamento.
In luogo degli SMS possono essere impiegati messaggi e-mail attraverso il modulo di connessione wireless opzionale 121, nel caso l‟utente abbia aderito al sistema con questa opzione, particolarmente utile nel caso di utilizzo di smartphone dotati di meccanismo di push e-mail, come i dispositivi BlackBerry.
Tutti i messaggi possono essere criptati, in particolare i messaggi diretti allo smartphone 210 del sistema possono essere criptati con la chiave pubblica del certificato dell‟utente legato ad un particolare numero di telefono. Infatti il certificato à ̈ noto al server applicativo e alla ricezione del messaggio sullo smartphone à ̈ possibile, per decrittare il messaggio stesso, utilizzare il codice PIN per attivare la chiave privata 201 ed eseguire la decifratura. Potenzialmente la chiave privata 201 di decifratura, la chiave pubblica e il certificato relativi, possono essere diversi da quelli di firma; in tal caso il certificato aggiuntivo à ̈ censito nel database del server applicativo.
Per maggiore sicurezza anche tutti i messaggi, soprattutto ricevuti dallo smartphone 210 ed inviati a questo dal server applicativo 315, possono essere firmati con firma elettronica qualificata eseguita dal server applicativo 315 attraverso un dispositivo di firma massivo e remoto di tipo HSM (Hardware Security Module) certificato secondo quanto richiesto dalle disposizioni nazionali ed internazionali per la firma elettronica qualificata; in tal caso il codice PIN di firma sull‟HSM viene digitato da un responsabile del server applicativo 315 connesso con detto HSM che promuove un processo di firma massiva dei messaggi di richiesta a base testo 340 in uscita; in tal caso l‟applicazione multifunzionale 220 à ̈ dotata del certificato digitale corrispondente alla chiave privata di firma presente sull‟HSM, e al certificato della Certification Authority che lo ha emesso.
Attraverso tale certificato l‟applicazione multifunzionale 220 può verificare la firma ricevuta e validarla come inviata dal server applicativo considerato associato nell‟applicazione multifunzionale al servizio utilizzato.
Anche i messaggi di richiesta client 351 e conferma client 352 possono essere firmati e/o crittati, nonché tutti i messaggi tra gli altri nodi server e client della rete dedicata. In generale il contenuto dei messaggi può essere o firmato o crittato, o prima firmato e poi crittato.
Normalmente nella rete dedicata il certificato di firma e la chiave privata 201 di firma per un dato utente sono unici; lo stesso certificato di firma à ̈ copiato sui server applicativi utilizzati dall‟utente, ma in questo contesto di firma elettronica qualificata, poiché il certificato à ̈ pubblico per definizione e non contiene la chiave privata, ciò non comporta un problema di sicurezza. E‟ possibile anche definire coppie di certificati e chiavi private di firma distinte, in base al server applicativo. In tal caso sullo smartphone sono presenti più chiavi private, da selezionare nel momento dell‟apposizione del codice PIN per la firma.
Una volta eseguita l‟operazione di firma il messaggio inviato dallo smartphone può contenere anche il Serial Number del certificato di firma e indicazione della relativa Certification Authority, estratti dall‟applicazione per la firma elettronica qualificata 220 dalla memoria certificata per consentire un ulteriore controllo da parte del server circa il certificato.
La memoria certificata può essere eventualmente alloggiata in altro lettore connesso allo smartphone, rispetto a quello spesso incorporato con lo smartphone stesso. Il lettore può essere posto ad esempio all‟interno di un guscio che contenga anche lo smartphone o connesso attraverso un‟interfaccia di ingresso e uscita disponibile come il foro per cuffie e microfono. E‟ altresì possibile considerare l‟utilizzo, all‟interno della rete dedicata, di differenti repository per la chiave privata rispetto alla memoria certificata, che siano ad esempio embedded nel telefono mobile, o connessi a questo o che coincidano con la SIM. In contesti ove non sia necessario l‟utilizzo della firma elettronica qualificata ne‟ della assimilata, si possono utilizzare repository per la chiave privata non certificati per la firma elettronica qualificata, algoritmi di hashing differenti da quelli necessari per la firma elettronica qualificata, ed à ̈ possibile evitare un preventivo riconoscimento de visu dell‟utente.
La soluzione qui sopra descritta presenta diversi vantaggi rispetto all‟arte nota.
Il sistema di firma e procedimento di firma secondo l‟invenzione vantaggiosamente permette, grazie all‟utilizzo della memoria certificata, in connessione a un apparato telefonico mobile e a una rete per la firma elettronica qualificata, di proteggere la chiave privata 201 contro la copia e l‟estrazione, e di utilizzare tale chiave privata per la firma elettronica qualificata onde consentire all‟utente di sottoscrivere documenti, disporre pagamenti ed effettuare accessi a servizi informatici, in sicurezza e in mobilità , essendo inoltre protette le informazioni sensibili a livello di server applicativi della rete dedicata, essendo tali server applicativi protetti, ed essendo non sensibili invece le informazioni utilizzate all‟interno della rete dedicata a livello dei server di front-end e server di interfaccia 302 Tramite l‟adozione dell‟algoritmo di firma RSA di tipo asimmetrico e a quanto richiesto per la firma elettronica qualificata si raggiunge un elevato grado di sicurezza, tale da far equiparare legalmente tale firma elettronica alla firma autografa in molte legislazioni nazionali.
La memoria certificata à ̈ vantaggiosamente installata su un supporto rimovibile e non necessita di accordi con gli operatori telefonici per il suo utilizzo, né à ̈ legata necessariamente al circuito delle carte di credito. Il supporto rimovibile ne permette l‟alloggiamento nel telefono mobile, il quale à ̈ configurato per essere connesso tipicamente via SMS (Short Message Service) ad una rete di telecomunicazione dedicata per le operazioni di firma basata su una determinata architettura di componenti server all‟interno dei quali gli utenti del sistema sono registrati. L‟architettura della rete dedicata permette eventualmente l‟utilizzo di altri dispositivi di memorizzazione per contenere la chiave privata.
Vantaggiosamente il sistema fa uso nella maggior parte delle forme implementative di una firma elettronica qualificata in forma detached che non si accompagna nello stesso messaggio alla informazione in chiaro corrispondente per cui non à ̈ ricavabile da parte di un hacker l‟informazione in chiaro corrispondente, ne‟ dati sensibili. Fanno eccezione le forme realizzative ad esempio secondo l‟architettura di figura 6 dove la richiesta operativa viene firmata all‟origine prima del suo invio. In generale sulla rete del sistema di firma proposto non transitano password riutilizzabili, né codici PIN, né numeri di carta di credito in caso di e-commerce.
La firma stessa non può essere copiata e utilizzata nuovamente per richieste differenti: in questo caso le firme elettroniche qualificate utilizzate variano ogni volta poiché anche l‟informazione in chiaro associata cambia ogni volta; essa à ̈ presente sui server applicativi della rete dedicata e consente a questi di verificare la firma ricevuta e autenticare quindi l‟utente firmatario e verificare se la firma à ̈ relativa ad una certa informazione in chiaro o meno.
Naturalmente, fermo restando il principio dell‟invenzione, i particolari di costruzione e le forme di attuazione potranno ampiamente variare rispetto a quanto descritto ed illustrato a puro titolo di esempio, senza per questo uscire dall'ambito della presente invenzione.
E‟ possibile, oltre alla memoria certificata, considerare l‟utilizzo, all‟interno della rete dedicata, di altri mezzi di immagazzinamento, o repository per la chiave privata rispetto alla memoria certificata, che siano ad esempio embedded nel telefono mobile, o che siano a questo connessi, oppure che coincidano con la SIM. In contesti ove non sia necessario l‟utilizzo della firma elettronica qualificata ne‟ della assimilata, si possono utilizzare ad esempio tali repository per la chiave privata non certificati per la firma elettronica qualificata, algoritmi di hashing e cifrature differenti da quelli necessari per la firma elettronica qualificata, evitando eventualmente un preventivo riconoscimento de visu dell‟utente.
Claims (17)
- RIVENDICAZIONI 1. Sistema per la firma elettronica qualificata configurato per scambiare dati con primi mezzi di elaborazione (100; 303; 210) del richiedente configurati per permettere a un richiedente (300, 400) di generare in detto sistema richieste (305) richiedenti una firma elettronica qualificata attraverso detto sistema dirette a un destinatario (365; 400), detto sistema comprendendo secondi mezzi di elaborazione (210) del destinatario (365; 400) configurati per permettere al destinatario (365; 400) della richiesta (305) di apporre una propria firma elettronica qualificata, detti secondi mezzi di elaborazione (210) comprendendo un apparecchio terminale telefonico per la firma elettronica qualificata di tipo mobile, atto a scambiare comunicazioni (340) a base testo su reti di telecomunicazioni mobili in base a un identificativo del destinatario abbonato al servizio telefonico mobile compreso in un Subscriber Identity Module (120) cui à ̈ associato, caratterizzato dal fatto che detti secondi mezzi di elaborazione (210) comprendono mezzi (220) per effettuare firma elettronica qualificata attraverso una memoria certificata (200) comprendente una partizione sicura nella quale à ̈ memorizzata almeno una chiave privata (201), detto sistema per la firma elettronica qualificata comprendendo inoltre una rete di server (302, 310, 315) dedicata per mettere in comunicazione detti primi mezzi di elaborazione (100; 303; 210) del richiedente con detti secondi mezzi di elaborazione (210) del destinatario, comprendente almeno un server di front-end (310) configurato per ricevere e validare la richiesta (305) richiedente firma elettronica qualificata inviata per mezzo di detti primi mezzi di elaborazione (100; 303; 210), uno o più server applicativi (315) configurati per inviare dette comunicazioni a base testo sulla rete telefonica mobile (340) a detto destinatario (365; 400) detto server di front-end (310) essendo configurato per inviare detta richiesta validata (308) a un rispettivo server applicativo (315) in base all’identificativo del destinatario (365; 400) o suo numero di telefono, in base alla tipologia della richiesta (305), detto server applicativo (315) essendo configurato per inoltrare detta richiesta (305) come comunicazione a base testo sulla rete telefonica mobile (340) tramite detto identificativo dell’abbonato del servizio telefonico mobile in detto Subscriber Identity Module (120) a detti secondi mezzi di elaborazione (210), detti secondi mezzi di elaborazione (210) essendo inoltre configurati (220), in particolare tramite un’applicazione software dedicata, per impiegare detta chiave privata (201) in detta memoria certificata (200) e apporre una firma elettronica tramite cifratura di uno hashing di detta comunicazione a base testo sulla rete telefonica mobile (340) o di parti di essa per mezzo di detta chiave privata (201), inviando attraverso un messaggio di conferma (345) detta firma al server applicativo (315).
- 2. Sistema secondo la rivendicazione 1, caratterizzato dal fatto che detto messaggio di conferma (345) Ã ̈ in forma di messaggio di tipo SMS (Short Message System) e detta richiesta inoltrata (308) Ã ̈ inoltrata come comunicazione a base testo sulla rete telefonica mobile (340) in forma di messaggio di tipo SMS.
- 3. Sistema secondo la rivendicazione 1 o 2, caratterizzato dal fatto che detta richiesta (305) richiedente firma elettronica qualificata à ̈ una richiesta di pagamento o una richiesta di sottoscrizione documenti o una richiesta di accesso o disposizione su servizi di rete.
- 4. Sistema secondo la rivendicazione 1 o 2 o 3, caratterizzato dal fatto che detto server di front-end (310) Ã ̈ configurato, in detta operazione di validazione, per aggiungere alla richiesta (305) una parte variabile comprendente almeno un identificativo univoco della richiesta e una marca temporale, o timestamp.
- 5. Sistema secondo una delle rivendicazioni precedenti, caratterizzato dal fatto che l’apparato telefonico mobile (210) à ̈ configurato per mostrare automaticamente sul display (110) la richiesta a base testo (340) ricevuta e per inviare, dopo detta apposizione della firma elettronica, al server applicativo (315) una firma elettronica qualificata separata, o detached, al server applicativo (315) per permettere l’identificazione certificata dell’utente destinatario (365; 400) per mezzo di un certificato di firma presente nel server applicativo (315) al certificato della Certification Authority che lo ha emesso, essendo entrambi i certificati associati a detto utente destinatario (365; 400).
- 6 Sistema secondo la rivendicazioni precedenti, caratterizzato dal fatto che detto almeno un server di front-end (310) comprende un database utenti registrati della rete di server (302, 310, 315) dedicata ed à ̈ configurato per verificare in detto database utenti registrati, la presenza del destinatario (365; 400) e informazioni associate a detto destinatario (365; 400), per instradare la richiesta (305) richiedente firma elettronica qualificata al rispettivo server applicativo (315) del destinatario (365; 400).
- 7. Sistema secondo la rivendicazione 5, caratterizzato dal fatto che detto server applicativo (315) à ̈ configurato per verificare detta firma elettronica qualificata inviata dall’apparato telefonico mobile (210) e attivare operazioni dispositive determinate dalla tipologia della richiesta (305) richiedente firma elettronica qualificata.
- 8. Sistema secondo la rivendicazione 5, caratterizzato dal fatto che detto server applicativo (315), in particolare a seguito di dette operazioni dispositive, à ̈ configurato per aggiornare un corrispondente stato dell’operazione sul server di front-end (310) in base all’identificativo univoco della richiesta operativa (305).
- 9. Sistema secondo una delle rivendicazioni precedenti, caratterizzato dal fatto che anche detti primi mezzi di elaborazione del richiedente sono configurati come detti secondi mezzi di elaborazione (210), comprendendo un apparecchio telefonico di tipo mobile, atto a scambiare comunicazioni a base testo su reti di telecomunicazioni mobili in base a un identificativo dell’abbonato del servizio telefonico mobile compreso in un Subscriber Identity Module (120) cui à ̈ associato e mezzi (220) per leggere una memoria certificata comprendente una partizione sicura nella quale à ̈ memorizzata una chiave privata (201).
- 10. Sistema secondo una delle rivendicazioni precedenti, caratterizzato dal fatto che detti primi mezzi di elaborazione (100; 303; 210) del richiedente corrispondono a detti secondi mezzi di elaborazione (210) del destinatario
- 11. Sistema secondo una delle rivendicazioni precedenti, caratterizzato dal fatto che comprende un elaboratore dotato di mezzi di visualizzazione più ampi dei mezzi di visualizzazione di detto apparecchio terminale telefonico e dal fatto che detta richiesta inoltrata (308) sia inviata anche come messaggio di posta elettronica a un indirizzo accessibile al destinatario, detto messaggio di posta elettronica contenendo informazioni, in particolare un riferimento di indirizzo, per visualizzare uno o più documenti associati a detta richiesta inoltrata (308), in particolare documenti da sottoscrivere, su detti mezzi di visualizzazione più ampi.
- 12. Sistema secondo una delle rivendicazioni precedenti, caratterizzato dal fatto che detto messaggio di conferma (345) oppure il messaggio a base testo (340) o entrambi detti messaggi sono rispettivamente trasmessi e ricevuti in forma di comunicazione wireless tramite un modulo di connessione wireless (121), in particolare come messaggio di posta elettronica o altra comunicazione veicolata su Rete Internet.
- 13. Sistema secondo una delle rivendicazioni precedenti, caratterizzato dal fatto che comprende di impiegare certificati rilasciati da enti associati a detta rete di server (302, 310, 315) dedicata per una procedura di firma elettronica assimilata alla firma elettronica qualificata o una procedura di firma elettronica in generale.
- 14. Sistema una delle rivendicazioni precedenti, caratterizzato dal fatto che detta rete di server dedicata (302, 310, 315) comprende ulteriori mezzi di immagazzinamento di chiave privata, in particolare incorporati o connessi con i secondi mezzi di elaborazione (210) del destinatario o incorporati nel Subscriber Identity Module (120), certificati o non certificati per la firma elettronica qualificata
- 15. Procedimento di firma elettronica qualificata caratterizzato dal fatto di comprendere le operazioni eseguite dal sistema di firma elettronica qualificata secondo una delle rivendicazioni da 1 a 14.
- 16. Procedimento di firma elettronica qualificata secondo la rivendicazione 15 caratterizzato dal fatto di includere inoltre nella richiesta (305) richiedente una firma elettronica qualificata inserita nei primi mezzi di elaborazione (303; 100; 210) una password temporanea (ATP), visualizzare una stringa base in chiaro o come hashing della stringa base e detta password temporanea sui secondi mezzi di elaborazione del destinatario( 400), visualizzare detta stringa base in chiaro o hashing della stringa base e detta password temporanea sui primi mezzi di elaborazione (303; 100; 210) del richiedente, detto procedimento comprendendo in particolare di calcolare a detto server applicativo (315) detta stringa base in chiaro o hashing della stringa base in funzione di informazioni della richiesta (305) richiedente firma elettronica qualificata e di detta password temporanea (ATP), e in particolare inoltre di ulteriori informazioni includenti un identificativo di sessione sul server d’interfaccia (302) corrispondente all’identificativo della richiesta (305).
- 17. Apparecchio terminale telefonico per la firma elettronica qualificata, atto a scambiare comunicazioni a base testo su reti di telecomunicazioni mobili in base a un identificativo dell’abbonato del servizio telefonico mobile compreso in un Subscriber Identity Module (120) cui à ̈ associato, comprendente un sistema operativo e mezzi (220) per leggere una memoria certificata comprendente una partizione sicura nella quale à ̈ memorizzata una chiave privata (201), configurati, in particolare tramite un’applicazione software dedicata eseguita in detto sistema operativo, per impiegare detta chiave privata (201) in detta memoria certificata (200) e apporre una firma elettronica qualificata tramite cifratura a un messaggio di richiesta (340) o parti di esso per mezzo di detta chiave privata (201), adatto a operare con il sistema di firma elettronica qualificata secondo una delle rivendicazioni da 1 a 14 o secondo il procedimento secondo la rivendicazione 15 o 16.
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IT000902A ITTO20110902A1 (it) | 2011-10-10 | 2011-10-10 | Sistema di firma elettronica qualificata, relativo procedimento e apparecchio terminale per la firma elettronica qualificata |
| ES12188046.2T ES2563212T3 (es) | 2011-10-10 | 2012-10-10 | Sistema de firma electrónica reconocida, método asociado y dispositivo de teléfono móvil para una firma electrónica reconocida |
| EP12188046.2A EP2582115B8 (en) | 2011-10-10 | 2012-10-10 | A qualified electronic signature system, associated method and mobile phone device for a qualified electronic signature |
| PL12188046T PL2582115T3 (pl) | 2011-10-10 | 2012-10-10 | System kwalifikowanego podpisu elektronicznego, powiązany sposób i urządzenie końcowe dla kwalifikowanego podpisu elektronicznego |
| HUE12188046A HUE026214T2 (en) | 2011-10-10 | 2012-10-10 | Qualified electronic signature system, associated process and mobile phone device for qualified electronic signature |
| DK12188046.2T DK2582115T3 (en) | 2011-10-10 | 2012-10-10 | Qualified electronic signature system, associated method and mobile phone to qualified, electronic signature |
| HRP20160140T HRP20160140T1 (hr) | 2011-10-10 | 2016-02-08 | Kvalificirani elektronski sustav za potpisivanje, odgovarajući postupak i uređaj mobilnog telefona za kvalificirani elektronski potpis |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IT000902A ITTO20110902A1 (it) | 2011-10-10 | 2011-10-10 | Sistema di firma elettronica qualificata, relativo procedimento e apparecchio terminale per la firma elettronica qualificata |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ITTO20110902A1 true ITTO20110902A1 (it) | 2013-04-11 |
Family
ID=45094148
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| IT000902A ITTO20110902A1 (it) | 2011-10-10 | 2011-10-10 | Sistema di firma elettronica qualificata, relativo procedimento e apparecchio terminale per la firma elettronica qualificata |
Country Status (7)
| Country | Link |
|---|---|
| EP (1) | EP2582115B8 (it) |
| DK (1) | DK2582115T3 (it) |
| ES (1) | ES2563212T3 (it) |
| HR (1) | HRP20160140T1 (it) |
| HU (1) | HUE026214T2 (it) |
| IT (1) | ITTO20110902A1 (it) |
| PL (1) | PL2582115T3 (it) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102013221764A1 (de) * | 2013-10-25 | 2015-04-30 | Bundesdruckerei Gmbh | Verfahren zur Erzeugung einer elektronischen Signatur |
| US11037131B2 (en) | 2013-11-15 | 2021-06-15 | Apple Inc. | Electronic receipts for NFC-based financial transactions |
| US11042846B2 (en) | 2013-11-15 | 2021-06-22 | Apple Inc. | Generating transaction identifiers |
| US11392937B2 (en) * | 2013-11-15 | 2022-07-19 | Apple Inc. | Generating transaction identifiers |
| RU2557005C1 (ru) * | 2014-01-16 | 2015-07-20 | Общество с ограниченной ответственностью "Вай-Фай гид" | Способ обозначения устройства беспроводной связи и машиночитаемый носитель, позволяющий реализовать способ обозначения устройства беспроводной связи |
| BR102014002931A2 (pt) | 2014-02-06 | 2016-05-24 | Rd2Buzz Brasil Consultoria E Internet Ltda | sistema gerador e emissor de código de segurança com garantia de autenticidade e origem do emissor |
| RU2748559C2 (ru) | 2016-04-08 | 2021-05-26 | Петер КОЛАРОВ | Устройство для квалифицированной электронной подписи в форме стилуса и способ его применения |
| RU2637991C1 (ru) * | 2017-04-12 | 2017-12-08 | Общество с ограниченной ответственностью "СМ" | Способ электронной подписи |
| RU2708353C1 (ru) * | 2018-12-28 | 2019-12-05 | Акционерное общество "Лаборатория Касперского" | Система и способ стойкой к атакам проверки ЭЦП файлов |
| CN110569132B (zh) * | 2019-08-29 | 2022-07-12 | 高新兴科技集团股份有限公司 | 电子签名捺印方法、装置及计算机可读存储介质 |
| EP4091085A4 (en) * | 2020-01-17 | 2023-10-04 | Planetway Corporation | DIGITAL SIGNATURE SYSTEM USING RELIABLE SERVERS |
| CN111698225B (zh) * | 2020-05-28 | 2022-08-19 | 国家电网有限公司 | 一种适用于电力调度控制系统的应用服务认证加密方法 |
| US11877218B1 (en) | 2021-07-13 | 2024-01-16 | T-Mobile Usa, Inc. | Multi-factor authentication using biometric and subscriber data systems and methods |
| CN114239080B (zh) * | 2022-02-22 | 2022-07-08 | 麒麟软件有限公司 | 一种基于数字证书的软件多层签名方法及系统 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001049054A1 (en) * | 1999-12-28 | 2001-07-05 | Smarttrust Systems Oy | Digital signature |
-
2011
- 2011-10-10 IT IT000902A patent/ITTO20110902A1/it unknown
-
2012
- 2012-10-10 DK DK12188046.2T patent/DK2582115T3/en active
- 2012-10-10 PL PL12188046T patent/PL2582115T3/pl unknown
- 2012-10-10 ES ES12188046.2T patent/ES2563212T3/es active Active
- 2012-10-10 HU HUE12188046A patent/HUE026214T2/en unknown
- 2012-10-10 EP EP12188046.2A patent/EP2582115B8/en active Active
-
2016
- 2016-02-08 HR HRP20160140T patent/HRP20160140T1/hr unknown
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001049054A1 (en) * | 1999-12-28 | 2001-07-05 | Smarttrust Systems Oy | Digital signature |
Non-Patent Citations (1)
| Title |
|---|
| MARTIN WHITEHEAD: "GSMA Europe response to European Commision consultation on eSignatures and eIdentification", 15 April 2011 (2011-04-15), XP002683918, Retrieved from the Internet <URL:http://ec.europa.eu/information_society/policy/esignature/docs/pub_cons/offline_contrib/gsma.pdf> [retrieved on 20120917] * |
Also Published As
| Publication number | Publication date |
|---|---|
| ES2563212T3 (es) | 2016-03-11 |
| EP2582115A1 (en) | 2013-04-17 |
| EP2582115B8 (en) | 2016-03-16 |
| HUE026214T2 (en) | 2016-05-30 |
| PL2582115T3 (pl) | 2016-06-30 |
| DK2582115T3 (en) | 2016-02-22 |
| EP2582115B1 (en) | 2015-12-09 |
| HRP20160140T1 (hr) | 2016-03-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ITTO20110902A1 (it) | Sistema di firma elettronica qualificata, relativo procedimento e apparecchio terminale per la firma elettronica qualificata | |
| US10158491B2 (en) | Qualified electronic signature system, method and mobile processing terminal for qualified electronic signature | |
| US20230104288A1 (en) | Methods and systems for a digital trust architecture | |
| EP3618394B1 (en) | Data sharing method, client, server, computing device, and storage medium | |
| EP3632034B1 (en) | Methods and systems for ownership verification using blockchain | |
| US10367796B2 (en) | Methods and apparatus for recording a change of authorization state of one or more authorization agents | |
| US8769304B2 (en) | Method and system for fully encrypted repository | |
| US8788811B2 (en) | Server-side key generation for non-token clients | |
| US11949796B1 (en) | Secure digital communications | |
| TWI555353B (zh) | 電子郵件之接收記錄與認證方法 | |
| US11764975B2 (en) | Method for validating a digital user certificate | |
| EP2110981A1 (en) | Personal information managing device for preventing personal information form being falsely altered and preventing personal information from being denied | |
| KR102053993B1 (ko) | 인증서를 이용한 사용자 인증 방법 | |
| EP3343494A1 (en) | Electronic signature of transactions between users and remote providers by use of two-dimensional codes | |
| KR102198153B1 (ko) | 인증서 관리 방법 | |
| KR102296110B1 (ko) | 인증서 관리 방법 | |
| KR20150083178A (ko) | 인증서 관리 방법 | |
| KR102198160B1 (ko) | 인증서 관리 방법 | |
| KR20150083177A (ko) | 인증서 관리 방법 | |
| WO2013062438A2 (ru) | Система и способ осуществления платежных транзакций | |
| KR20150083181A (ko) | 인증서 관리 방법 | |
| KR20150083180A (ko) | 인증서 관리 방법 | |
| KR20150083176A (ko) | 인증서 관리 방법 | |
| KR20150083182A (ko) | 인증서 관리 방법 | |
| KR20150085172A (ko) | 인증서 관리 방법 |