IT202000025771A1 - Metodo per certificare l’autenticità di file digitali generati da un dispositivo di comunicazione - Google Patents

Description

Titolo: ?METODO PER CERTIFICARE L?AUTENTICIT? DI FILE DIGITALI GENERATI DA UN DISPOSITIVO DI COMUNICAZIONE?

DESCRIZIONE

La presente invenzione appartiene al campo del trattamento di file digitali, quali immagini e video. In particolare, la presente invenzione riguarda un metodo per certificare che foto o video generati da un dispositivo di comunicazione elettronico, nonch? screenshot e registrazioni dello schermo, non siano stati in alcun modo modificati.

Sfondo dell?invenzione

Da qualche tempo, in particolare a seguito della diffusione su larga scala di dispositivi di comunicazione mobile che hanno una o pi? fotocamere integrate, in particolare smartphone e tablet, si sta assistendo ad un aumento esponenziale della produzione di file digitali nella forma di immagini e video, con numeri che annualmente si aggirano nell?ordine di miliardi di miliardi di file generati. Tali file digitali possono essere messi in circolazione, ad esempio condivisi con altri dispositivi o diffusi in internet, in particolare tramite i social network, oppure possono rimanere immagazzinati nella libreria di foto e video del dispositivo.

Con la crescita del numero di file prodotti, si sono diffuse anche tecnologie e mezzi per modificare foto e video. Sebbene generalmente i file vengono modificati a scopo di intrattenimento, a scopo illustrativo, o comunque nella maggior parte dei casi con un fine migliorativo, pu? spesso accadere che i file vengano modificati con cattive intenzioni, a scopo di frode o anche con lo scopo di discreditare una persona o un?istituzione.

Ad esempio, una foto scattata da un guidatore a seguito di un incidente pu? essere modificata al fine di enfatizzare o sminuire l?entit? del sinistro davanti alla propria assicurazione. Allo stesso tempo, la rete ? disseminata di foto false, realizzate con programmi di ritocco fotografico e che ritraggono i personaggi in modo da estraniarli dal contesto reale in cui sono state scattate. ? un fenomeno basato sulla crescente diffusione delle cosiddette tecniche deepfake, ovvero software e tecnologie, che si fondano su algoritmi di intelligenza artificiale, in grado di sovrapporre pi? immagini e clip insieme. Spesso i file manipolati hanno un alto livello di attendibilit? e non c?? modo di attestarne la falsit? se non attraverso un preciso confronto con il file originale, che nella maggior parte dei casi non ? disponibile.

Un discorso analogo pu? essere fatto anche quando l?acquisizione riguarda ci? che viene mostrato dallo schermo del dispositivo utilizzato dall?utente, ovvero in caso di screenshot o video-registrazioni dello schermo. Col termine screenshot (in italiano anche schermata, cattura dello schermo o semplicemente cattura), si indica appunto ci? che viene visualizzato in un determinato istante sullo schermo di uno smartphone, di un tablet o di altri dispositivi video. Nonostante la terminologia inglese, ormai anche in italiano si utilizza questa parola per identificare la fotografia istantanea dello schermo di un dispositivo mobile, che poi pu? essere a sua volta trasmessa ad altri dispositivi, condivisa su social network, pubblicata su internet, e cos? via.

Fare uno screenshot o una foto dello schermo di un dispositivo mobile, oppure effettuarne una video-registrazione, sono attivit? consentite pressoch? dalla totalit? dei dispositivi mobili e vengono compiute quotidianamente da quasi tutti, sia per fini personali che in ambito professionale. Analogamente a quanto accade per foto o video standard, anche gli screenshot o le registrazioni dello schermo possono essere modificate.

Data l?enorme diffusione delle modalit? di acquisizione, inevitabilmente anche i file digitali sono entrati a far parte del mondo del diritto, soprattutto per quanto riguarda l?utilizzo di screenshot come prova in sede giudiziale. Essi sono infatti strumenti particolarmente utili a fotografare, ad esempio, conversazioni private fra le parti da produrre in un giudizio, con numerosi campi di applicazioni, quali casi di divorzio, dove si possono acquisire screenshot di una relazione extraconiugale, o ancora processi per stalking, molestie e minaccia, nei quali gli screenshot possono riportare frasi offensive ed ingiuriose delle quali si ? stati vittime.

In questo ambito, l?eventuale contraffazione dello screenshot o la possibile modifica di file digitali attraverso appositi programmi informatici sono opzioni che devono essere sempre tenute in considerazione nel momento in cui tali file arrivano a persone che devono prendere una decisione sulla base di quanto visualizzato. Pertanto ? spesso necessario ricorrere ad una analisi dettagliata di queste immagini, che un occhio umano non ? in grado di effettuare.

Negli ultimi anni sono stati sviluppati diversi sistemi e software, utilizzati anche in ambito legale, in grado di valutare se un file digitale, in particolare foto e video, ha subito modifiche dopo la sua acquisizione. Una breve disamina su tali sistemi ? fatta da Al-Ameen nel suo articolo ?Modern visibility enhancemente and tampering detection tools of digital image forensic: a laconic review? disponibile on-line all?indirizzo:

<https://www.researchgate.net/publication/314079132_Modern_Visibility_Enhanc ement_and_Tampering_Detection_Tools_of_Digital_Image_Forensics_A_Laconic _Review>.

I sistemi attualmente in circolazione permettono, grazie all?utilizzo di tecniche di analisi profonde, di rilevare modifiche effettuate sul file digitale e attestare che un file ? stato alterato. Bisogna tuttavia sottolineare che la mancata rilevazione di modifiche non ? sufficiente a garantire automaticamente che il file ? ?originale?. Tali strumenti, che nella quasi totalit? dei casi vengono eseguiti su dispositivi differenti da quello da cui ? stata scattata la foto o registrato il video, sono pertanto utili a rilevare se, dove e come un file analizzato ? stato modificato, ma proprio dal momento che effettuano analisi a posteriori, non possono in alcun modo garantirne l?autenticit?.

Ad oggi, l?unico modo per effettivamente certificare e autenticare un file digitale rimane quello di ottenere una certificazione da parte di un ente autorizzato oppure da una persona fisica, in particolare un notaio.

Da quanto appena esposto, ? tuttora sentita l?esigenza di un sistema in grado certificare l?autenticit? di un file digitale generato da un dispositivo. Un file digitale che sia stato certificato potrebbe non infatti necessitare in sede legale di ulteriore controlli tramite sistemi specifici.

Sommario dell?invenzione

Scopo della presente invenzione ? pertanto quello di fornire un metodo atto a certificare l?autenticit? di un file digitale generato da un dispositivo elettronico di comunicazione quale uno smartphone, un tablet, dispositivi indossabili o simili.

In particolare, scopo della presente invenzione ? quello di fornire un metodo in grado di verificare che file digitali quali foto, video, screenshot o videoregistrazioni dello schermo siano stati generati dallo stesso dispositivo su cui viene eseguito il metodo e che non siano stati in alcun modo modificati.

Altro scopo della presente invenzione ? quello di fornire un metodo per la certificazione di file digitali generati da dispositivi direttamente abbinati o sincronizzati al dispositivo su cui viene eseguito il metodo, come ad esempio dispositivi indossabili, nonch? altri dispositivi di comunicazione mobile come tablet, smartphone, ecc..

Altro scopo della presente invenzione ? quello di generare un report dell?attivit? di certificazione svolta che sia condivisibile al di fuori del dispositivo.

Altro scopo ancora ? quello di fornire un metodo per certificare praticamente in tempo reale un file digitale, in particolare una registrazione, acquisendolo immediatamente prima dell?avvio del metodo di certificazione.

Questi e altri scopi sono raggiunti da un metodo per certificare e autenticare un file digitale generato da un dispositivo in accordo all?invenzione avente le caratteristiche elencate nella annessa rivendicazione indipendente 1 e da un?applicazione eseguibile da un dispositivo elettronico secondo la rivendicazione 15.

Realizzazioni vantaggiose dell?invenzione appaiono dalle rivendicazioni dipendenti.

Sostanzialmente, la presente invenzione riguarda un metodo per certificare l?autenticit? di uno o pi? file digitali consistenti in foto, videoregistrazioni, screenshot o registrazioni di uno schermo generati da un dispositivo elettronico di comunicazione quale uno smartphone, un tablet, un dispositivo indossabile o simili, o generati da un dispositivo ad esso sincronizzato o direttamente abbinato, il metodo essendo atto ad essere eseguito da un utente tramite detto dispositivo e comprendendo, per ciascun file digitale, le fasi consistenti nel:

- ricevere in ingresso il file digitale;

- determinare la tipologia del file ingresso, in particolare se si tratta di una foto o di un video o di uno screenshot o di una registrazione di uno schermo;

- verificare che il file ? stato generato dal dispositivo su cui viene eseguito detto metodo o da un dispositivo ad esso sincronizzato o direttamente abbinato;

- verificare che il sistema operativo di detto dispositivo non ? stato manomesso;

- verificare che il file non ? stato in alcun modo modificato; e

- consentire all?utente di procedere alla certificazione dell?autenticit? del file solo se tutte le precedenti fasi di verifica hanno avuto esito positivo.

Breve descrizione dei disegni

Ulteriori caratteristiche dell?invenzione risulteranno pi? chiare dalla descrizione dettagliata che segue, riferita ad una sua forma puramente esemplificativa, e quindi non limitativa, di realizzazione illustrata nei disegni annessi, in cui:

la figura 1 ? un?illustrazione schematica esemplificativa dell?ambiente operativo in cui il metodo secondo la presente invenzione viene applicato;

la figura 2 ? un diagramma di flusso mostrante le operazioni eseguite dal metodo secondo la presente invenzione per permettere di certificare e autenticare un file digitale;

la figura 3 ? un?illustrazione schematica esemplificativa di un ambiente operativo implementato in cui il metodo secondo la presente invenzione viene applicato; e

la figura 4 ? un diagramma di flusso mostrante ulteriori operazioni eseguite secondo realizzazioni preferite della presente invenzione.

Descrizione dettagliata dell?invenzione

La presente invenzione sar? ulteriormente descritta in dettaglio con riferimento ai disegni annessi al fine di chiarirne gli scopi, i vantaggi e il funzionamento. Naturalmente i disegni non rappresentano tutte le possibili realizzazioni della presente invenzione, ma solo una parte di esse.

Con riferimento alla figura 1, che ? un?illustrazione a blocchi puramente esemplificativa e in nessun modo limitativa, il metodo di certificazione secondo la presente invenzione ? atto ad essere eseguito da un dispositivo elettronico di comunicazione mobile 11 (da qui in avanti indicato semplicemente come dispositivo), che ? lo stesso dispositivo da cui vengono generati i file digitali 1 da certificare. Il metodo secondo la presente invenzione, che pu? essere eseguito dal dispositivo 11 ad esempio, ma non esclusivamente, tramite un?applicazione A, riceve in ingresso un file digitale 1 e, attraverso il superamento di una serie di verifiche, permette di stabilire che esso ? originale, ovvero proviene direttamente dallo stesso dispositivo 11, ed autentico, ovvero che non ? stato in alcun modo modificato, con la possibilit? di ottenere un certificato 41.

Secondo un aspetto importante della presente invenzione, la verifica dell?originalit? non ? limitata a file digitali 1 generati dal dispositivo 11, ma ? estesa anche a file digitali 1 che sono stati generati da dispositivi 21 direttamente abbinati o sincronizzati al dispositivo 11 su cui viene eseguito il metodo. Questa situazione verr? illustrata in seguito in maggior dettaglio, con riferimento anche alla fig. 3, fermo restando che da qui in avanti, quando si parler? di file generati dal dispositivo 11, si far? riferimento anche a file generati da dispositivi 21 direttamente abbinati o sincronizzati, senza fuoriuscire dallo scopo dell?invenzione.

Il dispositivo di comunicazione 11 pu? essere uno smartphone, un tablet, nonch? un dispositivo indossabile, come ad esempio uno smartwatch (orologio intelligente), o un dispositivo analogo. Un file digitale 1 da certificare consiste invece in una foto o un video generato dalla videocamera integrata nel dispositivo, oppure, in un aspetto preferita dell?invenzione, in uno screenshot o in una registrazione dello schermo del dispositivo 11 o di un dispositivo ad esso sincronizzato o direttamente abbinato 21.

Le operazioni eseguite durante l?esecuzione del metodo secondo la presente invenzione verranno ora descritte in maggiore dettaglio con particolare riferimento al diagramma di flusso illustrato in fig. 2.

Un file digitale 1 da certificare ? ricevuto in ingresso o importato in una fase S10. Il file 1 pu? essere importato dall?utente del dispositivo, ad esempio selezionandolo dalla libreria di foto e video del sistema operativo, oppure pu? essere acquisito direttamente da un?applicazione A che esegue il metodo sul dispositivo 11. In una fase immediatamente successiva S20 si verifica se il file in ingresso 1 appartiene a una delle categorie certificabili, in particolare se si tratta di una foto standard, un video standard, uno screenshot o una registrazione dello schermo.

Dopo averne determinato la tipologia nella fase S20, sul file digitale 1 ricevuto in ingresso vengono effettuate una serie di verifiche. Una fase S30 permette di determinare se il file 1 proviene o meno dallo stesso dispositivo (o da un dispositivo 21 ad esso sincronizzato o direttamente abbinato). In una fase S40 viene effettuato un controllo sullo stato del sistema operativo del dispositivo 11 al fine di verificare che non sia stato manomesso o alterato, e in particolare se sia aggiornato a versioni recenti che non siano gi? state manomesse, mentre in una fase S50 viene verificato che il file non sia stato in alcun modo modificato. Se tutte queste fasi di verifica hanno esito positivo, in una fase S100 ? possibile stabilire che il file 1 ? originale e autentico e il metodo pu? quindi procedere alla certificazione, altrimenti il file 1 non pu? essere certificato o incluso in un report di certificazione (fase S0).

La sequenza delle fasi di verifica S30, S40 e S50 illustrata nel diagramma di flusso di fig. 2 non deve intendersi in un modo rigido, in quanto le verifiche potrebbero essere effettuate anche contemporaneamente o con una sequenza temprale differente da quella illustrata, fermo restando che tutte le tre condizioni di verifica devono essere soddisfatte per poter procedere alla certificazione.

La procedura appena descritta porta quindi a determinare in modo certo se un file digitale 1, consistente in una foto o in un video o in uno screenshot o in una registrazione delle schermo, ? stato generato dallo stesso dispositivo 11 su cui viene eseguito il metodo e se al momento dell?importazione non sia stato in alcun modo modificato. Per comprenderne meglio il funzionamento e gli scopi raggiunti, verranno analizzate le singole fasi, anche per mezzo di realizzazioni esemplificative.

Dopo aver ricevuto un file in ingresso, l?operazione compiuta nella fase S20 permette di determinare se esso rientra in una delle categorie previste per la certificazione. Questa operazione, come alcune di quelle effettuate nelle fasi successive, pu? essere effettuata visualizzando e interpretando le informazioni ?contenute? nel file digitale. Un file digitale, infatti, presenta sia i dati che caratterizzano il contenuto riprodotto, ossia nel caso di un immagine i valori cromatici di ogni singolo pixel, che metadati, ovvero le informazioni associate al file stesso. Tramite l?acquisizione dei metadati ? possibile immediatamente risalire ad informazioni quali la tipologia di file digitale (se ? un file audio, video, ecc?), la risoluzione e le dimensioni nel caso foto e video, eventuali modifiche avvenute sul file e cos? via.

Nella fase di ricezione in ingresso o importazione S10 del file digitale 1 vengono acquisiti, oltre ai metadati associati al file stesso, anche dati e informazioni sul dispositivo 11 in uso e su eventuali dispositivi 21 ad esso abbinati o sincronizzati. A puro titolo di esempio, le seguenti tabelle elencano alcuni dei dati e metadati importati per un dispositivo 11 e per un file digitale 1, rispettivamente. In questo caso non limitativo il file ? uno screenshot importato in un iPhone.

[Tabella 1]

Dati del dispositivo (nel momento dell?acquisizione)

Indirizzo IP

Coordinate GPS

Nome sistema operativo

Versione sistema operativo

Nome del dispositivo al momento dell'acquisizione

Carrier name

Carrier country code

Carrier country iso code (ISO 3166-1)

Carrier mobile network code

Tecnologia di collegamento SIM (i.e.: 3G, 4G, ecc.)

SSID e BSSID wi-fi in uso (se connesso a una rete wi-fi)

Versione applicazione

Modello del dispositivo

Dimensioni schermo (altezza e larghezza in pixel)

Data di generazione dell'acquisizione

[Tabella 2]

Dati del file multimediale

Fingerprint del file

Algoritmo di hashing utilizzato

Dimensioni dello screenshot (altezza e larghezza in pixel)

Apple media type

Apple media subtype

Apple source type

Data di creazione del file

Dopo aver determinato nella fase S20 che il file digitale 1 ricevuto in ingresso ?, ad esempio, uno screenshot, il metodo secondo la presente invenzione verifica (fase S30) se ? stato generato o meno dallo stesso dispositivo 11 su cui viene eseguito confrontando i dati e metadati acquisiti. Opzionalmente, in questa fase ? possibile verificare anche che abbia la stessa dimensione dello schermo del dispositivo 11. Stabilire che il file 1 ? stato effettivamente generato dal dispositivo 11 (o da un dispositivo 21 ad esso direttamente abbinato o sincronizzato) non ? tuttavia sufficiente a garantire che questo sia autentico e quindi non alterato.

La verifica effettuata nella fase S50 ha proprio lo scopo di verificare che il file non sia stato in alcun modo modificato. Vantaggiosamente, anche questa fase pu? essere effettuata andando a verificare i metadati acquisititi al momento della ricezione in ingresso del file 1. In particolare, nei file provenienti da dispositivi dotati di sistema operativo iOS questa informazione ? presente in uno specifico metadato, che esprime sotto forma di collezione di dati (array) tutte le modifiche e le alterazioni al file stesso. La verifica ? quindi volta a controllare che detto array sia vuoto.

Va inoltre notato che tale sistema operativo non permette in alcun modo di modificare i metadati dei file digitali, a meno che non venga alterato o manomesso con una procedura definita nel caso specifico jailbreak (evasione in italiano). Il jailbreak ? sostanzialmente una procedura che permette di rimuovere le restrizioni software imposte dalla casa produttrice, dando possibilit? all?utente di installare software e pacchetti di terze parti, non autorizzati e alternativi a quelli consentiti, che potrebbero quindi permettere di modificare i metadati dei file digitali. Procedure analoghe al jailbreak vengono effettuate anche per gli altri sistemi operativi.

Pu? quindi accadere che un file digitale ricevuto in ingresso, pur avendo superato le verifiche delle fasi S30 e S50, sia stato in realt? modificato, e con esso i suoi metadati. A tal fine, nella fase S40 viene verificato lo stato del sistema operativo, al fine di accertare che non sia stato manomesso (o, con una dicitura inizialmente gergale ma ampiamente utilizzata in ambito tecnico, ?craccato?).

Una modalit? di verifica preferita effettuata nella fase S40 consiste nel verificare la versione attualmente in uso del sistema operativo, nonch? l?ultimo aggiornamento effettuato. Va sottolineato che i produttori chiaramente non vedono di buon occhio lo sblocco dei propri dispositivi e che cercano di contrastare la diffusione di questo fenomeno. In particolare, ogni aggiornamento del sistema operativo iOS corregge le falle che hanno consentito il jailbreak nella versione precedente, facendo perdere anche tutte le applicazioni non ufficiali e le personalizzazioni applicate al sistema. Verificare che un sistema operativo ? aggiornato all?ultima versione significa, pertanto, verificare che non ? manomesso.

In realt? una versione del sistema operativo ?sicura?, ovvero non manomessa, potrebbe non corrispondere necessariamente a quella dell?ultimo aggiornamento disponibile, bens? potrebbe essere estesa anche a versioni con aggiornamenti meno recenti che tuttavia sono in grado di correggere tutti gli effetti di un eventuale jailbreak (o procedure analoghe per altri sistemi). Al fine di verificare che il sistema operativo non sia manomesso, nella fase S50 viene quindi verificato che il sistema operativo sia aggiornato rispetto all?ultima versione ?craccabile?.

Una verifica alternativa o complementare a quella appena esposta potrebbe consistere nel rilevare direttamente tramite l?analisi del file acquisito la presenza sul dispositivo di eventuali procedure di sblocco come il jailbreak.

Da quanto appena esposto, risulta evidente come per poter certificare (fase S100) che foto o video o screenshot o registrazioni dello schermo generati da un dispositivo non siano stati in alcun modo modificati ? necessario che tutte e tre le verifiche delle fasi S30, S40 e S50 diano esito positivo. Al contrario, anche una sola condizione non verificata non permetterebbe di procedere alla certificazione del file (fase S0).

Il metodo appena descritto permette quindi di certificare l?autenticit? di file generati dal dispositivo 11 su cui viene eseguito. Tuttavia, come gi? anticipato, potrebbe essere necessario certificare file che, sebbene non generati direttamente dal dispositivo 11, sono comunque autentici in quanto generati dallo stesso utente mediante un altro dispositivo collegato.

Per ovviare a questa limitazione, un aspetto importante della presente invenzione consente di certificare file digitali generati da uno o pi? dispositivi 21 direttamente abbinati o sincronizzati al dispositivo 11 su cui viene eseguito il metodo. Una tale situazione pu? essere rappresentata dall?utilizzo di un Apple Watch in associazione ad un iPhone, e a livello globale da tutti i dispositivi indossabili (come smartwatch in generale, ma non solo) abbinati in modo univoco, e quindi sincronizzati, a dispositivi di comunicazione.

Ancora pi? in generale, due o pi? dispositivi di comunicazione possono essere abbinati tra di loro in modo da avere i file sempre sincronizzati e condivisi su tutti i dispositivi. Ad esempio, Apple permette di sincronizzare un iPad con iPhone tramite i suoi servizi di condivisione iCloud. In linea di massima, ? quasi sempre possibile sincronizzare due o pi? dispositivi commercializzati dallo stesso produttore che condividono lo stesso metodo di autenticazione, in particolare uno stesso account.

In situazioni simili, un file digitale 1 generato da un dispositivo sincronizzato 21, quale ad esempio uno screenshot preso da uno smartwatch, pu? essere presente sulle librerie del dispositivo principale 11 su cui viene eseguito il metodo di certificazione. Pur non essendo generato direttamente dal dispositivo 11, un tale file ? comunque da considerare ?autentico?, in quanto ? stato generato dallo stesso utente del dispositivo 11, e pu? quindi essere sottoposto al processo di certificazione. La figura 3 ? un?illustrazione schematica illustrativa di tale situazione, a cui nel seguito sar? fatto riferimento per descrivere anche altre operazioni successive alla fase S100.

Chiaramente i metadati associati a un file acquisito da un dispositivo sincronizzato 21 hanno valori differenti da quelli generati dal dispositivo 11, in particolare possono presentare dimensioni e risoluzioni differenti, come nell?esempio di acquisizione di uno screenshot da uno smartwatch. A questo scopo, il metodo secondo l?invenzione, oltre a quanto gi? descritto, prevede di verificare nella fase S30 che il file in ingresso 1 provenga dal dispositivo 11 o da uno dei dispositivi 21 ad esso sincronizzati.

Se quindi tutte le condizioni delle fasi sopra descritte sono state verificate e ed ? stato stabilito (fase S100) che un file 1 ricevuto in ingresso ? ?autentico?, ovvero proveniente direttamente dallo stesso dispositivo, o da un dispositivo sincronizzato, e in alcun modo modificato, il metodo secondo la presente invenzione permette inoltre di generare un report 31 e di ottenere un certificato 41.

La fig. 4 mostra una sequenza di operazioni eseguite dopo la fase S100. In una fase S110 l?utente del dispositivo 11 fornisce un nome con cui catalogare l?acquisizione appena effettuata e in una fase S120 viene calcolato l?hash del file 1 ricevuto in ingresso. Tali operazione possono essere effettuate per un file singolo o per pi? file importati in sequenza durante una medesima acquisizione, dove per acquisizione deve intendersi un?esecuzione del metodo sul dispositivo 11. A questo punto viene creato (fase S130) un report 31 in cui sono contenuti tutti i metadati ottenuti dai file ingresso e dagli hash associati, al fine di stabilirne un?associazione univoca. All?interno del report 31 vengono inserite inoltre anche altre informazioni di natura tecnica, utili ad esempio a spiegare il funzionamento delle tecnologie impiegate.

Un report 31 cos? ottenuto conterrebbe gi? tutte le informazioni sufficienti a definire l?autenticit? dei file ricevuti in ingresso e potrebbe essere utilizzato di per s? in svariate applicazioni. Esso tuttavia, mancando di autenticazione, non presenterebbe i requisisti per essere utilizzato, ad esempio, in sede legale. Al fine di fornire un file certificato utilizzabile in sede legale, o in generale per ottenere un file certificato da esibire nei confronti di terzi, il report 31 e/o i file digitali 1 vengono inviati a un sistema esterno atto a certificarli digitalmente (fase S140).

La fase S140 ha lo scopo di ottenere per i file digitali 1 e/o per il report 31 un certificato 41 la cui validit? ? dimostrabile di fronte a terzi. Ci? pu? essere ottenuto in due modalit? preferite. Una prima modalit? consiste nell?inviare i file digitali 1 e/o il report 31 ad un sistema in grado di applicare una firma digitale, una marca temporale o entrambe. La firma digitale rappresenta un attestato di autenticit? e integrit? di un file informatico, mentre la marca temporale ? il risultato di una specifica procedura che attribuisce un preciso riferimento temporale al file informatico. Un file provvisto di firma digitale e marca temporale pu? quindi fungere da prova verso terzi.

Una seconda modalit? consiste nell?effettuare la certificazione attraverso la blockchain. In entrambi i casi, il risultato ? l?ottenimento, nella fase S150, di un certificato 41 associato ai file digitali 1 e/o al report 31, che ne garantisce l?autenticit? e l?immutabilit?. Il certificato 41 pu? essere generalmente, ma non esclusivamente, nella forma di un file xml.

Dopo aver ottenuto la certificazione, in una fase S200 i file 1 ricevuti in ingresso vengono salvati in una cartella insieme al report 31 generato e al certificato 41 appena ottenuto. La cartella cos? creata ? resa disponibile all?utente del dispositivo 11, anche per un?eventuale condivisione. In una realizzazione opzionale, la cartella contenente tutti i file, il report e i certificati viene salvata nel cloud per garantire la persistenza e la condivisione anche in caso di impossibilit? ad accedere ai file tramite il dispositivo utilizzato. Inoltre, la cartella pu? essere compressa e protetta da password.

Il metodo appena descritto ? in grado di certificare file digitali provenienti da un dispositivo 11 selezionandoli dalla libreria di foto e video del sistema operativo del dispositivo, oppure da librerie condivise, ad esempio tramite iCloud. In questo modo ? possibile certificare anche a una ragionevole distanza di tempo file generati.

In altre realizzazioni, la presente invenzione permette di certificare i file digitali praticamente in tempo reale, ossia file generati subito prima della fase S10 di ricezione in ingresso. Tali realizzazioni si applicano sostanzialmente a video e video-registrazioni dello schermo del dispositivo e permettono di fornire nella fase di verifica S50, in aggiunta o a parziale sostituzione alla verifica sui metadati, una garanzia ulteriore del fatto che il file non ? stato modificato, in particolare per quei sistemi in cui potrebbe essere pi? semplice modificare i metadati associati ai file da certificare.

In tali realizzazioni, il metodo secondo la presente invenzione permette, poco prima della ricezione in ingresso, di applicare a file digitali appena generati uno o pi? codici temporanei univoci (ad esempio una sequenza numerica o alfanumerica, un?immagine, ecc.) che sono validi esclusivamente per una singola sessione di acquisizione e che generalmente hanno una durata limitata. Per questo motivo l?applicazione di uno o pi? codici temporanei univoci ? particolarmente utile a stabilire l?autenticit? di un file.

Di seguito sono illustrati due esempi di realizzazioni in cui un file pu? essere certificato subito dopo essere stato generato.

Esempio 1 ? Certificazione di una registrazione con acquisizione ?esterna? Secondo questa realizzazione, poco prima della fase S10 consistente nel ricevere in ingresso il file digitale da certificare viene eseguita una fase di acquisizione in cui l?utente viene invitato ad avviare la registrazione (video normale o cattura dello schermo) avviando i normali strumenti del sistema (fotocamera del dispositivo o analogo).

Prima di terminare la registrazione, l?utente comunicher? l?intenzione di voler acquisire il file e contestualmente verr? visualizzato un codice temporaneo univoco che caratterizza la sessione di acquisizione, mostrato sia in un formato leggibile dai software, quale ad es. QRcode, codice a barre e simili, sia in un formato testuale, quindi leggibile. Il codice temporaneo univoco in formato leggibile da software e/o in formato testuale viene inoltre inserito nella registrazione che ? in corso di acquisizione.

Da questo momento, l?utente ha a disposizione una finestra temporale limitata (ad esempio trenta secondi o un minuto) per terminare la fase di acquisizione e importare la registrazione. Dopo aver visualizzato i codici e le informazioni, l?utente pu? quindi terminare, attraverso gli strumenti di sistema, la registrazione, che viene salvata nella libreria dei video del dispositivo. A questo punto il file digitale 1 ? pronto per essere importato e ricevuto in ingresso (fase S10).

Dopo aver ricevuto in ingresso il file appena generato, vengono eseguite tutte le fasi di determinazione e verifica gi? descritte (S20, S30, S40, S50). In questa realizzazione, la fase di verifica S50, consistente nel determinare che il file non ? stato in alcun modo modificato, pu? comprendere o essere basata esclusivamente sull?analisi della registrazione importata. La registrazione importata viene analizzata alla ricerca, ad esempio, del QRcode inserito in fase di acquisizione, per comprovare il fatto che il codice temporaneo univoco caratterizzante la sessione di acquisizione sia effettivamente incluso nel file appena acquisito certificando di fatto la autenticit? e la veridicit?.

Verificata la presenza del codice, ? possibile procedere alla certificazione del file nella fase S100 e proseguire con le operazioni gi? descritte. In questa applicazione, i codici temporanei univoci associati possono essere inclusi nel report 31 generato nella fase S130 e quindi certificati.

Esempio 2 ? Certificazione di una registrazione con acquisizione ?interna? In questa realizzazione, prima della fase S10 consistente nel ricevere in ingresso il file digitale da certificare, viene eseguita una fase di acquisizione in cui l?utente viene invitato a effettuare una registrazione (video normale o cattura dello schermo), che viene avviata autonomamente senza che l?utente debba attivare personalmente i normali strumenti del sistema.

L?utente avvia quindi la registrazione ed effettua una ripresa o naviga i contenuti del proprio dispositivo che vuole certificare. Per interrompere la registrazione, l?utente comunicher? l?intenzione di voler acquisire il file e contestualmente verr? visualizzato un codice temporaneo univoco che caratterizza la sessione di acquisizione, mostrato sia in un formato leggibile dai software, quale ad es. QRcode, codice a barre e simili, sia in un formato testuale, quindi leggibile. Il codice temporaneo univoco in formato leggibile da software viene inoltre inserito nella registrazione che ? in corso di acquisizione.

Al termine della fase di acquisizione, il file digitale ? pronto per essere importato e viene automaticamente ricevuto in ingresso (fase S10). A questo punto vengono eseguite tutte le fasi di determinazione e verifica gi? descritte (S20, S30, S40, S50). In questa realizzazione, la fase di verifica S50, consistente nel determinare che il file non ? stato in alcun modificato, pu? comprendere o essere basata esclusivamente sull?analisi della registrazione importata. La registrazione importata viene analizzata alla ricerca, ad esempio, del QRcode inserito in fase di acquisizione, per comprovare il fatto che il codice temporaneo univoco caratterizzante la sessione di acquisizione sia effettivamente incluso nel file appena acquisito certificando di fatto la autenticit? e la veridicit?.

Verificata la presenza del codice, ? possibile procedere alla certificazione del file nella fase S100 e proseguire con le operazioni gi? descritte. Anche in questa applicazione, i codici temporanei univoci associati possono essere inclusi nel report 31 generato nella fase S130 e quindi certificati.

Da quanto appena esposto, appaiono evidenti i vantaggi del metodo secondo l?invenzione, che permette di stabilire in modo certo che un contenuto generato da un dispositivo di comunicazione non ? stato in alcun modo modificato e di ottenere una certificazione che abbia anche valore legale, se previsto dalla normativa vigente.

Naturalmente l?invenzione non ? limitata alle particolari forme di realizzazione precedentemente descritte e illustrate nei disegni annessi, ma ad essa possono essere apportate numerose modifiche di dettaglio alla portata del tecnico del ramo, senza per questo uscire dall?ambito dell?invenzione stessa, definito dalle rivendicazioni annesse.

Claims (15)

RIVENDICAZIONI

1. Metodo per certificare l?autenticit? di uno o pi? file digitali (1) consistenti in foto, videoregistrazioni, screenshot o registrazioni di uno schermo generati da un dispositivo elettronico di comunicazione (11) quale uno smartphone, un tablet, un dispositivo indossabile o simili, o generati da un dispositivo (21) ad esso sincronizzato o direttamente abbinato, il metodo essendo atto ad essere eseguito da un utente tramite detto dispositivo (11) e comprendendo, per ciascun file digitale, le fasi consistenti nel:

- ricevere in ingresso (S10) detto file digitale (1);

- determinare (S20) la tipologia di detto file (1), in particolare se si tratta di una foto o di un video o di uno screenshot o di una registrazione di uno schermo;

- verificare (S30) che detto file (1) ? stato generato dal dispositivo (11) su cui viene eseguito detto metodo o da un dispositivo (21) ad esso sincronizzato o direttamente abbinato;

- verificare (S40) che il sistema operativo di detto dispositivo (11) non ? stato manomesso;

- verificare (S50) che il file (1) non ? stato in alcun modo modificato;

- consentire all?utente di procedere (S100) alla certificazione dell?autenticit? del file (1) solo se tutte le precedenti fasi di verifica (S30, S40, S50) hanno avuto esito positivo.

2. Metodo secondo la rivendicazione 1, in cui nella fase di ricezione in ingresso (S10) vengono acquisiti una serie di metadati associati sia al file digitale (1) importato sia al dispositivo (11) su cui viene eseguito il metodo e/o a dispositivi (21) sincronizzati o direttamente abbinati e dette fasi di determinazione (S20) e verifica (S30, S40) sono effettuate sulla base del controllo dei metadati acquisiti.

3. Metodo secondo la rivendicazione 2, in cui la fase (S50) consistente nel verificare che detto file (1) non ? stato in alcun modo modificato ? basata sulla verifica dei metadati acquisiti nella fase di ricezione in ingresso (S10), in particolare controllando uno specifico metadato in cui viene indicato se il file ? stato modificato.

4. Metodo secondo una delle rivendicazioni precedenti, in cui, dopo aver consentito all?utente di procedere alla certificazione (S100) di uno o pi? file digitali (1), vengono eseguite le fasi consistenti nel:

- fornire, da parte di un utente del dispositivo, un nome ai file per catalogare l?acquisizione (S110);

- calcolare l?hash (S120) dei file (1) in ingresso;

- generare (S130) un report (31) in cui vengono inseriti tutti i metadati relativi ai file digitali in ingresso (1), gli hash calcolati nella fase precedente (S120) e ulteriori informazioni tecniche relative al funzionamento delle tecnologie impiegate.

5. Metodo secondo la rivendicazione 4, comprendente inoltre le fasi consistenti nel:

- inviare (S140) i file (1) ricevuti in ingresso e/o il report (31) generato ad uno strumento di certificazione digitale al fine di garantirne l?immutabilit?; e

- ottenere (S150) un file contenente un certificato digitale (41).

6. Metodo secondo la rivendicazione 5, in cui i file (1) ricevuti in ingresso e/o il report (31) vengono inviati ad un sistema atto ad applicare una firma digitale e/o una marca temporale.

7. Metodo secondo la rivendicazione 5, in cui i file (1) ricevuti in ingresso e/o il report (31) vengono inviati ad un sistema atto a effettuare la certificazione tramite blockchain.

8. Metodo secondo la rivendicazione 5, 6 o 7, comprendente inoltre la fase consistente nel salvare (S200) in una cartella digitale detto uno o pi? file (1) ricevuti in ingresso, il report generato (31) e la certificazione (41) ottenuta, detta cartella essendo resa disponibile per la condivisione da parte dell?utente del dispositivo (11).

9. Metodo secondo la rivendicazione 8, in cui detta cartella comprendente i file in ingresso, il report generato e la certificazione ottenuta viene salvata nel cloud.

10. Metodo secondo la rivendicazione 8 o 9, in cui detta cartella comprendente i file in ingresso, il report generato e la certificazione ottenuta viene compressa e protetta da password.

11. Metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui detta fase di ricezione in ingresso (S10) consiste nell?importare uno o pi? file digitali (1) dalla libreria di foto e video del sistema operativo del dispositivo (11) su cui viene eseguito il metodo o da una libreria condivisa con dispositivi (21) sincronizzati a detto dispositivo (11), ad esempio tramite cloud.

12. Metodo secondo una qualsiasi delle rivendicazioni da 1 a 11, in cui:

- prima di ricevere in ingresso (S10) il file digitale (1), viene avviata una sessione di acquisizione consistente nel generare detto file, in particolare una videoregistrazione o una registrazione dello schermo del dispositivo (11) su cui il metodo viene eseguito, e nell?applicare ad esso un codice temporaneo univoco identificante la sessione di acquisizione in un formato leggibile da software, quale QRcode, codici a barre e simili, e in un formato testuale;

- dopo aver ricevuto il file (1) in ingresso, la fase consistente nel verificare (S50) che non ? stato in alcun modo modificato comprende l?analisi del file (1) acquisito alla ricerca del codice temporaneo univoco in formato leggibile da software applicato durante la sessione di acquisizione; e

- la fase consistente nel verificare (S50) che non ? stato in alcun modo modificato ha esito positivo solo se il file digitale (1) include il codice temporaneo univoco in formato leggibile da software applicato durante la sessione di acquisizione.

13. Metodo secondo la rivendicazione 12, in cui al termine della sessione di acquisizione il file digitale (1) su cui ? applicato detto codice temporaneo univoco viene salvato nella libreria di foto e video del sistema operativo del dispositivo (11) e la fase consistente nel ricevere in ingresso (S10) il file viene avviata dall?utente entro un intervallo temporale limitato.

14. Metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui detta fase consistente nel verificare (S40) che il sistema operativo del dispositivo (11) non ? stato manomesso prevede il controllo della versione e dell?ultimo aggiornamento effettuato sul sistema operativo e un confronto con l?ultima versione che pu? essere manomessa.

15. Applicazione (A) eseguibile da un dispositivo elettronico di comunicazione (11) atta ad eseguire un metodo per certificare l?autenticit? di uno o pi? file digitali (1) secondo una qualsiasi delle rivendicazioni precedenti.