Como gerenciar chaves GPG em vários sistemas?

Question

Eu sou novo em usar o GnuPG e tentar entender a melhor forma de usá-lo. Eu revisei Curto, 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. Copie todas as minhas chaves para o chaveiro em cada dispositivo e confie principalmente na senha da chave privada para proteção.

2. Crie uma chave mestra (com -gen-key) para representar minha identidade e 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 deve ser minha identidade digital. Muito esforço será gasto na criação de confiança em torno dessa identidade, e 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 como eu penso, mas eu sou novo para isso) .

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 posso sempre conceder a confiança da minha chave mestra a uma nova chave descartável.

Desculpe pela longa pergunta. : -)

TL; DR

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

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

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

    

Answer 1

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

Ao pesquisar quais subchaves são e por que eles podem ser usados em vez de --gen-key, me deparei com essa gem: link .

O wiki Debian explica como implementar a opção # 2 (veja OP) usando uma chave mestra com subchaves e 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 então ser distribuídas entre meus chaveiros em cada dispositivo.

Prós:

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

2. Se algum sistema for comprometido, a chave mestra não estará disponível imediatamente (a menos que eu insensamente deixe meu pen drive 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. (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 de chave: gpg --list-keys yourname
   • gpg --edit-key YOURMASTERKEYID
   • No prompt gpg> : 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 frequência 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 criptografia)", 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 as IDs da subchave seguidas por um ponto de exclamação: gpg --export-secret-subkeys SUBKEYID! [SUBKEYID! ..] )
   • Remova sua chave secreta principal: gpg --delete-secret-key YOURMASTERKEYID
   • Importar 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 frase secreta antiga.)

Seu computador agora 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 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, o gpg será criptografado apenas para a subchave de criptografia mais recente e não para todas as subchaves de criptografia conhecidas e não revogadas.

    

Answer 2

Como alguém que também não gosta de pontos únicos de falha (incluindo chaves mestras e especialmente senhas), esta é a maneira que eu faria isso. 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: keypairs de dispositivo e keypairs de timeframe . 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 de período de tempo é gerado por um servidor central em intervalos de rotina (mensal, diário, por hora - depende de quão paranoico você deseja estar). 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, use a chave do dispositivo de qualquer dispositivo para o qual esteja 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, backups de pares de timeframe mais antigos são salvos em cada dispositivo de acordo com uma estratégia apropriada (incluindo o servidor gerador de time-keypair, se você desejar - novamente, dependendo do seu nível de paranoia), ter outro conjunto de keypairs protegidos por senha protegendo as chaves mais antigas (com quantas senhas ao longo do tempo 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 pedir a um amigo de confiança que o verifique pessoalmente e revogar a chave do dispositivo comprometido e 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 VPS em um assalto 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 diretiva mais strong semelhante à de adicionar um novo dispositivo) e usar um servidor novo ou protegido novamente. (com um novo par de chaves para dispositivos) daqui para frente.