bate-papo da web de ponta a ponta com forte criptografia
0FC permite que você execute um bate-papo seguro em grupo no navegador com salas de bate-papo isoladas, com alguns recursos especiais:
- ponta a ponta para sala de bate-papo específica: o servidor não pode fazer melhor do que o ataque do DOS
- O servidor é considerado uma zona confiável mínima, todas as operações importantes acontecem no lado do cliente:
- As chaves efêmeras usadas para proteger o tráfego da sala de bate -papo são geradas no navegador do proprietário da sala e propagadas para o resto
- Tokens secretos, usados para dar acesso à sala de bate -papo, são gerados no lado do cliente (embora parte da verificação aconteça no lado do servidor)
- Durante o compartilhamento de chaves, todas as mensagens de serviço são protegidas por chaves, derivadas de dados aleatórios de mais de uma parte
- As mensagens de saída são criptografadas e enviadas apenas uma vez (todos os membros da sala compartilham a mesma chave simétrica)
- O token de acesso secreto é usado uma vez (excluído após a confirmação -chave)
O 0FC foi iniciado como testando playground para alguns casos de uso sofisticados de Themis/Webthemis, mas se tornou interessante o suficiente para lançá-lo como uma bolha separada de código.
Importante: Para ser considerado realmente seguro, o 0FC deve ser validado por terceiros e implantado corretamente. Nenhuma ferramenta criptográfica deve ser confiável sem auditoria de terceiros. Antes que isso aconteça (se é que acontece), há uma descrição do protocolo no final deste documento, que permite dar uma olhada no funcionamento interno do 0FC e fazer seu próprio julgamento. Nós mesmos estamos cientes de algumas ameaças raramente possíveis não relacionadas à criptografia, mas à maneira como o navegador funciona (consulte a seção do modelo de ameaça da postagem do blog).
O backend 0FC está escrito em Python, o front-end é baseado em webtheMis, por isso funciona apenas nos navegadores baseados no Google Chrome.
0FC é licenciado via licença Apache 2. Ficaríamos felizes se você construir algo com base neste código e no protocolo da 0FC; Se você quiser alguma ajuda com isso, entre em contato.
Leia a postagem do blog para saber mais sobre o 0FC e as tecnologias subjacentes.
Instalando e usando
0FC consiste em dois componentes: um servidor e cliente.
0FC Server
O servidor 0FC requer:
- Python 3.4
- pip
- Themis (construindo e instalando)
Primeiro, você precisará instalar dependências do Python:
pip install -r requirements.txt
Tendo feito isso, você pode executar o servidor:
Por padrão, o servidor ouvirá a porta 5103. Para alterar a porta Add -p <port> :
python3 server.py -port 333
0FC Client
O cliente 0FC já vem compilado em / estática / pasta. Lembre -se de que possui as teclas do servidor codificadas; Se você regenerar as chaves, precisará reconstruir o cliente (veja abaixo).
Usando 0fc
... é bastante auto-explicativo. Você pode criar uma nova sala, gerar tokens e convidar as pessoas para participar ou entrar no token existente para entrar na sala.
Reconstruindo o cliente 0FC
Se você quiser recompilar o cliente 0FC (objeto pnacl), aqui está o que você deve fazer:
- Para criar o objeto PNACL, você precisa instalar o NACL SDK e criar
PNACL_ROOT enxerto com o caminho para os arquivos SDK instalados. - CLONE 0FC Repositório com submódulos do GitHub:
git clone https://github.com/cossacklabs/0fc
cd 0fc
git submodules update --init --recursive
- Construa webthemis:
- Construa 0fc módulo pnacl:
Você terminou!
Arquitetura
0FC consiste em 2 componentes clássicos: cliente e servidor.
Os clientes são responsáveis por:
- mostrando a interface do usuário ao usuário
- todas as funções de gerenciamento criptográfico e de confiança
- Comunicação com o servidor de retransmissão
O servidor é responsável por:
- Servindo interface do usuário + pexe (módulo pnacl) para os clientes via http get
- Executando o WebSocket Relay Service, que recebe mensagens e as transmite para todos.
Sobre o link do WebSocket, os clientes conversam com o servidor via objeto SecureSession Themis, que fornece segurança de transporte de alto nível. As teclas do servidor são codificadas nos clientes, portanto, a confiança é estabelecida com base na correlação entre a chave do servidor real e a chave do servidor alimentada para o cliente em binários.
Dentro deste link de segurança, são transmitidas mensagens criptografadas em SecureCell.
Protocolo e esquema
Criação de quartos
- O proprietário da sala gera um par de chaves
[client] - O proprietário do quarto gera chave do quarto (que será usada para criptografar mensagens na sala)
[client] - O proprietário da sala solicita o servidor para criar a sala, recebendo ID da sala em resposta
[client] + [server]
Convidando outras pessoas (compartilhamento de chaves)
- O proprietário da sala gera um token de convite aleatório (único)
[client] - O proprietário da sala envia um convite de alguns canais fora da banda (como email), que inclui o token de convite, sua chave pública e ID da sala
[client] - O usuário recebe o token de convite
[client] - O usuário gera um par de chaves
[client] - Usuário gera chave de união aleatória
[client] - O usuário envia uma mensagem segura para o proprietário da sala através do servidor com key de ingresso criptografado
[client] - O servidor pode verificar se este convite é válido e passar a mensagem para o proprietário da sala
[server] - Proprietário da sala DesembrAps ingressando na chave
[client] - O proprietário da sala envia a chave da sala selada para o usuário através do servidor usando a chave de junção como chave mestre e convidar token como contexto
[client] - O servidor pode verificar se essa resposta é válida e passar a mensagem para o usuário
[server] - O usuário não sai da chave da sala
[client] - O usuário envia uma mensagem selada de confirmação para o proprietário da sala.
[client] - Proprietário, ao verificar os usuários confirmar a mensagem de confirmação de sua chave pública e envia para o servidor
[client] + [server] - O servidor verifica a assinatura e considera o usuário adicionado à sala de chat
[server] - Depois de convidar token, é descartado pelo proprietário da sala
[server]
Troca de mensagens
- Os membros da sala trocam mensagens que os selando com a chave do quarto. O servidor apenas encaminha mensagens criptografadas sem ter acesso ao seu conteúdo.
[server]
Gerenciamento -chave
- O Keypair é gerado para cada quarto
[client] - O Keypair é armazenado no navegador de armazenamento persistente
[client] - O armazenamento persistente do navegador é criptografado com célula segura (modo de vedação), chave derivada da senha do usuário, entradas ao ingressar no chat
[client]
Comunicação do servidor
- Os clientes se comunicam com o servidor usando a sessão segura de eles
[server] - A chave pública confiável do servidor é codificada nos clientes
[client] - O servidor não executa a autenticação do cliente, confia automaticamente em todas as chaves do cliente SS (este é o primeiro passo óbvio para endurecer se a segurança for mais importante que a ubiquity e o anonimato)
[server]
Rotação de chaves
- Cada 100 mensagens (configuráveis) enviadas e recebidas, o proprietário da sala gera nova chave, a criptografa com a chave antiga e envia uma mensagem especial
[client] - O servidor aplica essas mensagens só pode vir do proprietário da sala
[server]
Orquestração de quarto
- Uma lista de membros é mantida para todos os cômodos como uma lista de chaves públicas (+indicação de quem é o proprietário da sala)
[server] - Cada quarto tem um proprietário de quarto (originalmente, criador de quarto)
[server] - O proprietário da sala é responsável pela rotação chave
[client]
História do bate -papo
- O servidor permite que os clientes busquem histórico de bate -papo desde sua última partida para membros que estavam online e conhecem as chaves antes da rotação
[server] - O servidor permite que os clientes busquem histórico de bate -papo desde a última rotação de teclas para novos membros
[server]
Quer saber mais?
Leia nossa postagem no blog com alguns antecedentes sobre o desenvolvimento 0FC e várias considerações de segurança.
