Bê-a-bá do GPG, parte 1: crie sua chave hoje mesmo
Post do Pablo Hess no Blog do developerWorks:
Via ibm.com:
Imagine conseguir enviar um arquivo ou uma mensagem, via internet, para uma pessoa específica no outro canto do planeta, de forma que ninguém consiga ter acesso ao arquivo ou mensagem. Imagine ainda conseguir garantir ao destinatário que o conteúdo foi, de fato, emitido por você e que seu conteúdo está exatamente como era no momento dessa emissão. Este post fala justamente sobre como conseguir isso, e eu já adianto: é bem fácil.
• Publicado por Augusto Campos em
2012-04-13
@brlinuxblog
Feed RSS
Eu prefiro usar o gpg a criptografar o disco inteiro,eu escolhos os arquivos que preciso criptografar,compacto e depois mando para o gpg.
@Pablo Hess como você conhece bem do riscado,mais para frente
você poderia escrever um artigo sobre o “runlevel” o que pode ou não ser ativado ou desativado com segurança.
@anderson freitas, obrigado pelo elogio. Quanto à sua sugestão de artigo, os serviços opcionais dependem do que a máquina precisa fazer.
Por exemplo, se for um desktop, dificilmente haverá necessidade de subir o Apache ou o {My,Postgre}SQL, mas talvez (dependendo dos serviços que você usa) valha a pena ter um Postfix em execução.
Mas vou pensar mais em como fazer um artigo desses com a validade mais genérica possível. Obrigado pela sugestão!
Falando em GPG, não percam a Festa de Assinatura de Chaves do FISL13:
http://softwarelivre.org/fisl13/assinatura-de-chaves/festa-de-assinatura-de-chaves
Pablo Hess
“Por exemplo, se for um desktop, dificilmente haverá necessidade de subir o Apache ou o {My,Postgre}SQL”
Hoje em dia acho que todo desktop
está infectado comtem disponível Mysql.O Amarok é um que lembro, mas acho que tem outros. No KDE principalmente, para meu desgosto, uso opcional de Mysql, mas default .
Qualquer um pode criar uma chave e dizer que o proprietário dela é “Pablo Hess”, portanto não se aplica o que você disse:
“…garantir ao destinatário que o conteúdo foi, de fato, emitido por você…”
A única forma de garantir isso, legalmente, é com os certificados digitais (Serpro, Correios, Certisign, etc)… Que a propósito não funcionam com Linux.
Att,
Renato S. Yamane
@yamane
Alguns certificados digitais funcionam no Linux. Até mesmo no link do br-linux.org http://br-linux.org/2010/linux-receita-federal-e-certisign-relato-de-problemas-de-compatibilidade/ tem relatos, nos comentários, de usuários que conseguiram usar. Nem sei como está o status atual mas, no link acima, os problemas eram mais com a Certsign.
Mas existe uma outra forma de garantir que a chave realmente é a da pessoa certa que é cadastrar a chave no keyserver.pgp.com. Neste caso o cadastro é confirmado por email e ele assina as suas chaves nos servidores do gnupg. Um exemplo prático está na minha própria chave. Nos servidores tem duas chaves minhas. A primeira perdi a senha e a chave para revogar-la por um pequeno desastre na hora de aprender a utilizar. Daí fiz outra que deu certo, é a que uso atualmente e cadastrei no pgp.com. Agora vendo as duas chaves, quais delas é a que possui as assinaturas do pgp? :)
yamane, Existe uma distinção entre o certificado digital em si e o meio que é usado para transportá-lo. O certificado digital em si pode ser um simples arquivo. Se você estiver falando daqueles smartcards que armazenam o certificado dentro de um chip, existe um padrão (ISO 7816) para se comunicar com eles. Você pode se comunicar com um chip desses até mesmo usando um Arduino ou outro tipo de microcontrolador (http://hackaday.com/2008/11/25/how-to-read-a-fedex-kinkos-smart-card-sle4442/), quanto mais com o Linux. O problema que existe é com alguns aplicativos do governo que utilizam esses cartões, não com o suporte aos cartões em si. Esses problemas ocorrem porque o governo não testa ou não se preocupa com esses aplicativos funcionarem no Linux, e existem poucas pessoas da população com acesso a esses cartões e conhecimento suficiente para criar workarounds para suportar isso. Tudo deve melhorar quando sair o RIC, aí todo mundo vai ter um cartão desses, e com certeza vão aparecer pessoas com capacidade técnica para suprir aquilo que o governo não supre.
@yamane,
A “única forma” não. Afinal, o projeto Debian confia nos seus desenvolvedores através das suas chaves… Nenhum deles teve de adquirir um certificado para ser confiável. Para isso servem as Festas de Assinatura de Chaves e a Rede de Confiança.
@Adilson,
Cadastrar uma chave em um servidor de chaves não serve para autenticar alguém. Qualquer um pode enviar uma chave para um servidor de chaves no nome de quem quiser. Mesmo o keyserver.pgp.com validando por email… só o que isso garante é que quem enviou a chave controla o email ao qual ela se refere. Como eu escrevi acima, a Rede de Confiança é o meio de autenticar uma chave.
Nesse FAQ eu coloquei bastante informação acerca disso.
@yamane,
Apenas para completar… Se vc conhece a pessoa diretamente e ela te passou uma cópia da sua chave pública (ou seu KeyID e um apontamento para onde ela pode ser encontrada), também dá para garantir que algo assinado por ela foi escrito por aquela pessoa. Embora isso seja uma caso especial da Rede de Confiança, não ficou claro na minha resposta anterior… Esse tipo de chave você importa para o seu chaveiro com o maior grau de confiança, e o software te avisa desse grau de confiança quando verifica algo contra o chaveiro.
Mas imagino que maiores detalhes vão ser dados pelo Pablo Hess no próximo post.
Estou tentando enviar a chave para o servidor porém recebo isso como resposta:
k[~]$ gpg –send-keys XXXXXXXX –keyserver hkp://keys.gnupg.net
gpg: “–keyserver” not a key ID: skipping
gpg: “hkp://keys.gnupg.net” not a key ID: skipping
gpg: no keyserver known (use option –keyserver)
gpg: keyserver send failed: Syntax error in URI
k[~]$
Alguma ideia do que pode está ocorrendo?
Enviei para o ksp.softwarelivre.org e agora pegou :)
@Kleiton,
O servidor ksp.softwarelivre.org só serve para a Festa de Assinatura de Chaves do FISL13. Se você pretende participar da festa, está no caminho certo. Caso contrário, você deve enviar para um servidor público, tal como o keys.gnupg.net
Quanto a sua tentativa, não sei se o BR-Linux “comeu” os caracteres ou se você digitou errado mesmo… as opções têm dois hífens no início. Tenta:
gpg --keyserver keys.gnupg.net --send-keys XXXXXXXX
@Kleiton Moraes,
O problema que você encontrou foi a ordem dos parâmetros. O parâmetro
--send-keys XXXXXXXXtem que vir por último. Portanto, o comando precisa ser nesta ordem:gpg --keyserver seu.key.server --send-keys XXXXXXXX@Pablo Lorenzzoni,
Sim, isto (rede de confiança e assinatura de arquivos com a chave privada) será coberto no próximo post desse “Bê-a-bá”.
Se quiserem enviar mais ideias, agradeço! Essa da assinatura da chave pelo keyserver.pgp.net, por exemplo, eu não conhecia, e certamente vou incluir.
Obrigado.
@Pablo Hess,
Ao escrever sobre o keyserver.pgp.com, por favor, considere que essa “feature” é bastante criticada e há bastante tempo… Principalmente pq eles chamam a chave que assina de “PGP Global Directory Verification Key”, o que pode fazer com que pareça que aquilo serve para alguma coisa do ponto de vista de identidade. Como eu escrevi acima (e como vc sabe), isso só serve para provar que a pessoa que controla um dado email também controla uma dada chave.
Eles próprios escrevem isso na página detalhando a política de verificação de chaves. Só um trecho:
Consequently, there is always a risk that the verified key in the PGP Global Directory is not actually owned by the person who appears to own it. [...] The PGP Global Directory is not a replacement for the PGP Web of Trust