A criptografia de email é prática o suficiente?


9

Todos os emails que já enviei foram enviados como texto sem formatação. Como cartões postais, todos no caminho para o destinatário podiam ler e armazenar facilmente. Isso me preocupa. Eu sei que a privacidade é algo do passado, mas a criptografia de e-mails é possível, pelo menos em teoria. No entanto, gostaria de saber se é prático o suficiente.

Existe alguém que tenha experiência com segurança de email? É fácil de configurar? E você ainda pode enviar e receber e-mails de todos os seus amigos e conhecidos?

Respostas:


12

Muito infelizmente: Não.

Criptografia de correio geralmente significa criptografia de chave pública. Isso envolve que o destinatário tenha uma chave pública publicada em algum lugar - isso pode ser usado para criptografar emails. Essa chave possui um par secreto - uma chave privada que pode ser usada para descriptografar os emails.

Para que a criptografia de correio seja prática, o cliente de email precisa ser capaz de:

  1. Ao enviar um email, busque automaticamente a chave pública do destinatário para criptografar as mensagens.
  2. Ao receber um e-mail, busque a chave privada do usuário em um servidor designado, de preferência quem for quem estiver fornecendo o serviço de e-mail (geralmente o ISP ).
  3. Ao configurar a conta, crie e armazene automaticamente a chave privada.

Mas o maior problema aqui é a infraestrutura. Para que isso acontecesse, teria que haver:

  1. Uma maneira padrão e amplamente usada de publicar uma chave pública associada a um endereço de email (e esse método precisaria ser protegido por um sistema de certificação para que terceiros não pudessem mexer com ela com muita facilidade).
  2. Uma maneira padrão amplamente usada de criar automaticamente uma chave privada para um endereço de e-mail e armazená-la em um servidor remoto acessível por uma maneira padrão. De preferência, esse servidor faria parte de um serviço normal do provedor de email. O endereço desse servidor seria digitado como um procedimento normal nas configurações da conta do cliente de email, assim como os servidores de email de entrada e saída são inseridos hoje em dia, após o qual o cliente pode lidar com todo o aborrecimento com chaves.

Outro problema é que a maioria dos clientes de email precisaria lidar com a descriptografia, e a maioria dos provedores de email precisaria fornecer o serviço principal para que o sistema fosse eficaz. A criptografia precisa de suporte total nas duas extremidades da comunicação. Mas não vejo isso como um grande problema. Se um padrão fácil e prático aparecer em alguns clientes e servidores, eles poderão anunciar "apoiamos o padrão de email seguro" e outros provavelmente seguirão o exemplo.

Além disso, o usuário teria que ser notificado sobre se uma chave pública está disponível para o destinatário. Uma boa abordagem seria ao adicionar um destinatário, mostrando um símbolo seguro comum, como o cadeado ou o brilho azul usado nas conexões SSL / TLS com navegadores da web.

Obviamente, um servidor de chave privada alternativo, ou mesmo apenas um arquivo de chave, poderia ser configurado para o cliente de email, para que o usuário mais paranóico pudesse armazenar suas próprias chaves onde quisesse. Para o resto de nós, o provedor de e-mail ainda pode ler os e-mails enquanto armazena a chave privada - mas isso ainda tornaria as comunicações muito seguras. Afinal, a segurança geralmente é sobre quem podemos confiar.

Honestamente, eu realmente não sei por que isso ainda não aconteceu. Não é tão complicado. Continue com isso já!


2
Ótima resposta; Eu acho que você escolhe as razões pelas quais realmente não está difundida agora. (Anos atrás, eu gostava muito de PGP / GPG e gostava muito, por exemplo, do suporte interno do KMail para isso. Mas até eu, como estudante de CS, tinha muito poucas pessoas com as quais eu poderia ter trocas de e-mail criptografadas. Como você diz, nós 'd necessidade de ter a maioria das pessoas que utilizam os clientes que apoiá-lo totalmente, etc.)
Jonik

1
Boa resposta! "Realmente não sei por que isso ainda não aconteceu": porque a maioria das pessoas não se importa com privacidade. Basta olhar para a internet, onde as pessoas publicam todos os detalhes da sua vida.
Dimitri C.

@ Dimitri: Sim, infelizmente você provavelmente está certo. Mas mesmo que os usuários não se importem, eu espero que as pessoas de infraestrutura e desenvolvimento se importem. O sistema que eu detalhei seria praticamente transparente para o usuário desinformado.
Ilari Kajaste 03/09/09

Eu acho que muito disso ocorre porque o email é quase tão antigo quanto a própria Internet e é necessária uma solução alternativa tão complicada para cobrir a tecnologia existente. Se passássemos a entregar mensagens através de algo como XMPP, poderíamos evitar tudo isso e usar algo semelhante ao SSL para a própria transferência.
salmonmoose

@salmonmoose: Sim, o email está seriamente desatualizado, e a transferência SSL através de todos os links seria uma boa adição. No entanto, isso ainda permitiria a um servidor de email intermediário ler os emails. Pelo sistema que descrevi, apenas os provedores de serviços de Internet em ambas as extremidades poderiam fazer isso, e mesmo isso poderia ser evitado no mesmo sistema se o destinatário passasse pelo trabalho de configurar seu próprio arquivo / servidor de chave privada.
Ilari Kajaste

7

Sim, é prático ( PGP não é uma ciência misteriosa) e é recomendado. E é claro que você ainda pode enviar e receber e-mails não criptografados.

E se você estiver procurando um serviço de e-mail seguro e gratuito baseado na Web, inscreva-se no Hushmail .

No entanto, se todo mundo fizer, algumas agências do TLA ficarão sem fundos muito em breve :)


1
Gosto da ideia, no entanto, ele precisa de um grupo de pessoas que realmente configuram o PGP (por exemplo, para que serve um telefone com vídeo quando as pessoas que eu chamo não têm o hardware? Isso está mudando, mas a comunicação segura se popularizará tão rapidamente ?).
Nik

1
Eu acho que a idéia de assinaturas PGP é um pouco mais prática - mas resolve apenas o problema de identidade e não resolve o problema de privacidade.
Nik

como assim, não resolve o problema de privacidade? guarde esse chapéu de alumínio, não há backdoor na criptografia PGP. :)

Assinar email não é o mesmo que criptografá-lo. A assinatura resolve o problema de identidade (quem o enviou), mas não mantém o conteúdo em segredo.
Michael Kohne

As chaves PGP podem ser usadas para assinar uma mensagem, criptografar uma mensagem ou ambas. Para assinar uma mensagem para bob, alice usará sua chave privada e bob poderá verificá-la usando a chave pública de Alice. Para criptografar uma mensagem para bob, alice a criptografará com a chave pública de bob e bob usará sua chave privada para descriptografá-la. A maioria das mensagens pgp primeiro assina a mensagem e depois a criptografa, fornecendo uma garantia razoável de que a mensagem é autêntica e privada.
Keck

6

Na minha opinião, não há pessoas suficientes usando a criptografia de email para torná-lo utilizável, exceto em circunstâncias especiais (ou em certos grupos de pessoas). A assinatura de seus e-mails, por outro lado, não apresenta problemas de compatibilidade; portanto, isso provavelmente é útil, se você se importa.

O maior problema com a criptografia ainda é a troca inicial de chaves. Não conheço ninguém que realmente tenha resolvido esse problema do ponto de vista da usabilidade.


1
isso é realmente uma desvantagem, você nunca pode ter 100% de certeza se sua chave foi comprometida ou não, a menos que você organize uma troca pessoal, quando aplicável.

2
Você pode usar servidores de chaves para troca de chaves. Isso permite que você obtenha a chave muito simples. Depois disso, você deve validar a identidade do outro lado, ou seja, enviar uma mensagem criptografada e perguntar na próxima reunião pessoal, se isso funcionou.
Mnementh

1
verdade o suficiente. em termos de segurança, existem certos métodos que se aproximam (mas NUNCA são iguais) da troca pessoal de chaves.

@Mnementh: Se você vai ter reuniões pessoais, pode usá-las apenas para troca de chaves. Não há necessidade de um servidor de chaves, então. Os servidores de chaves são bons, mas você acaba tendo que confiar em outra coisa, de alguma forma, para usá-los. É aí que eu fico nervoso.
Michael Kohne

Não para refazer uma tarefa antiga, mas ... Se você vai confiar em um cliente de email baseado na Web, também pode confiar em um servidor de chaves baseado na Web para ativar a criptografia de email. Não perca seu tempo com a troca de chaves, esse problema foi resolvido pela criptografia de chave pública. Basta usar chaves de sessão aleatória, cifras simétricas e compartilhar as chaves nonce com PKE.
22612 Cris Crisfellow

4

Concordo com Molly acima, mas tenho muito a acrescentar. O PGP (ou GPG, se você quiser algo gratuito) é muito fácil de usar e funciona com muitos clientes de email independentes. Dito isto, ele não funcionará com o e-mail que você usa no navegador (tanto quanto eu sei) e as duas pessoas precisam ter o mesmo pacote (ou pelo menos entre trabalhos) instalado.

Isso não é difícil, mas convencer outras pessoas a instalá-lo e usá-lo pode ser difícil. Eu sei que tentei um tempo atrás, e ninguém iria acompanhá-lo.


1
Você não precisa do outro lado para instalar coisas, mas só pode enviar e-mails criptografados para outras pessoas instalando também o PGP / GPG. Pelo menos você pode enviar e-mails assinados. Mas, com a instalação do PGP / GPG, você não perde nada e outras pessoas já criptografam seus e-mails. Agora você também pode enviar e-mails criptografados.
Mnementh

funciona até certo ponto. você pode criptografar uma mensagem com PGP e anexá-lo a um e-mail a ser enviado através de um serviço de e-mail baseado na web

Acho que vi um script Greasemonkey que poderia ser usado para criptografar o campo de entrada de texto em um aplicativo de email da web. Ou foi um plugin do Firefox? Acesse o Google se estiver interessado. :-)
Deletado

2

Na minha opinião, o S / MIME é, no momento, mais prático que o PGP, porque seu modelo de confiança é mais claramente definido, porque já é suportado por clientes de email populares e porque a distribuição de chaves é incorporada ao protocolo.

O PGP possui um modelo de confiança tão definido que o usuário comum não se incomoda em assinar sua chave (ou verificar as impressões digitais das chaves) e se torna inútil para verificar a identidade. O conceito de PGP de uma "cadeia de confiança" também começa a desmoronar em grandes comunidades (como o mundo ), a menos que existam pessoas suficientes que passem a vida viajando de um signatário a um signatário que liga os bairros.

O S / MIME com X.509 é mais prático, porque depois de provar sua identidade a uma organização central como Thawte ou CACert , sua chave é imediatamente confiada por todos.

Eu gosto do CACert agora, porque é uma organização sem fins lucrativos que oferece chaves de graça, mas sua raiz não está atualmente distribuída na maioria dos computadores e navegadores da web. De qualquer maneira, instalar uma raiz é muito mais fácil do que configurar e manter uma instalação PGP.

(Para os super paranóicos, é claro, o PGP é superior porque não há organização central com o poder de emitir uma chave duplicada com seu nome e endereço de email em um TLA obscuro.)


2

Outra coisa a acrescentar a todos os outros - se um ponto final for comprometido, todas as apostas serão desativadas.

Por exemplo, se você enviar um e-mail criptografado usando um esquema de criptografia perfeito para um amigo, mas ele usar um computador infectado por spyware / trojan para verificar o e-mail, não há nada que mantenha seus e-mails confidenciais naquele momento.

Da mesma forma, se o seu próprio computador estiver comprometido, todos os emails que você enviar e / ou receber serão potencialmente públicos.


Para que o email seja seguro, ele não pode ser armazenado localmente no lado do cliente.
surfasb

@surfasb, com certeza ele pode ser armazenado localmente ... de forma criptografada
JoelFan

1

Não concordo com a praticidade simplesmente porque, para que a mensagem permaneça segura, o destinatário deve estar usando um sistema de email seguro e a transmissão entre servidores de email também precisa ser segura. Se você tem um destinatário específico e pode trabalhar com ele para enfrentar esses desafios, isso pode ser feito, mas para uma transição geral para o email criptografado, isso não é prático.


3
Na verdade, a transmissão segura não é necessária, apenas a troca segura de chaves inicial. Se você pode trocar chaves com segurança, E assumimos que o algoritmo de criptografia possui falhas exploráveis, não importa se as redes intermediárias são seguras ou não - apenas o destinatário poderá descriptografar a mensagem.
Michael Kohne

1
Eu concordo com Michael Kohne. O objetivo principal da criptografia do correio é enviá-lo por um canal não seguro e provavelmente comprometido. Somente os pontos de extremidade precisam ser seguros. Com clientes de desktop, isso significa que os computadores dos dois comunicadores não são invadidos. Com o webmail também o servidor de webmail e a comunicação com o site devem ser seguros.
Mnementh

1

Outra opção é o Voltage SecureMail. Ele usa o Voltage IBE (Identity Based Encryption), que é considerado a próxima geração de PKI que não requer certificados para a chave pública ... apenas um endereço de email.

O Voltage SecureMail possui plug-ins do Outlook ou uma interface da web para enviar email criptografado. As mensagens são completamente controladas pelo remetente e pelo destinatário. Nenhuma mensagem é armazenada nos servidores.

Os destinatários não precisam de nenhum software especial para descriptografar e ler suas mensagens. É muito mais fácil de usar do que PGP ou SMIME e igualmente seguro.

Experimente em: www.voltage.com/vsn


0

O principal problema é que você precisa convencer seus correspondentes a usar o mesmo esquema de criptografia. Isso é completamente impossível, pois ninguém quer se esforçar para aumentar a privacidade. Meu palpite é que as mensagens de email sempre serão enviadas sem criptografia, infelizmente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.