返回 登录
0

Secret背后的技术架构与安全实践

Secret作为一个创业项目虽然失败了,但这一过程却留下了不少值得汲取的经验和教训。2014年2月发布4天后,创始人David Byttow曾经在Medium上介绍了Secret的技术架构和安全实践,打消用户对隐私暴露的担心。下面是一些要点。

  • Secret本身寄存在GAE上,主要用Go语言开发,部分组件用的是Java和Python。这些都很自然,因为Byttow是Google出来的。
  • 数据放在Google数据中心的服务器中,这个数据中心还有一个大应用,就是Gmail,因此物理安全是令人放心的。
  • 所有线上的通信都用TLS加密。
  • 存储层用的是基于BigTable的高可用、非关系型数据存储,没有关系性数据库。
  • 所有消息数据在写入数据库之前都已加密,密钥保存在独立的密钥存储服务中。
  • 图片存储在Google的Cloud Storage里,通过Google的图片前端经TLS提供。
  • 对于从手机上获取的通讯录数据,会在本地散列化(这一转换是单向的),然后将散列值存到服务器中,服务器端只用散列值进行其他处理。所以Secret本身不知道用户的电话号码和其他数据。当然,如果攻击者获取了散列所用的salt值(这是全局共享的),仍然可能反推出来。Secret还在研究更安全的办法,比如加入客户端特定的数据预散列,或者Diffie-Hellman密钥交换。
  • 用户发送的秘密元数据保存时不会引用用户信息。秘密发给一个用户时,会为用户生成唯一的令牌,将其授权给秘密信息,是多对一的关系。令牌资源放在秘密而非用户拥有的一个ACL中。秘密极其评论的数据都在服务器端加密,当有令牌时解密。所以,显示秘密信息时,不需要个人身份数据。
  • 用户、秘密消息和ACL等数据结构的存储都是逻辑隔离的。
  • 身份方面,管理者不能查看或者修改特定用户的发送的秘密。如果为管理、调试或者其他目的,需要访问和修改这些信息的话,遵守两人规则,即必须两人同时进行、互相监督,一般情况下是两位创始人同时用自己的Google账号登录(并受双因鉴别保护),在同一时间请求同一资源。这种实践被Cloudflare称为红十月
  • 信息推送方面,设计目标是安全、快速、基于学习算法。秘密消息首先保存并发送给作者,然后运行一个异步作业,依据算法来决定还会推送给谁(可能是与作者有关系或者系统认为有关联的人)。通讯录是算法中的强信号,但不会推送给通讯录上的所有人。每个推送对于每个用户都是不同的,可以撤销,有助于识别和减少垃圾信息和其他无益的行为。
  • 推送时机方面,虽然推送管道的吞吐量很大,但并不是总是立即推送。系统中用户的朋友越少,推送的信息也越少。有助于避免用一些简单的办法隔离一些用户及其秘密消息。(?)用户在系统中朋友足够多了之后,看到的信息也越多,比如秘密来自朋友圈(朋友和朋友的朋友)。朋友再多一些,会看到来自朋友或者非朋友。这对于匿名环境中建立联系是至关重要的。
评论