A sincronização de chaves privadas é uma boa ideia?

Question

Perguntas frequentes sobre segurança do Ubuntu One indica que a Canonical criptografa conexões e restringe o acesso a dados do usuário. Isso tudo bem e bem, e eu confio SSL para serviços bancários on-line e outras coisas mais valiosas do que minhas chaves privadas.

Dito isso, estou bastante ansioso para colocar meu ~/.ssh/id_dsa na nuvem. Obviamente, nenhum sistema é totalmente seguro. Alguma parte conhecedora poderia quantificar os riscos de forma pragmática?

    

Answer 1

O armazenamento do Ubuntu One não é criptografado com uma chave criptográfica do usuário

Assim como o Dropbox, a loja do Ubuntu One não é criptografada com uma frase secreta especial. Portanto, seria tecnicamente possível que alguém acessasse seus dados, seja por um funcionário não confiável ou por uma violação de segurança. Veja este relatório de bug sobre a criptografia de dados de armazenamento do UbuntuOne ainda é uma lista de desejos.

Então, eu não sincronizaria minha pasta ~ / .ssh na nuvem. A menos que você defina um contêiner criptografado que é enviado para a nuvem, mas para as chaves ssh, nem sempre é prático. Mas eu ainda te dou maneiras úteis de criptografar seus dados:

• Protegendo seu armazenamento no Ubuntu One
• Usando o armazenamento em nuvem com segurança

Mais informações

O Ubuntu One está usando criptografia para a conexão (como dito no fato), isso significa que basicamente os dados são transmitidos através de algum tipo de HTTPS. Você pode usar uma animação muito bem feita de o que é visível para o interceptador ao usar HTTPS , cortesia do < href="https://www.eff.org/"> EFF (Electronic Frontier Foundation) .

Ao clicar no botão HTTPS na animação EFF, você poderá ver o que é visível para todos quando você coloca suas chaves SSH em um container Dropbox ou Ubuntu One. Como a animação diz, muitas pessoas no site.com (por exemplo, one.ubuntu.com) poderão visualizar seus dados (e muito mais). Mesmo se você usasse algo como o Tor para rotear todo o seu tráfego, isso ainda significaria que as pessoas no site.com poderiam acessar os dados.

Portanto, você precisa criptografar os dados antes que eles saiam do seu computador. Por isso, chega criptografado no site.com com credenciais que eles não conhecem. É claro, você teria que usar um mecanismo de criptografia strong para que isso tornasse extremamente lento para as pessoas no site.com quebrarem o vídeo.

É claro que, no caso de um banco, você não pode criptografar seu dinheiro, pois você paga ao banco para administrá-lo para você. Portanto, você não tem escolha a não ser confiar no banco para tornar seu sistema de TI tão seguro quanto seus cofres físicos, de modo que apenas um pequeno subconjunto de funcionários (os que gerenciam sua conta) possam visualizar e modificar seus dados.

    

Answer 2

  

Estou bastante ansioso para colocar meu ~ / .ssh / id_dsa na nuvem.

Bem, uma solução é o que faço com minhas chaves privadas ssh e gpg com o Dropbox: criptografe-as em um arquivo e exclua os originais "brutos". Sempre que necessário, eu o extraio temporariamente e, em seguida, excluo quando terminar.

Eu uso p7zip (usa criptografia AES-256), mas você pode usar várias outras ferramentas. Dessa forma, tudo o que é sincronizado é o arquivo criptografado e, mesmo que o armazenamento em nuvem esteja comprometido, ninguém pode extrair as chaves privadas, a menos que conheçam a frase secreta do arquivo.

Para tornar a vida mais fácil para coisas que você faz com frequência (digamos, descriptografia gpg), você pode ter um script simples manipulando a parte de descriptografia / uso / exclusão temporária; Ele também deve desabilitar qualquer daemons de sincronização temporariamente para que as chaves extraídas não sejam sincronizadas acidentalmente.

    

Answer 3

Você pode salvar suas chaves no U1 através da ferramenta de backup Deja-dup. Se você definir uma senha, os arquivos de backup serão criptografados automaticamente no U1. Não há necessidade de fazer isso manualmente.

    

Answer 4

Existem diferentes métricas disponíveis para a definição de risco, mas você precisa levar em conta o valor dos dados ou sistemas aos quais a chave pode dar acesso. Se a chave for perdida e alguma entidade puder usá-la para obter acesso, o que será comprometido? O medo será a exposição de dados confidenciais, perda de dados, a possibilidade de comprometimento de contas de um nível administrativo ou de conta, etc.? Se você puder recriar dados que não sejam confidenciais, e se você tiver dados confidenciais armazenados com segurança (por exemplo, criptografados), isso será menos urgente. Eu acho que enumerar soluções alternativas para diferentes fraquezas no sistema é parte da definição do seu risco geral.  Pragmaticamente, é improvável que o armazenamento do seu .id_rsa seja um problema, especialmente se você girar as teclas em algum intervalo. Isso depende de várias suposições, mas, no entanto, eu não armazenaria os dados .ssh sem criptografia se essa for uma opção viável.

    

O

Answer 5

Solução simples. Tipo de. Se você não pode usar algo como uma unidade flash USB, coloque uma senha em sua chave SSH. Autenticação instantânea de dois fatores (mais ou menos). Você nem precisa fazer o upload de uma nova chave pública.