Gnu Privacy Guard Tutorial, Parte 2

Por Inoshiro

Você já tem o GnuPG instalado e gerou um par de chaves para si. Agora, como você utiliza o GnuPG para garantir a segurança de dados, bem como autenticar coisas?


No último artigo, percorremos os passos de criação de um par de chaves, bem como algumas sugestões sobre como isto deve ser feito. Foi mencionado o uso de servidores de chaves centrais, mas não foi falado muito sobre isto. Este artigo guiará você pelas aplicações do GnuPG no dia-a-dia.

Ações comuns que você executará com o GnuPG incluem: assinar mensagens para que seja verificado que você é o autor, assinar chaves para demonstrar que você confia na fonte da chave (desenvolvendo uma web of trust, ou rede de confiança), e enviando mensagens criptografadas para outras pessoas.

A operação mais comum provavelmente é a assinatura de mensagens. Assinar mensagens, como o nome implica, prova que você, e somente você, originou a mensagem.

gpg --clearsighn < message.txt > signed.txt

(lembre que o comando acima usa a chave padrão)

A entrada será colocada entre linhas de informação que descrevem o hash usado, bem como a inclusão de uma cópia criptografada (usando a chave privada do usuário) do hash. Para verificar se a mensagem foi alterada, o receptor somente tem que descriptografar o hash com a chave pública do emissor, e comparar com o hash real da mensagem. Se os hashes são diferentes, então a mensagem foi alterada.

Obviamente, as assinaturas digitais ainda podem ser abusadas. Imagine o que acontece se o presidente enviar a ordem "Lançar os mísseis nucleares no Canadá". O Pentágono irá atender a mensagem e lançar os mísseis. Mais tarde, quando a paz for declarada, um grupo de anti-Canadenses pode re-enviar exatamente a mesma mensagem com a mesma assinatura. Como o corpo da mensagem não foi alterado, o Pentágono irá verificar a assinatura, e iniciar a WWIV. A solução é incluir uma data no corpo da mensagem. Desta forma, mesmo se a mensagem for reenviada, o receptor pode verificar que a mensagem já foi recebida anteriormente (em vez da data e hora, pode-se usar um id de mensagem único).

Outros métodos de assinatura interessantes incluem assinar e criptografar uma mensagem para uma pessoa:

gpg [-r recipientid] --armour --sign --encrypt < message.txt > signed.txt

Neste caso, a opção --armour produz saida em texto plano ASCII (caso contrário é binário, o que não é desejável para email). Você pode usar o ID do destinatário na linha de comando, usando a opção -r, senão o gpg irá perguntar pelo mesmo. Lembre-se: você precisa ter a chave pública do destinatário.

A verificação da assinatura é bastante simples, e pode ser feita em um passo.

gpg --verify < signed.txt

ou

gpg --verify signed.txt

Se a mensagem também estiver criptografada, basta remover a opção --verify, e o GnuPG por padrão irá descriptografar e verificar automaticamente. O opção --verify faz com que o GnuPG não peça por um arquivo de saídase você está apenas verificando a assinatura (excelente para uso em scripts).

Outro uso para assinaturas é a assinatura de chaves. Assinar chaves é uma das duas formas de estabelecer confiança (a outra forma é envolver um terceiro no processo, como o serviço de chaves keyserver.net).

O GnuPG oferece bastante flexibilidade para a assinatura de chaves. Uma vez que você tenha a chave em seu keyring, pode escolher 4 níveis de confiança:

  1. Não sei nada sobre esta chave (sem opinião)
  2. NÃO confio nesta chave
  3. Tenho alguma confiança nesta chave
  4. Confio plenamente nesta chave
gpg --edit-key recipient_id sign

A informação de confiança é armazenada em um arquivo diferente do keyring.

A criptografia de arquivos (e documentos) pelo GnuPG é até mesmo mais fácil de usar. Para criptografar usando o GnuPG:

gpg -e recipient_id unencrypted.txt -o encrypted.txt

Para criptografar o arquivo em um texto ASCII (talvez para transferência via email), basta acrescentar a opção --armour.

Para descriptografar um arqivo criptografado (ASCII ou binário), coloque o nome do arquivo na linha de comando (ou redirecione o mesmo). As opções padrão do GnuPG farão o resto:

gpg encrypted.txt -o unencrypted.txt

ou

gpg < encrypted.txt

(A segunda opção vai pedir pelo nome do arquivo de saída)

O GnuPG possui muitas opções (algumas das quais estão listadas acima) para informar ao programa exatamente o que ele deve fazer. Isto o torna excelente para automação, talvez em seu cliente de email ou aplicação de segurança pessoal, bem como para scripts (caso seu cliente de email não suporte diretamente o GnuPG).

Eis uma tabela de aplicações que suportam o GnuPG (direta ou indiretamente):

Aplicação Funcionalidade Comentários
Seahorse Front-end Gnome para o GnuPG Criptografa/descriptografa e suporte drag&drop, mas não suporta verificação de assinatura (ainda).
GnomePGP Front-end Gnome para o GnuPG Parece não estar sendo ativamente desenvolvido (mais de 6 meses desde a última atualização). Julgando pelo screenshot, ele tem um bom desenvolvimento pela frente.
TkPGP (*) Um front-end GUI para o GnuPG usando o conjunto de widgets Tk. Eu não experimentei este programa.
Mutt (*) Um cliente de email que suporta verificação de assinatura PGP, e outras funções. Eu gostaria de poder usar o Mutt, que pareceu ser bem sólido quando eu experimentei com ele. O suporte IMAP, entretanto, está muito incompleto para ser útil para mim.
Privtool Um cliente de email projetado para ser compatível com o mailtool da Sun, mas suporta PGP e GTK+ (bem como Motif). A documentação deste programa é incrível -- um guia do usuário completo tanto para a versão GTK+ quanto para a versão Motif.
Kmail Cliente de email oficial do KDE A versão em desenvolvimento tem suporte a PGP/GPG.

Mais programas estão listados na página de downloads relacionados do GnuPG.

(*) Indica que o programa não suporta diretamente o GnuPG. Entretanto, o pgpgpg existe para ajudar nesta situação. Ele é um script wrapper que transforma as opções de linha de comando do PGP 2.6 nas opções do GnuPG. Com ele, a maior parte das aplicações e scripts feitos para usar o PGP 2.6 devem funcionar normalmente com o GnuPG. Muito legal se você é um "code monkey", ou não tem acesso ao código fonte :-)

Se você está se perguntando sobre a implementação de criptografia em um sistema de email de rede, e não pode alterar clientes existentes (talvez o Outlook ou o Netscape mail), existe uma solução. E pode ser feita sem muitos problemas para o usuário (dados alguns passos). A restrição é que eu não descobri como criptografar todo o email que está saindo (isto requer algumas modificações no MTA, que está além do escopo deste documento).

  1. Filtro no lado do servidor (eu uso o procmail).
  2. Armazenamento de emails no servidor, para melhor segurança e transparência (o Cyrus IMAP é uma boa escolha)
  3. Toda a interação de email passando pelo SSL, para parar com o uso de texto plano (eu uso o stunnel)

Com uma solução IMAP no servidor, como o Cyrus IMAPD, você pode fazer com que o subsistema de mail classifique o email em diferentes sub-pastas, com checagens extras para o PGP, etc.

O fluxo de emails passa a ser o seguinte:

  1. O email chega, e é passado para o procmail.
  2. O procmail examina o corpo do mail procurando por assinatura PGP, um corpo criptografado pelo PGP, ou então ele é tratado como um mail normal.
  3. O usuário final faz a autenticação (com o SSL e o stunnel para segurança, veja Securing the border, part 4) e pode ler os vários tipos de email.

O email que está saindo precisa algum tipo de programação (entre aceitar o SMTPD e o processo de repasse SMTPD) que iria procurar por endereços de email conhecidos nos campos To:, CC: ou BCC:, e assinar/criptografar o email de acordo. O sistema de filhtro tem que ser muito mais inteligente para compensar. Este fica como exercício para o leitor :-)

Com uma configuração apropriada, e possível rejeição (ou scoring) de SPAM, você pode ter um ambiente seguro, tranqüilo, sem spam, para seus usuários. Devido ao fato de ser um processo que funciona no lado do servidor, o sistema tem uma boa chance de evitar o problema típico da criptografia: fazer realmente a criptografia. Ser transparente e automático é uma funcionalidade de todos os bons sistemas e configurações de criptografia, e este não é exceção.

O script que eu uso com o Cyrus segue abaixo. Em meu sistema, uma vez que o procmail tenha decidido o que fazer com o mail, ele é entregue via este script. Ele deve ser executado pelo usuário Cyrus, e pede dois argumentos: o nome do usuário, e a subpasta. Por exemplo: deliver_wrapper dylang pgp_code

#!/usr/bin/perl
# Written by Dylan Griffiths, with guidance by Rusty Foster.
# This script is released under the terms of the GNU Public Licence v2.0
# For more information please see: http://www.gnu.org/copyleft/gpl.html
@args = ("| /usr/cyrus/bin/deliver ", "-a ", $ARGV[0], " -e -q ", $ARGV[0]);

# This is brute force because I'm new to perl :-)
if ($ARGV[1]) {
    @args = ("| /usr/cyrus/bin/deliver ", "-a ", $ARGV[0], " -e -q -m ", $ARGV[1], " ", $ARGV[0]);
}

open(MAIL, "@args");

while () {
    last if $_ eq ".\n";
    print MAIL;
}

close MAIL;

Discussão completa: http://www.kuro5hin.org/story/2000/5/9/193916/2290


Todas as marcas e copyrights nesta página pertencem a suas respectivas companias. O resto © 2000 - 2001 Kuro5hin.org Inc.

1