安全浏览协议如何未能保护用户隐私 - The Trail of Bits博客
Trail of Bits
2019年10月30日
密码学专题
近期安全研究人员发现,苹果公司将中国用户的所有安全浏览数据发送给腾讯。这一发现使得安全浏览协议底层的安全与隐私保障机制受到严格审视。该协议声称通过所谓的k匿名性(k-anonymity)来保护用户,但本文将展示这种隐私定义在安全浏览场景下实际形同虚设。
安全浏览协议工作原理
早期Google通过Lookup API方案,要求用户提交IP地址和待检查URL到谷歌的恶意网站数据库。出于隐私顾虑,现行方案改用Update API(谷歌和腾讯均采用此方案)。
核心机制:
- 谷歌维护恶意URL及其256位哈希值的列表
- 为节省带宽,仅向浏览器分发32位哈希前缀
- 当匹配发生时,浏览器将32位前缀发送给谷歌
- 谷歌返回包含该前缀的所有黑名单URL完整哈希
- 最终匹配则向用户发出警告
什么是k匿名性
k匿名性传统用于数据库去标识化处理,通过数据泛化使得每条记录在特定属性上与至少k-1条其他记录不可区分。在安全浏览场景中,32位哈希前缀理论上可产生约14757次碰撞(Gerbet等人2015年研究数据),即浏览数据具有14757-匿名性。
k匿名性为何失效
尽管满足k匿名性定义,但通过以下技术手段可破解隐私保护:
-
跨查询关联攻击
- 利用cookie和IP地址关联多次查询
- 例如连续访问amazon.com及其购物车页面时,可推断用户购物行为
-
URL分解漏洞
- 协议要求提交URL层级分解(如http://a.b.c/1/2会同时检查):
- a.b.c/1/2
- a.b.c/1/
- a.b.c/
- b.c/
- 同时提交多个关联前缀会极大降低匿名性
- 协议要求提交URL层级分解(如http://a.b.c/1/2会同时检查):
Gerbet等人研究表明,该漏洞甚至可识别用户的色情内容浏览偏好。更严重的是,由于恶意数据库不公开,无法验证是否被人为植入追踪性哈希前缀。
未来展望
安全浏览协议虽提供安全价值,但无法有效防范企业或政府监控。k匿名性和差分隐私等技术并非放之四海皆准的方案,理论满足隐私定义的系统在实际部署中可能完全失效。
如需在应用中实施差分隐私或k匿名性等技术,我们的密码学服务团队可协助处理这些系统固有的复杂性——无论是协议设计还是现有代码审计,都能帮助构建值得用户信任的系统。