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

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

Dito isto, estou bastante ansioso por colocar meu trabalho ~/.ssh/id_dsana nuvem. Obviamente, nenhum sistema é totalmente seguro. Poderia alguém com conhecimento, quantificar pragmaticamente os riscos?

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

Como o Dropbox, a loja Ubuntu One não é criptografada com uma senha especial. Portanto, seria tecnicamente possível que alguém tenha acesso aos 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.

Portanto, não sincronizei minha pasta ~ / .ssh na nuvem. A menos que você defina um contêiner criptografado que é enviado para a nuvem, mas depois para chaves ssh, nem sempre é útil. Mas eu ainda lhe mostro 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), significa que basicamente os dados são transmitidos por algum tipo de HTTPS. Você pode usar uma animação muito bem feita do que é visível para os bisbilhoteiros ao usar HTTPS , cortesia da EFF (Electronic Frontier Foundation) .

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

Então você precisa criptografar os dados antes que eles deixem o computador. Portanto, ele chega criptografado no site.com com credenciais que eles desconhecem. Obviamente, você precisaria usar um mecanismo de criptografia forte para tornar extremamente lento para as pessoas do site.com quebrá-lo.

Obviamente, no caso de um banco, você não pode criptografar seu dinheiro, pois paga o banco para fazer isso por 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, para que apenas um pequeno subconjunto de funcionários (os que gerenciam sua conta) possam visualizar e modificar seus dados.

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: criptografá-las em um arquivo e excluir os originais "brutos". Sempre que necessário, eu o extraio temporariamente e o 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 na nuvem seja comprometido, ninguém poderá extrair as chaves privadas, a menos que conheça a senha do arquivo morto.

Para facilitar a vida das coisas que você faz com freqüência (por exemplo, descriptografia de gpg), você pode ter um script bash simples para lidar com a parte temporária de descriptografia / uso / exclusão; ele também deve desativar temporariamente todos os daemons de sincronização para que as chaves extraídas não sejam acidentalmente sincronizadas.

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.

Existem diferentes métricas disponíveis para definir o risco, mas você precisa levar em consideração o valor dos dados ou sistemas aos quais a chave poderia acessar. 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, a perda de dados, a possibilidade de comprometer as contas do nível administrativo ou da conta, etc.? Se você pode recriar dados que não são confidenciais e se possui dados confidenciais armazenados de forma segura (por exemplo, criptografados), isso é menos urgente. Penso que enumerar soluções alternativas para diferentes fraquezas do sistema faz 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 se baseia em várias suposições, mas, no entanto,

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