0fc

端到端谨慎的网络聊天与强密码学

0FC使您可以使用隔离的聊天室进行安全的浏览器组聊天，并具有一些特殊功能：

• 特定聊天室的端到端：服务器不能比DOS攻击更好
• 服务器被认为是最小信任的区域，所有重要操作发生在客户端：
  • 用于保护聊天室流量的短暂键是在房间所有者的浏览器中产生的，并传播到其余的
  • 秘密令牌用于访问聊天室，是在客户端生成的（尽管部分验证发生在服务器端）
• 在密钥共享期间，每个服务消息都受密钥保护，来自多个一方的随机数据
• 外向消息被加密并仅发送一次（所有房间成员共享相同的对称密钥）
• 一次使用秘密访问令牌（在密钥确认后删除）

0FC作为测试游乐场的开始，用于某些复杂的themis/webthemis，但变得足够有趣，可以将其释放为单独的代码斑点。

重要的是：要被认为是真正安全的，0FC应由第三方验证并正确部署。没有第三方审核，不得信任加密工具。在此之前（如果有的话），本文档末尾有一个协议描述，它使您可以查看0FC的内部工作原理并做出自己的判断。我们自己知道一些与密码学无关的很少可能的威胁，而是浏览器的工作方式（请参阅博客文章的威胁模型部分）。

0FC后端用Python编写，前端基于WebThemis，因此仅在基于Google Chrome的浏览器中起作用（尚未）。

0FC通过Apache 2许可获得许可。如果您基于此代码和0FC的协议构建某些内容，我们会很高兴；如果您需要任何帮助，请联系。

阅读博客文章，以了解有关0FC和基础技术的更多信息。

安装和使用

0FC由两个组件组成：服务器和客户端。

0FC服务器

0FC服务器需要：

• Python 3.4
• pip
• 主题（建筑和安装）

首先，您需要安装Python依赖项：

 pip install -r requirements.txt

这样做之后，您可以运行服务器：

 python3 server.py

默认情况下，服务器将收听端口5103。要更改端口add -p <port> ：

 python3 server.py -port 333

0FC客户端

0FC客户端已经在 /静态 /文件夹中编译。请记住，它的服务器键进行了硬编码；如果您重新生成钥匙，则需要重建客户端（请参见下文）。

使用0FC

...很不言而喻。您可以创建新房间，生成令牌并邀请人们加入，或输入现有的令牌进入房间。

重建0FC客户端

如果您想自己重新编译0FC客户端（PNACL对象），这就是您要做的：

1. 要构建PNACL对象，您需要安装NACL SDK并使用已安装SDK文件的路径创建Enviromant变量PNACL_ROOT 。
2. 克隆0FC存储库，带有GitHub的子模块：

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

3. 构建网络电视：

 cd webthemis
make

4. 构建0FC PNACL模块：

 cd ..
make

你完成了！

建筑学

0FC由2个经典组件组成：客户端和服务器。

客户负责：

• 向用户显示UI
• 所有密码和信任管理功能
• 与继电器服务器通信

服务器负责：

• 通过HTTP将UI + PEXE（PNACL模块）提供给客户
• 运行Websocket继电器服务，该服务接收消息并将其传递给所有人。

通过Websocket链接，客户通过确保Themis对象与服务器进行交谈，该对象提供了高级运输安全性。服务器密钥被硬编码为客户端，因此基于实际服务器密钥与二进制客户端的服务器密钥之间的相关性建立了信任。

在此确保链接中，传输了证券电路加密的消息。

协议和方案

房间创造

• 房间所有者生成一个钥匙对[client]
• 房间所有者生成房间钥匙（将用于加密房间中的消息） [client]
• 房间所有者请求服务器创建房间，接收房间ID以响应[client] + [server]

邀请他人（密钥共享）

• 房间所有者生成一个随机的（一次性）邀请令牌[client]
• 房间所有者发送一些带外频道的邀请（例如电子邮件），其中包括邀请令牌，他的公钥和房间ID [client]
• 用户收到邀请令牌[client]
• 用户生成一个密钥对[client]
• 用户生成随机加入密钥[client]
• 用户通过服务器将安全消息发送给房间所有者，并加入密钥[client]
• 服务器可以检查ACL是否有效，并将消息传递给房间所有者[server]
• 房间所有者解开加入密钥[client]
• 房间所有者使用服务器将密封的房间密钥发送给用户，使用加入密钥作为主密钥，并邀请令牌作为上下文[client]
• 服务器可以检查ACL是否有效，并将消息传递给用户[server]
• 用户解开房间密钥[client]
• 用户向房间所有者发送确认密封消息。 [client]
• 所有者，检查用户确认消息签署其公共密钥，并发送到服务器[client] + [server]
• 服务器检查签名并考虑将用户添加到聊天室[server]
• 使用邀请令牌后，它将被房间所有者[server]丢弃

消息交换

• 房间成员交换消息将它们用房间钥匙密封。服务器只是将加密的消息转发，而无需访问其内容。 [server]

密钥管理

• 每个房间都会生成Keypair [client]
• Keypair存储在浏览器持久存储[client]中
• 浏览器持久存储使用安全单元格（密封模式），从用户密码得出的密钥，加入聊天时输入[client]

服务器通信

• 客户使用Themis Secure Session [server]与服务器通信
• 服务器可信赖的公钥在客户端中进行了硬编码[client]
• 服务器不执行客户端身份验证，而是自动信任每个SS客户端密钥（如果安全性比无处不在和匿名更重要，这是硬化的第一步） [server]

钥匙旋转

• 每100条（可配置的）消息发送和接收，房间所有者会生成新密钥，使用旧密钥对其进行加密，并发送特殊消息[client]
• 服务器强制执行此类消息可能仅来自房间所有者[server]

房间编排

• 每个房间都保留一个成员列表，作为公共钥匙列表（+指示谁是房间所有者） [server]
• 每个房间都有一个房间所有者（最初是房间创建者） [server]
• 房间所有者负责钥匙旋转[client]

聊天历史

• 服务器使客户自上次出发以来就可以获取聊天历史记录[server]
• 服务器使客户能够获取聊天历史记录以来新成员的最后一个密钥旋转[server]

想知道更多吗？

阅读我们的博客文章，其中具有有关0FC开发和各种安全考虑因素的背景。