Come inviare e ricevere file criptati con una chiave GPG

Posted by Ingalex | Posted in GUIDE | Posted on 04-01-2010

0

Sempre rimanendo in tema con le chiavi GPG ho trovato un altro post molto interessante sul blog blogs.koolwal.net che ho deciso di tradurvi.

Tramite questa guida impareremo a usare le chiavi GPG per inviare e ricevere file criptati.

Supponiamo di voler inviare un messaggio criptato o un file criptato a un amico.

Indichiamo come:

Persona 1 – mittente

Persona 2 – destinatario

Supponiamo che la Persona 1 voglia inviare alla Persona 2 un file criptato chiamato account.txt. Supponiamo che il file account.txt contenga dei dati sensibili che vogliamo proteggere. Per esempio:

Numero di conto bancario: 12345678
Importo della transazione:  500,000 €

Procedimento per la Persona 1

  • Passo1: Importare la chiave della Persona 2

    Il primo passo consiste nell’importare nel proprio sistema la chiave pubblica della persona (Persona 2) alla quale si vuole inviare il file segreto. Ciò può essere effettuato in due modi:

    Metodo 1:

    Importare la chiave pubblica della Persona 2 usando un file che può essere stato inviato tramite email.  Supponiamo che il file si chiami persona2_pub_key.txt.  Eseguite il seguente comando per importarla:

    persona1:~# gpg --import persona2_pub_key.txt

    Nota:  Si suppone che che la Persona 2 abbia precedentemente generato una coppia di chiavi pubblica/privata (seguendo questa guida) e che in seguito la chiave sia stata esportata nel file persona2_pub_key.txt.

    Metodo 2:

    Un altro metodo consiste nel cercare la chiave pubblica della Persona 2 su un GPG keyserver. Ovviamente è possibile usare questo metodo unicamente se la Persona 2 ha inviato la chiave su un GPG keyserver e a patto che sia noto anche l’indirizzo del keyserver. Potete cercare la chiave della  Persona 2 usando alternativamente i seguenti comandi:

    persona1:~# gpg --search-keys --keyserver hkp://subkeys.pgp.net 'person2@abc.com'
    oppure
    person1:~# gpg --search-keys --keyserver hkp://subkeys.pgp.net 'Person 2 name'
    oppure
    person1:~# gpg --search-keys --keyserver hkp://subkeys.pgp.net 'Key-ID'

    Generalmente potete effettuare la ricerca indifferentemente in base al nome della Persona 2 , email o Key ID.

    Come risultato della ricerca dovreste ricevere un output di questo tipo:

    gpg: requesting key EE6E8046 from hkp server subkeys.pgp.net
    gpg: key EE6E8046: “Persona 2 nome (Public Key) persona2@abc.com” not changed
    gpg: Total number processed: 1
    gpg:              unchanged: 1

  • Passo 2: Verificare l’importazione della chiave

    Per verificare che la chiave relativa alla Persona 2 sia stata importata con successo nel nostro sistema, basta eseguire il seguente comando:

    person1:~# gpg --list-keys

    in tal modo dovrebbe essere visualizzato qualcosa di questo tipo:

    /root/.gnupg/pubring.gpg
    ————————
    pub   1024D/E4635BBE 2009-03-16
    uid                  John Doe (My first key) <gpg@abc.com>
    sub   2048g/0AC353C2 2009-03-16

    pub   1024D/EE6E8046 2009-02-20
    uid                  Persona 2 name (My GPG key) persona2@abc.com
    sub   2048g/AE3B1BD4 2009-02-20

    Le informazione della seconda chiave (riportate in corsivo) sono quelle relative alla Persona 2 alla quale intendiamo inviare il file criptato.

  • Passo 3: Encrypt the file using your private key

    Ora siamo pronti per criptare il file usando la chiave pubblica della Persona 2 seguendo i passi seguenti:

    persona1:~# gpg --encrypt --recipient 'persona2@abc.com' account.txt

    Nota: Potreste avere qualche messaggio di avvertimento riguardante l’autenticità della chiave pubblica. Semplicemente ignorateli digitando “y” dato che stiamo supponendo che Persona 2 sia una persona fidata.

    In questo modo verrà creato un file nominato account.txt.gpg. Questo è il file criptato e se provate a usare un editor di testo, vedrete solo una sequenza di simboli e le lettere  incomprensibile a conferma del fatto che il processo di criptazione ha avuto successo.

  • Passo 4:  Inviare il file criptato alla Persona 2

    Ora è possibile inviare il file criptato alla Persona 2 come allegato tramite email oppure tramite un qualsiasi dispositivo di memorizzazione dati.  Una volta che la Persona 1 ha inviato il file alla Persona 2 , il lavoro della Persona 1 è completato e ora la Persona 2 deve fare la sua parte per decriptare il file e renderlo leggibile.

Procedimento per la Persona 2

  • Ora la Persona 2 deve ripetere i gli stessi Passi 1 e 2 riportati sopra con l’eccezione che le informazioni della Persona 2 devono essere sostituite con quelle dalla Persona 1.  In pratica bisogna prima importare la chiave pubblica della Persona 1 e verificare che sia stata importata con successo. Questi passi sono riassunti qui di seguito:

    persona2:~# gpg --import persona1_pub_key.txt
    oppure
    persona2:~# gpg --search-keys --keyserver hkp://subkeys.pgp.net 'gpg@abc.com'
    persona2:~# gpg --list-keys

    Decriptare il file

    Finalmente la Person 2 può decriptare il file account.txt.gpg con il seguente comando:

    persona2:~# gpg --output account.txt --decrypt account.txt.gpg

    Vi verrà richiesta la votra passphrase per poter decriptare il file. Dopo aver inserito la passphrase potrete vedere un file chiamato account.txt (come specificato nella –output option nel comando riportato sopra) e potrete visualizzarne il contenuto con un editor di testo.

    persona2:~# less account.txt

    Numero di conto bancario: 12345678

    Importo della transazione:  500,000 €
    account.txt (END)

Questo è tutto. Persona 2 sarà felice di ricevere il messaggio con tutti i dettagli importanti e potrà ringrazione la Persona 1.

Backup, ripristino, revoca e cancellazione delle chiavi GPG/PGP in Debian e distribuzioni derivate

Posted by Ingalex | Posted in GUIDE | Posted on 02-01-2010

0

Navigando per la rete ho trovato un post molto interessante che ho deciso di tradurvi effettuando qualche integrazione, ritenendo possa tornare utile a molti.

Backup della coppia di chiavi pubblica/privata

 

Supponiamo che abbiate generato una coppia di chiavi pubblica/privata (seguendo questa guida).

Supponiamo in oltre che abbiate bisogno di effettuare un backup delle chiavi semplicemente per conservarle, per motivi di sicurezza oppure per importarle su un altro computer.

Per visualizzare la lista delle chiavi presenti sul vostro computer vi basta eseguire tramite terminale:

# gpg --list-keys

/root/.gnupg/pubring.gpg
————————
pub   1024D/EE6E8046 2009-02-20
uid                 John Smith (My GPG key) <test@abc.com>
sub   2048g/AE3B1BD4 2009-02-20

pub   1024D/E4635BBE 2009-03-16
uid                  Juan Carlos (My first key) <gpg@abc.com>
sub   2048g/0AC353C2 2009-03-16

Selezionate il KeyID relativo alle chiavi delle quali volete effettuare il backup. In questo caso supponiamo sia EE6E8046.

Per effettuare il backup della vostra Chiave Publica key eseguite il seguente comando:

#  gpg -ao mypub.key --export EE6E8046

In questo modo verrà creato un file chiama “mypub.key” contenete il backup della vostra chiave pubblica.

Per effettuare il backup della vostra Chiave privata eseguite il seguente comando:

#  gpg -ao myprivate.key--export-secret-keys EE6E8046

In questo modo verrà creato un file chiama “myprivate.key” contenete il backup della vostra chiave privata.

Ora salvate questi due file (mypub.key e myprivate.key) su un floppy disk, CD o USB drive e riponeteli in un posto sicuro.


Ripristinare le vostre chiavi GPG

 

Per poter ripristinare su un computer il precedente backup delle chiavi, vi posizionate tramite terminale nella directory dove si trovano i due file (mypub.key e myprivate.key) di backup ed eseguite:

# gpg --import myprivate.key

gpg: key EE6E8046: secret key imported
gpg: key EE6E8046: public key “John Smith (My GPG key) <test@abc.com>” imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

# gpg --import mypub.key

gpg: key EE6E8046: “John Smith (My GPG key) <test@abc.com>” not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

# gpg --list-keys

/root/.gnupg/pubring.gpg
————————
pub   1024D/EE6E8046 2009-02-20
uid                  Bill Till (My GPG key) <test@abc.com>
sub   2048g/AE3B1BD4 2009-02-20

Le vostre chiavi sono state ripristinate con successo e potete continuare a usarle così come fate di solito.


Generare la chiave di revoca

 

L’utilità di questo passo sarà spiegata nel paragrafo successivo. Per ora assicuratevi di eseguire semplicemente il seguente comando:

# gpg --output myrevoke.key --gen-revoke  EE6E8046

e rispondete alle domande che vi vengono poste. Inserite la vostra passphrase quando richiesto. Una volta eseguito il comando si creerà il file “myrevoke.key” che dovete conservare in un posto sicuro preferibilmente su un floppy or a CD.


Revocare le chiavi GPG

 

Pregate di non aver bisogno di eseguire questo passo perchè altrimenti significherebbe che:

a) La vostra chiave privata è stata compromessa

b) Avete perso i backup delle chiavi

c) Avete dimenticato la vostra passphrase (password)

Ora supponiamo che vogliate revocare la vostra chiave. Questo significa che non potrete più usare questa chiave in futuro e volete mettere al corrente di ciò anche le persone su Internet.

Prima di tutto dobbiamo revocare la chiave localmente sul vostro computer:

# gpg --import myrevoke.key
Dove il file  “myrevoke.key” corrisponde a quello generato nel passo precedente.

Ora dobbiamo informare tutti su Internet che stiamo revocando questa chiave e che le persone non più usare questa chiave per inviarti messaggi. Ciò può essere fatto informado i keyserver così come sono stati informanti quando è stata creata una nuova chiave pubblica. Per inviare le informazioni di revoca al keyserver basta eseguire il seguente comando:

# gpg —send-keys –keyserver hkp://subkeys.pgp.net EE6E8046

Ora tutti coloro che proveranno a inviare un messaggio usando la vostra chiave che è stata revocata riceverà un messaggio.

Dopodiché è necessario aggiornare il databese del portachiavi GPG database in modo tale che contenga le ultime informazioni sulle chiavi.

Per farlo basta eseguire il seguente comando:

# gpg --refresh-keys --keyserver hkp://subkeys.pgp.net


Cancellare una chiave

 

Supponiamo che abbiate creato troppe chiavi nel fare delle prove con GPG e ora siete confusi con tutte quelle chiavi. Supponiamo che vogliate cancellare tutte le chiavi eccetto una.  Seguendo il procedimento potete cancellare le chiavi inutili:

# gpg --list-keys

/root/.gnupg/pubring.gpg
————————
pub   1024D/EE6E8046 2009-02-20
uid                 John Smith (My GPG key) <test@abc.com>
sub   2048g/AE3B1BD4 2009-02-20

pub   1024D/E4635BBE 2009-03-16
uid                  Juan Carlos (My first key) <gpg@abc.com>
sub   2048g/0AC353C2 2009-03-16

Selezionate la KeyID relativo alla chiave che volete cancellare. In questo caso supponiamo sia E4635BBE.

# gpg –delete-secret-and-public-key E4635BBE

Il comando seguente rimuove la chiave dal portachiavi pubblico e privato.  Per verificare che la chiave sia stata effettivamente rimossa:

# gpg --list-keys

/root/.gnupg/pubring.gpg
————————
pub   1024D/EE6E8046 2009-02-20
uid                 John Smith (My GPG key) <test@abc.com>
sub   2048g/AE3B1BD4 2009-02-20

In base all’output riportato possiamo vedere che la chiave relativa a “Juan Carlos” non è più presente.

Cosa sono i keyserver

Posted by Ingalex | Posted in GUIDE | Posted on 11-12-2009

0

Come riportato nella Wikipedia:

Nell’ambito della sicurezza informatica, un key server è un sistema che si occupa di fornire, attraverso appositi programmi, chiavi crittografiche agli utenti che le richiedono.

Le chiavi fornite quasi sempre fanno parte di un certificato digitale, solitamente in un formato standard (per esempio X.509 o PKCS), che contiene oltre alla chiave anche informazioni sul proprietario della chiave e sulla sua identità. La chiave che viene restituita dal key server è la parte pubblica della chiave, da utilizzare con algoritmi di crittografia asimmetrica.

I key server più importanti e maggiormente accessibili, sparsi in tutto il mondo, sono quelli che contengono le chiavi PGP (e GPG) e le distribuiscono agli utenti di tali sistemi crittografici. Questi server quasi sempre sono mantenuti da singoli individui e forniscono un servizio “pubblico”, aiutando la costruzione della rete di fiducia, il sistema su cui si basa la garanzia dell’identità in PGP.

Per quanto riguarda i repository, ogni manutentore di un repository può decidere di firmare i propri repository. Per poter firmare il repository si generan una coppia di chiavi pubblica/privata. La chiave privata protetta con una passphrase (una password) viene conservata dal manutentore del repository. La chiave pubblica deve essere condivisa con gli utenti che intendono usufruire del repository. Per condividere la chiave pubblica generalmente vengono utilizzate due differenti tecniche:

  1. La chiave pubblica viene esportata in un semplice file di testo e poi può essere semplicemente imporatata eseguendo un comando del tipo:

    wget http://www.indirizzo_chive/public.key -O- | sudo apt-key add -
  2. In alternativa la chiave viene esportata su un server di chiavi (keyserver) tramite il comando:


    gpg --send-keys --keyserver <indirizzo_keyserver> <ID CHIAVE>


    In questo modo gli utenti possono importare la chiave pubblica eseguendo un comando del tipo:


    sudo gpg --keyserver <indirizzo_keyserver> --recv-keys <ID CHIAVE> && sudo gpg --armor --export <ID CHIAVE> | sudo apt-key add -

    sostituendo opportunamente <ID CHIAVE> e <indirizzo_keyserver>

E’ possibile esportare la chiave pubblica su un keyserver anche tramite interfaccia web tramite il sito relativo al keyserver (nel caso in cui esista una interfaccia web). Esistono tanti keyserver tra i quali i più noti e più utilizzati sono:

  • http://keyserver.ubuntu.com
  • http://pgp.mit.edu
  • hkp://search.keyserver.net
  • http://wwwkeys.eu.pgp.net

Su questo sito potete trovare una utilissima lista di keyserver.

Nuova struttura repository e aggiunta chiave di autentificazione

Posted by Ingalex | Posted in COMUNICAZIONI DI SERVIZIO | Posted on 10-12-2009

0

Vi comunico che ho modificato la struttura dei miei repository in modo tale da allinearmi alla struttura dei repository ufficiali Ubuntu, in modo tale da semplificare l’aggiunta di nuovi file e l’aggiornamento degli stessi.
Inoltre ho aggiunto anche una chiave pubblica per autentificare i repository in modo da non dover ogni volta confermare quando vogliamo installare un pacchetto.
Così finalmente non vedremo più la notifica:

I pacchetti elencati qui sotto non sono autenticati e potrebbero quindi avere una natura malevola.
Installare software non autentificato?

La nuova struttura dei repository è la seguente:

repo
.
|-debian
|—dists
|—–etch
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–lenny
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–sid
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–squeeze
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—pool
|—–etch
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–lenny
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–sid
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–squeeze
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|-mint
|—dists
|—–elyssa
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–felicia
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–gloria
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–helena
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—pool
|—–elyssa
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–felicia
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–gloria
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–helena
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|-ubuntu
|—dists
|—–hardy
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–intrepid
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–jaunty
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–karmic
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–lucid
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—pool
|—–hardy
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–intrepid
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–jaunty
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–karmic
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386
|—–lucid
|——-main
|———binary-all
|———binary-amd64
|———binary-i386
|——-non-free
|———binary-all
|———binary-amd64
|———binary-i386

Per informazioni sugli indirizzi relativi ai nuovi repository, su come aggiungere i nuovi repository e come autentificarli potete fare riferimento a questa guida.

Le varie sources.list presenti in tabella contengono ancora i riferimenti ai vecchi repository che sono ancora attivi, ma presto saranno sostituiti con i nuovi repository.

In questi giorni eliminerò i vecchi repository e lascerò attivi solo quelli nuovi. Vi invito pertanto a sostituire i vecchi indirizzi con quelli nuovi.

Autostart di Knetworkmanager senza password

Posted by Ingalex | Posted in LINUX | Posted on 19-11-2009

0

Come molti di voi sapranno, già da qualche versione, Kubuntu ha deciso di adottare come tool grafico predefinito proprio Knetworkmanager. Knetworkmanager sfrutta Kwalletmanager per poter proteggere le chiavi per le connessioni wifi e i dati sensibili relativi anche agli altri tipi di connessioni. Ciò comporta che ad ogni avvio ci viene richiesta la password affinchè Knetworkmanager possa accedere ai dati sensibili salvati in Kwalletmanager.

Con il tempo questa operazione ripetitiva può diventare noiosa. L’unico modo per aggirare la richiesta di password è quello di non proteggere Kwalletmanager con password.

Ovviamente dovete essere consapevoli che non proteggere con password il Kwalletmanager mette seriamente a richio i vostri dati sensibili: Kwalletmanager è nato proprio per conservare e proteggere i vostri dati sensibili in un file fortemente criptato, accessibile da tute le applicazioni, protetto con la master password definita dall’utente.

Detto ciò, se avete deciso di procedere dovete avviare Kwalletmanager (Sistema -> Strumento per la gestione dei portafogli).

kwalletmanager

Poi cliccate sull’icona Kdewallet.

File

Poi nel menù File cliccate su Cambia Password.

cambia password

Nei due form non inserite nessuna password e confermate cliccando su “OK”.

advice

Ovviamente visto che non è stata immessa nessuna password, vi apparirà un avviso di sicurezza per mettervi al corrente che la password immessa è troppo corta e che quindi presenta scarsa robustezza. Non vi resta che confermare cliccando su “Si”.

Se avete soluzioni migliori dal punto di vista della sicurezza vi prego di proporle inserendole fra i commenti.

TABELLA SOURCES.LIST