HackerPapers

HN 二十年,最值得读的论文。

从 Hacker News 2006 年以来的全部投稿里,挑出链接本身就是论文的帖子:arXiv、期刊、会议论文、技术报告。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从必读开始
  • 8,000+篇被 HN 讨论过的论文

Essential

必读 30 篇

在论文库里看全部精选

编辑精选里 HN 讨论最热的 30 篇,每篇都有中文导读。不知道从哪读起,就从这里开始。

  1. 正在载入论文…

Archive

论文库

点柱子按年份筛选。注:源数据里 2023 年的帖子分数记录不全,2026 年尚未过完,这两年收录偏少。

难度
排序

    About

    这些论文是怎么挑出来的

    1. 01

      全量扫一遍

      读取 Hacker News 自 2006 年以来的全部 446 万条链接投稿,找出指向 arXiv、期刊、会议、技术报告和学术 PDF 的帖子。

    2. 02

      只留论文本身

      由 AI 逐条判断,剔除介绍论文的新闻、博客和幻灯片,同一篇论文的多次投稿合并计算,并统计它在评论区被引用的次数。

    3. 03

      写导读、译评论

      讨论最热的 1,500 篇配上中文导读,并精选、翻译 HN 高赞评论。导读由 AI 生成,可能有误,请以原文为准。

    安全与密码学2017eprint.iacr.org

    制造 ZigBee 链式反应:针对物联网灯具的大规模攻击

    Creating a ZigBee Chain Reaction

    进阶 · 约 45 分钟读完前置知识:无线协议基础、密码学基础、ZigBee 协议

    读论文 HN 讨论
    160HN 得分
    130条评论

    导读

    这篇论文研究 ZigBee 无线协议(特别是 ZigBee Light Link)中的密钥机制缺陷,演示了如何利用其主密钥和配网流程在设备间引发“链式反应”式的感染/攻击,即攻破一个设备后可自动扩散攻破网络中的其他 ZigBee 设备。

    HN 关注点:IoT 设备普遍缺乏安全设计的根源与治理方式:是厂商责任、法律监管还是框架默认配置的问题。

    关键词 ZigBeeIoT安全ZLL主密钥供应链安全

    后来怎么样

    该研究揭示了 ZigBee Light Link 主密钥机制的缺陷,演示了可自传播的链式攻击,促使 ZigBee 联盟和厂商改进配网安全流程,是 IoT 安全领域被广泛引用的典型案例。

    HN 评论精选

    这几条评论里:质疑 1 补充 2 亲历 1

    补充应通过让厂商承担法律责任而非强制技术标准来倒逼安全

    安全实现对厂商来说成本高昂,所以他们把风险转嫁给客户和整个社会。要扭转这种局面,就得让“默认不安全”比“默认安全”更贵。政府与其为不断变化的技术制定详细安全标准,不如让厂商对损害承担法律责任,让市场自行演化出有效的标准和实践。但构建这样的立法并不简单:如何界定厂商何时担责、损害如何估算、涉及多个厂商产品时如何分摊,都是棘手的法律难题。有人(尤其是律师)对如何解决这个问题有见解吗?

    SkyMarshal查看英文原文

    Security is expensive for vendors to implement, so they externalize the risks to their customers and society in general. To reverse this dynamic, "insecure by default" needs to be more expensive than "secure by default". It seems simplest for the Govt to avoid trying to mandate detailed security standards for continuously changing tech, and rather simply make the vendors legally liable for damages and let the market evolve effective standards and practices. However, constructing effective legislation/regulation for doing so is a non-trivial legal challenge. Simply proving when the vendor is liable vs a user could get tricky, as well as estimating damages and divying them up among multiple vendors if damages involved products from multiple vendors. Among other things. Anyone, especially lawyers, have insight on best way to fix this problem?

    亲历IoT 框架默认不安全,做安全需要大量额外工作

    安全应该内置于 IoT 框架中并易于成为标准做法。但大多数 IoT 项目都是临时拼凑的,很少用标准方案;即使有框架,安全也往往不是核心特性。以我常用的 crossbar.io 为例:要保证安全需要配置 TLS 证书(默认是不加密的 websocket)、配置认证服务并写后端、划分 realm 并配置权限(默认权限形同虚设)、手动编写热更新流程、更新客户端时还要小心权限检查是否到位。总之,你可以把它做安全,但前提是你很懂行而且明天没有交付截止日。

    sametmax查看英文原文

    Security should be embedded in the IoT frameworks and should be easy for it to become the standard practice. But most IoT stuff are hacked on, rarely using anything standard, and even when there is a framework involved, it seldom has security as a main feature. Even when it does, it's still a lot of work. Take crossbar.io, which is my go to tool to communicate within a IoT context (or anything soft real time really). To secure it you need to: - setup the TLS certificate. Default communication transport is over unencrypted websocket. - configure the provided authentication service (and write a backend for your system). - declare several realms to isolate the clients, and configure the permissions accordingly (default permissions are YOLO, to ease the "hello world", which I understand). Make sure you don't expose important RPC to the wrong clients or allow anybody to declare callbacks. - manually code the procedure to use their hot reload system to swap code updates. It's made for local updates, not remote ones. - be very careful when updating your clients. Crossbar routed RPC is transparent and it's tempting to replace a call from JS to Python to a call from JS to Postgres to remove a layer of indirection. But do you make proper permissions checks in your SQL ? Are you sure you don't expose too much ? So basically, you can make it secure. But only if you know what you're doing and don't have a deadline tomorrow.

    补充ZLL 主密钥曾被 DMCA 大规模下架却没引发争议

    读这篇文章时我去搜了 ZLL 主密钥,让我惊讶的是它到处被 DMCA 下架,连 Hacker News 上也是(链接见原文),而且当时几乎没有人对此表示愤怒。非常奇怪。

    jrockway查看英文原文

    While reading this, I went looking for the ZLL master key. What surprises me is that it got DMCA'd everywhere, including Hacker News: https://news.ycombinator.com/item?id=9249841 And there was really no outrage about it. Very strange.

    质疑法律强制安全只会让厂商雇律师而非真正提升安全

    我不在 IoT 部门工作,但他们用我们公司的芯片。我可以保证:如果你把安全变成法律要求,我们公司不会多招工程师,而是会多招律师。

    Paul_S查看英文原文

    I don't work in the IoT department but they use our chips and I can guarantee you that if you make security a legal requirement my company will not hire more engineers, they will hire more lawyers.

    相关资源

    从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。

    视频与演讲

    历次讨论

    同领域还值得读

    1. 如何入侵一台已关机的电脑:在 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 分钟编辑精选
    2. 比特币:一种点对点的电子现金系统(2008)

      Bitcoin: A Peer-to-Peer Electronic Cash System (2008)

      中本聪 2008 年发表的比特币白皮书,提出了无需可信第三方的点对点电子现金系统。

      安全与密码学2017 · 536 分 · 394 评入门 · 约 45 分钟编辑精选
    3. GPRS 加密算法 GEA-1 的密码分析表明存在故意弱点

      Cryptanalysis of GPRS Encryption Algorithms GEA-1 suggest intentional weakness

      首次公开了对 GPRS 加密算法 GEA-1 和 GEA-2 的密码分析攻击。

      安全与密码学2021 · 487 分 · 107 评专业 · 约 90 分钟编辑精选
    4. Signal 消息协议的形式化安全分析

      A Formal Security Analysis of the Signal Messaging Protocol

      用形式化方法分析 Signal 消息协议(TextSecure)的安全性:作者在多阶段密钥交换模型下,借助自动化证明工具对协议的密钥协商与 Double Ratchet 密钥更新…

      安全与密码学2016 · 353 分 · 230 评专业 · 约 120 分钟编辑精选
    5. A2:模拟恶意硬件

      A2: Analog Malicious Hardware

      论文研究如何在芯片设计阶段植入模拟电路形式的恶意硬件后门,使其难以被常规检测发现。

      安全与密码学2016 · 315 分 · 94 评专业 · 约 75 分钟编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。