Questão Como gerenciar chaves GPG em vários sistemas?


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

Eu 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 o e-mail gerenciado por um serviço IMAP, portanto, todos os dispositivos precisam 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 assinar com a chave mestra. O primeiro reside apenas no meu PC, este último é distribuído para cada dispositivo. Desde que meus dispositivos móveis não sejam comprometidos, a chave descartável permanece válida.

Eu posso ser excessivamente paranóico e fazer isso mais complicado do que tem que ser, mas me agradeça, por favor. Eu acredito em não colocar todos os ovos na mesma cesta.

A chave mestra é supostamente minha identidade digital. Muito esforço será gasto na criação de confiança em torno dessa identidade, e eu prefiro sofrer a inconveniência de minha paranóia do que perder minha chave do descuido e ter que construir confiança em torno de uma nova chave mestra. (talvez isso não seja tão ruim quanto eu penso, mas eu sou novo nisso).

Estou mais propenso a perder meu laptop ou meu telefone do que meu PC. Se a perda == comprometer, então eu prefiro perder um par de chaves descartáveis ​​(que eu posso revogar) do que o meu par de chaves mestre. Eu sempre posso conceder a confiança da minha chave mestra a uma nova chave descartável.

Desculpe pela longa pergunta. :-)

TL; DR

É uma senha proteção suficiente para armazenar meu mestre chave privada em vários dispositivos?

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

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


81


origem




Respostas:


Bem, isso é um pouco embaraçoso. Passei horas ao longo de uma semana a tentar resolver este problema, e a resposta parece estar nas subchaves - um tópico que o manual do GnuPG e o FAQ apresentam.

Ao pesquisar quais subchaves são e por que eles podem ser usados ​​em vez de --gen-key, me deparei com essa joia: 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 explica ainda 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 então ser distribuídas entre meus chaveiros em cada dispositivo.

Prós:

  1. Não se baseia principalmente na 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 insensamente deixe meu pendrive conectado 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?

Porção relevante do 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, você pode precisar disso para retornar a um bom local conhecido. (note: 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 código de chave: gpg --list-keys yourname
    • gpg --edit-key YOURMASTERKEYID
    • No gpg> pronto: addkey
    • Isso pede sua frase secreta, digite-a.
    • Escolha o tipo de chave "RSA (somente sinal)".
    • Seria sensato escolher 4096 (ou 2048) tamanho de chave de bit.
    • Escolha uma data de expiração (você pode girar suas subchaves com mais freqüência do que as chaves mestras ou mantê-las por toda a vida da chave mestra, sem vencimento).
    • O GnuPG irá (eventualmente) criar uma chave, mas você pode ter que esperar que ela obtenha entropia suficiente para fazê-lo.
    • Salve a chave: save
  3. Você pode repetir isso e criar uma subchave "RSA (somente criptografar)", se desejar.

  4. Agora copie $HOME/.gnupg para suas unidades USB.

  5. Aqui vem a parte complicada. Você precisa remover a chave mestra privada e, infelizmente, o GnuPG não oferece 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 (para escolher quais subchaves exportar, especifique os IDs da subchave seguidos por um ponto de exclamação: gpg --export-secret-subkeys SUBKEYID! [SUBKEYID! ..])
    • Remova sua chave secreta principal: gpg --delete-secret-key YOURMASTERKEYID
    • Importe as subchaves de volta: gpg --import secret-subkeys
    • Verifique se gpg -K mostra um sec# em vez de apenas sec para sua chave privada. Isso significa que a chave secreta não está realmente lá. (Veja também a presença de um pacote OpenPGP fictício na saída de gpg --export-secret-key YOURMASTERKEYID | gpg --list-packets).
    • Opcionalmente, altere a frase secreta que protege as subchaves: gpg --edit-key YOURMASTERKEYID passwd. (Observe que o material da chave privada no backup, incluindo a chave mestra privada, permanecerá protegido pela senha antiga.)

Seu computador está agora 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 de linha de comando --home:

gpg --home=/media/something -K

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

Várias sub-chaves por máquina versus uma única sub-chave para todas as máquinas

Trecho do wiki de sub-chave do Debian. Originalmente anotado nos comentários. [Paráfrase] e ênfase meu.

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 de estar comprometida].

Mas isso só funciona para assinar subchaves. Se você tiver várias subchaves de criptografia, diz-se que o gpg só encripta para a subchave de encriptação mais recente e não para todas as subchaves de criptografia conhecidas e não revogadas.


46



Bom Q & A, mas AFAIK ainda há um problema com esta configuração ... É ótimo para assinar, mas não para criptografia, se você não quer compartilhar a mesma chave enc entre seus dispositivos diferentes, porque quando alguém faz você destinatário de um criptografado message, gpg usa por padrão a última chave não revogada gerada. Não é possível forçar os remetentes a usar uma subchave específica, dependendo do UID (casa ou trabalho, etc). - KurzedMetal
Talvez isso seja um problema. Minha maior preocupação é perder a rede de confiança que eu 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 for comprometida, o processo de recuperação envolve apenas eu mesmo; em vez de perder minha chave de assinatura mestre e ter que perguntar / convencer minha rede de confiança a assinar a nova chave. Eu não pretendia realocar a subchave de criptografia no meu cofre. - Justin C


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

Eu não sei se já existe um sistema para isso, mas acho que provavelmente poderia ser feito com um cron e algumas linhas de Bash.

Neste sistema, você tem duas classes de par de chaves: chaves de dispositivo e keypairs timeframe. 1 keypair do dispositivo é gerado para o usuário em cada dispositivo e permanece nesse dispositivo por toda a vida útil. UMA timepame de período de tempo é gerado por um servidor central em intervalos de rotina (mensal, diário, por hora - depende de quão paranóico você quer ser). A chave pública é anunciada publicamente (o próprio servidor tem seu próprio par de chaves de dispositivo para assinar com) 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 a mais privada possível, por exemplo, ter dispositivos conectados diretamente ao servidor.)

Para assinar mensagens, você usaria a chave do dispositivo de qualquer dispositivo para o qual estivesse enviando a mensagem. Se alguém quiser enviar uma mensagem, ele poderá assiná-la com sua chave de período pública atual. (Eles devem ter um sistema automatizado para acompanhar os anúncios.) Você pode ler a mensagem deles em qualquer dispositivo.

Para ler mensagens criptografadas mais antigas, os pares de chaves de prazos mais antigos são copiados em cada dispositivo de acordo com uma estratégia apropriada (incluindo o servidor de geração de timepore de chaves, se você desejar - novamente, dependendo do seu nível de paranóia) de keypairs protegidos por senha protegendo as chaves mais antigas (com muitas senhas ao longo do tempo, conforme você se sentir confortável em lembrar).

Se um dispositivo for roubado ou comprometido, você poderá usar outro dos seus dispositivos publicamente confiáveis ​​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 fazer com que um amigo de confiança o confirme pessoalmente) e revogar a chave do dispositivo comprometido e todas as chaves de 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 de 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 / infiltrar o telefone de um usuário, um PC de mesa e o VPS em um assalto combinado antes que o usuário perceba.

Se o seu servidor estiver comprometido, você acaba de revogá-lo pelo mesmo procedimento descrito para qualquer outro dispositivo comprometido (possivelmente com uma política mais forte semelhante àquela usada para adicionar um novo dispositivo) e usar um servidor novo ou protegido novamente (com um novo par de chaves do dispositivo) daqui para frente.


7



A seção de revogação está um pouco nublada como foi escrita - 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 (então os dispositivos devem ter 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 realizada. - Stuart P. Bentley
Na verdade, pode ser aconselhável ter outro mecanismo para revogar chaves, usando uma senha pública forte que seja atualizada manualmente (substituída) regularmente - assim, você pode revogar a chave sem depender de qualquer dispositivo (diga que você está fora apenas com o seu telefone e alguém o rouba), desde que você mantenha a senha em segredo. - Stuart P. Bentley