ITTO20130513A1 - Sistema e metodo per il filtraggio di messaggi elettronici - Google Patents

Description

DESCRIZIONE dell’Invenzione Industriale avente per titolo:

SISTEMA E METODO PER IL FILTRAGGIO DI MESSAGGI ELETTRONICI

DESCRIZIONE

La presente invenzione si riferisce ad un sistema e a un metodo per filtrare messaggi elettronici. E' noto, infatti, che la maggior parte degli attacchi informatici ai danni di singoli utenti avviene attraverso servizi di messaggistica tipo posta elettronica, messaggistica istantanea o altro.

Nell'ambito dei servizi elettronici di messaggistica una tecnica molto utilizzata per raggirare gli utenti à ̈ nota con il termine di "phishing". Il phishing à ̈ una metodologia di attacco informatico che consiste nell'invitare un utente (vittima) a fornire dati sensibili (ad esempio numeri di conto bancari, numeri di carte di credito, dati anagrafici riservati, password, ecc.) e nel raccogliere questi dati attraverso un server configurato per ingannare l'utente, preferibilmente attraverso una veste grafica molto simile o identica a quella di un server nel quale l'utente à ̈ solito compiere transazioni che richiedono la fornitura di detti dati sensibili.

Più in dettaglio, un malintenzionato (phisher) spedisce all'utente un messaggio, ad esempio attraverso la posta elettronica (email) e/o un servizio di messaggistica istantaneo (instant messaging), che simula, nella grafica e/o nella formattazione e/o nel contenuto, quello di un'istituzione nota al destinatario, come ad esempio una banca presso cui l'utente ha aperto un conto bancario, un provider di servizi web, un sito di aste online in cui l'utente à ̈ iscritto o altro.

Questo messaggio contiene di solito un avviso riguardante particolari situazioni o problemi che richiedono un intervento sollecito da parte dell'utente, come ad esempio il verificarsi di un grosso addebito sul proprio conto corrente, la scadenza del proprio account attraverso il quale à ̈ possibile compiere transazioni finanziarie, la vincita di un'importante somma di denaro o altro. Tipicamente il messaggio suggerisce all'utente di risolvere, in maniera rapida, questa situazione o problema attraverso uno o più collegamenti ipertestuali che conducono l'utente ad una o più pagine web presenti nel server che, essendo controllato dal malintenzionato, permette la raccolta dei dati sensibili in maniera fraudolenta. Infatti, queste pagine web sono costruite in modo da far credere all'utente di fornire i propri dati a un'istituzione in cui egli ha fiducia (ad es. una banca, una società di spedizioni o altro), quando invece i dati sono raccolti per conto del malintenzionato.

Questi dati sensibili sono successivamente utilizzati dal malintenzionato per commettere atti criminali, ad esempio trasferire somme di denaro dal conto dell'utente oggetto del raggiro a un altro conto, oppure vendere a organizzazioni che utilizzano questi dati a scopo commerciale e/o per creare delle false identità atte a mascherare attività illecite. Lo stato dell'arte mette a disposizione differenti approcci per affrontare il problema del phishing. Molti di questi metodi per filtrare i messaggi sono basati sull'impiego in elaboratori elettronici di programmi informatici che implementano tecniche di riconoscimento e catalogazione del testo dei messaggi (ad esempio attraverso l'impiego di reti neurali appositamente addestrate o altro). Purtroppo queste tecniche manifestano sempre un certo numero di falsi positivi/negativi, ossia alcuni messaggi "normali" (non fraudolenti) vengono catalogati come messaggi fraudolenti, mentre un certo numero di messaggi fraudolenti sono catalogati come messaggi non fraudolenti, non garantendo così un adeguato livello di sicurezza dei dati sensibili dell'utente.

Inoltre, i messaggi fraudolenti spesso contengono delle immagini che rappresentano del testo che, non essendo immediatamente decifrabile da un calcolatore elettronico, ha bisogno di un processo di riconoscimento ottico (OCR). Quest'ultimo procedimento aumenta il carico computazionale dell'elaboratore, diminuendo così il numero di messaggi processabili da esso nell'unità di tempo.

Un ulteriore metodo di filtraggio dei messaggi à ̈ basato sull'impiego della firma digitale che consente un elevato livello di protezione, ma che obbliga il mittente a firmare ogni messaggio con la sua chiave privata prima dell'invio, aumentando così le operazioni da compiere per l’utente, che non sempre à ̈ in grado di procurarsene una e/o à ̈ a conoscenza di questa possibilità. Inoltre essa non à ̈ sempre disponibile come per esempio può avvenire in caso di invio di un messaggio dalla casella di posta elettronica tramite browser web, ovvero nella cosiddetta modalità webmail. Questo problema à ̈ ancor più evidente nel caso in cui le stringhe dei collegamenti ipertestuali contenuti nei messaggi comprendono dei parametri specifici (ad esempio l'identificatore univoco dell'utente), in quanto ciascun messaggio avrà un contenuto (e quindi un hash) diverso da ogni altro messaggio inviato.

Inoltre, à ̈ da evidenziare che la maggior parte dei messaggi inviati all'utente, anche da parte di enti reali che avvertono dell'occorrenza di una situazione particolare (ad esempio la scadenza di una password o altro), sono solitamente trasmessi in chiaro, rendendo così quest'approccio difficile da conciliarsi con gli attuali modi d'impiego della messaggistica, in particolare della posta elettronica, e con le applicazioni che gestiscono tale aspetto. Oltre a ciò, le vittime generalmente non possiedono le capacità per controllare accuratamente se un messaggio in arrivo contiene una firma digitale, e quindi un messaggio inviato da un malintenzionato anche sprovvisto di firma digitale può essere inteso come autentico.

Sono noti sistemi di prevenzione anti-phishing che bloccano l’accesso a collegamenti ipertestuali contenuti in messaggi elettronici in base all'appartenenza o meno del suo mittente a una certa categoria di mittenti, per esempio quello dei mittenti segnalati come indesiderati e/o non affidabili oppure perché in base all’analisi del contenuto del messaggio stesso esso viene considerato non sicuro se proveniente da un mittente sconosciuto. Questi sistemi non funzionano sempre in modo efficace in quanto talvolta detta analisi dà risultati errati. Inoltre essi non tengono conto del fatto che alcuni collegamenti ipertestuali possono essere affidabili se contenuti in messaggi provenienti da un certo mittente, ma non esserlo se contenuti in messaggi provenienti da un altro mittente.

Inoltre à ̈ possibile che l’accesso all’utenza di posta elettronica o di messaggistica istantanea di un certo utente, ritenuto affidabile, cada nelle mani di malintenzionati che possono utilizzarla per inviare messaggi contenenti collegamenti ipertestuali truffaldini. I sistemi anti-phishing noti potrebbero non intercettare questi messaggi contraffatti in quanto provenienti da mittenti ritenuti affidabili mentre invece non lo sono.

In aggiunta esiste la possibilità da parte di soggetti malintenzionati di inviare messaggi di posta elettronica da server non certificati e pubblicamente accessibili, simulandone in tutto e per tutto l’invio da parte di mittenti noti che sono ritenuti affidabili da altre utenze di posta elettronica. Anche in tal caso collegamenti pericolosi possono non essere bloccati dai sistemi anti-phishing noti, comportando per l’utente vittima considerevoli pericoli ai suoi beni e anche alla sua privacy.

La presente invenzione si propone di risolvere questi ed altri problemi, mettendo a disposizione un metodo e un sistema per filtrare messaggi elettronici.

L’idea alla base della presente invenzione à ̈ di verificare se almeno una parte del messaggio ricevuto presenta caratteristiche, ad esempio collegamenti ipertestuali e/o una particolare formattazione del messaggio, che sono state specificate dal mittente del messaggio.

Quest'idea permette di effettuare un filtraggio dei messaggi in maniera rapida ed efficacie, ossia riducendo fortemente la presenza di falsi positivi/negativi ed evitando l'impiego di crittografia asimmetrica. Inoltre, il messaggio può essere controllato senza dover aprire gli eventuali collegamenti ipertestuali presenti in esso.

Ulteriori caratteristiche vantaggiose della presente invenzione sono oggetto delle allegate rivendicazioni.

Queste caratteristiche ed ulteriori vantaggi della presente invenzione risulteranno maggiormente chiari dalla descrizione di un suo esempio di realizzazione mostrato nei disegni annessi, forniti a puro titolo esemplificativo e non limitativo, in cui:

- fig.1 illustra un tipico scenario in cui un utente vittima viene raggirato;

- fig.2 illustra un tipico esempio di messaggio truffaldino inviato alla potenziale vittima; - fig. 3 illustra come il sistema secondo la presente invenzione si inserisce nello scenario di fig.1;

- fig. 4 illustra un diagramma entità-relazione riguardante la struttura di una base dati (database) compresa nel server secondo l'invenzione;

- fig.5 illustra una rappresentazione della base dati secondo il diagramma entità-relazione di fig.4;

- fig. 6 illustra un diagramma di flusso che rappresenta un modo di funzionamento del sistema secondo la presente invenzione;

- fig. 7 illustra una forma di realizzazione dell’invenzione secondo il modello clientserver.

Con riferimento alla fig. 1, uno scenario 0 in cui un utente potenziale vittima può essere raggirato comprende una macchina utente (detta anche macchina client) 1, una macchina ostile 2 controllata da un malintenzionato (detto anche phisher) e un server ostile di raccolta dati 3 che à ̈ a sua volta controllato dalla macchina ostile 2.

Nello scenario 0 il raggiro inizia con una fase di invio messaggio P1, nella quale un messaggio 4 à ̈ inviato all'utente destinatario 1 da parte della macchina ostile 2. Questo messaggio 4 comprende dei riferimenti, ad esempio almeno un collegamento ipertestuale o URL (Uniforme Resource Locator), che permettono al malintenzionato di avviare una fase di raccolta dati P2, ad esempio aprendo una sessione di comunicazione con un web server che risiede nel server ostile di raccolta dati 3 che simula la presenza di un sito Internet autentico e conosciuto all’utente.

Con riferimento anche alla fig. 2, un tipico esempio di messaggio truffaldino 4 simula come mittente le Poste Italiane. Questo messaggio 4 à ̈ congegnato in modo da mostrare come nome del mittente “Poste Italiane†e come indirizzo di posta elettronica di origine “notifica@poste.it†il cui dominio poste.it à ̈ autentico (vedi riferimento 20). Il testo del messaggio contiene un collegamento ipertestuale 25 che in chiaro ha un indirizzo che sembra autentico: “https://www.poste.it/online/personale/login-home.fcc†. Esso infatti appartiene apparentemente al dominio assegnato alle Poste Italiane (poste.it) e inoltre sembra utilizzare come protocollo di comunicazione crittografato l’HTTPS (HyperText Transfer Protocol over Secure Socket Layer), impiegato solitamente su Internet nella raccolta di dati sensibili, che devono essere protetti da attacchi malevoli. In realtà il messaggio à ̈ congegnato in modo da far apparire come URL una pagina del sito delle poste, mentre in realtà l’URL effettivamente presente (http://74.95.34.43/%20/www.poste.it/index.php?MfcISAPICommand=SignInFPP&Usin gSSL=1&email=&userid) attiva una sessione di comunicazione con un server ostile 3 controllato dal phisher su cui à ̈ ospitato un sito Internet fasullo che simula le sembianze del sito autentico delle Poste. Quando l’utente clicca sul collegamento ipertestuale camuffato 25 viene eseguita una finestra di navigazione Internet 28 che simula anche nell'intestazione il sito delle Poste su cui l’utente ha un conto corrente on-line.

Ovviamente la presente invenzione agisce sui collegamenti ipertestuali effettivi e non su quelli apparenti che, in caso di messaggi contraffatti, oltre a differire in genere da quelli effettivi simulano un riferimento a siti sicuri e autentici. Ad esempio in un messaggio formattato mediante il linguaggio di formattazione HTML (Hyper Text Markup Language), la presente invenzione esaminerà (anche) il campo “HREF†dell’etichetta “<A>†, contenente l’indirizzo web al quale verrebbe indirizzato l’utente che dovesse cliccare sul collegamento malevolo.

Durante la fase di raccolta dati P2, l'utente vittima immette dei dati (ad esempio dati sensibili come credenziali di accesso in forma di username e password, numero di conto o altro) nel server ostile di raccolta dati 3, il quale provvederà a memorizzarli localmente e/o a inviarli alla macchina ostile 2 al termine della fase P2. In questo modo la macchina ostile 2 à ̈ in grado di entrare in possesso dei dati sensibili dell'utente vittima, rendendo possibile al malintenzionato cha ha accesso alla macchina ostile 2 l'utilizzo di detti dati per scopi fraudolenti.

È evidente al tecnico del ramo che la macchina ostile 2 e il server ostile di raccolta dati 3 possono essere una singola macchina e non necessariamente due macchine distinte. Inoltre la URL può indirizzare indifferentemente a una pagina di un sito, a un documento o a un file elettronico di qualsiasi tipo (file eseguibile, file compresso, immagine, video, eccetera) o in generale a una qualsiasi risorsa raggiungibile on-line messa a disposizione dal malintenzionato per ragioni truffaldine.

Con riferimento anche alla fig.3, un sistema per filtrare messaggi elettronici 5 comprende almeno un modulo di sicurezza; tale modulo di sicurezza à ̈ preferibilmente un programma informatico o un componente software, preferibilmente un componente software aggiuntivo (plug-in), capace di interagire con dei software di messaggistica e/o di navigazione web (come ad esempio Outlook, Thunderbird, Skype, Internet Explorer, Chrome, Safari o altro) compresi nella macchina utente 1, così che tale modulo riesca ad avere accesso ad almeno una parte di ciascuno dei messaggi ricevuti, in particolare al contenuto e all'indirizzo del mittente e/o al nome del mittente di ciascuno di essi.

Il contenuto à ̈ solitamente una stringa di caratteri, ma può anche essere costituito da immagini, suoni o altro, mentre l'indirizzo del mittente à ̈ una stringa di caratteri che identifica in maniera univoca un certo soggetto che spedisce il messaggio. Nel caso della posta elettronica l'indirizzo del mittente à ̈ formattato secondo gli standard Internet RFC 5321, RFC 5322 e RFC 6531, mentre nel caso di un'applicazione di messaggistica istantanea tipo Skype à ̈ una semplice stringa di caratteri. Il nome del mittente à ̈ generalmente un nome associato all’indirizzo del mittente ed à ̈ composto da una stringa di caratteri (lettere alfabetiche, numeri, caratteri speciali quali “@†,†_†,“-“ e così via) solitamente scelto dall’utente in base a regole predefinite fissate da terzi.

Una volta che il contenuto di almeno uno dei messaggi ricevuti dall'utente à ̈ accessibile al modulo di sicurezza, detto modulo à ̈ configurato per compiere le seguenti fasi:

a. lettura dell'indirizzo del mittente e/o del nome del mittente del messaggio;

b. selezione di una o più parti sensibili del messaggio, preferibilmente dei collegamenti ipertestuali;

c. verifica che le parti sensibili del messaggio selezionate durante la fase b soddisfino le informazioni di validazione specificate da un mittente avente come indirizzo quello letto durante la fase a;

d. comunicazione all'utente dell'esito della verifica effettuata durante la fase c.

Le parti sensibili di un generico messaggio di posta elettronica possono comprendere i collegamenti ipertestuali contenuti al suo interno, ma in combinazione o in alternativa ad essi anche parti del messaggio che non sono direttamente visibili all'utente della macchina utente 1, come ad esempio indirizzi Internet, caratteri invisibili (ad esempio il carattere 255 del codice ASCII), formattazione o altro. In questo modo l'invenzione permette non solo di proteggere l'utente da attacchi informatici compiuti utilizzando la tecnica del "phishing", ma anche di verificare se un messaggio ricevuto à ̈ ben formattato, così da ridurre ulteriormente e vantaggiosamente le possibilità che l'utente malintenzionato riesca a compiere un attacco alterando il contenuto di un messaggio.

Un esempio tipico di alterazione di messaggio à ̈ quello che si chiama "email spoofing", ossia l'alterazione di parti del messaggio di posta elettronica al fine di far credere all'utente che il mittente del messaggio sia una terza persona. Utilizzando il trovato qui descritto, à ̈ possibile, oltre a evitare che l'utente malintenzionato inserisca collegamenti ipertestuali ad un server ostile di raccolta dati 3 sotto il suo controllo, verificare che il messaggio presenti determinate caratteristiche (ad esempio caratteri invisibili in una certa posizione), così da abbassare vantaggiosamente la probabilità che il malintenzionato riesca a compiere le sue azioni ai danni dell'utente della macchina utente 1.

La selezione di almeno una parte sensibile del messaggio ricevuto à ̈ preferibilmente effettuata attraverso l'impiego di un algoritmo di analisi sintattica (parser), che prendendo come ingresso il messaggio, preferibilmente il suo testo, produce in uscita la/le parte/i sensibile/i del messaggio.

Come à ̈ noto al tecnico del ramo, questo algoritmo di analisi sintattica à ̈ preferibilmente costruito/generato partendo da una grammatica che comprende un insieme di espressioni regolari (regular expressions) e, se necessario, anche delle regole di produzione (production rules).

L'esecuzione della fase c. da parte del modulo di sicurezza richiede l'impiego dell'indirizzo e/o del nome del mittente per recuperare e selezionare delle informazioni di validazione specificate dal mittente. Queste informazioni di validazione comprendono preferibilmente una lista di stringhe che identificano domini internet che solitamente ospitano dei contenuti a cui si fa riferimento, attraverso collegamenti ipertestuali, nel testo dei messaggi ricevuti dall'utente della macchina utente 1.

Queste informazioni di validazione possono però comprendere anche altri oggetti in combinazione o in alternativa alla lista di domini Internet, come ad esempio immagini, suoni, dati di formattazione, algoritmi, grammatiche o altro.

Una volta recuperate e selezionate le informazioni di validazione, la/le parte/i sensibile/i del messaggio ricevuto vengono verificate utilizzando dette informazioni di validazione. Nella forma esecutiva preferenziale, la fase c. consiste nel verificare se ciascuno dei collegamenti ipertestuali presenti nel messaggio, preferibilmente di posta elettronica, fa riferimento a un contenuto presente in almeno uno dei domini internet presenti in una lista di domini selezionati in base all'indirizzo del mittente; se tutti i collegamenti ipertestuali soddisfano tale criterio, la verifica ha esito positivo, altrimenti il risultato della verifica à ̈ negativo.

L'esito della verifica effettuata durante la fase c. à ̈ comunicato all'utente durante il passo d. preferibilmente attraverso l'impiego di una segnalazione visiva e/o sonora, come ad esempio evidenziando con un'icona di colore rosso i messaggi la cui verifica ha dato esito negativo, mentre con un'icona di colore verde i messaggi la cui verifica ha dato esito positivo. Se la verifica ha dato esito positivo, i collegamenti ipertestuali saranno preferibilmente disabilitati senza nessun intervento da parte dell’utente, così che detto utente non cada nella truffa messa in atto dal malintenzionato.

È possibile per il tecnico del ramo far comunicare il modulo di sicurezza con l'utente della macchina utente 1 in maniera differente rispetto a quella appena sopra descritta senza, comunque, allontanarsi dagli insegnamenti della presente invenzione.

Nella forma esecutiva preferita, il sistema per filtrare messaggi elettronici 5 comprende un server di verifica 6. Questo server di verifica 6 comprende mezzi per la memorizzazione di dati che servono al corretto funzionamento del sistema 5, ossia ad evitare che l'utente della macchina utente 1 sia esposto al rischio di essere truffato; tali dati che risiedono nel server di verifica 6 comprendono preferibilmente anche le informazioni di validazione.

Inoltre, detto server di verifica 6 può essere contattato dal modulo di sicurezza durante l'esecuzione del passo c, sopra descritto, per mezzo di un collegamento di rete (ad esempio un collegamento Internet/Intranet o altro).

La fig. 7 rappresenta una forma di realizzazione dell’invenzione utilizzante il modello implementativo client – server. In particolare la figura 7a presenta una forma di realizzazione più semplice mentre la figura 7b una più sofisticata. In entrambi i casi il processo inizia all’arrivo di un nuovo messaggio di posta elettronica o di instant messaging 705 sul lato client. Il messaggio viene innanzitutto analizzato dal parser (passo 710) per verificare la presenza nel messaggio 4 di contenuto potenzialmente pericoloso quale le URL (passo di verifica 715). In caso di esito negativo (assenza di URL) viene opzionalmente notificato all’utente tale assenza (passo 725), il messaggio viene ritenuto sicuro e il processo termina. In caso di esito positivo (presenza di almeno una URL nel messaggio) i collegamenti ipertestuali (link) vengono memorizzati e comunicati insieme ai dati identificativi del mittente del messaggio in esame al lato server al passo 720. A questo punto il client si mette in uno stato di attesa di un riscontro da parte del server. Quest’ultimo cerca in una base dati DB la lista delle URL ammesse (la cosiddetta white list) per il mittente identificato nella comunicazione ricevuta dal client (passo 805). Quindi viene verificato al passo 810 se si sono trovate corrispondenze per il mittente del messaggio 4; al passo 820 in caso positivo la lista dei domini Internet ammessi viene estratta dalla base dati DB e comunicata al client, oppure, in caso negativo, viene comunicata l’assenza di corrispondenze trovate o una lista vuota. In una realizzazione semplificata dell’invenzione, il server, a questo punto, termina le operazioni che continuano sul lato client, dove il client si trova al passo 720 in attesa di riscontro.

Al passo 730 viene verificata la comunicazione ricevuta dal server: in caso di lista vuota, cioà ̈ la mancanza nel DB di dati relativi al mittente del messaggio 4, al passo 735 viene notificato all’utente che il mittente à ̈ sconosciuto al sistema anti-phishing e il processo termina. In caso di lista non vuota viene verificato al passo 740 se le URL contenute nel messaggio e memorizzate precedentemente soddisfino i requisiti di sicurezza predefiniti. In genere si richiede che le URL appartengano ai domini Internet o agli indirizzi Internet estratti dal database. In una forma più sofisticata dell’invenzione si può richiedere che le URL presenti nel messaggio, per essere accettati, oltre ad appartenere ai domini specificati nel DB per quel mittente (white list), debbano usare dei protocolli di accesso definiti ammissibili (per esempio uno o più dei protocolli http, https, ftp, smtp, eccetera). In un’altra forma dell’invenzione si può prevedere che la lista ricevuta al passo 720 contenga dei domini Internet che sono associati ad un mittente soltanto simile a quello ricercato e non esattamente uguale. Ad esempio il mittente (fasullo) “Posta Italiana†potrebbe produrre gli stessi risultati del mittente (reale e falsificato) “Poste Italiane†. Al passo di riscontro della verifica 745 si hanno due possibilità: i criteri di sicurezza stabiliti per le URL sono rispettati e, quindi, il messaggio à ̈ ritenuto affidabile oppure no. Se il messaggio 4 à ̈ ritenuto affidabile, al passo 750 i collegamenti ipertestuali vengono attivati o lasciati attivi, l’accesso al messaggio 4 e al suo contenuto viene abilitato e il processo termina.

Nel caso in cui il contenuto del messaggio 4 non sia ritenuto affidabile, si hanno due possibilità di realizzazione dell’invenzione: la prima possibilità à ̈ esemplificata in fig.7a, mentre la seconda in fig. 7b. Facendo ora riferimento alla prima (fig. 7a), il messaggio viene ritenuto non affidabile (passo 755) e al passo successivo 760 i collegamenti non presenti nel DB vengono bloccati oppure viene bloccato l’accesso all’intero messaggio a seconda delle impostazioni di sicurezza attive al momento, dove dette impostazioni di sicurezza possono essere più o meno stringenti.

Nel caso in cui il mittente ricercato non sia esattamente uguale al mittente trovato nel DB ma sia soltanto simile, un ulteriore avviso viene fornito all’utente al fine di indicare tale differenza e richiedere all’utente di effettuare eventualmente ulteriori verifiche. Dopodiché la procedura termina anche sul lato client.

In questa forma di realizzazione dell’invenzione, il client non può influenzare in alcun modo le informazioni presenti nel DB del server. Le sue white list sono sotto l’esclusivo controllo del server e del suo amministratore, che può decidere le politiche di formazione e aggiornamento dei record presenti (aggiunte, cancellazioni e modifiche).

Nella seconda forma di realizzazione illustrata in fig. 7b dell’invenzione, al passo 765 il client comunica al server le URL considerate sospette, ovvero quelle che non hanno soddisfatto la verifica del passo 745, e si mette in uno stato di attesa di un riscontro da parte del lato server sulla loro attendibilità. Quest’ultimo, riceve la lista suddetta e la memorizza (passo 825), quindi verifica la loro attendibilità al passo 830. Esistono svariati modi noti al tecnico del ramo per effettuare tale verifica. Per esempio si possono consultare delle banche dati contenenti la lista dei domini e/o delle URL che sono state segnalate come non affidabili o pericolose (black list), ovvero consultarne delle altre indicanti la lista dei domini e/o delle URL che sono considerate note e affidabili (white list). Al passo 835 si controlla l’esito della verifica 830; se tutti i collegamenti ipertestuali presenti sono affidabili essi vengono aggiunti alla white list del mittente (passo 845), in caso contrario viene concluso (passo 840) che il messaggio non à ̈ affidabile e che vi potrebbe essere un uso fraudolento dell’utenza del mittente (casella di posta elettronica o utenza Skype).

In entrambi i casi l’esito della verifica 830 viene comunicata al client in attesa al passo 765, che a questo punto controlla se le URL sospette sono state tutte ritenute attendibili o meno (passo 770) e il processo termina. In caso positivo il messaggio viene ritenuto attendibile e ne viene abilitato l’accesso da parte dell’utente (passo 750). In caso contrario l’accesso ai collegamenti ipertestuali sospetti o all’intero messaggio vengono bloccati a secondo delle politiche di sicurezza impostate (passo 760) e il processo termina.

La forma di realizzazione dell’invenzione utilizzante l’approccio client-server non deve essere intesa in forma limitativa. Esso costituisce un modo, non l’unico, di realizzare l’invenzione. In via alternativa le funzioni svolte dal client e dal server possono essere svolte invece da un unico processo host residente sulla stessa macchina; in tal caso, per esempio, i blocchi 805-820 di fig.7a sarebbero eseguiti sequenzialmente tra i blocchi 720 e 730; inoltre gli scambi di dati tra client e server si ridurrebbero a una sequenza di memorizzazione e lettura di dati all’interno dello stesso processo.

In una delle forme di realizzazione dell’invenzione il client può risiedere in una macchina client d’utente 1 e il server può risiedere in un server di verifica 6. Il tecnico del ramo comprende però che client e server non devono necessariamente essere residenti in due macchine differenti; essi possono essere due processi eseguiti sulla stessa macchina e scambiare dati localmente, per esempio attraverso una porta Internet TCP/IP. È quindi possibile per il tecnico del ramo che il server di verifica 6 possa coincidere con la macchina client d’utente 1 senza comunque allontanarsi dagli insegnamenti della presente invenzione.

Per macchina client si intende un dispositivo di elaborazione dati provvisto di un processore in grado di processare dati digitali con l’ausilio di una memoria in cui memorizzarli, nonché di ricevere messaggi tramite una interfaccia fisica di comunicazione (per esempio una scheda di rete Ethernet, modulo Wi-Fi della famiglia degli standard IEEE 802.11, eccetera), nonché di accettare richieste di accesso a messaggi tramite delle unità di input (tastiera, schermi a tocco, mouse, eccetera) e di riprodurre il contenuto di collegamenti ipertestuali contenuti nei messaggi a un utente mediante delle unità di output (per esempio schermo, altoparlanti, eccetera). Inoltre la macchina client contiene moduli software che permettono al dispositivo di utilizzare le unità e ai moduli suddetti di funzionare secondo le modalità descritte per la presente invenzione. In generale, quindi, si può trattare per esempio di un PC desktop o portatile, uno smart phone, un tablet e apparati simili.

Per macchina server si intende un dispositivo di elaborazione dati (computer o calcolatore) provvisto perlomeno di un processore in grado di processare dati digitali con l’ausilio di una memoria in cui memorizzare i dati di una base dati, nonché di scambiare dati con la macchina client suddetta attraverso un qualsiasi canale di comunicazione. La macchina server può coincidere o meno con quella client in quanto comprende un sottoinsieme delle componenti di quest’ultima. In generale essa può avere una potenza di calcolo e capacità di memorizzazione adeguate a svolgere i compiti del processo server. Il tecnico del ramo può decidere la migliore forma di realizzazione dell’invenzione in forma di host unico, di modello client-server a macchine separate o a macchine unificate in base alle caratteristiche in termini di potenza di calcolo e capacità di memoria dei dispositivi da mettere al sicuro e anche del modello di gestione della sicurezza, centralizzato o distribuito, che intende impiegare.

E’ possibile combinare la presente invenzione con altre procedure di controllo della attendibilità del contenuto dei messaggi. Per esempio à ̈ possibile escludere l’intera procedura di controllo secondo la presente invenzione a una certa categoria di messaggi ritenuti sicuri, come per esempio la posta certificata. In questo caso a monte della verifica 705 di figura 7 viene verificato se il messaggio appartiene alla categoria suddetta e la sequenza di operazioni da 710 in poi viene eseguita solo in caso di esito negativo.

Con riferimento anche alla fig. 4, il server di verifica 6 può comprendere la base dati o database DB, preferibilmente di tipo relazionale, a oggetti o di altro tipo.

La base dati à ̈ realizzata preferibilmente partendo da uno schema 61 progettato per un'applicazione del trovato in un contesto di prevenzione dell'attività di phising; tale schema 61 comprende una relazione che a sua volta comprende due attributi: 'nome_mittente' e 'domino_affidabile'. Entrambi questi attributi hanno cardinalità uno a molti, così che a ogni mittente possa essere associato più di un 'nome_mittente' e più di un 'dominio_affidabile'.

Con riferimento anche a fig. 5, à ̈ possibile vedere come lo schema 61 può essere implementato su una base dati di tipo relazionale impiegando due tabelle distinte: la prima denominata mittenti e la seconda denominata domini_affidabili. La tabella mittente comprende le colonne ID e nome che assieme costituiscono una chiave della tabella, mentre la tabella dominio comprende le colonne ID e URL che assieme anch'esse costituiscono una chiave di detta tabella. Inoltre, al fine di assicurare l'integrità della base dati, à ̈ presente un vincolo d'integrità referenziale sulla colonna ID della tabella domini_affidabili verso la colonna ID della tabella mittenti.

Il database così creato può essere aggiornato da un amministratore o direttamente dai mittenti che vogliono beneficiare del sistema 5 attraverso Internet o altro mezzo di comunicazione.

Al fine di soddisfare al meglio i requisiti della specifica applicazione, Ã ̈ possibile per il tecnico del ramo utilizzare una base dati di tipo diverso e/o con un differente schema rispetto a quello sopra descritto senza, comunque, allontanarsi dagli insegnamenti della presente invenzione.

Più in generale, quando questo server 6 à ̈ contattato dal modulo di sicurezza per compiere la fase c sopra descritta, il server 5 esegue almeno le seguenti fasi:

e. ricezione dell'indirizzo e/o del nome del mittente del messaggio da parte del modulo di sicurezza;

f. selezione delle informazioni di validazione specificate dal mittente.

La fase e. può essere preferibilmente effettuata attraverso l'impiego del protollo HTTP o altro protocollo ben noto al tecnico del ramo, mentre la fase f. può essere effettuata per esempio eseguendo la seguente interrogazione SQL:

SELECT da.URL

FROM mittenti AS m, domini_affidabili AS da

WHERE m.ID = da.ID AND m.nome = ?

dove con il carattere '?' si identifica l'indirizzo del mittente e/o nome del mittente ricevuto durante la fase e. Inoltre, la fase f. può prevedere una ricerca più estesa del mittente, ad esempio per individuare quelle stringhe di caratteri che di poco differiscono dal mittente ricercato, ossia che hanno al massimo un numero prefissato di caratteri differenti rispetto a quelli di un nome del mittente archiviato in detta base dati (DB), così da ridurre il numero di falsi negativi dovuti a variazioni intenzionali o meno del mittente indicato nel messaggio ricevuto. A titolo di esempio si consideri il mittente fasullo “Posta Italiana†che potrebbe indurre l’utente a pensare che si tratti del mittente reale “Poste Italiane†. In questo caso la ricerca effettuata dal server 6 potrebbe produrre gli stessi risultati attesi dalla ricerca di “Poste Italiane†. E’ quindi possibile prevedere che la lista inviata al client nel punto 820 contenga, oltre ai domini affidabili, anche i corrispondenti dati del mittente selezionato che potrebbe essere di poco differente da quello inizialmente ricercato.

Con riferimento anche alla fig. 6, una possibile modalità di funzionamento, più generale di quelle sopra descritte, del sistema per filtrare messaggi elettronici 5 à ̈ rappresentata attraverso una macchina a stati finiti; tale macchina a stati finiti può essere implementata dal modulo di sicurezza compreso nella macchina client d’utente 1 ed eventualmente in parte anche dal server di verifica 6 e comprende i seguenti stati:

− uno stato di lettura S1, in cui il modulo di sicurezza legge l'indirizzo e/o il nome del mittente e seleziona una o più parti sensibili di un messaggio ricevuto eseguendo le fasi a. e b. sopra descritte;

− uno stato di richiesta S2, in cui il modulo di sicurezza effettua un interrogazione alla base dati utilizzando almeno l'indirizzo e/o nome del mittente eseguendo o facendo eseguire al server di verifica 6 le fasi e. ed f.;

− uno stato di elusione verifiche S3, in cui il modulo di sicurezza non effettua alcuna verifica delle parti sensibili del messaggio ricevuto, poiché l'indirizzo e/o nome del mittente non à ̈ associabile a nessun dato nella base dati DB;

− uno stato di lettura risultati S4, in cui il modulo di sicurezza e/o il server di verifica 6 legge i risultati dell'interrogazione eseguita verso la base dati, dove detti risultati costituiscono le informazioni di validazione che sono necessarie a verificare le parti sensibili del messaggio ricevuto, e confronta ciascuna parte sensibile del messaggio con ciascuna delle informazioni di validazione eseguendo la fase c.;

− uno stato di notifica risultati S5, in cui il modulo di sicurezza comunica l'esito del confronto eseguito nel passo 4 eseguendo la fase d.

È da notare che gli stati S2 e S4 sono compresi nell'esecuzione della fase c. da parte del modulo di sicurezza.

Quando un messaggio 4 viene ricevuto dalla macchina utente 1, il sistema 5 entra nello stato di lettura S1, dopodiché esegue un’interrogazione verso l'opportuna base dati DB entrando nello stato di richiesta S2. Se l'esecuzione dell'interrogazione non produce risultati (occorrenze), il sistema 5 notifica all’utente che l’indirizzo e/o nome del mittente non à ̈ presente nel database DB (fase S3) e poi termina la sua esecuzione, mentre se sono presenti risultati, il sistema 5 entra nello stato di lettura risultati S4 e poi comunica all'utente della macchina utente 1 i risultati della verifica entrando nello stato di notifica risultati S5, per poi terminare la propria esecuzione.

I risultati della verifica comprendono, oltre ai dati del mittente (nome e/o indirizzo) o ad un suo identificativo noto al terminale client, l’insieme dei domini Internet e/o delle URL attendibili che il messaggio proveniente dal mittente identificato dai dati suddetti può contenere in quanto ritenuti sicuri. In via opzionale per determinati o tutti i domini o le URL appartenenti a un dominio possono essere specificati anche i protocolli di accesso consentiti: per esempio per la URL “www.poste.it/bancoposta.login.asp†può essere specificato in un qualsiasi modo che essa può essere contenuta nel messaggio di quel mittente solo tramite il protocollo HTTPS per cui la URL deve iniziare con la stringa “https://†. Se così non à ̈, il collegamento ipertestuale viene ritenuto pericoloso e quindi bloccato.

In una prima variante della forma esecutiva preferita del sistema 5 appena descritta, un modulo di sicurezza (simile a quello sopra descritto) invia le parti sensibili del messaggio ricevuto ad un server di verifica (simile al server di verifica 6 appena descritto) durante l'esecuzione del passo c. In questo modo il server di verifica à ̈ a conoscenza non solo dell'indirizzo e/o nome del mittente, ma anche delle parti sensibili, preferibilmente dei collegamenti ipertestuali (hyperlink) del messaggio ricevuto da quel mittente, così da essere vantaggiosamente in grado di capire se ci sono dei tentativi di truffa (phishing) in atto ai danni dell'utente della macchina utente 1 e della persona o dell'istituzione a cui corrisponde l'indirizzo del mittente. Accentrando queste informazioni all'interno del server di verifica à ̈ possibile vantaggiosamente configurare detto server per avvertire la persona o l'istituzione a cui corrisponde l'indirizzo del mittente e/o le autorità di pubblica sicurezza, come ad esempio il Centro nazionale anticrimine informatico per la protezione delle infrastrutture critiche (CNAIPIC) o altro ente preposto, che c'à ̈ almeno un tentativo di truffa in atto.

L'accentramento di questo tipo di informazioni consente di avere vantaggiosamente un miglior livello di supervisione, in quanto si riesce ad analizzare un numero maggiore di messaggi e non solo quelli ricevuti da un singolo utente.

In una seconda variante, à ̈ possibile che siano presenti più basi dati e/o più server di verifica 6 e che il modulo di sicurezza, eseguendo il passo c, selezioni la base dati da interrogare in base alle informazioni contenute in essa e/o la base dati più aggiornata. Questa selezione può essere compiuta preferibilmente in base ad almeno parte dell'indirizzo del mittente, ad esempio il contenitore ("@yahoo.it", "gmail.com", ecc.), o altro.

In una terza variante, à ̈ possibile che le informazioni di validazione specificate dal mittente comprendano solo parte di un collegamento ipertestuale (ad esempio un prefisso tipo "http://poste.it/user="), in quanto à ̈ oggi molto diffuso l'utilizzo dei parametri. In questo modo si evita vantaggiosamente al mittente (che vuole beneficiare del sistema oggetto dell'invenzione) di fornire una lunga lista di collegamenti ipertestuali che contengono elementi ripetuti.

In una quarta variante della presente invenzione, à ̈ possibile al passo 720 analizzare le immagini contenute nel messaggio in forma di file grafico incorporato (e non di URL a un'immagine residente su un sito remoto) per estrarre delle informazioni in grado di individuarle, cioà ̈ delle firme digitali quali per esempio signatures, features o key points, e inviarle al server per l’analisi in sostituzione o in aggiunta all'indirizzo e/o nome del mittente. Il database DB potrebbe comprendere, oltre all’attributo 'nome_mittente', un ulteriore attributo †̃key_points’ comprendente le firme digitali quali features o key points di loghi, marchi, ed immagini note di domini affidabili. Questo attributo ha cardinalità uno a molti, così che a ogni attributo †̃key_points’ può essere associato più di un 'nome_mittente' e più di un 'dominio_affidabile'. Il server, una volta che ha ricevuto le informazioni dal client, cerca nel proprio database DB la lista delle URL ammesse (la cosiddetta white list) per il key_point identificato nella comunicazione ricevuta dal client. Quindi viene verificato se si sono trovate corrispondenze per le key points estratte dal messaggio; in caso positivo la lista dei domini Internet ammessi viene estratta dal database DB e comunicata al client che provvederà a bloccare le URL come descritto al passo 760, oppure, in caso negativo, viene comunicata l’assenza di corrispondenze trovate.

Come à ̈ noto al tecnico del ramo, l’estrazione delle features o key points può avvenire con algoritmi di elaborazione delle immagini, mentre la comparazione delle features o key points nel server può avvenire con le tecniche note usate per il riconoscimento delle immagini. Questa ulteriore variante ha il vantaggio di individuare i messaggi che in modo fraudolento contengono immagini, loghi, e marchi di siti attendibili al fine di ingannare la potenziale vittima.

In un'ulteriore variante, il mittente può anche specificare il periodo di validità della durata delle informazioni di validazione, così da vantaggiosamente aumentare il livello di sicurezza del sistema oggetto dell'invenzione.

In una ulteriore variante il database DB può anche comprendere una lista di domini e/o collegamenti ipertestuali ritenuti sicuri e affidabili a prescindere dal mittente, cioà ̈ valida per tutti i mittenti per risparmiare capacità di memoria. Se un certo messaggio contiene solo contenuti compresi in questa lista universale, il suo contenuto à ̈ ritenuto sicuro a prescindere dal mittente.

Numerose sono dunque le varianti possibili, senza per questo uscire dai principi di novità insiti nell'idea inventiva. È chiaro all’esperto che, nell’attuazione pratica, le forme dei dettagli illustrati possono essere diverse e che essi possono essere sostituiti con elementi tecnicamente equivalenti. È dunque facilmente comprensibile che la presente invenzione non à ̈ limitata agli esempi illustrativi descritti, ma à ̈ suscettibile di varie modifiche, perfezionamenti, sostituzioni di parti e di elementi equivalenti senza scostarsi dall’idea inventiva di base, come specificato nelle seguenti rivendicazioni.

Claims (26)

1. RIVENDICAZIONI 1. Metodo per filtrare almeno un messaggio elettronico (4) ricevuto da una macchina utente (1), in cui detto messaggio (4) comprende dati identificativi del suo mittente, comprendente una fase di a. leggere i dati identificativi di detto mittente, caratterizzato dal fatto di comprendere anche le fasi di b. individuare e memorizzare contenuti potenzialmente pericolosi di detto messaggio, c. verificare se i contenuti potenzialmente pericolosi di cui alla fase b. soddisfino delle condizioni di validazione specifiche per il mittente avente i dati identificativi letti durante la fase a., d. attivare o disattivare l’accesso a detti contenuti potenzialmente pericolosi in base all'esito della verifica effettuata durante la fase c.
2. 2. Metodo secondo la rivendicazione 1, in cui i contenuti potenzialmente pericolosi comprendono almeno un collegamento ipertestuale presente nel messaggio (4).
3. 3. Metodo secondo la rivendicazione 2, in cui le condizioni di validazione comprendono l’appartenenza dei collegamenti ipertestuali o loro parti a dei domini Internet ritenuti affidabili, e in cui la verifica effettuata nel corso della fase c. ha esito positivo se ciascuno dei collegamenti ipertestuali o loro parti presenti nel messaggio fa riferimento a un contenuto presente in almeno uno di detti domini Internet ritenuti affidabili, in caso contrario la verifica ha esito negativo.
4. 4. Metodo secondo una qualsiasi delle rivendicazioni da 1 a 3, in cui se l’esito della fase c. à ̈ negativo l’accesso ai contenuti potenzialmente pericolosi del messaggio viene bloccato.
5. 5. Metodo secondo una qualsiasi delle rivendicazioni da 1 a 4, in cui se l’esito della fase c. à ̈ positivo viene consentito all’utente della macchina d’utente (1) l’accesso ai contenuti potenzialmente pericolosi.
6. 6. Metodo secondo la rivendicazione 3, in cui i domini Internet ritenuti affidabili vengono letti da una base dati (DB) comprendente un’associazione tra i dati identificativi di un mittente e i domini Internet ritenuti affidabili se contenuti in un messaggio proveniente dal mittente avente detti dati identificativi.
7. 7. Metodo secondo una qualsiasi delle rivendicazioni da 1 a 6, in cui in caso di esito negativo della verifica della fase c. viene compiuta una verifica di attendibilità dei contenuti potenzialmente pericolosi e, se detta verifica di attendibilità ha esito positivo, dette condizioni di validazione vengono aggiornate per detto mittente, mentre, in caso di esito negativo, l’accesso ai contenuti potenzialmente pericolosi del messaggio viene bloccato.
8. 8. Metodo secondo la rivendicazione 6, in cui detta base dati (DB) risiede in una macchina server (6) che riceve da detta macchina d’utente (1) i dati identificativi del mittente, in caso di presenza di associazioni relative a detto mittente detta macchina server (6) estrae da detta base dati (DB) la lista dei domini Internet ritenuti affidabili e la comunica a detta macchina d’utente (1), e in caso di assenza di dette associazioni detta macchina server (6) ne notifica l’assenza a detta macchina d’utente (1).
9. 9. Metodo secondo la rivendicazione 8, in cui la macchina client (1) comunica a detta macchina server (6), assieme ai dati identificativi del mittente, anche i contenuti potenzialmente pericolosi di detto messaggio (4).
10. 10. Metodo secondo una qualsiasi delle rivendicazioni da 8 a 9, in cui la macchina client (1) Ã ̈ fisicamente distinta dalla macchina server (6).
11. 11. Metodo secondo la rivendicazione 6, in cui detti dati identificativi di mittente comprendono un nome e/o un indirizzo e in cui le condizioni di validazione specifiche per il mittente avente i dati identificativi letti durante la fase a., vengono applicate anche a messaggi provenienti da mittenti identificati tramite un nome che ha al massimo un numero prefissato di caratteri differenti rispetto a quelli di un nome del mittente archiviato in detta base dati (DB).
12. 12. Metodo secondo la rivendicazione 6, in cui detti contenuti potenzialmente dannosi comprendono immagini contenute in detto messaggio (4), per ciascuna immagine presente in detto messaggio (4) viene ottenuta una firma digitale in grado di identificare detta immagine, detta base dati (DB) comprende un campo per memorizzare almeno una firma digitale che identifica almeno una immagine ritenuta affidabile contenuta in un messaggio proveniente dal mittente avente detti dati identificativi, e le condizioni di validazione comprendono l’appartenenza delle firme digitali ricavate da detto messaggio (4) a quelle contenute in detto campo della base dati (DB).
13. 13. Sistema (5) per filtrare almeno un messaggio elettronico (4) comprendente una macchina utente (1) che comprende un modulo di sicurezza, in cui detto modulo di sicurezza ha accesso ad almeno un messaggio (4) inviato da un mittente identificato nel messaggio mediante propri dati identificativi e ricevuto da detta macchina utente (1), in cui detto modulo di sicurezza à ̈ configurato a a. leggere i dati identificativi di detto mittente, caratterizzato dal fatto di essere configurato a b. individuare e memorizzare contenuti potenzialmente pericolosi di detto messaggio (4), c. verificare se i contenuti potenzialmente pericolosi di cui alla fase b. soddisfino delle condizioni di validazione specifiche per il mittente avente i dati identificativi letti durante la fase a., d. attivare o disattivare l’accesso a detti contenuti potenzialmente pericolosi in base all'esito della verifica effettuata durante la fase c.
14. 14. Sistema secondo la rivendicazione 13, in cui i contenuti potenzialmente pericolosi comprendono almeno un collegamento ipertestuale presente nel messaggio (4).
15. 15. Sistema secondo la rivendicazione 14, in cui le condizioni di validazione comprendono l’appartenenza dei collegamenti ipertestuali o loro parti a dei domini Internet ritenuti affidabili, e in cui la verifica effettuata nel corso della fase c. ha esito positivo se ciascuno dei collegamenti ipertestuali o loro parti presenti nel messaggio fa riferimento a un contenuto presente in almeno uno di detti domini Internet ritenuti affidabili, in caso contrario detta verifica ha esito negativo.
16. 16. Sistema secondo una qualsiasi delle rivendicazioni da 13 a 15, in cui se l’esito della fase c. à ̈ negativo l’accesso ai contenuti potenzialmente pericolosi del messaggio viene bloccato.
17. 17. Sistema secondo una qualsiasi delle rivendicazioni da 13 a 16, in cui se l’esito della fase c. à ̈ positivo viene consentito all’utente della macchina d’utente (1) l’accesso ai contenuti potenzialmente pericolosi.
18. 18. Sistema secondo la rivendicazione 15, in cui i domini Internet ritenuti affidabili vengono letti da una base dati (DB) comprendente un’associazione tra i dati identificativi di un mittente e i domini Internet ritenuti affidabili se contenuti in un messaggio proveniente dal mittente avente detti dati identificativi.
19. 19. Sistema secondo una qualsiasi delle rivendicazioni da 13 a 18, in cui in caso di esito negativo della verifica della fase c viene compiuta una verifica di attendibilità dei contenuti potenzialmente pericolosi e, se detta verifica di attendibilità ha esito positivo, dette condizioni di validazione vengono aggiornate per detto mittente, mentre, in caso di esito negativo di detta verifica di attendibilità, l’accesso ai contenuti potenzialmente pericolosi del messaggio (4) viene bloccato.
20. 20. Sistema secondo la rivendicazione 18, in cui detta base dati (DB) risiede in una macchina server (6) che riceve da detta macchina d’utente (1) i dati identificativi del mittente, in caso di presenza di associazioni relative a detto mittente detta macchina server (6) estrae da detta base dati (DB) la lista dei domini Internet ritenuti affidabili e la comunica a detta macchina d’utente (1), e in caso di assenza di dette associazioni detta macchina server (6) ne notifica l’assenza a detta macchina d’utente (1).
21. 21. Sistema secondo la rivendicazione 20, in cui la macchina client (1) comunica a detta macchina server (6), assieme ai dati identificativi del mittente, anche i contenuti potenzialmente pericolosi di detto messaggio (4).
22. 22. Sistema secondo una qualsiasi delle rivendicazioni 20 o 21, in cui la macchina client (1) Ã ̈ fisicamente distinta dalla macchina server (6).
23. 23. Sistema secondo la rivendicazione 18, in cui detti dati identificativi di mittente comprendono un nome e/o un indirizzo e in cui le condizioni di validazione specifiche per il mittente avente i dati identificativi letti durante la fase a, vengono applicate anche a messaggi provenienti da mittenti identificati da un nome che ha al massimo un numero prefissato di caratteri differenti rispetto a quelli di un nome del mittente archiviato in detta base dati (DB).
24. 24. Sistema secondo la rivendicazione 18, in cui detti contenuti potenzialmente dannosi comprendono immagini contenute in detto messaggio (4), per ciascuna immagine presente in detto messaggio (4) viene ottenuta una firma digitale in grado di identificare detta immagine, detta base dati (DB) comprende un campo per memorizzare almeno una firma digitale che identifica almeno una immagine ritenuta affidabile contenuta in un messaggio proveniente dal mittente avente detti dati identificativi, e le condizioni di validazione comprendono l’appartenenza delle firme digitali ricavate da detto messaggio (4) a quelle contenute in detto campo della base dati (DB).
25. 25. Programma di computer che comprende mezzi di codifica di programma atti a realizzare il metodo come una qualsiasi delle rivendicazioni da 1 a 12, quando detto programma à ̈ fatto eseguire su di un computer.
26. 26. Mezzi leggibili da computer comprendenti un programma registrato, detti mezzi leggibili da computer comprendendo mezzi di codifica di programma atti a realizzare il metodo come una qualsiasi delle rivendicazioni da 1 a 12, quando detto programma à ̈ fatto eseguire su di un computer.