Em continuação ao OpenPGP Email Summit, esta postagem de blog fornecerá um breve resumo de nossa experiência geral em relação ao evento. Estamos engajados com várias pessoas por trás de diferentes projetos baseados no OpenPGP, acadêmicos e outros indivíduos conscientes de segurança / privacidade de e-mail na quarta cúpula de e-mail do OpenPGP realizada por nós. O Mailfence é uma suíte de e-mail segura e privada que fornece aos usuários controle total sobre seus dados, e os participantes do 4º Encontro do OpenPGP consideraram o Mailfence uma parte útil e muito necessária de todo o ecossistema.
Mailfence - Obtenha seu e-mail seguro e gratuito.
4.1 baseado em 177 avaliações de usuários
Palestras do plenário e sessões abertas da 4ª Cúpula do e-mail OpenPGP (20-10-2018) – Dia 1
OpenPGP: palestra plenária
por Phill Zimmermann
O OpenPGP requer muitas melhorias. Vamos fazer acontecer.
– Livre-se das primitivas criptográficas antigas / obsoletas e use algoritmos / medidas criptográficas modernas, bem examinadas e livres de patentes nas versões procedentes do protocolo (o TLS 1.3 poderão servir como um bom exemplo).
– Chacha20, Poly1305 e AES são apenas alguns dos bons algoritmos (não goste do Galois / Counter Mode).
– Verificação de chaves: o modelo de confiança do OpenPGP é difícil de explicar para usuários não técnicos. Fazemos a verificação de impressões digitais de chaves públicas usando diferentes canais secundários que na maioria das vezes não são convenientes. As impressões digitais de chave pública podem ser transferidas por meio do protocolo WhatsApp / Signal / Wire, ZRTP e Signal no mesmo cliente (ou seja, telefone silencioso). A ideia é usar outro mecanismo / sistema em cima do OpenPGP para alavancar (re-inforce) a confiança, ao invés do atual modelo de confiança do PGP.
– Falta de efeito de rede no OpenPGP: devido à complexidade operacional, não conseguimos atingir mais usuários. Vamos passar por isso, tomando exemplos de sistemas que já alavancaram com sucesso o efeito de rede.
– Ansioso para as pessoas para quem estaria interessado em trabalhar na melhoria do OpenPGP.
OpenPGP: Reflexões sobre a integração da criptografia pós-quântica no OpenPGP
por Phill Zimmermann
– Devemos começar também a usar a criptografia pós-quântica no OpenPGP. A hora chegou.
– Chaves pós-quânticas podem ser enormes, não vamos transportar chaves, mas impressões digitais e baixá-las de alguns servidores de chaves da próxima geração.
O futuro
– Padrão atual RFC4880; Novo rascunho padrão RFC4880bis; Grupo de trabalho: https://tools.ietf.org/wg/openpgp/
– Retire as primitivas criptográficas antigas / obsoletas: cifras, algoritmos de compactação, … e outras opções de projeto (por exemplo, substitua MDC por AEAD).
– Livre-se de coisas antigas, reduza o máximo possível, enquanto ajusta os pontos de melhoria no quadro sintático existente.
– Use primitivas criptográficas modernas (por exemplo, apenas pares de chaves baseadas em ECC-curve25519 para novos usuários, …). Solte o suporte para legado (por exemplo, remova a opção para gerar chaves antigas baseadas em codificação, …) e mova-se na direção certa.
– Peça aos provedores de software do OpenPGP para manterem sua implementação atualizada nos dispositivos do usuário (por exemplo, usar algum tipo de atualização automática) e forçar os usuários a atualizarem seu par de chaves suspendendo o antigo (se necessário).
– O universo do OpenPGP é uma lixeira, precisamos modernizá-lo. Será preciso muita vontade política.
Outras palestras plenárias e informativas também foram dadas nos projetos AutoCrypt, DeltaChat e NextLeap (prevenção de MITM) pelos respectivos proprietários / membros do projeto.
OpenPGP: servidores de chaves SKS
por Kristian Fiskerstrand
– Pools do Keyserver: https://sks-keyservers.net/overview-of-pools.php
– Tópicos cobertos: Os novos requisitos do pool, desmontando IDs do usuário por motivos de privacidade, melhorando o desempenho do servidor de chaves
– O pool de servidores principais mantém atualmente 5 servidores executados por 2 operadores.
– Que dados devem manter o servidor de chaves? Devemos armazenar IDs de usuário? Não devemos permitir assinaturas de confiança externas em servidores-chave e usar um serviço diferente para isso? A SKS deve responder apenas a impressões digitais? Ou devemos fazer tudo isso opcional?
– Outros problemas de balanceamento de carga também existem.
– Para tornar os servidores-chave não intencionalmente ignorantes ao fornecer a chave correta, devemos executar as operações criptográficas (por exemplo, verificar as assinaturas de confiança e tomar uma decisão razoável) ou devemos abandonar toda essa noção do servidor principal para algum serviço externo?
– Implementações alternativas (não-Ocaml) também são bem-vindas (de preferência para requisitos mínimos).
– Outros mecanismos de descoberta de chaves: WKD (https://wiki.gnupg.org/WKD), servidor de chaves Mailvelope, …
– Quer saber o feedback da comunidade sobre tudo isso.
Para acompanhamento: Mailing list openpgp@ietf.org (https://www.ietf.org/mailman/listinfo/openpgp)
OpenPGP: Autocrypt level 2
por autores de especificação Autocrypt
– Discussão sobre o que sincronizar (Chave privada: mensagem de configuração de autocrypt, estado Autocrypt, catálogo de endereços, roteamento alternativo, preferências gerais do MUA: Signature / HTML / …, política de definição de regras, anel de chaves públicas, regras de filtragem, tags etc.)
– Propriedades para sincronizar: Fácil de usar, autenticado e confidencial, em andamento, automaticamente, mais de dois dispositivos
– Opções para obter sincronia: protocolo Kolab, mecanismo de emparelhamento, MLS: protocolo de mensagens de grupo, perda de mensagem de capa
– Risco / efeitos colaterais: Sincronização final com um dispositivo que você deseja sincronizar (evite canal de derivação de fio), exclusão / duplicação, falha de sincronização (exclusão de chaves, ….), movimento lateral após comprometimento
– Separe em múltiplas Camadas: Defina mecanismo de emparelhamento e sincronização (como estabelecer uma autenticação, canal não a sintaxe para sincronizar, …), armazenamento (IMAP, NextClout, Gdrive, …), o que é para sincronizar
– Counter MITM: Verificação de chave pessoal baseada no código QR da chave pública (automatizado com tokens de autenticação), Time-outs no fluxo de verificação (ainda não planejado, a ser discutido), chaves separadas armazenadas para diferentes contextos (grupos vs 1: 1), troca de chave inteira se algum bit for alterado na chave
– Autocriptografia e Webmail: os jogadores estão pensando em integrar autocriptografia (por exemplo, Mailfence, Mailvelope). A autocrypt não define técnicas para implementação e, na maioria das vezes, deixa essa escolha para o implementador seguir a melhor decisão em sua arquitetura de aplicativo.
– Embora a autocrypt não exija, os provedores de webmail assinam cabeçalhos Autocrypt usando o DKIM para garantir sua integridade.
OpenPGP: métodos de descoberta de chave múltipla
por DKKG, PM, Mailpile, GnuPG4Win / GpgOL, Mailfence, Startmail, …
– O MUA suporta vários métodos de descoberta de chaves: como lidar com eles e como usar diferentes respostas de descoberta de chaves de diferentes locais para tomar uma decisão lógica / razoável para a chave certa a ser usada.
– Métodos de descoberta de chaves existentes: Autocrypt (via email), WKD (via email), pool SKS (via email / keyid / fpr), servidor de chaves Mailvelope (via email / keyid / fpr), LDAP (via email / keyid / fpr) DNS (via email), Pilha de lixo por Kai e PEP (via e-mail / keyid / fpr), keybase.io (via nome de usuário / endereço de mídia social / fpr), substituição local (por exemplo, assinaturas locais em chaves importadas manualmente ou a lista de endereços)
– Confiança nos principais métodos de descoberta (via endereços de e-mail): o WKD está sendo usado pelo Protonmail, GpgOL, Enigmail, … e criptografa automaticamente as mensagens entre dois usuários cuja chave pública é conhecida pelo WKD.
– Classificação / ordenação e manipulação de colisão: quando os serviços usam vários métodos de descoberta de chave e obtêm várias respostas com diferentes chaves públicas. O Enigmal e o GnuPG têm uma lista em uma ordem na qual eles procuram chaves e tomam uma decisão razoável sobre qual chave usar. O servidor de chaves Mailvelope e a pilha de lixo retornam apenas um resultado.
– Quando várias chaves são encontradas: ações possíveis?
> Ranking – por validade ou outros critérios como a última subchave criada
> Criptografar para todos eles – tem a vantagem de haver o menor risco de que o destinatário não possa descriptografar a mensagem
> Escalar o problema para o usuário
…
– Preocupações de vazamento de metadados, cada fonte de descoberta de chave tem vazamento de metadados diferente, por exemplo, DNS é especialmente problemático, WKD só vaza o domínio, … Para pesquisa iniciar sem vazamento de metadados e pouca latência
OpenPGP: Representação da mensagem de validação de assinatura digital ao longo do tempo por XXX
– Parece que não temos uma representação unificada da representação da mensagem de validação de assinatura ao longo do tempo, nos casos em que a chave do assinante foi expirada / revogada depois que a assinatura foi feita.
– Não está claro o que significa uma assinatura ao longo do tempo, com um protocolo de armazenamento e envio como e-mail. Perguntas postas: Quais são as maneiras que uma assinatura válida / inválida afeta meu MUA? Olhando para mensagens antigas, e o status agora é diferente, isso afeta o que o meu MUA vai fazer?
– OpenPGP.js: Expiração e revogação são tratadas de forma diferente. Quando uma assinatura é verificada, a validade da chave é derivada do tempo de assinatura (o Protonmail usa o último registro de data e hora do cabeçalho recebido na maioria dos casos).
– GnuPG: usa timestamp na própria assinatura, se a chave não estava expirada, é considerada válida. Caso contrário, é inválido.
– MUAs diferentes exibem mensagem de validação de assinatura de forma diferente: Exigem mais testes de usabilidade
– Usando diferentes pontos de dados relacionados ao tempo, que podem ser considerados ao avaliar a validade da assinatura (resultados de validação de armazenamento em cache?) E, assim, exibir a mensagem de validação de assinatura correta para o usuário.
– Assinaturas e datas estão sendo usadas de maneiras muito diferentes em diferentes aplicativos de e-mail e deixam uma sala para muito mais conversas e aprendendo uns com os outros.
OpenPGP: cabeçalhos protegidos / furo de memória
por DKG, PM, Mailpile, GnuPG4Win / GpgOL, Mailfence, Startmail, …
– As especificações foram feitas em 2016, mas não evoluíram. IETF internet draft está chegando nos meses seguintes. Uma nova fonte com informações centralizadas seria mais (por exemplo, um site).
– Alguns clientes o implementam, mas ainda há implementação (por exemplo, problemas de encadeamento com assunto, …) e problemas de compatibilidade (por exemplo, o modo retroceder levando a mensagens ilegíveis, o MUA não está descriptografando essas mensagens …).
– Como a especificação ainda está evoluindo, é necessária uma coordenação no sentido de remover as especificações até um nível mínimo (por exemplo, começando com a criptografia do objeto e sem referências, etc. – isso serviria como uma boa base para continuar as iterações).
– Reduzir o recurso de pesquisa: a pesquisa com assunto real da mensagem não é possível.
– Também é necessário fornecer conselhos aos MUAs para diferentes aspectos, por exemplo, basta usar a primeira parte MIME dentro da mensagem criptografada, ‘Assunto criptografado’ como nome do sujeito também serve como indicador de segurança: Use “Sem Assunto” ou “Assunto indisponível” ou “Assunto Incorporado” ou “Assunto Oculta” – nenhum sujeito seria antipático pelas medidas de detecção de spam, não localize a sequência escolhida que possa revelar o idioma da mensagem real.
DIA 2:
OpenPGP: Servidores de chaves públicas e preocupações baseadas em GDPR
by DKG, PM, Mailpile, GnuPG4Win/GpgOL, Mailfence, Startmail, …
– A chave OpenPGP é PII. O upload automático de chaves sem o consentimento do usuário em linguagem clara e fácil de entender (a caixa de seleção não funciona porque não são tão claras e indicativas) está tornando os aplicativos GDPR-críticos.
– Os servidores de chaves públicas não receberam uma reclamação até agora por um DPA. Mas precisamos nos mover na direção certa.
– As pessoas realmente usam endereços de e-mail para encontrar chaves públicas, e isso funciona para as pessoas na maioria dos casos, por exemplo, servidor de chaves Mailvelope (mas isso baixa a federação e outros requisitos que temos no pool).
– Ideia: A marca neutra de um servidor de chaves é necessária, não use o mailvelope keyserver no OpenKeychain. O Keys.openpgp.org pode servir de lar para este novo servidor. Será gerenciado por um grupo pequeno, mas estável. As chaves devem ser verificáveis e elimináveis.
– Pontos de discussão: endereço de e-mail, assinatura de terceiros, quanto de uma solução drop-in queremos? Pesquisar somente por IDs completos (+ impressões digitais) e não substrings se IDs por motivos de desempenho?
– Interface: HKP? Deixe a escolha para as implementações do servidor principal (ou uma substituição imediata), em quais dados devem ser retornados (por exemplo, todas as IDs de chave?). Governança: Pergunte a qualquer organização sem fins lucrativos para executá-lo? (por exemplo, EFF)?
– O Gmail e alguns outros provedores usam determinado algoritmo para limpar (remover pontos, …) a parte local de um endereço de e-mail – o que quebrará a estratégia de correspondência exata. Poderia ser implementado em tabelas de consulta ou normalizar a representação de e-mail por meio de algum intermediário?
– Olhar para cima usando identificações de chave longas (64 bits) pode levar a colisões? Mais tarde, soltar longas identificações de chave, quando as impressões digitais estão em assinaturas
OpenPGP: Indicadores de segurança (spoofing HTML)
por DKG, PM, Mailpile, GnuPG4Win / GpgOL, Mailfence, Startmail,…
– Visualizar HTML leva a vários riscos: canais de ex-filtração? Desativá-los completamente? Ou permitir a visualização limitada de conteúdo externo?
– Indicadores na lista de mensagens? Preencher a linha do remetente ou outras partes que não podem ser manipuladas pelo corpo? Renderizar e-mails como somente texto, com um botão para permitir a visualização de HTML?
– Vários clientes têm problemas com o estado de assinatura única, o pgp inline é problemático especialmente para assinados em parcelas. Talvez, tenha apenas um estado de assinatura por mensagem (mas isso terá impacto imediato nas assinaturas da lista de discussão).
– Limitar o status criptográfico a “envelope criptográfico” versus “carga criptográfica” – use somente o conjunto de camadas de criptografia MIME no lado externo da mensagem. https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html
– Se houver um blob criptografado embutido em uma mensagem de texto não criptografado, deixe o usuário descriptografá-lo manualmente “?
– A Universidade de Bochum enviou e-mails para muitos MUAs sobre indicadores de IU spoofable. Devemos estar preparados para nos ligar a esse trabalho quando surgirem reclamações sobre a apresentação simplificada: https://www.golem.de/news/openpgp-gnupg-signaturen-faelschen-mit-html-und-bildern-1809-136738.html
– O espaço para cabeçalhos de segurança no nível da interface está sendo gerenciado de forma diferente por implementações. Muitas melhorias podem ser feitas, certificando-se de educar o usuário da maneira mais fácil de entender (por exemplo, mostrando um indicador detalhado por padrão, mas deixe-o minimizar o indicador enquanto aproveita a oportunidade para educá-lo em indicadores menores …)
OpenPGP: Timestamping para validação de assinatura
por Danny decock (COSIC-KU LEUVEN)
– Declaração de problema: A validação de assinatura digital do OpenPGP (na maioria das implementações) leva em conta o status atual (revogado / expirado) da chave do assinante e exibe uma mensagem de validação de assinatura imprecisa / confusa se a chave do assinante for revogada / expirada.
– Com base no status do par de chaves do signatário (válido / inválido) quando a assinatura foi feita (registro de data e hora), se válido – a assinatura digital permanece válida para sempre e vice-versa no outro caso.
– Manter estados: use um terceiro confiável para manter registros de data e hora e forneça informações de validação de assinatura em caso de conflito.
– Ou use as árvores merkel para combinar diferentes valores de hash (usando a ordem dos nós) para verificar. Por exemplo, o receptor de mensagens pode obter todas as assinaturas obtidas e manter um registo do mesmo (por exemplo, numa base de dados baseada na árvore Merkle) que pode ser utilizado como um meio verificável que pode ser produzido em tribunal.
– Em caso de revogação da chave do assinante, sempre haverá um tempo entre o momento em que a chave foi realmente comprometida (o que pode ser desconhecido para o usuário) e quando ela foi realmente revogada pelo usuário. Qualquer assinatura feita durante esse período seria considerada maliciosa. No caso de ter uma autoridade confiável, o retorno pode ser feito na última assinatura verificada (feita pelo usuário quando a chave não foi comprometida).
– Além do ponto acima, em vez de ter uma autoridade confiável, podemos pedir ao assinante da mensagem que publique o último estado verificado da chave em algum canal público (por exemplo, servidores de chaves públicas, outros canais, …) que serve como um ponto de dados para o último estado verificado (que pode ser usado para tomar uma decisão razoável, por exemplo, tempo de assinatura versus último estado verificado?).
Slides de sessão: http://homes.esat.kuleuven.be/~decockd/slides/20181021.signature.validation.pdf
OpenPGP: exibição de validação de assinatura
por
– A exibição da mensagem de validação de assinatura é diferente em várias implementações.
– A mensagem de validação de assinatura também precisa informar ao usuário que uma assinatura válida não significa que a chave do assinante usada para assinar a mensagem pertence ao proprietário de direito. Pode haver um segundo parâmetro que faça uma declaração sobre a confiança na chave do assinante.
– Algumas implementações também fornecem informações de verificação de endereço do remetente além da própria assinatura digital.
– As assinaturas são feitas sem contexto, as implementações podem fornecer opções, por exemplo, sempre assinar para este destinatário com esta impressão digital, etc.
– Uma apresentação geral da mensagem de validação de assinatura digital pode ser um estado binário, se uma mensagem for válida ou não.
OpenPGP: e-mail excluído
Conversa principal: Daniel Kahn Gillmor
– Definindo email deletável: verifique o período de tempo em que o email pode ser lido.
– Uma tentativa de reenquadrar “sigilo de encaminhamento” e adotá-lo para um formato de mensagem de arquivamento, como e-mail.
– OpenPGP pode usar sub-chaves de rotação frequente para conseguir a mesma coisa (com uma janela de tempo maior). Mas fazer as pessoas mudarem é um desafio, especialmente onde você não pode ler e-mails antigos, o que não é desejável.
Os emails devem ser arquivados? Isso é uma contradição ao ‘sigilo antecipado’. No entanto, muitos argumentam que o arquivamento de e-mails é uma característica tanto nos casos de uso corporativo (por exemplo, por motivos de conformidade) quanto nos casos de uso pessoal (por exemplo, os usuários mantêm e-mails por opção).
Algumas implementações (por exemplo, NotMuch) armazenam a chave de sessão (simetricamente criptografada), enquanto permitem que os usuários excluam / girem (assimétricas) as chaves e permitem que os usuários ainda leiam a mensagem criptografada antiga. Outra abordagem seria re-criptografar todas as mensagens para uma chave local.
– Não há política de exclusão automática em clientes de email. Sob alguns mensageiros (instantâneos) permitem isso. Outras opções também podem ser exploradas nesta política de exclusão automática, por exemplo, em cabeçalhos de email, anotações de subchave etc. No entanto, a execução pode exigir acordos de ligações bilaterais / mútuas.
– Excluir um email localmente não é suficiente, pois sempre há algo que pode ser recuperado. Os usuários podem simplesmente tirar uma captura de tela ou usar qualquer outro canal lateral para manter uma cópia desse email.
– Algumas pesquisas nessa área foram propostas para uma subchave diferente para cada mensagem. No entanto, isso leva a problemas comuns (por exemplo, ambientes com vários dispositivos, …).
– A exclusão de e-mails depois que uma pequena janela (por exemplo, uma semana) ou semestral seria uma melhoria em contraste com mantê-los por tempo indeterminado?
– Idéia: pré-gerar e publicar chaves para ‘rotação pesada’, permitindo a comunicação de peças para uma chave particular por um curto período de tempo, e uma chave diferente. No entanto, a rotação frequente pode levar as pessoas a consultar frequentemente os principais servidores, o que pode levar a meta-dados (IP, destinatário, …). Requerer canais fora da banda para acessar.
– Falando de pequena janela, os e-mails podem ser um dia para serem entregues. Precisamos descobrir qual seria o momento adequado.
OpenPGP: https://sequoia-pgp.org/talks/2018-08-moving-forward/moving-forward.pdf https://www.youtube.com/watch?v = an6oYjikAPY
Os grupos de trabalho foram seguidos por uma sessão de encerramento, e o dia terminou com uma sessão de colaboração / hacking entre diferentes projetos do OpenPGP, com muitas palestras úteis. Uma versão mais detalhada das sessões Q / A, pode ser encontrada aqui.
Estamos felizes por termos tido a oportunidade de sediar a Cúpula de E-mail do OpenPGP e ganhar, compartilhar e trocar conhecimentos sobre tópicos importantes que contribuirão para moldar o futuro do OpenPGP. Isso também ajuda a aumentar a capacidade da Internet de se conectar com outras pessoas no campo da segurança. Aguardamos ansiosamente novos desenvolvimentos em todos os tópicos em várias conversas plenárias / sessões abertas / palestras paralelas e continuaremos apoiando qualquer outra iniciativa.
Muito obrigado a:
- Patrick Brunschwig do Enigmail por reunir todas estas pessoas excelentes para esta cimeira
- The Renewable Freedom Foundation por financiar jantares
- O incrível público do 4º OpenPGP Email Summit
O Mailfence é uma suíte de e-mail segura e privada que fornece aos usuários controle total sobre seus dados. Acesse a nossa página de imprensa para saber mais sobre a Mailfence.
Junte-se à luta pela privacidade online e pela liberdade digital.
Tem perguntas sobre O 4º Encontro de E-mail OpenPGP? Não hesite em contatar-nos (suporte em mailfence ponto com).
Siga-nos no twitter/reddit e mantenha-se informado em todos os momentos.
