Qual o aplicativo de mensagens mais seguro? Whatsapp, Telegram, Facebook, Snapchat, Hangout?
Quais
aplicativos e ferramentas realmente protegem suas mensagens?
à vigilância generalizada da Internet, precisamos de um meio seguro
e prático para falar uns com os outros por meio dos nossos telefones
e computadores. Muitas empresas oferecem produtos “de mensagens
seguras” — mas será que esses sistemas são realmente
seguros? Decidimos descobrir, na primeira fase de uma nova campanha
da EFF para criptografia segura e utilizável.
tabela métrica representa apenas a primeira fase da campanha. Em
fases posteriores, estamos planejando oferecer exames mais profundos,
sobre a usabilidade e a segurança das ferramentas que tiverem aqui a
maior pontuação. Como tal, os resultados no scorecard abaixo não
devem ser lidos como recomendações para ferramentas individuais ou
garantias da sua segurança. Estas são apenas indicações de que os
projetos estão no caminho certo. Para conselhos práticos e
tutoriais sobre como proteger a sua comunicação on-line contra
vigilância, confira ao guia sobre auto-defesa contra a vigilância
do EFF.
Sobre os Critérios e Métricas
anos, especialistas de segurança e privacidade em todo o mundo pedem
ao público em geral, para adotar criptografia forte, em código
aberto para proteger as nossas comunicações. As revelações de
Snowden confirmaram os nossos piores medos: governos estão
espionando a nossa vida digital, interceptando as comunicações
transmitidas. Dada a vigilância generalizada do governo,
porque as pessoas não usam rotineiramente ferramentas para
criptografar as suas comunicações? Não seria melhor, e todos nos
comunicaríamos um pouco mais livres, sem a sombra da vigilância?
a duas coisas: segurança e usabilidade. A maioria das ferramentas
que são fáceis de usar para o público em geral, não dependem de
as melhores práticas de segurança — incluindo criptografia de
ponta a ponta e código-fonte aberto. Ferramentas de mensagens que
são realmente seguras, muitas vezes não são fáceis de usar. Usuários comuns podem ter dificuldades para instalar a tecnologia,
verificar a sua autenticidade, criar uma conta, ou até podem
acidentalmente usá-las de maneiras que expõem as suas comunicações.
em colaboração com Julia Angwin do ProPublica e Joseph Bonneau do
centro para política de tecnologia da informação em Princeton,
estão se unindo para lançar uma campanha para criptografia segura e
utilizável. Nós também defendemos as tecnologias que são
fortemente seguras e também simples de usar.
matriz de métricas para mensagens seguras examina dezenas de
tecnologias de mensagens e classifica cada uma em uma gama de práticas
recomendadas de segurança. A nossa campanha está focada em
tecnologias de comunicação, incluindo clientes de bate-papo,
aplicativos de mensagens de texto, aplicativos de e-mail e
tecnologias para chamadas vídeo. Estas são as ferramentas que os
usuários comuns precisam para se comunicar com amigos, familiares e
colegas, e precisamos de soluções seguras para elas.
escolhemos tecnologias que têm uma base de usuários grande — e,
deste modo, uma grande quantidade de comunicações confidenciais dos
seus usuário — além de pequenas empresas que são pioneiras em
práticas avançadas de segurança. Esperamos que a nossa matriz
servirá como uma corrida-ao-topo, estimulando a inovação em torno
de criptografia forte para comunicações digitais.
Metodologia
estão os critérios que nós utilizamos na avaliação da segurança
de várias ferramentas de comunicação.
1.
A sua comunicação é criptografada em trânsito?
critério exige que todas as comunicações do usuário sejam criptografadas ao longo de todos os links no caminho de comunicação.
Note que nós não estamos exigindo que os dados transmitidos em uma
rede da empresa sejam todos criptografados, embora isso seja ideal.
Nós não exigimos que os metadados (como nomes de usuários ou
endereços) sejam criptografados.
2.
A sua comunicação é criptografada com uma chave para a qual o
provedor não tem acesso?
critério exige que todas as comunicações do usuário sejam
criptografadas de ponta-a-ponta. Isto significa que as chaves
necessárias para descriptografar as mensagens devem ser geradas e
armazenadas nos pontos finais (ou seja, pelos usuários, e não por
servidores). As chaves nunca devem deixar os pontos de cada
extremidade, exceto por uma ação explícita do usuário, tais como
uma chave de backup ou para sincronizar chaves entre dois
dispositivos. É aceitável se as chaves públicas dos usuários são
trocadas usando um servidor centralizado.
3.
Você pode verificar independentemente a identidade do seu
correspondente?
critério exige que possa existir um método interno para que os
usuários possam verificar a identidade dos correspondentes com quem
eles estão falando e também a integridade do canal, mesmo que o
prestador de serviços ou outros serviços terceiros estejam
comprometidos. Duas soluções aceitáveis são as seguintes:
-
Uma
interface para os usuários visualizarem a impressão digital (hash)
das chaves públicas do seu correspondente bem como as suas
próprias, que os usuários podem verificar manualmente ou fora de
rede. -
Um
protocolo para intercâmbio de chaves com uma cadeia de texto para
autenticação curta, tal como o protocolo Socialist Millionaires.
soluções também são possíveis, mas qualquer solução deve
verificar uma ligação entre os usuários e o canal de criptografia
que foi configurado. Para a nossa matriz, simplesmente exigimos que
um mecanismo esteja implementado e não avaliamos a usabilidade e a
segurança do mesmo mecanismo.
4.
Comunicações passadas estão seguras se as chaves forem roubadas?
critério exige que o app forneça sigilo antecipado, ou seja, todas
as comunicações devem ser criptografadas com chaves efêmeras que
são rotineiramente excluídas (juntamente com os valores aleatórios
usados para derivá-las). É imperativo que essas chaves não possam
ser reconstruídas após o fato, por alguém mesmo dando acesso a
longo prazo às chaves particulares de ambas as partes, assegurando
assim que se os usuários escolherem apagar as suas cópias locais da
mensagem, que esta seja apagada permanentemente. Observe que
este critério requer o critério 2, criptografia de ponta a ponta.
Para esta fase da campanha, nós aceitamos uma abordagem de sigilo
antecipado híbrida com sigilo sobre a camada de transporte (por
exemplo através de TLS com uma suite de cifra de Diffie-Hellman) e
criptografia de ponta a ponta de sigilo não-antecipado, além de
uma garantia explícita de que as mensagens cifradas não são
registrados pelo provedor. Trata-se de um compromisso, já que requer
confiar que o provedor não esteja a registrar as mensagens cifradas,
mas nós preferimos esta configuração a não ter nenhum
sigilo antecipado.
5.
O código está aberto para uma revisão independente?
critério exige que se tenha publicado suficiente código-fonte para
que uma implementação compatível possa ser compilada de forma
independente. Embora seja preferível, não exigimos que o código
seja lançado sob alguma licença específica livre/open source. Só
exigimos que todo o código que pode afetar a comunicação e a
criptografia realizada pelo cliente esteja disponível para uma
revisão, a fim de detectar bugs, backdoors e problemas
estruturais.
quando ferramentas são fornecidas por um fornecedor de sistema
operacional, apenas exigimos que esteja disponivel o código para a
ferramenta e não para o sistema operacional inteiro. Este é um
compromisso, a tarefa para garantir a segurança para sistemas
operacionais e atualizações para sistemas operacionais está além
do âmbito deste projeto.
6.
O projeto de criptografia está bem documentado?
critério exige explicações claras e detalhadas sobre a
criptografia usada pelo aplicativo. De preferência, esta deve
assumir a forma de um white-paper escrito para revisão por um
público de profissionais criptógrafos. Este deve fornecer respostas
às seguintes perguntas:
-
Quais
algoritmos e parâmetros (tais como os tamanhos das chaves ou os
grupos de curva elíptica) são utilizados em cada etapa do processo
de criptografia e autenticação; -
Como
as chaves são geradas, armazenadas e trocadas entre os usuários; -
O
ciclo de vida das chaves e o processo para que os usuários possam
alterar ou revogar a sua chave; -
Uma
declaração clara sobre as propriedades e proteções que o
software visa proporcionar (implicitamente, isto tende também a
fornecer um modelo de ameaça, mas é bom ter um modelo de ameaça
explícita também). Isto também deve incluir uma declaração
clara dos cenários em que o protocolo não é seguro.
7.
Tem havido recentemente uma auditoria de segurança independente?
critério exige que uma revisão de segurança independente tenha sido realizada nos 12 meses antes da nossa avaliação. Esta revisão deve
cobrir tanto o design como a implementação do app e deve ser
executada por um partido de auditoria nomeado que seja independente
da equipe de desenvolvimento principal da ferramenta. Auditorias por
uma equipe de segurança independente dentro de uma organização
grande são suficientes. Reconhecendo que as auditorias não
publicadas podem ser valiosas, não exigimos que os resultados da
auditoria se tenham tornado públicos, só que seja possível verificar que a auditoria tenha sido executada.
Comparativo
Vejamos então o resultado da avaliação das apps segundo os critérios relacionados.
Ferramentas | Criptografado em trânsito? | Criptografado de modo que o provedor não pode ler? | Pode verificar as identidades de contatos? | Comentários passados estão seguros, se as chaves forem roubadas? |
O código está aberto para revisão independente? | O projeto de segurança está devidamente documentado? | Houve alguma auditoria recente do código? |
AIM |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
Blackberry Messenger |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
Blackberry Protected |
Sim
|
Sim
|
Sim
|
Não
|
Não
|
Sim
|
Sim
|
ChatSecure +Orbot |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
CryptoCat |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Ebuddy XMS |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
Facebook Chat |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Sim
|
FaceTime |
Sim
|
Sim
|
Não
|
Sim
|
Não
|
Sim
|
Sim
|
Google Hangouts/Chat “off the record” |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Sim
|
Hushmail |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
iMessage |
Sim
|
Sim
|
Não
|
Sim
|
Não
|
Sim
|
Sim
|
iPGMail |
Sim
|
Sim
|
Sim
|
Não
|
Não
|
Sim
|
Não
|
Jitsi + Ostel |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Não
|
Kik Messenger |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
Mailvelope |
Sim
|
Sim
|
Sim
|
Não
|
Sim
|
Sim
|
Sim
|
Mxit |
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
Off-the-Record Messaging for Mac (Adium) |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Não
|
Off-the-Record Messaging for Windows (Pidgin) |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
PGP for Mac (GPGTools) |
Sim
|
Sim
|
Sim
|
Não
|
Sim
|
Sim
|
Não
|
PGP for Windows (Gpg4win) |
Sim
|
Sim
|
Sim
|
Não
|
Sim
|
Sim
|
Não
|
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Sim
|
|
RetroShare |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Não
|
Signal / Redphone |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Silent Phone |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Silent Text |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Skype |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
SnapChat |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Sim
|
StartMail |
Sim
|
Não
|
Sim
|
Não
|
Não
|
Sim
|
Não
|
SureSpot |
Sim
|
Sim
|
Sim
|
Não
|
Sim
|
Sim
|
Não
|
Telegram |
Sim
|
Não
|
Não
|
Não
|
Sim
|
Sim
|
Sim
|
Telegram (secret chats) |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
TextSecure |
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Sim
|
Threema |
Sim
|
Sim
|
Sim
|
Sim
|
Não
|
Sim
|
Sim
|
Viber |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
Virtru |
Sim
|
Não
|
Não
|
Não
|
Não
|
Sim
|
Sim
|
Sim
|
Sim*
|
Não
|
Não
|
Não
|
Não
|
Sim
|
|
Wickr |
Sim
|
Sim
|
Sim
|
Sim
|
Não
|
Não
|
Sim
|
Yahoo!Messenger |
Sim
|
Não
|
Não
|
Não
|
Não
|
Não
|
Não
|
Conclusão
*UPDATE! Whatsapp agora suporta criptografia de ponta a ponta, e portanto ganha vários pontos na avaliação, estando “menos longe” do Telegram em termos de segurança. Se torna uma alternativa viável, embora seja necessário analisar os demais critérios de acordo com sua preocupação com o comprometimento das chaves, auditabilidade do código e demais critérios do estudo.
Um agradecimento especial ao brother Ivo Peixinho, mestre em segurança da informação, pela lembrança para atualizar o post. Valeu! 🙂