Como você faz backup com segurança de uma chave privada do GPG?

Question

Encontrei um gerenciador de senhas da CLI muito interessante chamado pass . Para usá-lo, você gera um par de chaves GPG2 e usa a ferramenta para ajudá-lo a armazenar senhas em arquivos criptografados por gpg2.

Para criptografar os arquivos (adicionar uma nova senha), ele usa a chave pública.

Para descriptografar os arquivos (recuperar uma senha armazenada), ele usa a chave privada, que requer uma senha.

Isso funciona muito bem.

Agora que a ferramenta está armazenando todas as minhas senhas, quero fazer backup de todos esses dados para que, se meu computador travar, não fique bloqueado de todas as minhas contas on-line.

A ferramenta se integra muito bem ao git, então eu pude facilmente empurrar os arquivos .gpg para o meu repositório privado em um computador diferente. Pelo que entendi, esses arquivos são inúteis sem a chave privada para descriptografá-los.

A minha pergunta é: como faço para fazer backup das chaves privada e pública de forma segura, para que eu possa restaurar o "banco de dados" em outra máquina, se necessário? Posso apenas armazenar as chaves públicas e privadas no meu repositório do git e importá-las em uma máquina diferente posteriormente? Ou é considerado prática insegura armazenar uma chave privada em um repositório local privado? O repositório git requer uma senha para acessar. A chave privada é criptografada e requer uma senha para abrir - isso torna seguro armazená-la?

    

Answer 1

Armazenar uma chave privada PGP em um sistema de controle de revisão não representa, por si só, nenhum problema de segurança significativo. Armazenar a chave privada em um repositório local, privado (não publicado) git não deve ter implicações significativas de segurança versus armazenar a chave privada no mesmo computador, mas fora de qualquer repositório git.

O único problema em que posso pensar que vem do armazenamento da chave privada de uma maneira controlada pela versão é que, a menos que você consiga de alguma forma destruir as revisões mais antigas, as alterações da chave secreta oferecem menos proteção do que poderiam.

O que pode vir com seu próprio conjunto de implicações de segurança é armazenar uma chave privada de tal forma que outra pessoa possa ter acesso ao arquivo-chave. Em tal situação, tudo isso fica entre um invasor e sua chave é a força de sua frase secreta.

Reconhecendo que a segurança de armazenamento não é perfeita, e ainda mais no ambiente moderno em que as pessoas fazem backup regularmente em serviços em nuvem (que literalmente traduzido significa "computador de outra pessoa"), geralmente protegemos nossas chaves secretas com senhas. Eu confio que, mesmo se você estiver executando, por exemplo, gpg-agent, você está fazendo o mesmo.

O resultado é que, desde que sua frase-senha seja boa, até mesmo o armazenamento de uma cópia do arquivo de chave criptografada no computador de outra pessoa deve ser relativamente seguro.

No entanto, isso é muito grande se: a maioria das senhas ou senhas das pessoas é péssima no que diz respeito às tentativas computadorizadas de quebrá-las. O GnuPG faz um bom trabalho para tentar trabalhar tão bem quanto possível com o que você dá, mas para uma proteção de dados sólida, você precisa de uma boa frase-senha, e você precisa para configurá-lo antes importar a chave privada para o repositório git. Após a chave ter sido importada, um invasor pode, em princípio, atacar qualquer versão dele e se tiver razão acreditar que uma determinada revisão tem uma senha de baixa qualidade provavelmente irá para isso. Por esse motivo, certifique-se de escolher a senha com cuidado. Eu escrevi uma pequena cartilha sobre como lidar com senhas, incluindo sugestões sobre como escolher senhas ou senhas que você precisa ser capaz de lembrar , o que você pode achar útil.

    

Answer 2

Eu estive considerando uma configuração semelhante recentemente. Antes de abordar sua pergunta, deixe-me apontar o que me incomoda. Isso é explicado em grande extensão aqui . Em suma, quando o Pass chama GPG, ele executa criptografia assimétrica (RSA / EC) desnecessária sob o capô. Desnecessário - porque não há uma parte não confiável aqui.

Isso é irritante porque a criptografia assimétrica é menos à prova do futuro do que a criptografia simétrica. Por exemplo, a criptografia assimétrica de hoje é quebrada por computadores quânticos suficientemente grandes, que ainda não existem. Mais geralmente, a criptografia assimétrica depende de "problemas matemáticos" que não sabemos como resolver, muito mais do que a criptografia simétrica.

Para atenuar essa fraqueza, o mínimo que você pode fazer é manter sua chave pública GPG usada com o Pass privado também, porque, por exemplo, o ataque quântico (potencial) precisa dessa chave pública: see here .

Para sua pergunta atual, não está claro se você pretende armazenar o repositório do git (com as senhas) publicamente ou em particular. Se você quiser mantê-lo privado, você pode praticamente fazer o que quiser, e reduzir a segurança da chave privada do GPG àquela do meio onde você faz o backup do repositório. No entanto, isso pode se tornar um problema de galinha e ovo: se o repo for privado, como recuperá-lo em caso de acidente? Em outras palavras, no caso de uma "falha grave", deve haver algo que você recupere primeiro . Então você pode querer manter o repositório git privado, mas faça o backup da chave GPG de forma que você possa recuperar primeiro, independentemente de qualquer outra coisa.

Soluções de backup off-line são numerosas, advogados, porões etc. veja aqui . Mas os porões não são para todos, então sugiro uma solução on-line:

• Crie uma frase secreta super strong que não deve ser digitada por anos. Sugestão: Erro de ortografia longa e memorável de uma frase que tenha algum significado pessoal ou de um livro que não ficará sem cópias se você precisar procurá-la.

• Crie um tarball com sua chave secreta de GPG exportada e talvez suas credenciais de SSH.

• Criptografe simetricamente com sua frase secreta: gpg --symmetric --armor .

• Crie uma conta gratuita de hospedagem git.

• Crie um repositório público , que possa ser clonado sem credenciais.

• Coloque a bola alcalina encriptada e blindada lá.

Para recuperá-lo após um "erro grave":

• Inicialize um pendrive ao vivo.

• Clone repo público.

• gpg --decrypt .

A senha simétrica será sua principal proteção contra os zumbis. As pessoas às vezes não dão a você, ou ao leitor anônimo, o benefício da dúvida quando se trata de escolher senhas. Mas com uma boa frase-senha, a criptografia simétrica deve ser sólida.

Quando você exportar sua chave privada do GPG, ela será criptografada com uma frase secreta própria. Versões recentes do GPG não permitem uma exportação não criptografada. Você pode usar sua senha de GPG "regular" aqui. Lembre-se de que, no caso de uma falha, você precisará das duas senhas para acessar sua chave privada do GPG.

    

Answer 3

Outra opção que eu uso é: Imprima sua chave no papel .

Os detalhes estão na resposta vinculada. As grandes vantagens são: você pode armazená-lo facilmente onde quiser e verificar se ele ainda está em boa forma apenas olhando para ele. Mas a maior vantagem é: ninguém pode hackeá-lo sem estar fisicamente no local em que você armazena seu backup e o toma.

    

Answer 4

Outra resposta para isso é "offline", ou seja, armazená-lo em algum lugar seguro e não conectado a nenhum computador. Eu mantenho uma cópia completa, descriptografada de todas as minhas chaves em um disquete (eu faço isso há muito tempo, agora é um hábito) no cofre do banco. A razão pela qual eu os mantenho descriptografado na mídia no banco é que um cenário em potencial para "perder" a chave é esquecer a frase secreta (minhas frases secretas tendem a ter muitas pontuações e grafias esquisitas, e esquecer apenas uma delas faz com que inutilizável). Eu nunca tive que recorrer a recuperá-lo dessa cópia, mas planejo o pior.

Além disso, há uma revogação de chave na mídia e uma nota instruindo meus herdeiros sobre o que fazer com ela, no caso de eu não estar mais disponível.