欧盟年龄验证因硬件信任问题遭 Hacker News 质疑

欧盟年龄验证项目在其规范将原生加密硬件纳入合规路径后，受到了 Hacker News 的审视。这项要求旨在防止年龄凭证被提取或复制。但当一个开源钱包依赖获批准的应用、可信硬件和被认可的操作系统时，它也引出了一个更棘手的问题：谁来控制访问权限？

这场争议比“欧盟已禁止 Linux”或“要求所有场景都使用 Google Play Integrity”之类的说法更具体。已发布的规范并不能直接推导出这两种结论。桌面用户可以借助移动钱包完成跨设备流程，而各国实施方仍可自行决定是否加入额外的完整性检查。

不过，这种担忧并非凭空而来。当前架构以移动设备为中心，凭证提供方必须拒绝不在欧盟委员会维护的合规名单上的应用。这样的组合意味着，源代码可用性只是实际开放性的一部分。

其结果是一项真实的政策权衡。硬件绑定能够防止被复制的凭证和被修改的客户端削弱年龄门槛；同一套信任模型也可能排除社区构建版本、替代 Android 系统、旧设备以及没有兼容智能手机的人群。

欧盟年龄验证规范实际要求什么

绑定规则涉及加密硬件，但投入生产的访问权限还取决于应用审批和凭证提供方的政策。

欧盟委员会于 2025 年 7 月 14 日发布了其白标年龄验证蓝图的首个版本。该蓝图旨在作为可复用基础，供成员国改造为本国应用。

该项目支持《数字服务法案》第 28 条；该条款要求受监管平台通过适当且相称的措施保护未成年人。欧盟委员会将该系统定位为过渡方案，直至预计于 2026 年底前推出的欧洲数字身份钱包落地。

其基本工作流程将年龄证明与身份披露分离。经授权的提供方核验个人年龄，并签发数字证明。网站随后可请求某项年龄条件，例如访问者是否已满 18 岁。

依赖该证明的网站只会收到所请求的年龄结果，而非完整身份记录。该设计旨在避免反复向各个服务发送护照、支付信息、面部图像或出生日期。

根据已发布的技术规范，年龄验证应用在具备相关能力时“必须”使用原生加密硬件。示例包括 Apple 的 Secure Enclave，以及 Android 的可信执行环境或 StrongBox。

这些组件将加密操作与主操作系统隔离。即使常规应用存储被复制或检查，与凭证绑定的私钥也可以保持不可获取。

该要求并未明确表示每个部署都必须使用 Google Play Integrity 或 Apple App Attest。硬件支持的密钥存储与远程平台证明是相关控制措施，但它们回答的是不同问题。

安全存储关注的是密钥是否受到设备保护。远程证明则可以判断服务器是否识别该应用、操作系统、启动状态、硬件或分发渠道。

在一篇原始报道描述其对 Linux 和替代移动系统的影响后，这一区别变得尤为关键。该报道指出，参考实现并未普遍强制采用更严格的服务。

不过，该规范仍规定了其他强制性控制措施。每份年龄证明均为一次性使用，出示后会从已签发的批次中移除。证明提供方在签发凭证前，必须以“实质性”或“高”等级的保证水平核验年龄。

提供方还必须拒绝向不在欧盟委员会合规应用名单上的应用签发证明。应用提供方在发布符合要求的钱包前必须通知欧盟委员会，而委员会则维护相应名单。

这一治理层与硬件条款同样重要。任何人或许都能检查或分叉代码，但分叉版本未必能够从生产环境的签发方获得真实凭证。

该项目目前仍是参考实现，而非已经完成的通用服务。其 Android 代码库称，该演示版仍在积极开发中，距离生产部署还需要额外工作。

成员国或其他实施方必须处理应用加固、签发方配置、安全存储、密钥管理、注册安全、本地化和法律合规等问题。它们的选择将决定最终系统采用基础硬件绑定，还是严格得多的设备判定机制。

为什么 Hacker News 聚焦于“开源但无法开放访问”

Hacker News 的争论归根结底在于：当机构仍控制凭证与信任名单时，可审计的代码是否已经足够。

该项目依据 European Union Public Licence 发布源代码。开发者可以检查参考应用、在本地构建、报告问题并提出修改建议。

这带来了有意义的透明度。在各国部署触达数百万用户之前，研究人员可以审查注册流程、凭证存储、出示协议和依赖项。

然而，开源许可并不要求签发方信任每一个经过修改的二进制程序。这会与系统的安全目标冲突，因为被篡改的客户端可能移除认证检查或自动化凭证出示。

因此，欧盟委员会需要一种方法，将被接受的应用与任意软件区分开来。其规范通过合规应用名单以及对证明提供方施加的规则来实现这一点。

这产生了两种不同的开放性定义。

第一种是代码开放性。开发者无需取得专有供应商的许可，即可研究、编译和修改应用。

第二种是运营开放性。经过修改的应用无需获得中央机构或平台守门人的批准，也能参与真实的凭证网络。

欧盟项目显然支持第一种定义。由于签发方被要求只识别列入名单的应用，它对第二种定义的支持在设计上受到限制。

参与相关讨论帖的人围绕这一缺口展开讨论。一些人认为，硬件要求是防止凭证复制的必要防线；另一些人则认为，这种架构可能成为排除用户自主控制软件的途径。

两种观点都指出了该设计的真实特性。签发方无法将每个客户端都视为可信，但如果批准流程的规则不透明，或独立开发者难以满足要求，它就可能成为一道障碍。

该架构还将桌面访问与钱包执行分开。其文档描述了同设备和跨设备两种出示流程。

在同设备流程中，钱包和网站在同一台设备上运行。在跨设备流程中，桌面上的网站展示请求，由附近的移动钱包完成操作，通常通过二维码进行。

这意味着 Linux 并未被明确禁止。Linux 用户可以访问受限制的网站，并通过受支持的手机出示证明。

但这并不等同于原生支持 Linux 钱包。当前参考实现主要面向 Android 和 iOS，而规范将白标移动应用称为主要交付渠道。

只有 Linux 笔记本、却没有兼容智能手机的用户，仍会面临访问问题。手机缺少所需安全硬件，或无法满足某个国家部署的完整性政策的用户，同样如此。

Android 参考应用要求 API 级别为 29，对应 Android 10。在任何额外的生产加固开始之前，这一基线就已排除了更旧的设备。

无障碍性也不仅涉及操作系统。注册可能依赖国家电子身份、受支持的身份证明文件、可信提供方或其他特定国家的信息来源。

没有受支持证件的人，可能在硬件信任变得相关之前就遇到障碍。难民、移民、访客，以及其记录无法顺利关联至签发方的居民，都需要可行的替代方案。

这些问题并不能证明该系统旨在成为监控机制。但它们确实表明，“开源”本身无法解决访问争议。

开放代码库使审查成为可能，但并不保证不同设备、操作系统、证件状况或国家实施方案之间享有平等参与机会。

硬件绑定保护凭证，但也转移控制权

核心权衡是：以更强的凭证盗取防护为代价，换取对硬件供应商、应用分发商和机构信任决策更高的依赖。

一旦网站接受可复用的年龄证明，它就会具有价值。攻击者随之有动机复制凭证、生成伪造证明、自动化出示操作，或修改钱包以绕过本地认证。

硬件支持的密钥可降低这些风险。钱包可以请求签名，而不会将私钥暴露给常规应用内存或存储。

这能防范直接提取。将钱包文件复制到另一台设备上，理论上不应复制出示凭证所需的加密权限。

该规范还加入一次性证明，以限制重放和跨服务追踪。提供方分批签发凭证，钱包在每次出示后移除对应证明。

建议的最长有效期为三个月，这限制了已签发批次的可用时长。该文档避免强制撤销机制，因为撤销服务会增加复杂性，并可能提高可关联性。

这些选择体现了该项目的隐私工程设计。中央服务无需批准每一次网站访问，而依赖方只会收到范围狭窄的年龄属性。

欧洲数据保护委员会也发布了年龄保证的十项隐私原则。这些原则强调必要性、相称性、数据最小化、公平性、准确性、安全性和有效替代方案。

硬件保护有助于安全，但并不会自动满足其他原则。一个技术上安全的系统仍可能排除用户，或暴露超出特定服务所需的信息。

当实施方加入远程完整性服务时，争议会进一步扩大。Google 将 Play Integrity 描述为一种评估机制，用以判断请求是否来自在真实、经认证 Android 环境中运行的已识别应用。

其完整性层级可包括硬件支持的信号、引导加载程序状态、操作系统认证情况、近期安全更新、应用识别和安装来源。

这些能力有助于检测被篡改的客户端和已 root 的设备。它们也可能拒绝采用替代操作系统的设备，即使这些系统提供了强大的安全性，只是未被纳入 Google 的认证模型。

Google 自身建议采用分级执行方式，因为符合最严格判定条件的设备较少。这一建议承认了覆盖范围的问题：最严格的安全响应并非所有合法用户都能获得。

Apple 的 App Attest 采用类似的服务器验证模式。它会创建基于硬件的密钥，并让 Apple 证明该密钥属于一个有效的应用实例。

Apple 的认证指南同样建议开发者检查服务可用性，并妥善处理不受支持的设备。它并不假设每一种设备或应用类型都能提供该服务。

欧盟规范目前并未将所有硬件保护都归入这两项商业服务。它提及原生加密环境，并将额外的加固决策留给实施者。

这种灵活性很重要，但也推迟了关键的政策问题。各国部署可以选择不同的控制措施，而这些措施会对替代应用商店、后装操作系统以及独立编译的钱包产生不同影响。

较为宽松的实施方式可以将凭证绑定到安全密钥，而无需平台运营商批准整个软件环境。更严格的实施方式则可能要求获得认可的应用签名、锁定的引导加载程序、经过认证的操作系统以及官方分发路径。

这两种实施方式都可能自称由硬件支持，但它们对竞争和用户自由的影响将截然不同。

因此，开发者不应将“硬件认证”视为一种不可分割的单一技术。实际的信任政策取决于验证方要求哪些声明，以及接受哪些机构作为权威。

设备可以证明某个密钥存储在安全硬件中，但无法证明 Google 批准了其操作系统。相反，Play Integrity 可以将硬件证据与 Google 对应用和设备的分类结合起来。

真正关键的问题并不是是否涉及硬件，而是谁定义何为可接受的设备、需要哪些证据，以及被拒绝的用户是否能获得另一条安全路径。

隐私承诺仍面临现实弱点

该架构能够尽量减少向网站披露的信息，但无法证明持有成人凭证的人就是正在浏览内容的人。

欧盟设计解决了传统年龄核验中的一个重大隐私问题。受限制的网站无需收集身份证明文件，也无需维护将法定身份与浏览活动关联起来的数据库。

委员会的白标蓝图描述了一种可由成员国定制的隐私保护方法。该凭证旨在披露年龄条件，而非无关的个人信息。

这种分离具有价值。大规模收集护照、自拍照、出生日期和支付记录，会成为攻击者眼中的诱人目标，并放大数据泄露的后果。

然而，保护隐私并不能解决凭证出借的问题。儿童可以使用成年人的手机，成年人也可以替他人批准请求。

该规范承认设备可能由多名用户共享。它要求在出示认证前进行可靠的本地认证，例如 PIN 码、密码、图案或生物识别验证。

这只能验证对钱包的访问权限，无法确认在证明被接受后，究竟是谁在查看目标屏幕上的内容。

更严格的本地控制可以降低随意共享的便利性，但系统无法持续将内容消费与接受年龄核验的人员绑定。要做到这一点，需要更具侵入性的监控。

这是许多年龄核验系统背后的根本限制。提高可信度通常需要额外的身份凭据、生物识别核验、行为分析或重复认证。

每增加一项措施，都可能减少绕过机会；但每一项也可能带来新的数据收集、排斥、无障碍和安全风险。

硬件绑定能够保护凭证不被提取，但无法阻止用户主动交出已解锁的设备。应用认证可以发现被修改的软件，但无法判断坐在屏幕另一端的是谁。

该项目的零知识机制也值得准确解读。规范性文本称，应用程序应实施规定的零知识证明机制，而依赖方应实施其验证机制。

在标准语言中，“应”具有重要意义，但比“必须”更弱。因此，各实施方案在实现不可关联性和选择性披露的方式上可能存在差异。

零知识证明允许一方在不披露底层秘密的情况下证明某项事实。在此情境下，目标是在不披露身份或精确出生日期的情况下证明满足年龄条件。

即使设计完善的证明系统，也运行在更广泛的网络环境中。签发方、应用、信任列表、网站、设备和平台服务仍会产生运营数据。

隐私取决于这些组件能否关联签发和出示事件，也取决于日志政策、时间戳精度、网络标识符、分析工具以及各国的实施选择。

该规范试图通过一次性认证和限制时间戳精度来减少关联。这些措施值得肯定，但独立测试必须确认完整部署的实际表现。

现有 Android 应用明确属于仍在积极开发中的演示版本。其代码库警告称，生产部署需要安全存储、密钥管理、应用加固、注册验证和治理工作。

演示版本中的缺陷未必会使协议失效。同样，一个健全的协议也无法保证每个国家级应用都能安全实施。

这一区别应成为未来安全报告的基础。研究人员需要说明，弱点影响的是演示版本、某项部署选择、凭证协议，还是整个可信模型。

Hacker News 上的反应反映了人们对这类系统的担忧：它们起初服务于狭窄目的，后来可能获得更广泛的用途。当前规范聚焦于在线服务访问，并将若干现实世界场景视为优先范围之外。

这一范围可能会随着后续政策决定而变化。为年龄证明构建的技术组件，最终可能在更广泛的欧洲数字身份框架中支持其他属性。

这种扩展并未由现行年龄核验文件确立。不过，治理机制应在部署前处理用途限制问题，因为技术兼容性会使后续复用更容易。

因此，隐私承诺并非空洞，但它是有条件的。该设计可以比直接核验文件披露更少的信息，但其成败取决于实施、监督、替代方案以及抵御范围扩张的能力。

开发者和用户接下来应关注什么

决定性证据将来自各国信任政策、独立安全测试，以及对未通过首选完整性检查的合法设备的处理方式。

第一个信号是应用程序的生产合规政策。委员会的可接受钱包列表将决定独立提供商是否拥有进入该生态系统的现实路径。

开发者需要公开的标准、审核时间表、申诉程序，以及针对开源可复现构建的规则。否则，即使源代码保持公开，这份列表也可能成为不透明的门槛。

一个可信的流程应说明由社区维护的应用能否获得资格，还应明确钱包获接受后，谁负责安全更新、事件响应和凭证吊销。

第二个信号是成员国如何实施设备信任。仅使用硬件支持的密钥存储，与强制要求 Play Integrity 或 App Attest 判定，会产生不同的访问后果。

各国应用应记录它们请求哪些信号，以及如何应对失败。空白的完整性结果不应自动被视为欺诈证据，因为不受支持的硬件或替代操作系统也可能产生相同结果。

备用方案至关重要。缺少兼容手机的人需要另一种与风险相称的年龄证明方式，尤其是在访问涉及合法信息、而非可选商业功能时。

这些替代方案可能包括来自另一受信任钱包的跨设备凭证、协助注册、受支持的线下渠道，或平台中立的安全硬件。每一种选项都需要各自的威胁分析。

第三个信号是对完整系统的独立评估。参考代码库提到了持续更新、生产加固和社区测试，但公开代码审查不能替代结构化评估。

研究人员应测试凭证提取、重放抵抗能力、钱包克隆、签发方滥用、验证方串通、共享设备场景、元数据关联、拒绝服务和无障碍故障。

他们还应公布发现针对的是协议还是某项实施。这样的清晰度可以避免将可修复的应用漏洞描述为全面的密码学失败。

反过来，安全的演示版本也不应被用来宣称政策模型已经解决了年龄保障问题。凭证出借、文件访问、数字排斥和用途扩张都不是普通的软件缺陷。

平台同样面临运营决策。网站必须验证认证是否来自授权提供商，以及是否包含所请求的属性。

它应只请求法律或政策所需的最低年龄条件。收集额外属性将削弱该系统相对于高度依赖身份信息的核验服务商所宣称的优势。

整合该协议的开发者需要关注不断变化的规范，因为该项目与持续演进的欧洲数字身份架构和参考框架保持一致。互操作性声明取决于这些不断变化的标准。

他们也不应假设一个国家的实施能预测另一个国家的情况。该蓝图允许各国围绕注册、年龄门槛、安全控制、保留期限和提供商配置进行调整。

对用户而言，最明确的问题是实际问题：国家钱包能否在他们的设备上运行，他们能否获得凭证，以及能否对错误拒绝提出申诉？

用户还应被告知依赖网站会收到什么信息、钱包会保存认证多久，以及签发是否可能与后续出示关联。这些说明应当无需阅读协议规范也能理解。

欧盟方法最有力的理由在于，它可以用范围受限、一次性的年龄证明取代反复披露身份。硬件绑定的密钥使这些证明更难被复制或伪造。

最有力的反对意见是，安全可能演变为许可。如果生产凭证只能通过获批准的软件和供应商认可的设备运行，用户即使获得源代码，仍会失去实质控制权。

这正是为什么 Hacker News 上的争议不能仅靠将项目标签化为“保护隐私”或“排斥性”来解决。该架构包含支持两种结果的机制。

先关注合规列表，然后关注各国的完整性要求，最后关注完整生产流程的独立测试结果。这些信号共同将表明，硬件信任究竟是在保护私密凭证，还是正在成为合法互联网访问的门槛。

开发者、政策制定者和用户在接受全国范围推广之前，应要求得到一个明确答案：当合法用户无法满足首选设备验证时，仍有哪些安全途径可用？这一回应将揭示，该系统是将兼容性故障视为可妥善处理的例外，还是将其作为排除用户的理由。相比是否采用 Secure Enclave 或 StrongBox，这一选择更将决定欧盟的年龄验证项目能否赢得技术新闻圈之外的信任。