安全与密码学2018cs.ucr.edu
Rendered Insecure：GPU 侧信道攻击切实可行
Rendered Insecure: GPU Side Channel Attacks Are Practical
进阶 · 约 60 分钟读完前置知识：侧信道攻击基础、GPU 架构基础、浏览器渲染流程
导读
这篇论文（CCS 2018）展示了针对 GPU 的侧信道攻击是现实可行的：攻击者可通过探测 GPU 内存分配等共享资源，推断用户在浏览器中的打字行为，进而结合网页指纹识别猜测用户输入的密码。论文还讨论了从 GPU 和浏览器侧进行缓解的可能。
HN 关注点：这类攻击的实际威胁模型是什么（是否需要本机恶意进程、能否通过 WebGL 远程发起），以及浏览器/GPU 厂商有哪些容易实施的缓解措施。
HN 评论精选
这几条评论里：质疑 1 补充 2
质疑质疑攻击的实际威胁模型：既然已有本机进程，为何不用更简单的键盘记录；并指出密码管理器和统一输入框大小可缓解
浏览器密码捕获攻击很精彩。不过需要澄清：这需要一个攻击者控制的外部进程来监控 GPU，对吧？如果已经在受害者机器上有进程了，装键盘记录器不是更容易吗？或者是否存在合法程序允许运行任意不受信任的 GPU 代码（WebGL 算一个，但如果这攻击完全能在浏览器内实现，作者应该会急于展示）？还是说新颖之处在于通过网站指纹更容易判断哪些按键是密码？无论如何，网站可以把登录页所有输入框做成同样大小来增加攻击难度，而使用任何密码管理器（包括浏览器内置的）的人基本不受影响。总之非常酷。
kibwen查看英文原文
The browser password capture attack is awesome. To clarify though, that requires an external attacker-controlled process to monitor the GPU, yes? If you've already got a process running on the victim's computer, aren't there easier ways of installing a keylogger? Alternatively, are there legitimate programs that grant the ability to run arbitrary untrusted GPU code (WebGL springs to mind, but you'd think that if this attack were possible entirely from within the browser that they'd have been eager to show it off)? Or is the novelty here the ability to more easily guess which keystrokes represent passwords due to the website fingerprinting step? In any case, it suggests that websites could slightly frustrate the attack by making all the textboxes on their login page the same size, and that anyone using any password manager, including the one built in to their browser, is largely protected. Very cool nonetheless.
补充好奇浏览器为何为文本框重绘分配 GPU 内存，并提出浏览器侧的简单缓解方案
我有点惊讶浏览器会为文本框重绘反复分配和释放 GPU 内存，因为文本框尺寸并没有变。这应该是纹理内存吧？有人知道具体发生了什么吗？浏览器为所有元素重绘分配内存是常态，还是打字/字体处理特有的？论文提到了 GPU 侧的缓解手段，但浏览器侧也有简单的缓解：对密码框做速率限制、在用户只往小文本框打字时避免 GPU 内存分配，就能消除这种时序攻击。网站自己也能这么做。
dahart查看英文原文
> By probing the GPU memory allocation repeatedly, we can detect the pattern of user typing (which typically causes re-rending of the textbox or similar structure animating the characters). I guess I’m a tiny bit surprised that the browsers are de-allocating and re-allocating memory for the re-render of the text box elements, since they don’t change size. Presumably this would be texture memory? Does anyone here know precisely what’s happening there, and whether a render-to-texture won’t work for some reason? Is it normal for browsers to allocate memory for all element repaints, or is this something unique to text typing or font handling? The paper mentioned some mitigation avenues from the GPU’s perspective, but there are easy mitigations from the browser side here too. Given their interest in security, it seems reasonable for browsers to move on easy mitigations without waiting for changes to the GPU API. Rate limiting password fields in the browser, and avoiding GPU memory allocations while the user is only typing into a small text box element would remove the ability to do timing attacks on passwords. Individual websites can even do these things if they’re worried about it.
补充引用经典安全分析方法论，强调侧信道是老问题，系统未经充分分析证明前都应视为不安全
请跟我重复信息安全奠基者的教训：每个系统，从单个组件到其集成，在经过充分分析证明可信之前都是不安全的。你还必须对“安全”有精确定义才能对照比较。到 1992 年，人们已经用这类方法发现了从内核攻破到基于缓存的时序信道等各种问题。任何集中式或去中心化系统中的每个软硬件组件都存在泄露你秘密的隐蔽信道。相关方法包括共享资源矩阵（1983）、Wray 的时序信道扩展（1991），以及“隐蔽信道”“侧信道”“非干扰分析”“信息流分析”等关键词，甚至有专门防止意外泄露或做常数时间实现的编程语言。
nickpsecurity查看英文原文
Repeat after me the lesson from the founders of information security: every system, from individual components to their integration, is insecure until proven trustworthy by sufficient analysis. You have to also have a precise statement of what secure means to compare the system against. You then apply methods proven to work for various classes of problems. By 1992, they had found everything from kernel compromises to cache-based, timing channels using such methods. On this topic, every hardware and software component in every centralized or decentralized system has covert channels leaking your secrets. Now, if you're concerned or want to be famous, there's something you can do: Shared Resource Matrix for Storage Channels (1983) http://www.cs.ucsb.edu/~sherwood/cs290/papers/covert-kemmerer.pdf Wray's Extention for Timing Channels (1991) https://pdfs.semanticscholar.org/3166/161c3cbb5f8cd150d133a3746987da2d264d.pdf Using such methods were mandatory under the first, security regulations called TCSEC. They found a lot of leaks. High-assurance, security researchers stay improving on this with some trying to build automated tools to find leaks in software and hardware. Buzzwords include "covert channels," "side channels," "non-interference proof or analysis," "information flow analysis (or control)," and "information leaks." There's even programming languages designed to prevent accidental leaks in the app or do constant-time implementations for stuff like crypto. Go forth and apply covert-channel analysis and mitigation on all the FOSS things! :) Here's an old Pastebin I did with examples of that: https://pastebin.com/ajqxDJ3J
历次讨论
- 2018Hacker News 讨论帖185 分 · 28 评
同领域还值得读
如何入侵一台已关机的电脑：在 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 分钟编辑精选