0fc

chat web discreto de extremo a extremo con criptografía fuerte

0FC le permite ejecutar un chat de grupo seguro en el navegador con salas de chat aisladas, tener algunas características especiales:

• De extremo a extremo para sala de chat específica: el servidor no puede hacerlo mejor que el ataque de DOS
• El servidor se considera una zona de confianza mínima, todas las operaciones importantes ocurren en el lado del cliente:
  • Las claves efímeras utilizadas para proteger el tráfico de la sala de chat se generan dentro del navegador del propietario de la sala y se propagan al resto
  • Los tokens secretos, utilizados para dar acceso a la sala de chat, se generan en el lado del cliente (aunque parte de la verificación ocurre en el lado del servidor)
• Durante el intercambio de clave, cada mensaje de servicio está protegido por claves, derivadas de datos aleatorios de más de una parte
• Los mensajes salientes están encriptados y enviados solo una vez (todos los miembros de la sala comparten la misma clave simétrica)
• El token de acceso secreto se usa una vez (eliminado después de la confirmación de la clave)

0FC se inició como un patio de recreo para algunos casos de uso sofisticados de themis/Webthemis, pero se volvió lo suficientemente interesante como para liberarlo como un blob de código separado.

IMPORTANTE: Para considerarse realmente seguro, 0FC debe ser validado por terceros e implementados correctamente. No se debe confiar en ninguna herramienta criptográfica sin auditoría de terceros. Antes de que eso suceda (si alguna vez lo hace), hay una descripción del protocolo al final de este documento, que le permite echar un vistazo al funcionamiento interno de 0FC y hacer su propio juicio. Nosotros mismos somos conscientes de algunas amenazas raramente posibles no relacionadas con la criptografía, sino de la forma en que funciona el navegador (consulte la sección Modelo de amenazas de la publicación de blog).

0FC Backend está escrito en Python, el front-end se basa en Webthemis, por lo que funciona solo en navegadores basados en Google Chrome (todavía).

0FC tiene licencia a través de la licencia Apache 2. Estaríamos contentos si construye algo basado en este código y el protocolo de 0FC; Si desea ayuda con esto, póngase en contacto.

Lea la publicación del blog para obtener más información sobre 0FC y tecnologías subyacentes.

Instalación y uso

0FC consta de dos componentes: un servidor y un cliente.

Servidor 0FC

El servidor 0FC requiere:

• Python 3.4
• pepita
• themis (construcción e instalación)

Primero, deberá instalar dependencias de Python:

 pip install -r requirements.txt

Después de haberlo hecho, puede ejecutar el servidor:

 python3 server.py

Por defecto, el servidor escuchará el puerto 5103. Para cambiar el puerto Agregar -p <port> :

 python3 server.py -port 333

Cliente 0FC

El cliente 0FC ya viene compilado en / carpeta / carpeta. Tenga en cuenta que tiene claves de servidor duras; Si regenere las claves, deberá reconstruir el cliente (ver más abajo).

Usando 0FC

... se explica por sí mismo. Puede crear una habitación nueva, generar tokens e invitar a las personas a unirse, o ingresar al token existente para ingresar a la habitación.

Reconstrucción del cliente 0FC

Si desea recompilar el cliente 0FC (objeto pnacl) usted mismo, esto es lo que tiene que hacer:

1. Para construir el objeto PNACL, debe instalar NACL SDK y crear una variable de entorno PNACL_ROOT con ruta a archivos SDK instalados.
2. Repositorio Clone 0FC con submódulos de GitHub:

 git clone https://github.com/cossacklabs/0fc
cd 0fc
git submodules update --init --recursive

3. Construir webthemis:

 cd webthemis
make

4. Build 0FC Módulo PNACL:

 cd ..
make

¡Ya terminaste!

Arquitectura

0FC consta de 2 componentes clásicos: cliente y servidor.

Los clientes son responsables de:

• Mostrando la interfaz de usuario al usuario
• Todas las funciones de gestión criptográfica y de confianza
• Comunicación con el servidor de retransmisión

El servidor es responsable de:

• servir ui + pexe (módulo pnacl) a los clientes a través de http get
• Ejecutar el servicio de retransmisión de WebSocket, que recibe mensajes y los transmite a todos.

A través del enlace WebSocket, los clientes hablan con el servidor a través del objeto Securesession Themis, que proporciona seguridad de transporte de alto nivel. Las claves del servidor están codificadas en los clientes, por lo que la confianza se establece en función de la correlación entre la clave del servidor real y la clave del servidor alimentado al cliente en binarios.

Dentro de este enlace de aseguramiento, se transmiten los mensajes cifrados de SecureCell.

Protocolo y esquema

Creación de habitación

• El propietario de la habitación genera un par de claves [client]
• El propietario de la habitación genera una llave de habitación (que se utilizará para cifrar mensajes en la habitación) [client]
• El propietario de la habitación solicita al servidor que cree la habitación, recibiendo ID de habitación en respuesta [client] + [server]

Invitar a otros (compartir clave)

• El propietario de la habitación genera un token de invitación aleatorio (único) [client]
• El propietario de la sala envía una invitación por algún canal fuera de banda (como el correo electrónico), que incluye token de invitación, su clave pública y su identificación de la habitación [client]
• El usuario recibe el token de invitación [client]
• El usuario genera un par de claves [client]
• El usuario genera la clave de unión aleatoria [client]
• El usuario envía un mensaje seguro al propietario de la habitación a través del servidor con la clave de unión cifrada [client]
• El servidor puede verificar a través de ACL si esta invitación es válida y pasar el mensaje al propietario de la habitación [server]
• El propietario de la habitación se desenvuelve la tecla de unión [client]
• El propietario de la habitación envía una tecla de habitación sellada al usuario a través del servidor utilizando la tecla de unión como clave maestra e invitar al token como contexto [client]
• El servidor puede verificar a través de ACL si esta respuesta es válida y pasar el mensaje al usuario [server]
• El usuario se revela la tecla de habitación [client]
• El usuario envía un mensaje sellado de confirmación al propietario de la habitación. [client]
• Propietario, al verificar los usuarios, el mensaje de confirmación firma su clave pública y envía al servidor [client] + [server]
• El servidor verifica la firma y considera que el usuario se agregó a la sala de chat [server]
• Una vez que se ha utilizado el token de invitación, el propietario de la habitación [server]

Intercambio de mensajes

• Los miembros de la sala intercambian mensajes que los sellan con la llave de la habitación. El servidor solo reenvía mensajes cifrados sin tener acceso a su contenido. [server]

Gestión clave

• Se genera KeyPair para cada habitación [client]
• Keypair se almacena en el navegador almacenamiento persistente [client]
• El almacenamiento persistente del navegador está encriptado con celda segura (modo de sello), clave derivada de la contraseña del usuario, entradas al unirse al chat [client]

Comunicación del servidor

• Los clientes se comunican con el servidor utilizando la sesión segura de themis [server]
• La clave pública de confianza del servidor está codificada en los clientes [client]
• El servidor no realiza la autenticación del cliente, confía automáticamente cada clave del cliente SS (este es el primer paso obvio para endurecer si la seguridad es más importante que la ubicuidad y el anonimato) [server]

Rotación de llave

• Cada 100 mensajes (configurables) enviados y recibidos, el propietario de la habitación genera nueva clave, la cifra con la clave anterior y envía un mensaje especial [client]
• El servidor aplica tales mensajes solo pueden provenir del propietario de la habitación [server]

Orquestación de la habitación

• Se mantiene una lista de miembros para cada habitación como una lista de claves públicas (+indicación de quién es el propietario de la habitación) [server]
• Cada habitación tiene un propietario de una habitación (originalmente, creador de habitaciones) [server]
• El propietario de la habitación es responsable de la rotación clave [client]

Historia de chat

• El servidor permite a los clientes obtener el historial de chat desde su última partida para los miembros que han estado en línea y conocen claves antes de la rotación [server]
• El servidor permite a los clientes obtener el historial de chat desde la última rotación de la clave para nuevos miembros [server]

¿Quieres saber más?

Lea nuestra publicación de blog con algunos antecedentes sobre el desarrollo de 0FC y varias consideraciones de seguridad.