Voglio con questo articolo arrivare a spiegare come la posta elettronica sia uno strumento potentissimo se utilizzata con la combinazione di questi tre elementi :
--- le giuste procedure di sicurezza;
--- la firma digitale (che nell'ordinamento italiano, è definita come una firma qualificata basata sulla tecnologia della crittografia a chiavi asimmetriche);
--- la posta certificata.
Nota: uso nel testo evidenziare con rettangolino verde gli argomenti per rendere facile la lettura degli argomenti o saltare da un passo all'altro dell'articolo.
Si "dovrebbe" arrivare ad una certezza molto alta (la probabilità è obbligatoria dati alcune "falle" del sistema come "collisioni delle funzioni hashing/scambio chiavi nella firma digitale/sicurezza posta certificata/attendibilità ente certificatore: esporremo più avanti tali problemi)
--- dell'identità del mittente,
--- dell'integrità del messaggio,
--- della sicurezza del canale di comunicazione (crittografia asimmetrica),
--- della "certezza della ricezione / invio" ossia del timestamp certo di invio / ricezione (posta elettronica certificata),
--- dei dispositivi di crittografia
a cui si aggiunge, una volta entrati nel meccanismo della crittografia asimmetrica e della firma digitale, un uso esteso di tali strumenti anche a documenti personali (fogli elettronici, immagini, files in generale) di rilevante valore.
fonte immagine: http://www.ngsservice.net/it/cat/posta-elettronica
Facciamo il punto della situazione.
Parleremo di:
-- crittografia simmetrica
-- crittografia asimmetrica
-- chiave pubblica
-- chiave privata
-- funzioni di hashing
-- firma digitale
-- firma elettronica
-- posta elettronica crittografata
-- certificatori
-- posta elettronica certificata
e ciliegina sulla torta ... :
-- combinazione di firma digitale, crittografia asimmetrica dei messaggi, e posta elettronica certificata.
fonte immagine: www.lucapacini.it
-- riferimenti normativi italiani
-- riferimenti normativi europei
Cercherò di essere breve e il più semplice possibile dato che molte sono le informazioni che si trovano in rete.
La crittografia:
tecnica per rendere intellegibili i documenti a chi non dispone di relativa chiave (algoritmo)
e può essere di tipo:
- simmetrica
- asimmetrica
Crittografia simmetrica
La metafora del forziere torna bene.
Abbiamo degli oggetti di valore da spedire ad un nostro fidato amico.
Mettiamo tutti gli oggetti di valore in un forziere.
Chiudiamo con un lucchetto di acciaio il nostro forziere con una sola chiave che possediamo solo noi.
Spediamo il nostro forziere con la certezza che nessuno può aprirlo se non con la chiave in nostro possesso.
fonte immagine: http://www.magichousetortona.it/
Quando sarà giunto a destinazione come farà il nostro amico ad aprirlo ?
Dovrà avere naturalmente a disposizione una copia dell'unica chiave che apre il forziere e che è al momento in nostro possesso.
Come ben si può osservare sorge un grosso problema per questo tipo di scambio.
E' necessario che i due soggetti che comunicano tra di loro abbiamo preso un accordo prima di stabilire la comunicazione.
Sia il mittente che il destinatario dovrebbero avere una identica copia dell'unica chiave che apre il forziere.
Quindi si devono incontrare di persona, scambiarsi le chiavi e poi iniziare la comunicazione.
Questa in breve la crittografia simmetrica.
Il forziere rappresenta il messaggio cifrato, mentre il contenuto del forziere, (gli oggetti di valore) rappresentano il nostro messaggio in chiaro che vogliamo proteggere da occhi indiscreti.
La chiave che usiamo per chiudere il forziere rappresenta l'algoritmo di cifratura simmetrico.
Andiamo avanti.
Torneremo su questo punto a breve.
Introduciamo la crittografia asimmetrica.
Per ovviare a questo problema è stata introdotta la crittografia asimmetrica.
Questo tipo di crittografia prevede l uso di due chiavi (algoritmi).
Per non fare troppa confusione definiamo bene il concetto di chiave.
Le chiavi in crittografia (e quindi in informatica) sono degli algoritmi di cifratura / decrittazione.
Una chiave può essere usata in entrambe le operazioni, sia di cifratura del messaggio sia di decrittazione.
Nella crittografia asimmetrica abbiamo due chiavi:
- una chiave privata
- una chiave pubblica
La chiave privata viene utilizzata solo ed esclusivamente dal proprietario
La chiave pubblica invece è di dominio pubblico.
Se un mio amico vuole inviarmi un forziere con dentro degli oggetti preziosi io gli fornirò la mia chiave pubblica.
Lui con la sua chiave privata firmerà il messaggio (una sorta di sigillo in ceralacca sul foglio con il messaggio) e con la mia chiave pubblica renderà intellegibile il messaggio (chiusura del forziere).
Inoltre per permettermi di leggere la firma (cioè di riconoscere il sigillo in ceralacca), che lui ha apposto al messaggio nel forziere, mi invierà la sua chiave pubblica insieme al forziere.
Facciamo alcune considerazioni.
Il forziere giunge a destinazione, cioè a me.
Il forziere è stato chiuso con la mia chiave pubblica abbinata alla mia chiave privata.
Quando viene chiuso un forziere con la mia chiave pubblica, io resterò da quel momento in poi, l'unica persona che potrà aprire il forziere perché possessore della unica chiave privata abbinata a quella chiave pubblica.
La mia chiave privata mi permetterà di aprire il forziere e di visionare il contenuto del messaggio.
Problema : ma come sono sicuro che il messaggio sia stato inviato dal mio amico ?
Con la chiave pubblica del mio amico posso verificare l'integrità del messaggio ma non il mittente.
Per rendere più chiaro quanto esposto fin'ora ecco una immagine che sintetizza (in parte) bene:
fonte immagine: http://upload.wikimedia.org/wikipedia/commons/e/e6/Crittografia_asimmetrica_schema.png
Riassumendo per la crittografia asimmetrica:
Sia il mittente che il destinatario hanno due chiavi K_pub (chiave pubblica e distribuibile ai propri interlocutori e con chiunque voglia comunicare) e K_priv (chiave privata, strettamente personale e incedibile a terzi, da proteggere sempre da chiunque).
Mittente: Alice (K_pub_A,K_priv_A)
Destinatario: Bob (K_pub_B,K_priv_B)
Come Alice invia un messaggio ?
Alice -> vuole inviare un messaggio cifrato a Bob in modo che nessuno riesca a leggerne il contenuto.
Ecco le operazioni che svolge Alice prima dell'invio.
Prima di scrivere il messaggio si procura la chiave pubblica di Bob (e su questo punto torneremo perche sta proprio qui una delle falle del sistema di crittografia asimmetrica)
Hashing(Msg_Alice) = Stringa alfanumerica univoca (= hash_str)
K_priv_A (hash_str) = impronta_di_Alice
In cosa consiste l'hashing ?
L’hash viene generato da una funzione matematica (algoritmo di hashing) che è una operazione One-Way e consiste in una stringa alfanumerica univoca.
Alice con questa operazione mette la propria "impronta digitale" al messaggio.
In questa procedura di Alice siamo difronte alla cosiddetta "Firma digitale" o meglio anche definita come "particolare tipo di firma elettronica qualificata".
Riporto per completezza la definizione data dal CNIPA (ad oggi DigitPA):
firma digitale :
"E’ un particolare tipo di firma elettronica qualificata basata su un sistema di chiavi asimmetriche a coppia, una pubblica e una privata, che consente al titolare tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l’integrità di un documento informatico o di un insieme di
documenti informatici "
Mentre per firma elettronica qualificata:
"la firma elettronica ottenuta attraverso una procedura informatica che garantisce la connessione univoca al firmatario, creata con mezzi sui quali il firmatario può conservare un controllo esclusivo e collegata ai dati ai quali si riferisce in modo da consentire di rilevare se i dati stessi siano stati successivamente modificati, che sia basata su un certificato qualificato e realizzata mediante un dispositivo sicuro per la creazione della firma"
fonte immagine : http://www.thepopuli.it/2009/11/segreto-di-stato-i-rifiuti-e-la-sicurezza-nazionale/
Il messaggio appartiene sicuramente ad Alice (concetto di non ripudiabilità, autenticità ed integrità del messaggio).
K_pub_B (Msg_alice, impronta_di_Alice) = msg_cifrato_pronto
fonte immagine: http://www.areanetworking.it
Anche su questo punto torneremo (Problema : come facciamo ad essere sicuri di avere in nostro possesso la chiave pubblica K_pub_B di Bob ?)
Dopo questa ultima operazione di Alice, se siamo sicuri di aver utilizzato la chiave pubblica giusta di Bob (K_pub_B), solo Bob con la sua chiave privata (K_priv_B) sarà in grado di leggere il contenuto del messaggio.
Per permettere a Bob di verificare l'integrità del messaggio e che è Alice il reale mittente del messaggio, Alice invia insieme al messaggio la sua chiave pubblica (K_pub_A).
Come riceve il messaggio Bob ?
Con una operazione di "reverse" Bob potra leggere il messaggio ed esserne sicuro della provenienza.
Nei dettagli, Bob:
K_priv_B (msg_cifrato_pronto) = Msg_alice, impronta_di_Alice
Poi:
K_pub_A (impronta_di_Alice) = hash_str
Hashing(Msg_Alice) = Stringa alfanumerica univoca (= hash_str)
E confronta le hash_string del messaggio cosi ottenute per verificare che corrispondano.
In tal modo Bob saprà che il messaggio è giunto integro e che il mittente è Alice.
Il problema della crittografia asimmetrica (conosciuta come crittografia a chiave pubblica) sta nello scambio delle chiavi pubbliche e nell'identificare con certezza il nostro interlocutore.
Una tecnica di riconoscimento dell'interlocutore potrebbe essere la seguente:
Prendiamo sempre Alice (A) e Bob (B) come soggetti interessati alla comunicazione.
Ipotesi iniziali:
il problema di Alice è di inviare la sua chiave pubblica a Bob.
Bob non conosce la chiave pubblica di Alice e nemmeno le sue intenzioni di voler comunicare.
Alice preleva la chiave di Bob (si fa inviare la chiave pubblica da Bob) e crea un impronta della sua chiave pubblica.
Fa la seguente operazione:
Hashing (K_pub_A) = stringa_alfanumerica = hash_K_pub_A
con la chiave pubblica di Bob:
K_priv_A(hash_K_pub__A) = impronta_K_pub_A
e invia il messaggio a Bob allegando la sua chiave pubblica (K_pub_A), cioè invia:
msg_A = (impronta_K_pub_A, K_pub_A)
Pero Alice non si ferma qui.
Vuole rendere il messaggio intellegibile a chiunque e fa una ulteriore operazione:
K_pub_B (msg_A) = K_pub_B (impronta_K_pub_A, K_pub_A) = msg_cifrato_con_K_pub_B
in questo modo sa che l'unico che può leggere il messaggio (dovrebbe, e qui il condizionale è di obbligo) essere Bob.
Usiamo il condizionale perché sorge un problema : come fa Alice a monte di tutte le operazioni ad essere effettivamente "sicura al 100 %" che la chiave pubblica che sta usando per stabilire un canale di comunicazione con Bob sia "effettivamente di Bob" ?
Cioè, come fa ad essere sicura che sia stato "Bob" ad inviargli la chiave pubblica (K_pub_B) ?
fonte immagine : http://jannessinho.wordpress.com/2009/04/03/un-giro-di-chiave-per-il-weekend/
La risposta è che Alice non può saperlo con assoluta certezza.
(Problema del "man in th middle")
fonte immagine : http://www.e.govt.nz/services/authentication/library/docs/authentication-bpf/chapter5.html
Non può in alcun modo saperlo.
L'unico modo per avere questa certezza consiste nello scambio diretto tra i due delle loro chiavi pubbliche.
I due, Alice e Bob, dovrebbero incontrarsi di persona per scambiarsi le chiavi in tutta sicurezza e certezza.
Ma a questo punto ritorneremmo al problema della crittografia simmetrica.
Un grosso problema è che nella realtà non possiamo incontrare di persona tutti i nostri interlocutori di posta elettronica.
Per risolvere questo problema dello scambio delle chiavi pubbliche tra due interlocutori è stata introdotta la figura "super partes" di enti governativi (e non governativi) detti "certificatori" (variabili come enti di controllo super partes a seconda dello stato/nazione e delle norme vigenti che regolano le comunicazioni a crittografia asimmetrica).
(Principio della "delega di fiducia")
In Italia esiste il CNIPA (Centro Nazionale per l'Informatica nella Pubblica Amministrazione) di cui vi riporto l'attuale sito ufficiale:
(vecchio sito http://www.cnipa.gov.it/site/it-IT/ )
E nuovo sito dopo aver cambiato nome in DigitPA (Digitalizzazione nella Pubblica Amministrazione) :
http://www.digitpa.gov.it/
Il CNIPA (o meglio ad oggi DigitPA), è un ente governativo italiano che "opera presso la Presidenza del Consiglio dei Ministri per l’attuazione delle politiche formulate, a nome del Governo dal Ministro per le Riforme e le Innovazioni nella Pubblica Amministrazione, con la missione di contribuire alla creazione di valore per cittadini e imprese da parte della Pubblica Amministrazione, fornendo a questa supporto nell’uso innovativo dell’informatica e, più in generale, dell’ICT (Information and Communication Technology)".
Fonte: http://www.cnipa.gov.it/site/it-IT/Il_Centro_Nazionale/Chi_siamo/
Fonte: http://www.digitpa.gov.it/digitpa/funzioni
Perché chiamati "certificatori" ?
fonte immagine: http://robertoscano.info/random-bits/cnipa-ministro-brunetta-raddrizzi-la-situazione/
Perché tutti gli utenti che vogliono usare la "firma digitale" devono rendere univoca la corrispondenza tra la "propria chiave pubblica" e la "propria identità".
E di stabilire la veridicità di questa corrispondenza se ne occupa proprio l'ente certificatore.
L'ente certificatore compie le seguenti azioni:
---- rilascia un "attestato di autenticità della chiave pubblica" a chi ne fa espressa richiesta;
---- mantiene una copia delle chiavi pubbliche delle persone che ne hanno fatto richiesta e che ha riconosciuto come valide;
---- permette la verifica delle chiavi pubbliche degli enti, persone giuridiche e fisiche che hanno richiesto la certificazione.
Un esempio proprio da Poste italiane s.p.a:
http://postecert.poste.it/firmadigitale/acquista.shtml
http://postecert.poste.it/firmadigitale/privati.shtml
https://postecert.poste.it/verificatore/servletverificatorep7m?tipoOp=10
Ecco un link interessante con l'elenco pubblico dei certificatori riconosciuti dal CNIPA:
"Elenco pubblico dei certificatori, data ultimo aggiornamento 16 giugno 2010"
http://www.cnipa.gov.it/site/it-IT/Attivit%C3%A0/Firma_digitale/Certificatori_accreditati/Elenco_certificatori_di_firma_digitale/
Sempre dal sito del CNIPA:
"il certificatore garantisce l’identità dei soggetti che utilizzano la firma digitale ed è soggetto a attività di vigilanza da parte del CNIPA ... "
Fonte: http://www.cnipa.gov.it/site/it-IT/Attivit%C3%A0/Firma_digitale/Certificatori_accreditati/Elenco_certificatori_di_firma_digitale/Informazioni_per_l%27utente/
Perché tutta questa introduzione ?
Perché proprio questo meccanismo è alla base della posta elettronica certificata e della firma digitale.
Due potentissimi strumenti che utilizzati in modo congiunto danno come risultato un'ottima affidabilità della posta elettronica.
Una volta ottenuta la certificazione della propria chiave pubblica (K_pub_A e K_pub_B) tramite richiesta all'ente certificatore, i nostri due interlocutori potranno essere sicuri ognuno dell'identità dell'altro.
E qui inizia la vera sicurezza della posta elettronica.
Dopo aver scambiato le chiavi, nulla vieta ai nostri interlocutori (nel nostro caso Alice e Bob) di scambiarsi le chiavi private di un algoritmo simmetrico e di comunicare con un algoritmo a crittografia simmetrica.
Ma qui sorge ancora un altro grosso problema degli algoritmi simmetrici.
Sono ottimi per crittografare ma per ogni nostro interlocutore dovremmo avere una chiave privata diversa.
Le conclusioni sono che all'aumentare de numero dei nostri interlocutori aumenterebbe la procedura per lo scambio (prima si utilizza algoritmo di crittografia asimmetrico con chiave pubblica per stabilire la sicurezza del canale di comunicazione, rendendo dispendiosa in termini di tempo lo scambio di informazioni) e poi si procede allo scambio della chiave privata dell'algoritmo di cifratura simmetrico.
Ci ritroveremmo con un "portachiavi" (per algoritmi a cifratura simmetrica) proporzionale ai nostri contatti in rubrica.
Per tale motivo si preferisce utilizzare algoritmi cifratura asimmetrica nella maggioranza dei casi.
La certificazione avviene in modo simile all'operazione di Alice nel firmare digitalmente la propria chiave pubblica da inviare a Bob.
Solo che nel nostro caso l'ente certificatore appone la propria firma (dopo aver verificato la nostra richiesta di "certificazione" e la nostra effettiva identità") alla nostra chiave pubblica, generando anche i relativi certificati di revoca associati alla nostra chiave.
(per approfondire, vedere in fondo all'articolo i relativi link e documenti consigliati come letture)
Vediamo un esempio pratico seguendo una ottima guida di M. Pascucci on line (link al suo blog personale: http://www.ismprofessional.net/pascucci/), con Gnu PG.
fonte immagine : http://www.gnupg.org/misc/logo-contest.html
Questo link è ottimo.
Inutile aggiungere altro per l'uso di Gpg.
Fonte delle informazioni : http://www.gnupg.org/index.it.html
Fonte delle informazioni: http://www.ismprofessional.net/pascucci/documenti/gpg/ar01s02.html
Riporto in sintesi i principali comandi (da Bash Linux) con una breve descrizione sotto per capire cosa fanno, e cito sin da qui la fonte web delle informazioni estratte:
(Fonte : http://www.poluz.net/tutorial:comandi-gpg)
(Fonte : http://www.gnupg.org/howtos/it/GPGMiniHowto_big.html)
gpg --version
Versione attualmente in uso
gpg --gen-key
Creare una chiave
gpg --export [UID]
Esportare una chiave
gpg --import [nomefile]
Importare una chiave
gpg --list-keys
Lista delle chiavi presenti nella cartella delle chiavi
--------------------------------------------
Versione attuale
akillex@ulissex:~$ gpg --version
--------------------------------------------
gpg (GnuPG) 1.4.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Algoritmi supportati:
A chiave pubblica: RSA, RSA-E, RSA-S, ELG-E, DSA
Cifrari: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compressione: Non compresso, ZIP, ZLIB, BZIP2
akillex@ulissex:~$
Elenco rapido e veloce
-----------------------------------
visualizzare breve help on
gpg --help
-----------------------------------
generare le chiavi
gpg --gen-key
-----------------------------------
Esportare le chiavi
gpg --export [UID]
Se non si indica un UID (User ID), verranno esportate tutte le chiavi presenti nel portachiavi.
-----------------------------------
gpg --import [nomefile]
se si omette il nome del file, i dati verranno letti dallo stdin.
-----------------------------------
gpg --gen-revoke
genera un certificato di revoca. Per poter fare questo occorre la chiave privata, altrimenti chiunque
potrebbe revocare la chiave.
-----------------------------------
gpg --list-keys
verranno mostrate tutte le chiavi esistenti.
-----------------------------------
gpg --list-sigs
per firmare le chiavi
-----------------------------------
gpg --fingerprint
Vedere le impronte digitali ("Fingerprint") serve ad assicurarsi che la chiave appartenga davvero alla persona
che sostiene di esserne il proprietario
-----------------------------------
Per vedere la lista delle chiavi private
gpg --list-secret-keys
-----------------------------------
Per cancellare una chiave pubblica
gpg --delete-key UID
----------------------------------
Per cancellare una chiave privata
gpg --delete-secret-key
----------------------------------
gpg --edit-key UID
Usando questo comando ` possibile modificare (tra le altre cose) la data di scadenza di una chiave, aggiungere
UID o firmare una chiave (ovviamente per questo ` necessaria la propria passphrase).
Dopo aver eseguito il comando –edit-key si otterr` un prompt interattivo da cui digitare i comandi successivi.
----------------------------------
Per firmare una chiave
gpg --edit-key UID e successivamente il comando sign
----------------------------------
Il comando per cifrare
gpg -e destinatario [dati]
o
gpg --encrypt destinatario [dati]
-----------------------------------
Il comando per decifrare
gpg [-d] [dati]
o
gpg [--decrypt] [dati]
Anche in questo caso, l’output predefinito ` lo stdout, ma ` possibile
redirigere l’output a un file con l’opzione -o
-----------------------------------
Per firmare dati con la propria chiave
gpg -s (o --sign) [dati]
risultato non leggibile
-----------------------------------
Per avere un risultato leggibile
gpg --clearsign [dati]
-----------------------------------
gpg -b (o --detach-sign) [dati]
E possibile scrivere la firma in un file separato
--armor pu` tornare utile
-----------------------------------
Per dati cifrati e firmati allo stesso tempo
gpg [-u mittente] [-r destinatario] [--armor] --sign --encrypt [dati]
-----------------------------------
verificare le firme con
gpg [--verify] [dati]
-----------------------------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.14 (GNU/Linux)
mQSuBE1cD84RDAC/8krYIYPcpTJ05uUttVOAk5D9VtROOZCyCTi/32IcoEp9aLxa
hDF1aqEV2Te1FgOyd96bVg2dS0v72W1UFHa1ySONFw1j+ekZOT2+lVk/Xeij4qjA
VCGK/LbxfbSYTKBAZQQ1kYKZlacbBNL4x1H6r4ImNP2jdcVBJ4hVJgU72VCi1IaP
3e1T4DgGgh8poKEOLGtob6el8D2bOFNhYbn6jikrQaFHoMgqt4xreKJBufXS4322
1YEvg7sKvt4F6Ed6mlyVCOCbumrX5jVt4w3l6WnXeHbzKvu2h1kV2Hg8erGd5QhL
M1y02WHXzuyC1KlpLh8N2F3Iwhy1yA3+6aysoWB4xXbH5szCYFbcT+aewB5QQFrE
CMY9KYh029iCwWE8emSXoYM5hkiJlZfDMnc2dAwniQFBIj0MNxjLFA+/USkAJ8rP
hEBiHS33eE2Jl4WGT3YpXZCLruGROMAGr4mq9gQBfdqTRw5TB1tfWfmJMXz2SC1l
KRe/M1O430rHyO8BALYEDw4o2uZDiw5wSaJshw3LOCqkkXy4fbJcY5gE/oQNC/90
ZGLfA+L4eJtYcs8eiormmYTweIke2uvCiEVOC8van7YPCAP94yA2NzjosgoHNoi6
cq/n78QZfb2MPrHs7aqSy1s8HUXyhqVNPY6sLIpJl1D9Ufaz5O0dSZxqQv8l0H/o
BhbOp8PkuYMTHnPT1G3g30MnmEDZJy2Y8vfJ8MJFioCyiyQgMe9C526JaGovpq7I
hpWq0g21FhxoMRZC8oWMwu2WyNlprLct3xz6prlezrp05Dt0aIDqlkpjrgYE6o40
Yji6tBPBljOgvuJxauu9Rz1CXmLdQWkjqaRpv/Dw+mtR8smCqJr3iBdNZEq/KVkF
k6ucS46gmSsNOdXO8MN/tHxJQjQvQVKFllLUr2w7UnXSO5sr5F4W+lKxR5XLTv7a
lfq9JNM0B/K+NePu54pzAxgQ19X+hMVkm3BsrfIG/VsmH+/yRT2PtInVp+B6aoB+
nmYGJzmrj/2fWa3u4hnOGKkEk2fJick4HWaO9iZXj0eOBLE+v32h6oSHN/y5rxEM
AJpUUiT13ElIsqhh9vSc0hQT6Bwrodp6pMchK5hhjhoTnIw5qupnsQ2Il/oSTrRA
BeQz12GpuyXSVTodUORSTBt3uXFLzQ+t3+z6JQ0M11m/3oYKnll0WYVyq7dILxK3
0ZX0Sad3yxy4ITTT00QGgoqcyXSrkB3HmLTBpb0LDwdrsVBWwfjXBoFItVWdXk1m
s5n9TVj1sqaRDVrOhXXWGTIzXsIy7pKaKAJ3mIyswn9W7w1TEbsPOTkDK4DUeXtY
VpAFmaD73L1xO9c93zznYKDZXiUpQkYh4LKr9OfMAiXoUAoKzdyckD9yZPw2srnJ
9O0gnFqkwuBIwIeRZJ7VsKnpAbFkLjBmNBIpJoN+HCtLFN4y4teYEC0FobrVUm6Y
DAAPknDpt+AGlcAM8348DbfHQB4iTX7l8aoOVsiFptTZFJ3bhOgdVyJvMFo4QhgN
E3qHIlmv36ZgTzIHxfsL9yZnMMDEascQY3L7BMwyF8E1L3003Tek3q6hvLwnaRka
TbQ9QWxlc3NhbmRybyBDb2x1Y2NpIChQZXJzb25hbCkgPGNvbHVjY2lhbGVzc2Fu
ZHJvOTlAZ21haWwuY29tPoiABBMRCAAoBQJNXA/OAhsDBQkFo5qABgsJCAcDAgYV
CAIJCgsEFgIDAQIeAQIXgAAKCRCb1p+pfhji4f5lAP4iY19/UNI7hBlRBe0wrx/T
RlwrQfv+u4bX1SuEm7HGUgD+OBjvD6T/PXVVavr3dNJx+2eif5QRc0o3rZR34aML
pqC5Aw0ETVwPzhAMAOmxIvBluY8mxrCGUG/9OKnlbt1MuOt4IPBQVD3s+K9VEprp
VJF30/h2cIcK0H8fEWxEae/1CwYxpqmDhtZZVC/N/TKU0FhaNGNtnOwyESr3CaZn
ZkLDmMWFAntaBx3v28rA2PWJ4gGI/xoO07bJ+LaeoQg1HwTCPnIXQ3XlOkngj+Hz
EO1JOyQv+IKGWzt/L4GqeSRqLHP+3qv6ikRPCKTPAcDTOplMG9I60uwUZszJez6I
MfHU7pMaYMbKpRu89Vn6qvS3JXDZ5xt5LyVods5pJnsEzmLsyz6PKZQc+wgBywdu
fEYNNbcNvzGSy5ae9H4TT6T8N5HfTO7bFvY2rcYFuuc0IEXldqhPiiycoCY+ypPA
oZzn06o4lV1CZGYNsz96LiU0ob7jBNIImAJf6OBbccIXpRTT8MhoiMatHrAsrh4v
HfFEOKcJGKaPj3Q/U6g8DVEppYZNLkWxoektmfGCPFDsqnfdhqtuvVziZMuh6NRf
nz8Az/XErqsh/prZvwADBQv/fHOQmcgLg1AZmauR3o2zsop4owrOIaP7d0nRw5Zr
WI9YBUW0+4lVLDqf2QmSG024QmybEEAl4qcHh77aK8ItHVWfEOrZTzI137COwBUE
93HzxT6sHGWR4d755tB0oke9EClKjdf5UbdtlDaNKUrKJMN8qrvFuZ3jOhMiyhEq
7H+YEb9FVR3/DXO9+rXMscrnuj9Ljd5NJeVb5IMHfXqfQrl0y/lRHCbb3MfAzIvV
F/fgmpkhb4AKh0bnPPdTXUCrcF68z5CltjvM3bx1blr03R6LPq9NNJbWiXSZrEfM
kQESLoooVYj08yHAvLXRkC4coCPFTHZHvdSYaAxbP7+HFaGGAIU8aw4u2kj8iDeA
+MdThlNDPtB7hNQmZFClcfXeokoPZcIsMCrN0fMEOJJVOdy3tSlUFzxB3WNgvWbU
vu4ogON52FGB4irlAIPQOaWoBE0n8lEqWbKChbisrHjznR5O11bC6DuWJL0XCOvR
l7AhpNPvW2dFFvrUBah/0/g8iGcEGBEIAA8FAk1cD84CGwwFCQWjmoAACgkQm9af
qX4Y4uF1PAEArUFrop3/0w2NPIkF59AMYsLXq49qy+TA+JX9/bgaCmgA/AsszUj1
sUrkcxyYcprQJlr62+XyG5JpNz+mavGALGp3
=WaH3
-----END PGP PUBLIC KEY BLOCK-----
Ultimo aggiornamento: 16.02.2011 - da terminare -
0 commenti:
Posta un commento