安全与密码学2016arxiv.org
ZeroDB白皮书：端到端加密数据库
ZeroDB white paper: An end-to-end encrypted database
进阶 · 约 60 分钟读完前置知识：B-Tree 索引、加密学基础、客户端-服务器架构
导读
ZeroDB 是一个端到端加密数据库的白皮书：数据在客户端加密后存储在不可信服务器上，服务器通过 B-Tree 索引协助查询，但客户端在遍历索引时逐步取回并解密节点，服务器始终不知道加密密钥和明文内容。这样在保持查询能力的同时实现数据机密性。
HN 关注点：端到端加密数据库的可行性，讨论焦点集中在方案泄露的信息（访问模式、范围查询）以及性能与密钥管理上的安全隐患。
HN 评论精选
这几条评论里：质疑 2 补充 2
质疑质疑论文的机密性声明：访问模式会泄露节点顺序信息，主动攻击者可做交叉查询推断，且多客户端写协调未说明。
概念很有意思，但不同意论文中“服务器只能知道哪些桶是叶节点/分支节点，而不知道子节点在父节点左边还是右边”的说法。范围查询会泄露返回块的数量和身份——树中顺序越接近的节点越可能被同一请求触及，被动攻击者可借此推断加密节点的相对顺序。主动攻击者问题更严重：若能诱导客户端对两个不同字段分别做索引查询，通过观察两次查询共同触及的节点就能提取大量信息。另外论文没说明 B-Tree 如何修改——若只有客户端能解密节点，节点分裂合并就由客户端负责，多客户端之间是否需要分布式协调以免互相覆盖？
teraflop查看英文原文
Interesting concept. I disagree with this statement from the "Data confidentiality" section: > Unlike CipherBase [6], our approach doesn’t leak information about the order of the elements. By observing access patterns, the server can only figure out which buckets are leaf nodes and which are branch nodes, but not whether the child node is located to the left or right of the parent node. The paper correctly notes that when a client does a range query, it leaks information about the total number of blocks returned. However, if I've understood correctly, it also leaks the identities of those blocks. The closer two tree nodes are in order, the more likely they are to be touched by the same request. A passive adversary could use this to extract information about the relative ordering of encrypted nodes. Also, active adversaries cause much worse problems. Let's say I have the ability to cause someone to do queries on the encrypted database, without observing the results. By simply doing separate index lookups on two different fields, I can extract a lot of information by looking at which nodes were touched by both queries. Finally, I noticed that the paper doesn't describe how the B-trees are modified. If the client is the only party that knows how to decrypt nodes, then it's responsible for splitting and merging nodes to keep the tree balanced. Doesn't this require some kind of distributed coordination, so that multiple clients don't trample on each other's changes?
补充认为这是 FHE 之外的好方案，但担心逐层遍历索引的多轮网络往返会带来性能问题。
看起来很有意思，算是仅次于全同态加密（FHE）的方案？但代价应该是性能：客户端查询时要逐层远程遍历索引、取回并解密桶才能决定下一层取哪些，多次网络往返可能很慢。频繁访问的桶可以客户端缓存来减少网络调用。不知道有没有对性能不敏感的特定使用场景？希望有更懂行的人来评论，真希望能用上这样的数据库。
saganus查看英文原文
This looks very interesting. I guess that this would be the next-best thing after FHE?. The catch is the performance, right? I mean, the paper says: "In order to make the database end-to-end encrypted yet still capable of performing queries, the client encrypts the buckets (at the time of creation or modification). The server, which stores the buckets, never knows the encryption key used. The objects referenced by the leaf nodes of the B-Tree indexes are also encrypted client-side. As a result, the server doesn’t know how individual objects are organized within the B-Tree or whether they belong to an index at all. Since ZeroDB is encryption agnostic, probabilistic encryption can ensure that the server cannot even compare objects for equality. When a client performs a query, it asks the server to return buckets of the tree as it traverses the index remotely and incrementally, as in Fig. 2b. The client fetches and decrypts buckets in order to figure out which buckets in the next level of the tree to fetch next. Frequently accessed buckets can be cached client-side so that subsequent queries do not make unnecessary network calls." Which would suggest that it might be a bit slow to do many round-trips for each query. I'm guessing there could be some specific use-cases where this is not so relevant? I would love to have some more knowledgeable people comment on this as it would be really neat to be able to start using a DB with these features.
补充指出目前仅支持 Python，但协议定义清晰，扩展到其他语言只是时间问题。
目前初始版本似乎只支持 Python。客户端显然很重，因为要执行所有查询逻辑。好在协议定义得很清晰，支持更多语言只是工作量问题。
augustl查看英文原文
Seems that this initial release only supports python. The client is obviously heavy, since it has to run all the queries, etc. Thankfully the protocol is well defined, so it's just a question of effort to support more languages. https://docs.zerodb.io/
质疑指出把口令派生密钥的盐存在不可信服务器上是个重大安全隐患，长期运行下暴力破解迟早能得手。
读了白皮书，有个细节特别扎眼：客户端可用口令派生私钥（scrypt），而派生用的盐存储在服务器端——服务器恰恰被定义为不可信方。虽然用了 scrypt，但这仍是个巨大的隐患。数据库系统往往要连续运行数年，如果服务器拿到盐，即使是很慢的暴力破解，迟早也能重新派生出认证凭据，然后随意发起查询。
swordswinger12查看英文原文
I read the whitepaper, and while I have many questions one detail in particular jumped out at me: "The client authenticates with an X.509 certificate or a self-signed certificate where the private key is derived from a passphrase. When a passphrase is used, the scrypt algorithm is used to derive a private key from the passphrase. Information about the salt is stored server-side and is given before establishing an authenticated encrypted connection. ... The symmetric key is derived from either the passphrase, the private key in an X.509 certificate, or provided by a key management service (KMS)." You're deriving a private key from a user-defined passphrase, then storing the salt used to derive the password on the server, which is defined to be untrusted. I understand you use scrypt to derive the private key, but this still seems like a massive, massive footgun. Database systems are usually kept up and running for a long time, like maybe even years. If the server gets the salt, isn't it only a matter of time before even a very slow brute-force attack can re-derive the authentication credential and make whatever queries it wants?
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2016Hacker News 讨论帖171 分 · 38 评
同领域还值得读
如何入侵一台已关机的电脑：在 Intel ME 中运行未签名代码
How to hack a turned-off computer, or running unsigned code in Intel ME
这篇 Black Hat 2017 白皮书讨论 Intel Management Engine（ME）的安全问题：如何在 ME 中运行未签名代码，以及攻破处于关机状态的电脑的相关…
安全与密码学2017 · 543 分 · 107 评专业 · 约 40 分钟编辑精选比特币：一种点对点的电子现金系统（2008）
Bitcoin: A Peer-to-Peer Electronic Cash System (2008)
中本聪 2008 年发表的比特币白皮书，提出了无需可信第三方的点对点电子现金系统。
安全与密码学2017 · 536 分 · 394 评入门 · 约 45 分钟编辑精选GPRS 加密算法 GEA-1 的密码分析表明存在故意弱点
Cryptanalysis of GPRS Encryption Algorithms GEA-1 suggest intentional weakness
首次公开了对 GPRS 加密算法 GEA-1 和 GEA-2 的密码分析攻击。
安全与密码学2021 · 487 分 · 107 评专业 · 约 90 分钟编辑精选Signal 消息协议的形式化安全分析
A Formal Security Analysis of the Signal Messaging Protocol
用形式化方法分析 Signal 消息协议（TextSecure）的安全性：作者在多阶段密钥交换模型下，借助自动化证明工具对协议的密钥协商与 Double Ratchet 密钥更新…
安全与密码学2016 · 353 分 · 230 评专业 · 约 120 分钟编辑精选A2：模拟恶意硬件
A2: Analog Malicious Hardware
论文研究如何在芯片设计阶段植入模拟电路形式的恶意硬件后门，使其难以被常规检测发现。
安全与密码学2016 · 315 分 · 94 评专业 · 约 75 分钟编辑精选