一、前言
在上次《拨开俄乌网络战迷雾-域名证书测绘篇》里，对俄乌双方网站域名证书的存活情况和颁发机构分布情况变动研究中，发现难以从部分证书解析得到的颁发者名称及机构中，正确识别其证书颁发机构（Certificate Authority, CA）。针对此类问题进行调研，发现一篇发表在USENIX 2021的论文工作[1]，如图 1.1 所示。其作者提出基于CA对证书的操作行为特征进行聚类的Fides系统，能够检测实际控制数字证书的CA（即证书运营商），并建立了一个新的证书运营商数据库[2]。所谓控制，就是对证书关联的加密密钥具有操作访问权限，并能够对由密钥颁发的证书负责。
图1.1 论文标题、作者信息
二、基本概念
下面介绍证书相关的基本概念。
2.1 公钥基础设施（PKI）
如图 2.1 所示，公钥基础设施（Public Key Infrastructure, PKI）是创建、管理、分发、使用、存储和撤销数字证书以及管理公钥加密所需的一组角色、策略、硬件、软件和程序[3]。
图2.1 公钥基础设施关键角色
2.2 证书颁发机构（CA）
其中，证书颁发机构是存储、签署和颁发数字证书的权威机构。这里CA分为两种，能够签发根证书的根CA和签发中间证书的下级CA（根证书和中间证书统称CA证书，而直接签发给订阅者的为叶证书）。根CA也可以签发中间证书。根CA和下级CA的主要区别在于，签发的中间证书的实际控制权在哪儿。一般情况下，根证书签发的中间证书控制权有三种情况，由相同的根CA控制所有、由根CA控制但法律上属于下级CA、由下级CA控制所有。这里主要把第三种与前两种进行区分。即，中间证书虽然可以继承根证书的信任，但它不一定继承和根证书相同的证书运营商。同时，下级CA可以对叶证书具有独立的身份验证和撤销机制。
2.3 审计机构
第三方专业审计机构对CA运营情况进行审查，除了披露CA操作是否与其政策一致或偏离的情况外，还包括审核范围内的证书列表。
2.4 用户代理（浏览器）
通常情况下，每个验证证书的用户代理（如Web浏览器）都附带一组受信根证书，作为Web PKI中的可信根。根CA很少使用根证书直接签发叶证书，而是通过根证书签发中间证书，再利用中间证书处理叶证书的日常签发。因此根证书可以保持离线状态，从而保护它们免受损害。不同的浏览器具有自己的根证书库，同时对库中包含的证书具有一定要求。例如，Mozilla要求根CA在Common CA Database (CCADB)[4]中公开披露不受约束的中间证书。
CCADB是一个由Mozilla运营的CA信息库，其中存储有关证书的元信息。它为CA证书运营商提供了一种自我披露证书、证书策略和审计的方法。CCADB被许多浏览器用来管理他们的根证书库，以提高安全性、透明度和交互性。
2.5 订阅者（网站）
订阅者是使用叶证书的实体。叶证书被签发给某个域名或IP，往往直接作用于某个网站，为网站用户提供身份认证、加密通信等功能。
三、研究动机
由前述概念介绍可知，通常情况下，证书的颁发机构，是实际控制证书的机构。但由于颁发者命名要求不严、机构所有权更改和证书生存期极长等原因，可能会导致证书解析的CA与实际控制机构不一致。这不仅会混淆订阅者对可信CA的选择，还会妨碍浏览器将证书问题正确地归咎于某个CA。
3.1 浏览器基于CA判定是否信任证书
如图 3.1 所示，由于在2009年至2017年期间赛门铁克一再错误地颁发证书，2017年，Chrome、Mozilla、Apple和Microsoft浏览器宣布不信任赛门铁克颁发的证书。不过，即使赛门铁克的所有根证书都不受信任，也并非所有的中间证书都不受信任。Apple和Chrome运营着与赛门铁克根证书相关联的7个下级CA，它们由于独立运营而被明确列入白名单。
图3.1 赛门铁克证书不受信事件
3.2 证书解析相似但实际运营商不同
如图 3.2 所示，证书字段值虽然相似，但并没有共享相同证书运营商。它们一个属于DigiCert，一个属于Sectigo。考虑探索实际控制证书的运营商前提下，重新构建已有研究工作，可能得到更准确的结果。
图3.2 不同证书运营商的相似证书
四、方法流程
4.1 Fides：揭示证书所有权的系统
Fides揭示CA证书所有权的基本假设是，来自同一个组织机构签发的证书，在使用的证书生成软件、证书验证/撤销相关网络基础设施、证书审计策略等方面，存在相似性。
因此，如图 4.1 所示，Fides首先利用证书生成软件、网络基础设施、审计细节来构建大量证书的指纹信息；其次通过对满足条件的证书指纹信息进行聚类，检测可能被同一个组织机构控制的证书；然后结合CCADB的标签对聚类过程进行优化；最终构建了一个更准确地描述CA证书运营商的新数据集。
图4.1 Fides系统处理流程
4.2 实验数据集构建：CT+CCADB+SSPKI
数据集的初始来源是，在2020年7月1日前证书透明度（Certificate Transparent, CT）日志中，Chrome和Apple信任的2.9B个叶证书。CT旨在监控、审计、记录由CA颁发的所有证书，从而有效识别错误或恶意颁发的证书[7]。通过对叶证书中的CA证书进行提取、过滤Google签发的临时CA证书、添加CCADB中揭露的CA证书、利用撤销列表标记证书等处理步骤，最终得到了如图 4.2 所示，包含2.9B个受信任叶证书和9,154个CA证书的数据集，其中具有6,549 个Subject+Subject Public Key Info (S+SPKI=SSPKI)对。
图4.2 数据集概况
4. 3 叶证书指纹生成：证书1结构
通过开发证书ASN.1指纹识别工具[5]，分析每个CA证书签发的叶证书ASN.1结构，识别出证书结构一致的集群。如图 4.3 所示，分析证书ASN.1结构时，无需提取叶证书的节点值。这使得生成的指纹，更关注由于不同证书生成软件/配置导致的不同。
图4.3 证书1结构指纹[6]
4.4 CA网络基础设施：AIA+CRL+OSCP
CA网络基础设施包括用于在线证书链构建的颁发机构信息访问（Authority Information Access, AIA）CA颁发者，以及与证书撤销相关的证书撤销列表（Certificate Revocation List, CRL）和在线证书状态协议（Online Certificate Status Protocol, OSCP）。该文从叶证书中共计提取了2,334个完全合格域名（Fully Qualified Domain Name， FQDN），包括991个OCSP、938个CRL和800个AIA颁发者域名。通过解析每个FQDN对应的IPv4地址，得到在309个AS自治系统中共计835个IPv4地址。如图 4.4 所示，展示了FQDN和IP在CA证书中的分布，发现大约一半的FQDN仅与单个CA证书关联，同时许多FQDN共享相同的底层IPv4地址。
图4.4 证书关联网络基础设施分布
4.5 CA审计：CCADB审计报告
通过下载CCADB中保留的所有从公共数据源收集的CA审计报告，对生成的1,266个PDF文件进行文本提取，利用开发的正则表达式获取每个审计报告中的证书SHA-256指纹，用来关联CA证书审计数据。
4.6 判定标准：满足至少2个维度相似/相同
如图 4.5 所示，只有通过至少两个维度关联的证书才被认为具有共同的CA证书运营商。应用此启发式标准后，Fides生成320个集群类别，其中包含2,599个CA颁发者，集群规模从2到696个CA证书不等。
图4.5 启发式CA运营商集群生成流程[6]
4.7 效果评估：精度高，召回低
标注数据集。由于目前没有CA证书运营商的公开标注数据集，因此很难直接评估Fides是否正确。通过搜集2014年5月至2019年7月期间，由浏览器根证书库管理人员手动检查发现的28个错误报告，把它们作为近似的标注数据集。
评估方法。首先提取与每个错误报告相关的CA证书和颁发者（SSPKI），并根据错误详细信息手动确定CA所有权；然后通过查看Fides每个集群的证书指纹、网络基础设施和审计报告，手动标记包含错误报告CA证书的集群，为每个集群分配一个可能的CA运营商；最后将Fides的CA运营商与每个错误报告中披露的CA进行比较。
评估结果。如图 4.6 所示，共计检查了28个错误报告，涉及150个颁发者。Fides正确识别了150个颁发者中32%的运营商，并能正确标记3/28个错误报告中的所有颁发者。排除47个身份不明的颁发者，Fides能够正确识别47%颁发者的运营商，并能正确标记7/22个错误报告中的所有颁发者。由于Fides中所有48个颁发者都出现在正确的集群中，Fides整体上具有较高的精度，但召回率较低，仅能标记不到一半的颁发者。
图4.6 Fides评估结果
五、实践发现
本节利用Fides发现CCADB中具有错误或误导性所有权数据的CA证书。如图 5.1 所示，首先使用CCADB的所有权数据标记CA证书，其次对CA证书利用Fides进行聚类，然后当检测到CCADB标签与聚类标签冲突、未标记CA证书属于某个集群时，通过手动检查审计报告和操作特征纠正不一致数据，最后构建一个更接近CA证书实际操作控制机构的数据集。
图5.1 CA运营商数据集构建流程[6]
5.1 标记Fides节点：解决SSPKI所有权不一致
CCADB通过SHA-256指纹标识单个CA证书，Fides通过SSPKI标识颁发者。通过SSPKI对CCADB证书进行分组，发现39个颁发者（110个证书）映射到多个CCADB所有者。其中31个SSPKI包含被撤销、过期或作为下级CA正确披露的证书；另外8个SSPKI（20个证书）的CCADB控制权模糊，单个密钥似乎拥有多个CCADB所有者。之后通过检查审计和证书主体进行人工识别，以解决此39个SSPKI所有权冲突（更正了64个证书）。通过发现有557个不在CCADB中的CA证书，与带CCADB标签的证书共享一个SSPKI，将CCADB标签进行扩展，原理如图 5.2 所示。
图5.2 CCADB标签扩展至Fides[6]
5.2 多运营商集群：白名单+未公开+笔误+误报
单个Fides集群中存在多个CCADB所有者，表明CCADB标签（包括下级CA报告）与Fides自动推断的CA证书控制之间可能存在不一致。如图 5.3 所示，通过手动检查这11个集群以确定不匹配的根本原因。其中2个是误报，另外9个集群由581个证书的728个颁发者组成。通过解决下级CA白名单、未公开控制、笔误、误报问题，最后更正了125个颁发者和136个CA证书的标签。
图5.3 11个多运营商集群
5.3 少数未标记集群：节点标记个数占比大于70%
如图 5.4 所示，发现少数节点未标记的17个Fides集群，集群中绝大多数（超过70%）节点共享相同的CCADB所有者标签。Fides总共标记了94个证书，涵盖84个颁发者。由于这些新标记CA证书的审计数据和CCADB元数据不足，无法正确评估这些新标签的准确性，并且可能存在一定误报。为了减少这些可能性，选择每个集群中未标记节点占比不高于30%的阈值。
图5.4 17个未标记集群
5.4 CA运营商数据集：优化了2%的CA证书
如图 5.5 所示，Fides生成了一个新的CA运营商数据集[2]，该数据集为来自85个颁发者的90个受信CA证书更正了CA运营商标签，同时扩展了115个受信CA证书的覆盖范围，Fides共计改进或扩展了208个受信CA证书覆盖范围，占Microsoft、Apple或NSS信任的所有3,338个CA证书的6.2%。
图5.5 CCADB vs. Fides
六、推荐建议
Fides虽然可以发现CCADB证书所有权标签和运营实践的不一致，但它的启发式方法并不完美，精度高而召回率低。为了真正解决CA证书控制权透明度的问题，该文提出以下推荐建议。
6.1 CCADB结构化数据：添加证书所有权显式字段
由于CA证书控制更改的频率超过了CA证书更换的频率，当前的CA证书必须将其名称（存储在证书中）与其身份（存储在证书之外）分开。CCADB是跟踪谁控制每个CA根证书和中间证书的自然位置，为所有权详细信息添加显式字段将允许浏览器和研究人员更好地跟踪CA行为。浏览器还可以执行更严格的CCADB策略，以帮助消除拒绝向CCADB提交详细信息CA的信任依赖。
6.2 增加中间限制：浏览器要求包含证书所有权信息
浏览器可以要求中间CA证书包含最新的所有权详细信息，类似扩展验证证书的要求，并限制其所有权更改。同时还可以进一步限制中间证书的有效期，以抑制所有权转移并减少证书控制变化的影响。
6.3 反思根CA标签：暂时忽略证书Subject Name字段
考虑是否应该暂时忽略证书包含的信任锚主体名称字段，就目前而言，根证书上的标签对很大一部分CA具有误导性，而浏览器提供的标签可能可以提供更多最新的所有权细节（如从CCADB中提取）。
6.4 Fides未来发展：验证审计文档与外部测量结果一致性
Fides目前可以帮助识别用户错误和可疑CA实践，未来可以验证CA文档/审计声明与外部可测量行为之间的一致性。比如，通过扩展Fides包括CA向订阅者提供证书的IP地址，可以自动检查CA文档/审计中披露的操作位置准确性；进一步发展Fides证书指纹技术，以识别不同CA使用的CA软件，从而更好地发现和修复证书颁发问题。
七、总结
数字证书作为提供身份认证、加密通信、可信机制的网络空间基础资源十分重要。目前面向证书测绘的工作，往往通过直接解析证书，得到颁发者名称及机构字段值来判定证书控制机构。但由于颁发者命名要求不严、机构所有权更改和证书生存期极长等原因，使得证书解析的CA与实际控制机构不一致。从而导致测绘结果不全或者不准确，影响分析结果。
本文介绍的这篇研究工作[1]，基于证书ASN.1结构指纹、网络基础设施、审计报告等特征构建的Fides系统，利用启发式方法得到实际控制CA证书的运营商标签，再结合CCADB和人工分析纠正的方式，构建了一个更准确的证书运营商数据集[2]，包含6,846个证书及其操作指纹、证书运营商标签等。
后续面向证书测绘的研究工作，可以借鉴其思路及相关开源代码工具和数据库，在证书解析基础上，进一步实现对CA字段的校准优化，有助于准确关联机构，提高数据和分析的准确性。
参考文献
[1]Ma Z, Mason J, Patel S, et al. What’s in a Name? Exploring {CA} Certificate Control[C]//30th USENIX Security Symposium (USENIX Security 21). 2021: 4383-4400.
[2]https://github.com/zzma/ca-transparency
[3]https://en.wikipedia.org/wiki/Public_key_infrastructure
[5]https://github.com/zzma/asn1-fingerprint
[6]https://www.usenix.org/conference/usenixsecurity21/presentation/ma
[7]https://en.wikipedia.org/wiki/Certificate_Transparency
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。