爱沙尼亚电子身份证（ID卡）被认为是世界上基于智能卡的国家身份证系统最成功的部署之一。卡上存储的公钥密码和私钥使爱沙尼亚身份证持有人能够使用电子服务，提供具有法律约束力的数字签名，甚至在全国选举中投下i-vote。
在本文中描述了在身份证制造过程中发现的一些安全漏洞。通过分析从公共ID卡证书存储库中收集的公共密钥证书已发现了这些缺陷。特别是发现在某些情况下，与安全性要求相反，ID卡制造商已在芯片外部生成了私钥。在某些情况下，同一私钥的副本已导入到不同持卡人的ID卡中，从而使它们可以相互冒充。另外，由于制造过程中存在一个单独的缺陷，证书中包含了损坏的RSA公钥模块，这在一种情况下导致了相应私钥的完全恢复。本文描述了这些发现的发现过程以及当局采取的事件响应措施。
0x01 Introduction
爱沙尼亚发布了几种类型的信用卡大小的身份证件（以下称为ID卡），其中包含智能卡芯片。嵌入在芯片中的加密功能可通过Internet进行安全身份验证，并创建具有法律约束力的数字签名。爱沙尼亚身份证于2002年开始推出，在传播和积极使用方面被认为是世界上最成功的身份证之一。在130万爱沙尼亚居民中，有67％的人在2018年下半年至少使用了一次电子身份证。
这种电子身份方案的安全性取决于持卡人私钥的保密性。至关重要的是，以安全的方式生成私钥，并且只有相应的持卡人才能访问私钥。与其他许多国家一样，在爱沙尼亚ID卡方案中，密钥管理（密钥生成，证书发行）也委托给ID卡制造商。因此，必须确保制造商生成高质量的密钥，并且不存储所生成密钥的副本。不幸的是，没有有效的控制措施来验证制造商是否值得信赖并正确处理密钥管理。业界对这些担忧的回应是，制造商从事的是信任业务，因此，他们绝不会因采取草率的安全做法或恶意行为而冒其声誉的风险。
在这项工作中的贡献是以爱沙尼亚身份证为例，表明这种信任模型并不总是有效。证明了ID卡制造商采取了草率的安全措施，忽略了密钥管理过程中反复出现故障的迹象，并且在某些情况下故意违反了ID卡制造合同，从而创建了持卡人的私钥副本。尽管这些发现导致了针对身份证制造商金雅拓的公开诉讼，但没有证据表明这种信任的丧失会影响金雅拓的声誉或其业务价值。
本文的发现基于对多年来从公共ID卡证书存储库收集的ID卡公共密钥证书的分析。研究结果显示为在不同时间段进行的三项独立研究。对于每项研究，都会介绍背景并描述如何识别和处理缺陷的过程
首先，发现多个ID证书共享相同的RSA公钥。经过进一步调查，发现受影响的身份证也共享相同的私钥。发现重复的私钥表明，与安全要求相反，ID卡制造商已在卡外部生成了密钥。获得令人信服的证据，表明大多数ID卡密钥是在卡中生成的，而ID卡更新过程中生成的一组特定密钥是在卡外部生成的。结论是，这种违反可能是由于性能原因引起的。
还发现了ID卡制造过程中的另一个故障，该故障导致证书中包含损坏的RSA公钥模块。在一个实例中能够充分分解受影响的密钥，从而证明该故障对安全的影响。分析了造成问题的可能原因，并讨论了预防和发现措施。
0x02 Estonian ID card
（1）加密功能
从2002年推出至今，爱沙尼亚ID卡提供的核心加密图形功能一直保持不变。 ID卡包含两个带有相应X.509公钥证书的非对称（RSA或ECC）密钥，以及用于对卡执行卡管理操作的对称密钥。
验证密钥。身份验证密钥用于通过在TLS客户端证书身份验证过程中提供签名来登录电子服务。该密钥还可以用于解密为持卡人加密的文档。必须使用4位PIN1码授权使用此密钥的签名和解密操作。
数字签名密钥。数字签名密钥用于提供具有法律约束力的数字签名，根据eIDAS ，该数字签名被视为合格的电子签名。必须使用5位数的PIN2码对每个带有该密钥的信号进行自然操作。
卡管理操作。卡预装有对称密钥，制造商可以使用对称密钥在发行后的阶段执行各种卡管理操作。这样可以重置PIN码，以防持卡人忘记PIN码，生成新密钥，编写新证书，甚至在需要时甚至重新安装整个智能卡小程序。
（2）所涉缔约方
身份证是国家签发的身份证件。警察和边防局（Politseija Piirivalveamet – PPA）是负责采购身份证制造服务和签发身份证件的机构。
从2002年推出ID卡开始，TrübBaltic AS就进行了卡的制造和个性化。 2015年2月，金雅拓收购了TrübBaltic AS及其母公司TrübAG。截至2018年底，ID卡由Oberthur（现称为IDEMIA）制造。
ID卡证书由私人拥有的爱沙尼亚证书颁发机构（CA）SK ID Solutions AS（以下简称SK）颁发。根据eIDAS术语，SK是颁发合格证书的合格信托服务提供商。 SK是卡制造商的分包商。
爱沙尼亚信息系统管理局（RiigiInfos-üsteemiAmet-RIA）是负责协调和开发电子身份和网络安全的国家机构。 RIA负责组织ID客户端软件的开发工作。
（3）芯片平台和文件类型
在本节中，按时间顺序介绍了多年来使用的智能卡平台表格以及相应的身份证明文件类型。使用通用术语‘ID卡’来指代所涵盖的所有身份证明文件类型。此项工作不涵盖基于SIM卡的Mobile ID形式的数字身份证。
a）MICARDO
2002年，爱沙尼亚推出了身份证，这是所有15岁及以上的爱沙尼亚居民的强制性身份证件。卡的电子功能是在智能卡操作系统MICARDO Public 2.1之上实现的。智能卡接口记录在EstEID规范中，该规范后来成为国家标准。由MICARDO驱动的ID卡于2002年至2011年发行（上图）。该平台仅限于1024位RSA密钥。
b）MULTOS
2010年10月，引入了数字身份证。由于本文档只能以电子方式使用，因此可以在PPA客户服务点进行个性化处理并立即发布。数字身份证的目的是在持卡人的身份证无法使用的情况下提供备份解决方案。该卡由Key Corp的MULTOS I4E平台提供动力。已开发出MULTOS小程序来模仿EstEID规范中描述的MICARDO接口。由MULTOS驱动的卡已发行至2014年12月（上图）。该平台仅限于1024位RSA密钥。
c） jTOP SLE66
2011年，身份证的生产转移到了一个新的芯片平台，该平台基于在SLE66CX800PE芯片上覆盖的英飞凌产品JCLX80jTOP20ID之上（上图）。该卡运行由Trusted Logic开发的jTOP（Java可信开放平台）JavaCard操作系统。 EstEID功能在JavaCard小程序中实现。该平台使用2048位RSA密钥。随着jTOP SLE66平台的推出，引入了居留证（下图）。该卡发给居住在爱沙尼亚的非欧盟第三国国民。由jTOP SLE66驱动的ID卡已发行至2014年底。
d）jTOP SLE78
2014年底，身份证，居民许可证和数字身份证的生产已切换到jTOP SLE78平台。身份证和居留证的视觉设计保持不变，但是，数字身份证的视觉外观更加鲜艳（见上图）。
EstEID功能是在SLE78CLX800P芯片上的英飞凌产品SLJ52GCA080CL之上的JavaCard小程序中实现的，该芯片运行由Trusted Logic开发的jTOP JavaCard操作系统。随着切换到jTOP SLE78平台，引入了电子居民的数字身份证。该卡是通过电子居留计划发行给非爱沙尼亚居民的。在2017年初，引入了外交身份证（下图）。该卡发给具有外交地位的人。最初，jTOP SLE78平台使用2048位RSA密钥，但是由于ROCA漏洞，在2017年底，使用曲线P-384切换到ECC密钥。由jTOP SLE78驱动的ID卡已发行至2018年底。当前制造的ID卡由IDEMIA提供的芯片平台供电（本工作未涵盖）。
（4）证书库
在公共LDAP目录ldap://ldap.sk.ee 中可以找到SK发行的所有有效的ID卡证书。证书的发布受文档加密用例的推动，为发件人提供了获取收件人的公钥的便捷方法。
身份证证明包含持卡人的全名和个人标识码（个人ID码）。个人ID码是一个唯一的11位数字，通常在该人的一生中保持不变，因此在公共和私人数据库中广泛用于标识个人。证书的有效期通常对应于相应的私钥所在的身份证明文件的有效期。
（5）分析的证书
多年来，已经收集了超过700万个在LDAP证书存储库中发布的ID证书。存储库中的证书搜索仅限于个人ID代码。但是，由于所有可能的个人ID代码的搜索空间相对较小，因此，随着时间的推移，所有可能的个人ID代码持有者的证书可能会被搜寻。证书数据集不完整，但认为它包含多年来颁发的ID卡证书的代表性示例。上图显示了ID卡证书在数据集中按发行月（基于证书的notBefore field1）在不同ID平台上的分布。相应的平台已由证书字段和公用密钥的属性确定。由于爬网过程，该数据集缺少2002年至2007年之间颁发的证书以及在短时间内有效的证书。因此，一般而言，发现仅对受影响证书的数量提供了下限。
还收集了公共CRL中累积的证书吊销信息。 CRL中的信息可用于推断持卡人访问证件发行人以接收其新ID卡且旧ID卡被吊销的时间。这些信息以及生态系统的其他一些特性，使得可以得出许多重要的见解。
0x03 Related Work
在爱沙尼亚身份证历史的17年中，已经公开披露了一些与身份证有关的安全漏洞。
由jTOP SLE78平台提供支持的700,000张ID卡受到英飞凌RSA密钥生成缺陷（ROCA缺陷）的影响。英飞凌专有的RSA密钥生成算法中的漏洞仅允许在140.8 CPU年内分解2048位RSA密钥。 2017年发现此漏洞后开始了所谓的爱沙尼亚ID卡危机，此危机通过切换到平台实现的ECC算法并撤销易受攻击的RSA证书得到缓解。
公众很少注意到2011年发行的jTOP SLE66 ID卡中的缺陷。由于ID卡制造商开发的EstEID JavaCard applet的公开未公开缺陷，2011年发行了12万张ID卡。尽管当局声称该卡是安全的，并且使用该卡进行的所有交易都是完全可靠的，但在ROCA漏洞爆发后，媒体披露了2011 ID卡中的漏洞可通过访问获得利用卡。上下文表明这可能是PIN侧信道漏洞的一种。
在2002年，人们发现PIN码打印得太暗，无法通过PIN信封看到它们。具有讽刺意味的是，在接管了ID卡的制造之后，IDEMIA在2018年再次引入了PIN信封的相同缺陷。
发生了以下事件：证书中包含重复的电子邮件地址，颁发的公钥编码不正确的证书，吊销死者的证书等。
0x04 Certifificates with duplicate RSA public keys
2013年春季，在数据集中发现了包含相同RSA公钥的几个证书对。在大多数情况下，公钥是在同一ID卡的身份验证和数字签名证书之间共享的，但是，在两种情况下，同一公钥是在两个不同持卡人之间共享的。此类故障的发生只能通过严重违反生产过程来发生，因为即使对于同一ID卡上的密钥，每个密钥对也必须是唯一的。
上表中列出了包含重复的公共密钥的10个已识别证书对的集合。所有证书都是针对使用jTOP SLE66供电的ID卡发行的。对于每对证书，证书颁发时间仅相差几秒钟，这表明证书是并行或彼此靠近颁发的。在大多数情况下，重复的公共密钥是在PPA客户服务点执行的ID卡更新过程的结果，以替换2011年发行的ID卡的易受攻击的applet。
（1）可能的原因和影响
对于这些重复密钥的一种解释可能是在卡上密钥生成过程中使用的不良随机性来源。但是，由于ID卡芯片没有内置的时间源，例如可以用来植入伪随机数，因此希望这种故障会随机出现，与生成密钥的时间无关数字生成器。由于受影响的ID卡的密钥是在几秒钟的间隔内生成的，因此可以安全地拒绝此假设。
证书签发的接近时间表明，由于某些软件错误（例如竞争条件），证书中包含错误的公共密钥，即，同一公共密钥作为证书签名请求的一部分发送了两次。但是，这将导致该对中的至少一个证书无法电子使用，因为驻留在ID卡上的实际私钥将不对应于证书中包含的公钥。
如果同一张ID卡的数字签名和身份验证证书之间共享同一公钥，则存在的风险是，仅知道一个PIN（PIN1或PIN2，取决于哪个插槽包含相应的私钥）就可以允许该卡用于两种目的。
在不同持卡人之间共享同一公钥的两种情况下，发生更严重的风险。例如，在表中第1对的情况下，根据Toivo可以代表Ülle签名，或者Ülle可以使用其数字签名密钥以Toivo进行电子身份验证并解密为Toivo加密的文件，具体取决于谁的ID卡包含相应的私钥。 （但是，这些用例需要修改软件）
不能排除ID卡实际上确实包含重复的私钥。但是，在这种情况下，唯一可信的解释是与安全要求相反，制造商已在卡外生成了密钥，并且由于个性化过程中的缺陷，同一密钥被导入了两个不同的ID中。卡/钥匙槽。
（2）证明ID卡具有相同的密钥
由于怀疑私钥可能是在ID卡之外生成的，因此决定研究Ülle的数字签名证书和Toivo的认证证书（表中第1对）的共享公钥。
2013年夏天与Toivo取得联系，Toivo告知他的身份证已在Viljandi的PPA客户服务点更新。他提供了加密证明，证明其身份证中的两个私钥均与证书中指定的公钥相对应。为了证明Toivo的身份验证私钥可以成功地用于伪造Ülle的数字签名，在Toivo的协助下创建了以Ülle为名的概念验证数字签名容器（下图）。
未能与Ülle取得联系以从其身份证获得类似的密码证明。 2014年10月，获悉制造商已发现此事件，因为Toivo被邀请用保修期内发行的新身份证替换其身份证。但是，Ülle的身份证证明仍然有效。 2015年春季，获得了爱沙尼亚服务提供商的确认，即Ülle已使用ID卡对服务提供商的电子服务进行身份验证和签名。尽管这使得确信她的ID卡包含相同的私钥，但仍然希望获得对此的加密证明。 2016年夏天，设法与Ülle的女儿取得联系，后者告诉研究者她的母亲每天都使用该卡在网上进行银行交易签名，但是与Ülle自己取得联系的尝试并未成功。后来得知，她的身份证在塔林的PPA客户服务点更新了。
还从Liis（第9对）获得了类似的（非加密）卡的两个密钥都可以电子使用的确认。成功使用重复证书对中涉及的两个证书的能力表明，由于ID卡更新过程中的错误（例如，竞争条件），受影响的ID卡/密钥插槽确实共享了与父级导入的相同私钥。
（3）事件响应
最晚在2014年10月，制造商了解到重复密钥的异常。 2014年10月9日，为Toivo生产了新的身份证，2014年10月10日，Toivo收到了PPA的邀请，将其身份证更换为保修期内的新身份证。电子邮件中指出，2012年11月6日的ID卡更新失败，并且该卡无法通过电子方式使用（实际上是不正确的）。对于其他持卡人，补发卡分别于2014-10-09、2014-12-22和2015-01-06发行（表1的最后一列）。由于未知原因，错过了桑德拉（第3对）身份证上的重复钥匙，因为她没有签发替换身份证。显然，该缺陷的原因尚未完全解决，并且未实施检测机制。结果，稍后Siim的ID卡（对10）再次发生类似的故障。
必须指出的是，该事件并未作为安全问题来处理。在持卡人访问PPA客户服务点以接收替换卡之前，不会撤消受影响的证书。 Ülle可以使用她的身份证，直到身份证到期之前不久才被更换。 Liis告诉研究者，PPA的邀请没有到达她，因此她一直使用她的身份证，直到身份证到期为止。
在2017-02-06的会议上，向RIA通报了Toivo和Ülle的情况，以及最有可能在ID卡外部生成密钥的解释。当时，没有排除RIA和PPA可能清楚了解该漏洞背后的真正原因的可能性。
当与当局联系时，制造商回应说这是2014年已经调查过的旧案件，并且该错误仅发生在公开密钥上。 2017年底，RIA下令进行后续研究，以确定是否可以找到身份证之外的其他任何密钥生成证据。使用统计方法，发现有力的证据表明，在PPA客户服务点的更新过程中，密钥是在ID卡外部生成的。
从前表中可以看到，在第3对最初发行的ID卡中还发现了具有重复公钥的证书。这些情况可能是由于单独的个性化错误导致的，其中卡实际上不包含重复的密钥。敦促RIA和PPA使用SK维护的OCSP证书有效性响应数据库进行调查，以查看依赖方是否已请求对所涉及证书的有效性进行确认。由此可以推断ID卡是否已被成功使用，从而包含了证书中指定的密钥，不知道是否已对此进行调查。
0x05 Private keys generated outside the ID card
2013年底，在斯诺登的启示中，爱沙尼亚发表了一篇观点文章，表达了对当局拥有身份证私钥副本的担忧。当局驳斥了这种担忧，声称私钥的记录是通过所使用的技术方案来排除的，即密钥是在芯片内部生成的，而ID卡的设计应使私钥本身永远不会离开卡。
实际上，ID卡概念中已经提出了芯片内部ID卡密钥生成的安全性要求，已在EstEID技术规范中进行了说明。在SK认证政策中，根据该政策对CA进行了审核，并且还存在于制造商与国家之间的ID卡制造合同中。
此要求的基本原理是芯片内部的密钥生成可提供更高的安全性。确保不创建副本比确保所有副本都被不可逆转地销毁以消除潜在的滥用要容易得多。例如，Mobile-ID技术会带来额外的风险，因为有文献证明Mobile-ID的密钥是在芯片外部生成的。
（1）查找证据
在2016年，Svenda等人[1]描述了一种可用于从RSA公钥模数中推断出有关生成密钥算法的细节的方法。特别地，发现模量N的最高有效字节（MSB）允许建立选择质数p和q的范围。对于RSA密钥生成算法的不同实现，此范围不同。使用此技术和其他技术来验证ID卡证书中RSA密钥中的属性是否与ID卡平台实现的密钥生成算法的属性匹配。为了获得参考密钥，从每个ID卡平台生成并导出了数千个密钥（如果可能），同时测量了卡上密钥生成过程所花费的时间。
a）MICARDO
在所有由MICARDO驱动的ID卡中发现了一个配置缺陷，该缺陷使得能够使用PIN2执行卡管理操作，而无需知道制造商的对称卡管理密钥。使用它来生成和导出平台生成的一百万个以上的1024位RSA密钥对。
MICARDO平台不允许设置公共指数e的值。平台会根据配置为每个密钥选择一个随机的公共指数e，长度为2、3或4个字节。这种特殊性在证书中可见–对于数据集中所有超过一百万个由MICARDO提供动力的ID证书，公开指数值是随机的，没有一个值被过多代表。
如上图所示，MICARDO平台生成的密钥的N的MSB分布与MICARDO支持的ID卡证书的密钥非常匹配。由于MICARDO平台生成的密钥中N的MSB分布显示出在任何已知软件库生成的密钥中均未观察到的独特模式，因此可以得出结论，MICARDO-平台已生成有源ID卡。但是注意到，数据集在2002年至2007年期间没有颁发足够的证书，无法对在此期间生成的密钥得出明确的结论。
b）MULTOS
无法访问非个性化的MULTOS平台，因此无法生成参考密钥。在数据集中，为MULTOS供电的ID卡颁发了29262份证书。上图显示了这些密钥的MSB值的分布。公钥具有一个随机的4字节公钥，模仿了MICARDO的非标准行为。
无法对这些密钥的来源做出结论，但是，看到这些密钥不是由OpenSSL（非FIPS）生成的，因为模数并不总是等于1模数3。
c） jTOP SLE66（最初发行）
要导出由jTOP SLE66平台生成的一百万个密钥，使用了空白的jTOP SLE66 JavaCard。由于RSA密钥生成是在JavaCard平台级别上实现的，因此不需要访问制造商专有的EstEID JavaCard小程序。
观察到此CC认证JavaCard平台存在功能错误。当要求生成2048位RSA密钥时，在38％的情况下，将返回2047位密钥。当从1024位素数的分布中均匀选择p和q时，这接近38.6294％的理论比率。为了生成所需长度的RSA模数，通常或者使用拒绝采样方法来再生素数，直到其乘积达到所需长度为止，或者对素数进行采样以确保k位素数大于√2·2^(k-1)。 jTOP SLE66平台生成的密钥中N的MSB分布如下图所示。
由jTOP SLE66驱动的ID卡从2011年发行到2014年底。所有最初发行的ID卡的证书都包含带有随机4字节公共指数的公共密钥，这类似于MICARDO的非标准行为。 JavaCard规范要求实现支持至少4个字节长的任意公共指数值。验证了jTOP SLE66平台可以接受并能够生成长度为4个字节的任意奇数e的RSA密钥对，因此该平台可能已从证书生成了密钥。
对于2014年发行的ID卡，MSB的分布与平台生成的分布相匹配（上图b）。但是，2014年之前发行的ID卡缺少2047位RSA密钥（MSB值小于128）（上图a）。 3位持卡人除外，他们在2013年10月获得了带有2047位密钥的证书。这些持卡人是SK的两名员工和一名与制造商有关的人员。假设这些卡是在生产之前发行的，用于测试制造过程中的变化。
由于2047位RSA密钥的生成仅是jTOP SLE66平台所特有的异常，可以得出结论，对于2014年发行的ID卡，密钥是由该平台生成的。
通过分析身份验证和数字签名证书的notBefore字段之间的时差，发现令人信服的证据表明，平台生成了2014年之前发行的ID卡和2014年发行的ID卡的密钥 。
显然，2014年之前的ID卡制造流程拒绝了2047位密钥，以确保证书包含符合标准的2048位密钥。拒绝2047位密钥将密钥生成时间增加了1.63倍，因此，密钥生成的平均时间（在随机e的情况下）从87秒增加到141秒。较慢的密钥生成时间可能是导致2014年终止2047位密钥拒绝实践的原因
d） jTOP SLE66（PPA更新）
为了修复2011年ID卡中的漏洞，ID卡制造商介绍了可在PPA客户服务点执行的ID卡更新程序。在续订过程中，删除了旧的EstEID JavaCard小程序，并安装了具有新密钥和证书的新小程序。该更新在2015年晚些时候被重新使用，以解决证书中指定的重复电子邮件地址的事件，并在2016年被修复以使用公钥编码错误的证书。由jTOP SLE66驱动的ID卡的更新已于2017年7月1日终止。在PPA客户服务点，总共更新了超过74000张由jTOP SLE66驱动的ID卡。
与最初发行的ID卡相反，在PPA客户服务点中更新的密钥的公共指数设置为65537。这些密钥显示的MSB分布与jTOP SLE66平台生成的密钥完全不同（请参见上图）。这种分布是将p和q的两个最高有效位设置为112的结果。
从理论上讲，PPA客户服务点中安装的EstEID applet版本可能会重新生成密钥，直到p和q的两个最高有效位为112。但是，这将使密钥生成时间增加4倍，则将密钥生成的平均时间（在e = 65537的情况下）从33秒增加到132秒。没有合理的解释为什么会这样做，因此认为这些密钥是在智能卡外部生成的。这样做可能会提高密钥生成速度，从而提高PPA更新服务的吞吐量。实际上，当局可以通过查看PPA客户服务点中更新以jTOP SLE66驱动的ID卡所需的平均时间来验证这一点。
有几个软件库通过将p和q的两个最高位设置为112来生成密钥。它们是：Botan 1.11.29，cryptlib 3.4.3，GPG Libgcrypt 1.6。 5，LibTomCrypt 1.17，Net tle 3.2，OpenSSL FIPS 2.0.12，PGP SDK 4和WolfSSL 3.9.0。 OpenSSL 1.0.2g被排除在外，因为OpenSSL（非FIPS）生成的模数始终等于1模数3，而在证书中观察到的模数则并非如此。
e） jTOP SLE78
由于jTOP SLE78平台受到ROCA漏洞的影响，因此可以使用[2]中公开的方法来验证为jTOP SLE78驱动的ID卡颁发的证书是否包含受ROCA漏洞影响的密钥。该方法没有误报，并且2048位RSA密钥的误报率可以忽略不计(1/[2^(713)])。
验证表明，RSA密钥确实是由平台生成的。这包括所有密钥-最初发布，远程更新以及在PPA客户服务点中更新的密钥。但是，有23个密钥没有易受攻击的密钥的结构。
（2）从证书颁发时间推断密钥生成时间
尽管现代计算机能够在不到一秒钟的时间内生成2048位RSA密钥，但智能卡芯片中的RSA密钥生成平均需要数十秒。由于花在密钥生成上的时间可以用来推断密钥是否是通过卡片上缓慢的密钥生成过程生成的，因此决定研究是否可以从证书颁发的时间来观察花费在生成密钥上的时间。
在ID卡个性化过程中，如果在生成特定（身份验证或数字签名）密钥对之后立即将证书签名请求提交给CA，则第一张和第二张ID卡证书的notBefore字段之间的时差将包括生成第二个密钥对所花费的时间。另一方面，如果在个性化过程中，在两个密钥对都生成之后一起提交了证书签名请求，则证书的notBefore日期之间的差异将不包括密钥生成时间。
如果在相同类型的身份证明文件的24小时窗口中将证书颁发给同一持卡人，则将证书分成属于同一ID卡的对，并查看有效日期之前的时间差异的分布。
a）MICARDO
对于所有最初发行的MICARDO证书，证书中的有效日期之前时间的时间部分设置为“ 00:00:00”。对于在证书续订过程中颁发的证书，notBefore字段包含不同的值，这些值似乎与CA颁发证书的实际时间相对应。在MICARDO平台上生成1024位RSA密钥平均大约需要15秒。但是，每个月证书之间的平均时间差低于4秒。但是，这是可以预期的，因为在MICARDO证书续订过程中生成了两个密钥对之后便会颁发证书。
b） MULTOS
MULTOS驱动的ID卡的所有证书在notBefore字段中具有不同的值，该值可能对应于颁发证书的时间。但是，证书颁发之间的时间差最多只有几秒钟。这是可以预期的，因为MULTOS平台仅用于数字身份证，数字身份证通过预先生成的密钥分发给PPA客户服务点。
c） jTOP SLE66（最初发行）
对于在2011年7月9日之前发行的使用jTOP SLE66的ID卡，证书中notBefore有效日期的时间部分设置为“ 00:00:00”。但是，从2011-07-11开始，notBefore日期包含不同的时间值，这些时间值似乎对应于证书颁发的时间。
证书签发时间差大于2小时的ID卡从分析中排除。每个月这种身份证的数量不到0.32％。这些情况可能是卡个人化过程中断的结果，该过程随后又完成了。
上图a中显示了按月分组的第一张证书和第二张证书的颁发之间的时间差异分布（方框图中的异常值覆盖了5％和95％以上的百分位数）。在2011-10-06之前，证书颁发之间的时间差异很小，其中认证证书是第一个颁发的证书，时间接近一半。从2011年10月6日开始，认证证书至少是99.88％的时间是第一个颁发的证书，并且证书颁发之间的平均时间差显着增加。
看到时间差的分布非常类似于jTOP SLE66卡上密钥生成的密钥生成时间分布。也就是说，从2011年11月到2014年1月，观察到的分布与使用随机公共指数e时RSA卡上密钥生成的分布相匹配，并且当产生的模数长度为2047位（平均）时重新生成密钥时间141秒）。当使用随机公共指数e时，从2014年1月开始观察到的分布又与RSA卡上密钥生成的分布相匹配，但未应用拒绝采样方法（平均时间为87秒）。
观察到的时间支持以下假设：2014年之前和2014年发行的ID卡上的密钥是由jTOP SLE66平台生成的。在2011-10-06之前观察到的时间差异很小，因此无法对这些密钥的来源做出明确的结论，因为这些密钥的属性与2011-10-06之后发布的密钥的属性相匹配，倾向于得出结论，这些密钥也是由平台生成的。
d） jTOP SLE66（PPA更新）
已经发现在PPA中更新的由jTOP SLE66驱动的ID卡的密钥不是由该卡生成的，但是为了不忽略任何可能的证据，还研究了这些ID卡的认证和数字签名证书签发之间的时间（见前图b），第一张和第二张证书的发行之间的时间差仅稍有变化。看到在2013-02、2015-08和2016-07年，PPA续签过程中引入了一些更改，这些更改导致了证书发行时间差异的更改。由于时间差不接近零，并且认证证书是99.79％的时间是第一个颁发的证书，因此倾向于得出这样的结论：观察到的时间差包括花费在密钥生成和导入上的时间，以及可能将证书加载到ID中卡。
e） jTOP SLE78
由jTOP SLE78驱动的ID卡的身份验证和数字签名证书颁发之间的时序如前图c所示。分析中排除了数字身份证证书。看到当e = 65537（平均时间13秒）时，证书颁发的时间与jTOP SLE78平台的密钥生成时间的分布相匹配。从2016-06年开始，平均时间低于13秒的原因是2016年6月22日引入了远程ID卡更新。在远程更新过程中，在卡生成两个密钥对之后，将颁发证书。
（3）讨论
在jTOP SLE66驱动的ID卡更新中非法导入密钥的做法绝非偶然。 EstEID小程序必须经过特殊编程才能实现这样的密钥导入功能。
身份证制造商能够使用该禁止功能多年而不被发现的事实，得出一个推论即制造商可以类似地使用密钥导出功能，在私钥被使用后检索私钥。由芯片生成。目前尚不清楚在什么程度上违反严格的行业规则。
签名密钥的大规模滥用将很难保密，而解密密钥的滥用则不会如此。希望制造商的意图不是恶意的，并且这种非法行为仅出于增加PPA更新服务吞吐量的需要。
尚不清楚制造商最初是否理解生成具有随机公共指数的密钥会将平均密钥生成时间从33秒增加到87秒（有关分配，请参见上图）。该增加是由于候选日期素数p和q不适合的可能性更大，因为随机选择的公共指数e可能具有较小的素数除数。拒绝2047位RSA密钥会使平均密钥生成时间增加更多，达到141秒。仅生成两个ID卡密钥对，平均就可以将更新过程平均延长大约五分钟，并且在最坏的情况下，甚至可以花更多的时间，如图上图b所示。
对于使用jTOP SLE78的ID卡，使用随机公共指数的毫无用处的实践结束了。在初始密钥生成过程以及PPA客户服务点中的ID卡更新中，平均13秒的平均时间（分配参见下图）被认为是可以接受的。后来，使用曲线P-384切换到ECC，将板载密钥生成时间平均缩短到0.37秒。
同一密钥被导入到在不同的PPA客户服务点更新的两个不同的ID卡中的事实表明，密钥是在制造商的后端中生成的，并通过Internet导入到ID卡中。即使密钥是通过端到端加密通道发送的，制造商也可以使用日志和对称卡管理密钥来恢复导入的私钥。
制造商未经授权对EstEID小程序进行的修改也对使用受影响的平台制作的数字签名的有效性产生深远的影响。由于此EstEID小程序的修改版本从未按照eSignature指令1999/93 / EC的要求通过安全签名创建设备（SSCD）一致性评估，因此该ID卡平台从不具有SSCD状态，即是数字签名具有手写签名状态的法律前提
（4）事件响应
收到本文分析后，当局决定召回在PPA客户服务点更新的由jTOP SLE66驱动的ID卡。在超过74 000张更新的身份证中，只有12 500张仍然有效。
PPA于2018-05-17公开宣布12 500个ID卡不符合安全性要求，因为其私钥是在芯片外部生成的。这些卡将在保修期内更换，并且在2018年6月1日将撤销受影响的证书。
当天，受影响的持卡人收到了电子邮件通知以申请更换。持卡人必须做出回应，指定要收集新卡的PPA客户服务点。作为替换，持卡人收到了由jTOP SLE78驱动的ID卡，该卡的有效日期与原始卡的有效期相同。但是，如果原始到期日期少于三个月，则不会发行替换卡。
2018年6月1日，吊销了11100张未替换ID卡的证书，有3300位持卡人在等待领取替换卡。证书撤销的法律依据是EITSETA法案，第19（4）2）条：“未经证书持有者同意，可以使用与证书中包含的公钥相对应的私钥” 。
注意到，即使当局不认为这是安全问题，也存在不合规问题，因此，根据《 EITSETA法案》第19（4）12）条，证书也可能被吊销：证书或证书中输入的数据出现错误”，因为未按照证书中引用的CA证书策略颁发证书。
（5）向制造商索赔
根据PPA的说法，在内部审计中，发现政府没有要求也不知道金雅拓正在卡外生成密钥。在收到本文的初步分析后，PPA向金雅拓提交了索赔。然而，金雅拓否认侵犯行为的回应仅在宣布召回身份证之前的前一天收到。
PPA发布后的第二天，2018年5月18日，金雅拓宣布PPA的声明令人惊讶，并且它已履行了ID卡合同及其中约定的义务。显然，身份证制造商是不能被信任的，但是根据合同，他们必须生产身份证，直到2018年底新的制造商IDEMIA接管为止。
在未能达成协议后，PPA在2018年9月26日将金雅拓告上法庭，要求在芯片外生成密钥的合同罚款金额为1.52亿欧元。但是，此要求必须与金雅拓其他正在进行的诉讼结合起来考虑-PPA向金雅拓索赔30万欧元，原因是金雅拓未能将ROCA漏洞告知政府，金雅拓就身份证的结果提出上诉采购。法院对这些案件的判决尚待观察。
0x06 Certifificates with corrupted RSA public keys
在2012年，Heninger等人[3]发布了一种有效的方法来测试RSA公钥中共享的主要因素。该方法用于发现来自某地公民数字证书的103个RSA密钥共享主要因素。使用相同的方法从爱沙尼亚ID卡证书中测试RSA公钥中共享的主要因素，并在成对GCD计算的输出中发现了几个小的公共因素（例如3、5、7）。通过使用带有小的素数的试验划分，发现了14个证书，其公钥模数可以除以一个或几个小因素。由于2048位RSA的公钥模数是通过将两个不同的随机1024位素数相乘而生成的，因此证书中包含的公钥模数显然已损坏。这种损坏似乎只影响jTOP SLE78平台，因为所有具有损坏模数的证书都是针对由jTOP SLE78平台提供动力的ID卡颁发的。
使用软件工具YAFU和椭圆曲线方法（ECM）的GMPECM实现来测试数据集中所有RSA密钥的小因素，已测试到t-level t20。但是，这没有找到任何其他损坏的密钥。其中两个损坏的密钥存在明显异常-模数的长度为2040位。在数据集中发现了另一个异常的2040位模数，并且通过对其进行更多的ECM测试（大约t40），能够找到一个132位的质数因子。后来Nemec等人[2]公开了一种检测易受攻击的英飞凌密钥生成算法生成的模量的方法，能够识别出8种可能损坏的模量。这些是在观察到这些证书（根据证书吊销日期已由于ROCA漏洞而被吊销，因此已针对具有jTOP SLE78功能的ID卡发行的，不具有ROCA密钥结构）而发现的。下表列出了完整的23种已识别证书。
（1）全分解
颁发具有损坏的公共密钥模数的ID卡证书意味着这些ID卡的持卡人将无法使用加密功能，因为驻留在其ID卡中的私钥与证书中的公钥不对应。但是，公钥的损坏也具有严重的安全后果。通过从损坏的模量中恢复所有素数，可以计算相应的私有指数并使用该密钥执行私有密钥操作。如果模数具有2048位，可以期望以任意破坏的概率将分解的模数有效分解为12 – 22％。
能够完全分解出这些损坏的公共密钥之一，即发给Svetlana B的数字签名证书中的密钥。模数由7个因素组成（9位，15位，21位，39位，53位，153位和1762位）。在使用2个内核的Core i5-6260U@1.8GHz CPU上，概率YAFU ECM因式分解过程花费了60个小时（t40.80）。在RSA多素数设置中计算了私有指数d，并作为概念证明在空文件上成功伪造了数字签名。正如预期的那样，数字签名通过了国家提供的数字签名验证软件的验证（参见下图）。
（2）事件响应
在2017-02-06的会议上向RIA通报了公钥被损坏以及Svetlana密钥成功分解的情况。那时，最初确认的15张证书中有8张已经被吊销，可能是因为持卡人发现加密功能不起作用并申请了新卡。
2017年2月22日，Svetlana的身份证证书被暂停。同时，RIA使用其资源进行了计算，以验证本文的发现并确定完整证书数据库中更多的损坏密钥。
仅在2017-06-09时，受影响的ID卡（包括Svetlana的那些）的证书被吊销，PPA在担保下向持卡人颁发了新的ID卡。由于无法排除芯片中的缺陷，因此还向Lennart发行了替换ID卡，Lennart在2016年7月1日在PPA客户服务点已使用用于替换公钥编码错误的证书的更新程序成功更新了他的钥匙。
由于不知道问题的根源，因此采取了一种措施，即使用小素数进行试验划分，以发现身份证生产过程中损坏的模量。不幸的是，如Raja的损坏密钥所示，损坏密钥的最小因素可能很大，因此无法通过此方法发现。
由于发现ROCA漏洞而撤销了由jTOP SLE78驱动的ID卡的所有RSA密钥，并且将由jTOP SLE78驱动的ID卡的制造转换为ECC密钥，最终在2017年11月3日减轻了风险。 ECC密钥也不能排除类似的损坏，但是，已经验证了数据集中的所有ECC密钥都具有曲线上的EC点，并且导致曲线上EC点的随机损坏不会提供优势。推导相应的私钥。
值得注意的是，制造商已在2015年8月发现2040位RSA模数异常，因为新的ID卡随着原始卡的失效日期在3个持卡人中产生了2个（Raja和Svetlana S.）在2015-08-24和2015-09-04。由于不明原因，制造商未理会Raisa案。对于她来说，替换身份证仅在告知当局公钥已损坏之后才于2017-06-09发行。
在2015年，此案件未作为安全问题处理，因为包含损坏密钥的证书仅在持卡人访问PPA以获得替换卡后才被撤销。这是通过简单地发行替换ID卡，没有找到根本原因并且没有分析其规模和安全影响来缓解ID卡生产过程中严重异常现象的又一个示例。
（3）数据损坏的原因
根据检测易受ROCA攻击的模量的方法，试图通过修改模数来恢复损坏的模量，直到ROCA密钥检测测试返回阳性结果为止。能够成功恢复13个密钥的损坏。在2040位RSA模数的情况下，每个模数的不同位置缺少字节0x81（100000012）。对于2048位RSA模数，每个模数在不同位置的字节0x80（100000002）被替换为字节0x00（000000002）。进行了详尽的搜索，在任何位位置最多修改4位，在任何字节位置最多修改3个字节，但是无法恢复任何其他密钥的损坏。
在将公钥包含在证书中之前，公钥的任何损坏都可能发生。损坏也可能是由于芯片中的故障而发生的，例如，芯片在某些特定的操作条件（例如温度或电压）下无法生成或正确存储生成的密钥。但是注意到，即使这些安全芯片处于恶劣的环境条件下，它们仍声称采取了一套检测和防止损坏的措施。
联系了受影响的ID卡的所有者Lennart，然后分享了他于2016-01-15发送给ID卡客户支持的屏幕截图，其中显示了Mozilla Firefox 43.0.4错误消息“同行报告签名验证失败。尝试对服务器执行TLS客户端证书认证后出现的“错误或密钥交换（SSL_ERROR_DECRYPT_ERROR_ALERT）”。此错误表示ID卡能够生成签名，但是服务器无法使用来自认证证书的损坏的公钥来验证签名。
签名可能使用有效的私钥创建，因为CRT形式的私钥操作不使用模数，而是使用p和q。如果p或q被破坏，则模数（p和q的乘积）将比上面发现的一点变化更严重。这些卡上有效RSA私钥的存在不排除在读取或写入内存中模数时模数损坏的可能性。然而，在2040位模数情况下丢失的字节很难通过芯片内部的存储器损坏来解释。
在2018年夏季联系了英飞凌，询问他们是否听说过该产品的类似事件，如果没有，他们是否会完全排除由于芯片故障而导致损坏的可能性。引用英飞凌的话：“我们不知道系统中的任何过程（软件或硬件）可能导致这种变化。” 。
在没有其他可用证据的情况下，提出了这样的假设：制造商的个性化生产线在卡与读卡器之间的通信过程中发生了损坏。在2040位模的情况下，丢失的字节可以通过在面向字节的T = 0协议的APDU传输中错误接收的字节的重传失败来解释。对于已恢复损坏的13个模数中的4个，看到模数的第254个字节（第二个最高有效字节）已损坏。在T = 0协议的情况下，这将相当于在过程字节之后发送的第二个字符，以为芯片在单个APDU响应中返回了256字节的模数。由于制造商的个性化生产线使用专用硬件，因此不能排除此类故障。
（4）预防和检测措施
在传统的PKI部署中，通过采用PKCS＃10标准（要求使用相应的私钥对证书签名请求（CSR）进行签名），可以降低在证书中包含损坏的公共密钥的风险。在这种情况下，CA认为此要求是不必要的，它依赖于制造商必须实施的公开未记录的组织措施，以确保制造商拥有相应的私钥。正如现在所看到的，实际上，这些未知的组织措施不足以提供已签署的企业社会责任所提供的保证。
无论模块是在芯片内部还是在从芯片的传输中损坏，此处的教训是，即使对于在受信任环境中进行的个性化设置，也应通过在MAC-上进行传输来保护关键APDU数据的完整性。受保护的安全通道。如果是这种情况，那么损坏的源将以加密精度定位。
为了避免将错误的证书或具有不正确的公钥的证书装入卡的这种和其他个性化错误，卡应执行内部标志验证完整性检查，以验证加载的证书中的公钥是否与私钥相对应。密钥卡存储。
（5）来自未知来源的有效RSA模数
提出了这样的假设：为Vladislav和Pirgit的ID卡发行的4个证书实际上确实包含有效的RSA密钥，但是这些密钥不是由相应的ID卡生成的。
基于以下假设：与前表中的所有其他证书相反，这些证书是在PPA客户服务点的证书续订过程中颁发的，而不是在最初的ID卡个性化过程中颁发的。看到这些密钥中的3个具有jTOP SLE78平台生成的MSB模数不在144-168范围内，但所有4个都在144-255范围内，这与外部制造商生成的RSA密钥的范围相对应身份证。
似乎由于某种未知的故障，对于这些ID卡，假设它们由jTOP SLE66平台提供动力，则制造商的后端执行了更新过程。在未检测到更新过程（包括密钥导入）不成功的情况下，生成了密钥并激活了相应的证书。在没有其他可用证据的情况下，一旦这些模因数分解可行，将只能证明或反驳这一假设。
0x07 Discussion and conclusions
改进的安全工程师的做法可以避免所有问题，除了制造商决定通过在ID卡之外生成密钥来违反安全性要求之外。尽管制造商发现了重复的公共密钥和损坏的公共密钥的缺陷，但仍未对其进行充分调查并导致重复事件。
在eIDAS的上下文中，密钥管理是CA的职责。在CA的内部和外部审核中未发现制造商的违法行为，这一事实表明，这些审核提供的保证水平有限。
违反合规性也是Web浏览器CA中的常见问题。但是，浏览器供应商需要CA发布发现的违规的详细报告，从而迫使CA调查事件并改进其行为。如果CA缺乏信任度，浏览器可能会不信任它们。
同样，要求欧盟成员国建立监督机构，以监督信任服务提供商是否遵守eIDAS要求。对于爱沙尼亚身份证，实施强制措施可能会因以下事实而受到阻碍： 在爱沙尼亚身份证的情况下，采取强制措施可能会受到以下事实的阻碍：身份证制造商(因此CA)是政府的合同合作伙伴，直到至少5年的身份证制造合同到期。但是，这项工作的结果表明，国家不能依靠身份证制造合同中提供的安全保证，而应该通过公共政策或身份证制造合同的条款寻求有效的监督手段。
总体而言，本文的研究结果提供了一个例证，盲目地信任制造过程的安全性是不可持续的。从技术角度来看，建议寻找容错设计，例如那些涉及阈值加密技术的设计。这些设计应寻求提供有效的手段来防止意外故障，并确保在严重的恶意行为中，制造商会要求更高的阴谋，从而增加发现和归因的风险。
不幸的是，还没有看到爱沙尼亚身份证制造过程的组织和执行方面的根本变化，因此，类似的事件注定会再次发生。但是，希望公众对这些事件的了解已经改变了人们对身份证的认识。现在，这应允许构建更好的安全系统和法律规则，以应对ID卡的潜在安全故障。
Reference
[1]Petr Svenda, Matus Nemec, Peter Sekan, Rudolf Kvasnovsky, David Formanek, David Komarek,and Vashek Matyas. The Million-Key Question – Investigating the Origins of RSA Public Keys. In FI MU Report Series, FIMU-RS-2016-03,pages 1–83. Masaryk University, 2016. https://crocs.fi.muni.cz/_media/public/papers/usenixsec16_1mrsakeys_trfimu_201603.pdf.
[2]Matus Nemec, Marek Sys, Petr Svenda, Dusan Klinec,and Vashek Matyas. The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security,CCS ’17, pages 1631–1648, New York, NY, USA, 2017.
ACM.
[3]Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices. In Presented as part of the 21st USENIX Security Symposium(USENIX Security 12), pages 205–220, Bellevue, WA,2012.USENIX.