Como gerenciar chaves GPG em vários sistemas?


103

Eu sou novo em usar o GnuPG e tentar entender a melhor forma de usá-lo. Revi curto, fácil de entender a explicação de GPG / PGP para pessoas não-técnicos? , mas a maioria dos guias explica o PGP com uma perspectiva de máquina única.

Quero usar o GnuPG em três dispositivos de computação: um PC Linux, um laptop Linux e um telefone Android.

O caso de uso fundamental é criptografar / descriptografar emails gerenciados por um serviço IMAP, para que todos os dispositivos precisem da mesma chave privada para descriptografia.

Eu acho que minhas escolhas são:

  1. Basta copiar todas as minhas chaves para o chaveiro em cada dispositivo e confiar principalmente na senha da chave privada para proteção.

  2. Crie uma chave mestra (com --gen-key) para representar minha identidade e, em seguida, crie uma chave descartável separada (novamente com --gen-key) para criptografar / descriptografar e-mails e assinada com a chave mestra. O primeiro reside apenas no meu PC, o último é distribuído para cada dispositivo. Desde que meus dispositivos móveis não sejam comprometidos, a chave descartável permanecerá válida.

Eu posso ser excessivamente paranóico e tornar isso mais complicado do que tem que ser, mas, por favor, me dê um humor. Eu acredito em não colocar todos os seus ovos em uma cesta.

A chave mestra deve ser minha identidade digital. Muito esforço será gasto para criar confiança em torno dessa identidade, e eu prefiro sofrer o inconveniente da minha paranóia do que perder minha chave por descuido e ter que construir confiança em torno de uma nova chave mestra (talvez isso não seja tão ruim quanto eu pense, mas sou novo nisso) .

É mais provável que eu perca meu laptop ou telefone do que meu PC. Se a perda == comprometer, prefiro perder um par de chaves descartável (que posso revogar) do que meu par de chaves mestre. Sempre posso conceder a confiança da minha chave mestra em uma nova chave descartável.

Desculpe pela pergunta realmente longa. :-)

TL; DR

Uma senha é proteção suficiente para armazenar minha chave privada mestra em vários dispositivos?

Meu plano para a opção 2 é viável? Entendi algo errado ou pode ser melhorado?

Se a opção 2 for uma má ideia, quais são as melhores práticas ao usar o GnuPG para um único usuário em vários dispositivos?

Respostas:


59

Bem, isso é um pouco embaraçoso. Passei horas ao longo de uma semana tentando descobrir esse problema, e a resposta parece estar com subchaves - um tópico que o manual do GnuPG e as perguntas frequentes encobrem.

Ao pesquisar o que são subchaves e por que elas podem ser usadas em vez de --gen-key, deparei-me com esta jóia: http://wiki.debian.org/subkeys .

O wiki do Debian explica como implementar a opção # 2 (veja OP) usando uma chave mestra com subchaves, e ainda explica como remover a chave mestra de qualquer sistema depois de armazená-la em uma mídia de backup (por exemplo, uma unidade flash). As subchaves podem ser distribuídas entre os meus chaveiros em cada dispositivo.

Prós:

  1. Não depende principalmente da senha para proteger a chave mestra,

  2. Se algum sistema estiver comprometido, a chave mestra não estará disponível imediatamente (a menos que eu tolamente deixe minha unidade flash conectada ou conecte a unidade a um sistema comprometido),

  3. Esta é uma prática implementada pela equipe de desenvolvimento do Debian.

  4. Usa o recurso de subchave do GnuPG. O que parece um pouco mais organizado do que ter um monte de chaves soltas no seu chaveiro, sim?

Parte relevante da Debian Subkey Wiki

  1. Faça backups dos seus arquivos GnuPG existentes ($ HOME / .gnupg). Mantenha eles salvos. Se algo der errado durante as etapas a seguir, talvez seja necessário retornar a um local conhecido. (nota: umask 077 resultará em permissões restritivas para o backup.)

    • umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg
  2. Crie uma nova subchave para assinatura.

    • Encontre seu ID da chave: gpg --list-keys yourname
    • gpg --edit-key YOURMASTERKEYID
    • No gpg>prompt:addkey
    • Isso solicita sua senha, digite-a.
    • Escolha o tipo de chave "RSA (somente assinatura)".
    • Seria bom escolher o tamanho da chave de 4096 (ou 2048) bits.
    • Escolha uma data de validade (você pode girar suas subchaves com mais frequência que as chaves mestras ou mantê-las por toda a vida útil da chave mestra, sem validade).
    • O GnuPG (eventualmente) criará uma chave, mas você pode ter que esperar para obter entropia suficiente para isso.
    • Salve a chave: save
  3. Você pode repetir isso e criar uma subchave "RSA (somente criptografia)" também, se desejar.

  4. Agora copie $HOME/.gnupgpara suas unidades USB.

  5. Aqui vem a parte complicada. Você precisa remover a chave mestra privada e, infelizmente, o GnuPG não fornece uma maneira conveniente de fazer isso. Precisamos exportar a subchave, remover a chave privada e importar a subchave de volta.

    • Exportar as subchaves: gpg --export-secret-subkeys YOURMASTERKEYID >secret-subkeys(escolher qual subchaves para exportar, especificar os IDs de subchaves cada seguiram com um ponto de exclamação: gpg --export-secret-subkeys SUBKEYID! [SUBKEYID! ..])
    • Remova sua chave secreta mestre: gpg --delete-secret-key YOURMASTERKEYID
    • Importe as subchaves de volta: gpg --import secret-subkeys
    • Verifique se gpg -Kmostra um em sec#vez de apenas secpara sua chave privada. Isso significa que a chave secreta não está realmente lá. (Veja também a presença de um pacote fictício do OpenPGP na saída de gpg --export-secret-key YOURMASTERKEYID | gpg --list-packets).
    • Opcionalmente, alterar a proteger as subchaves senha: gpg --edit-key YOURMASTERKEYID passwd. (Observe que o material da chave privada no backup, incluindo a chave mestra privada, permanecerá protegido pela frase secreta antiga.)

Agora seu computador está pronto para uso normal.

Quando você precisar usar as chaves mestras, monte a unidade USB criptografada e defina a variável de ambiente GNUPGHOME:

export GNUPGHOME=/media/something
gpg -K

ou use o argumento da linha de comando --home:

gpg --home=/media/something -K

O último comando agora deve listar sua chave privada com sece não sec#.

Múltiplas subchaves por computador vs. Uma única subchave para todos os computadores

Trecho do wiki da subchave Debian. Originalmente anotado nos comentários. [Parafraseando] e ênfase minha.

Pode-se ficar tentado a ter uma subchave por máquina, para que você só precise trocar a subchave potencialmente comprometida dessa máquina. No caso de uma única subchave usada em todas as máquinas, ela precisa ser trocada em todas as máquinas [quando essa subchave é suspeita ou comprometida].

Mas isso funciona apenas para assinar subchaves . Se você tiver várias subchaves de criptografia, é dito que o gpg criptografa apenas para a subchave de criptografia mais recente e não para todas as subchaves de criptografia conhecidas e não revogadas.


5
Boas perguntas e respostas, mas no AFAIK ainda há um problema com essa configuração ... É ótimo para assinar, mas não para criptografia, se você não quiser compartilhar a mesma chave de codificação entre seus diferentes dispositivos, porque quando alguém o torna destinatário de um código criptografado mensagem, o gpg usa por padrão a última chave de codificação não revogada gerada. Não é possível forçar os remetentes a usar uma subchave enc específica, dependendo do UID (casa ou trabalho, etc.).
KurzedMetal

2
Talvez isso seja um problema. Minha maior preocupação é perder a rede de confiança que construo em torno da minha chave mestra (que apenas assina). É claro que a subchave de criptografia deve existir em todos os dispositivos que eu uso para ler mensagens criptografadas. Se minha chave de criptografia estiver comprometida, o processo de recuperação envolverá apenas a mim mesmo; em vez de perder minha chave de assinatura principal e ter que pedir / convencer minha rede de confiança a assinar a nova chave. Não pretendia realocar a subchave de criptografia no meu cofre.
23613 Justin C #

9

Como alguém que também não gosta de pontos únicos de falha (incluindo chaves mestras e especialmente senhas), é dessa maneira que eu faria. Ele permite que os dispositivos operem através de uma rede de confiança, enquanto ainda permite uma identidade descentralizada.

Não sei se já existe um sistema para isso, mas acho que provavelmente poderia ser contornado com um trabalho cron e algumas linhas do Bash.

Neste sistema, você tem duas classes de pares de chaves: pares de chaves do dispositivo e pares de chaves do período . Um par de chaves do dispositivo é gerado para o usuário em cada dispositivo e permanece nesse dispositivo por toda a vida útil. Um par de chaves do período de tempo é gerado por um servidor central em intervalos de rotina (mensal, diariamente, a cada hora - depende de quão paranóico você deseja ser). A chave pública é anunciada publicamente (o servidor em si possui seu próprio par de chaves de dispositivo para assinar) e a chave privada é distribuída criptografada com a chave pública de cada dispositivo que deve ter acesso a essa chave. (Essa distribuição deve ser o mais privada possível, por exemplo, ter dispositivos conectados ao servidor diretamente.)

Para assinar mensagens, você usaria a chave do dispositivo de qualquer dispositivo do qual a mensagem seja enviada. Se alguém desejar enviar uma mensagem para você, poderá assiná-la com sua chave de prazo público atual. (Eles devem ter um sistema automatizado para acompanhar os anúncios.) Em seguida, você pode ler a mensagem deles em qualquer dispositivo.

Para ler mensagens criptografadas antigas, é feito o backup de pares de chaves do período mais antigo em cada dispositivo, de acordo com uma estratégia apropriada (incluindo o servidor de geração de pares de chaves do período de tempo, se você desejar - novamente, dependendo do seu nível de paranóia), onde você tem outro conjunto de pares de chaves protegidos por senha que protegem as chaves mais antigas (com, no entanto, muitas senhas ao longo do tempo que você se sinta confortável em se lembrar).

Se um dispositivo for roubado ou comprometido de outra forma, você poderá usar outro dispositivo publicamente confiável para criar uma mensagem assinada publicamente verificando sua identidade (por qualquer meio, por exemplo, observando que você estará em uma reunião pública e / ou ter um amigo de confiança para verificar você pessoalmente) e revogar a chave do dispositivo comprometida e todas as chaves do período a que teve acesso. Ao revogar a chave, você também remove o dispositivo roubado da lista de dispositivos confiáveis ​​do servidor (com uma senha e sua chave do dispositivo confiável).

A política para confiar em chaves de dispositivo recém-anunciadas deve seguir algo como as atuais políticas de confiança - acredito que uma política apropriada é confiar no servidor gerador, em um dispositivo móvel e em um dispositivo grande e pesado, pois é difícil roubar / se infiltrar telefone de um usuário, PC de mesa e VPS em um assalto concertado antes que o usuário perceba.

Se o servidor estiver comprometido, basta revogá-lo pelo mesmo procedimento descrito para qualquer outro dispositivo comprometido (possivelmente com uma política mais forte semelhante à de adicionar um novo dispositivo) e use um servidor totalmente seguro ou totalmente novo (com um novo par de chaves do dispositivo) daqui para frente.


A seção de revogação está um pouco nublada, conforme escrito - a revogação de um dispositivo deve ser possível com um anúncio de qualquer outro dispositivo (para não falhar se alguém roubar seu laptop e seu telefone não puder entrar em contato diretamente com o servidor), mas não é possível ser feito por um ladrão (para que os dispositivos tenham uma chave protegida por senha para revogação). No caso de relatórios conflitantes, todas as chaves devem ser temporariamente desconfiadas até que a verificação manual por terceiros possa ser executada.
Stuart P. Bentley

De fato, pode ser aconselhável ter outro mecanismo para revogar chaves, usando uma senha pública forte que é atualizada manualmente (substituída) regularmente - dessa maneira, você pode revogar a chave sem depender de nenhum dispositivo (diga que você é apenas com o telefone e alguém o roubar), desde que você mantenha a senha em segredo.
Stuart P. Bentley
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.