ACM通信

实践

每个人口袋里的身份

由菲尔·瓦尚
ACM通信，2021年1月，第64卷第1期，46-55页
10.1145 / 3424262
评论

几乎每个技术从业者都有某种类型的智能手机。在世界各地，手机连接比清洁的自来水更普遍。通过智能手机，用户可以办理银行业务，与当地政府互动，购买日常必需品，或者只是与世界各地的亲人保持联系。

正是这种无处不在的特性带来了有趣的安全挑战和机遇。甚至在不到10年前，生物识别认证这样的概念还只是一个新奇事物，只在政府和金融服务行业的专门应用中使用。如今，你很难找到没有过用指纹解锁手机的经历的用户，或者最近没有过仅靠看屏幕解锁手机的用户。但这幅图远不止照相机所能看到的:在炫目的用户界面的深层，是一个由安全处理器、硬件支持的密钥存储和用户身份管理驱动的世界，这些都是看似简单的功能。

较新的手机以许多不同的方式和组合使用这些安全功能。然而，与任何安全技术一样，不正确地使用特性会产生一种错误的安全感。因此，许多应用程序开发人员和服务提供商今天不使用任何现代手机提供的安全身份管理设施。对于属于这一阵营的人，本文旨在让您了解如何将硬件支持的、基于生物特征的用户身份概念引入到您的生态系统中。

目标很简单:让攻击者尽可能难以窃取凭据并在空闲时使用它们。让我们甚至让用户难以复制自己的凭证与其他用户共享。除了这种保护之外，让我们确保添加额外的因素，如生物识别认证，可以更有力地确保用户是谁。让密钥和其他秘密越来越接近与用户物理相连的某些东西，可以更好地保证刚刚向设备进行身份验证的用户的身份。

回到顶部

什么是数字身份?

在现实世界中，证明你的身份可能涉及检查身份文件，如护照、签证或驾照，并匹配照片或其他生物识别印在那份文件上。伪造这些文件的价值是相当高的，所以民族国家和其他身份发行人竭尽全力使其变得困难。与此同时，它们必须使验证者更容易发现即使是最复杂的伪造。设计安全文档的背后有一个完整的行业(例如，https://www.jura.hu)，发展防伪技术(https://www.muehlbauer.de)，并大规模生产这些文件。当然，这些努力并不是万无一失的，有时最敏感的用例需要使用嵌入在文档本身的“秘密”安全特性对身份文档进行更仔细的检查。

在技术领域，身份是通过某种加密方案证明的，身份本身体现在用户持有的密钥中。然而，仅仅拥有这个秘密通常是不够的:就像没有照片来识别所有者的物理身份文件一样，一些加密秘密可能被任何人窃取和使用。对于大多数用例，政策围绕着秘密如何存储变得至关重要。存储在笔记本电脑硬盘上的私钥可能不如存储在智能卡上的私钥可信。

例如，考虑经典的邪恶女仆攻击，攻击者使用对物理空间(如私人住宅)的特权访问，以所有者无法察觉的方式更改、偷窃或仅仅使用设备或凭证。存储私钥的位置可能会产生影响。邪恶的女仆可以简单地复制存储在笔记本电脑磁盘上的私钥，但他或她不能轻易地在智能卡上做到这一点，因为智能卡很难克隆和提取信息。邪恶的女仆不可能在你不注意的情况下拿走一张智能卡，而且在大多数现代实现中，在短时间内复制这张卡是一项困难的任务。随身携带一张智能卡也更容易，这样就可以让你远离邪恶女仆的魔爪。

回到顶部

移动电话作为安全密钥库

经过多年的开发、来之不易的安全工程经验和实际经验，大多数现代智能手机都具备了广泛的安全功能。在讨论移动电话作为身份管理设备的使用之前，让我们从高层次上定义这个设备是什么样子的。

图1展示了理想化的智能手机。注意AP(应用程序处理器)和SP(安全处理器)之间的区分，以及它们如何控制手机的不同方面。

图1。理想化的智能手机。

智能手机的部件相当简单:

• 一个显示。
• 生物识别传感器(面部识别、指纹识别)。
• 一个“安全的”处理环境，或称SP (GlobalPlatform更喜欢使用这个术语)可信执行环境,或三通．在建筑上，这些概念是相似的，但使用SP避免与通常用于指代android特定实现的术语混淆)。SP是专门的安全软件运行的地方，如苹果的SEPOS(安全飞地处理器操作系统)或高通的QTEE;与SP环境相关的所有包含内存的程序代码和数据都受到保护，这样即使是同一芯片上的其他cpu也不能访问SP数据(稍后将详细介绍)。
• 安全的存储环境，用于存储SP的机密和其他敏感信息。
• “应用程序”处理环境，简称AP，应用程序和手机操作系统(如iOS或Android)在此运行。AP与SP之间只能通过有限的通道进行通信。

这里的一个假设是，设备通常属于用户。此外，附加的保护措施，如PIN被认为足够强大，以保护设备免受攻击。尽管考虑一个拥有无限资源的民族国家可能实现的攻击很有趣，但按照如此高的标准进行设计并不总是实际的。

有了这个智能手机模型，你可以开始思考如何构建一个安全系统。可以把SP和AP看作是同一部手机上的两个不同的世界。对于iPhone，苹果推出了SEP。大多数Android手机要么有一个完全独立的芯片(例如，谷歌的Titan M芯片在Pixel 3和以后的版本中)，要么使用Trust-Zone将SP实现为TEE，⁹arm专有的应用程序处理器CPU的安全虚拟化状态。

SP有一个专用的安全内存区域，该区域经过加密，通常经过身份验证。^3.，6这种加密还可以保护安全内存，防止攻击者在物理上占有电话，以及防止AP改变或恢复SP的状态。如果不能访问用于加密内存的密钥，任何人都很难恢复原始内存内容。这是一种对现代SoC(芯片上的系统)，如苹果或高通的硬件强制控制。任何对这一控制的破坏都将是灾难性的，允许AP自由访问SP内存中的任何敏感数据。(SP软件中的漏洞将允许攻击者以类似于安全硬件试图阻止的方式访问SP的内存。如果这对您的应用程序造成的风险太大，您可能需要考虑其他硬件安全令牌，如YubiKeys，甚至构建您自己的令牌。)

SP还可以访问AP无法访问的自己的一组外设(如指纹传感器或用于支付处理或安全数据存储的安全外部设备)。SoC的某些功能，如赋予智能手机独特身份的加密密钥，也只能由SP专用的硬件访问。为安全处理器加密所有长期存储的密钥通常使用这种类型的机制存储。

SP的持久存储包括许多重要的数据块，包括应用程序生成的密钥、代表授权用户的生物特征模板和唯一标识手机的密钥。在大多数实现中，这些数据位是加密的包装使用长期存储密钥，使它们只能被SP中运行的软件访问。然后，持久数据被交还给AP，在闪存中进行长期存储。这个包装过程保证了信息的安全，并确保在AP上运行的任何应用程序都不能假装自己是SP。更重要的是，包装可以防止恶意方从手机中提取秘密并克隆它们(或更糟糕的是，巧妙地破坏这些秘密)。

与AP相比，SP运行的操作系统极其简单。通常情况下，第三方应用程序不能安装在这种环境中，能够运行的代码是专门为设备所需的安全应用程序而构建的。这是为了将暴露的攻击面最小化，并降低软件漏洞危及SP完整性的概率。正如您所知，软件，即使在SP中，也永远不会真正完美。¹⁰

SP和AP之间的所有通信都是严格控制的。根据设计，AP不能访问SP的内存，但SP可能能够看到AP的一些内存。两个世界之间的所有通信都是通过rpc(远程过程调用)进行的，序列化从不安全世界传递到安全世界的所有参数和数据(或者反之亦然)。

用这个RPC机制定义的操作通常是相当高级的。例如:"Generate key pair"使用命令中指定的参数生成一个新的密钥对;然后它返回公钥和密钥ID作为响应，“带密钥对的签名blob”接受密钥ID和指向一团数据的指针，然后返回签名作为响应。这些操作是不灵活的，但这是经过设计的:灵活性引入了更多可能出错的方式。

图2显示了SP和AP之间的逻辑划分。注意SP如何拥有自己的私有加密硬件，以及该硬件如何成为访问制造过程中生成的关键材料的唯一途径。这甚至可以保护密钥不受软件破坏。大多数SP没有足够的闪存来存储所需的所有密钥，而是将使用只有SP才能访问的密钥加密的数据传递给AP进行长期存储。安全内存保护防止AP能够“看到”SP的内存空间中正在发生的事情，但允许SP读写AP的内存空间。

图2。SP和AP之间的逻辑划分。

图3显示SP生成和持有的任何密钥的使用顺序。注意AP只能通过特定的rpc请求使用密钥，而不能访问私钥本身。

图3。AP生成的密钥的使用顺序。

一个重要的教训是，为了实现现代手机的安全特性，在AP和SP上运行的硬件和软件之间发生了精心设计的舞蹈。一个错误，整个安全模型就可能被破坏。

需要考虑的最后一块拼图是手机的身份从何而来。建立信任需要一点证据，证明手机是按照预期的安全标准生产的。追溯到安全生产过程的可追溯性要求设备在生产过程中有一个加密的秘密程序，可以跟踪到制造商。使用这个制造秘密签署的身份证明，结合持有密钥的设备的物理安全性知识，以及围绕您生成的密钥可能被使用的方式和位置的软件策略，允许您决定您在设备上生成的身份究竟有多可信。

回到顶部

基本身份验证模型

到目前为止，我们应该很清楚，大多数最新的手机都具备创建数字身份所需的所有部件。开发人员如何使用这些部件来建立一个身份，使其能够验证在手机上运行应用程序的用户，从而访问运行在云中或某些内部基础设施中的服务?

为支持对应用程序的用户进行身份验证而生成的任何标识都有一个通用的生命周期。无论是智能手机、独立生物识别令牌还是其他，基本步骤是:

1. 招生．这将启动生成所需密钥的过程。
2. 认证和交付．这将验证密钥是安全的、安全存储的，并且很难提取和克隆。如果成功，您可以向设备交付某种形式的身份以供将来使用。
3. 使用．密钥可能用于相互TLS(传输层安全)身份验证或其他一些带外身份验证协议。
4. 失效．当用户或手机的某些信息发生某种变化时，应该删除用户身份密钥，迫使用户重新注册。

当我们研究使这种标识模型工作所涉及的各种技术时，我们将详细介绍这些步骤对您的应用程序的意义。

回到顶部

密钥对

在实际应用中，密码身份用非对称密钥对表示。尽管非对称密码学的细节超出了本文的范围，但作者还是建议您这样做数学密码学导论“，Jeffrey Hoffstein, Jill piphher和J.H. Silverman(施普林格2008)深入研究了密码方案是如何工作的;实际的加密尼尔斯·弗格森和布鲁斯·施奈尔(Wiley, 2003)的作品也是一个很好的参考，尽管有点过时。

不需要详细说明，非对称密钥可以由两部分组成:一个必须保密的私钥，可以用来生成密码证明(以数字签名的形式)，和一个公钥，另一方可以使用它来验证这些签名。私钥必须在最受控制的情况下使用——使用最受保护的硬件，确保没有人能够捕获私钥。在智能手机的模式图1，这意味着使用私钥执行的所有操作都在SP的环境中完成。

回到顶部

键和认证

如果没有验证这些属性的方法，就很难考虑私钥及其存储策略的可信性。如何获得生成的密钥已经存储在实际SP中的信心?

密钥认证过程使用另一个私钥(通常是在制造过程中安装的私钥)来形成证明。该证明采用结构化数据的形式，其中包含您生成的公钥和密钥的属性，包括是否需要生物特征因子来访问此密钥以及围绕其使用的其他策略。当这些数据以及硬件唯一密钥的有效性证明，加上设备的详细安全策略一起考虑时，您就有了决定是否信任密钥存储在具有指定策略的安全硬件中的所需信息。让我们回顾一下表示该认证的机制。

身份秘密和证书。任何身份验证器都需要一个公钥来执行某种类型的验证。该密钥可以自由共享，不像设备SP中作为秘密持有的私钥。一些平台，如苹果的SEP，允许用户在NIST P-256椭圆曲线上生成密钥对。相反，Android的硬件支持的密钥存储库实现了RSA (Rivest-Shamir-Adleman)方案。²

公钥本身是模糊的，很难了解任何信息;公钥只包含一个大整数(或一对整数，在椭圆曲线加密的一般情况下)，没有其他唯一的元数据。要显示密钥的目的并显示作为创建密钥的一部分所执行的任何策略检查，必须有一个容器来携带关于密钥的元数据，以及包装该容器的签名，以允许接收方验证此信息的真实性。

这种验证最常见的形式是X.509证书，它是一个ASN.1(抽象语法符号1)DER(区分编码规则)编码的对象，包含许多字段，包括:

• 当证书变得可以使用时。
• 证书不再有效时。
• 谁验证了持有证书私钥方的真实性。
• 公钥本身。
• 来自验证密钥属性并创建证书的受信任机构的签名，显示证书内容的真实性。

通常X.509证书与一组权威证书组合在一起，这些证书表示谁对证书的内容进行了身份验证。这个完整的权威证书集，连同被验证的最终实体，形成一个证书链．

密钥认证过程依赖SP执行一系列步骤，以生成一个X.509证书链，该证书链将设备的来源显示回某个权威机构。iPhone与苹果运行的权威绑定，而对于Android，这个权威是谷歌。图4显示了一个示例密钥认证X.509证书链。

图4。密钥认证X.509证书链示例。

当然，X.509证书无处不在。密钥认证只是一种有限的用途。X.509证书链可用于唯一地标识服务或用户，这通常用于web应用程序。为用户颁发的X.509证书将与存储在硬件中的私钥连接在一起。在验证密钥保存在安全硬件中并且该密钥的策略符合预期之后，您就可以为刚刚验证的密钥向用户颁发自己的X.509证书。这意味着您不需要每次验证用户时都验证密钥认证;它还允许信任您作为身份提供者的其他方验证您的用户身份。

生物因素。大多数智能手机都包含生物识别因素:如今的最低配置是指纹传感器。面部识别在高端设备中越来越多地出现，但在大多数人都戴着口罩的新冠肺炎(COVID-19)时代，面部识别的便利性降低了。事实上，为了保证安全，苹果让密码解锁更容易执行。⁴

手机必须个性化，生物特征因子才能被应用程序使用。这意味着用户必须通过系统机制注册至少一个生物特征因子。应用程序开发者必须做出一个关键的假设，即对手机进行个性化设置的用户是手机的所有者或授权用户。

对于许多用例来说，生物特征因素的存在是为了方便。当用户每次想要解锁设备时，无需输入冗长的密码，用户只需出示一个生物特征因子来证明自己是谁。大多数设备要求用户至少每7天提供一次密码，以及在重新启动或其他系统事件之后。减少输入长密码的频率意味着用户更有可能选择长而复杂的密码，从而提高了设备的整体安全性。

iOS和Android都可以设置一个标志，这样一个密钥只有在用户成功执行生物特征认证的情况下才能被使用——提供了额外的信任级别，并强制证明拥有生物特征因子。(马来西亚发生的一起事件显示了偷车贼为了偷一个生物识别因子来解锁一辆奔驰s级车愿意走多极端。⁸现在大多数指纹传感器都有某种形式的活体检测，以阻止这种可怕的攻击。)

生物识别认证可以确保一个人不会在多个用户之间共享密码，或者在解锁手机时不会让人摸到肩膀上的密码。要求用户在执行加密操作之前证明自己的身份，可以在一定程度上保证他们至少在设备现场并被授权使用设备。SP执行整个生物特征认证过程，确保涉及生物特征模板的任何操作都发生在安全的环境中，并且篡改模板是不现实的。

大多数实现在SP和生物特征传感器之间有一个安全通道。这使得盗取生物特征因子并在之后重放它变得非常困难。将测量的生物特征值包装在一个安全的、经过身份验证的通道中会导致重放攻击，在重放攻击中传感器和SP之间的通信被捕获，这是不切实际的。这为传感器的物理存在提供了更强的保证。

要寻找为什么这个安全通道很重要的证据，你不需要寻找太远。2018年，Technische Universität Berlin的研究人员演示了一种攻击，他们从物理卡片上恢复了潜在的指纹图像，然后移除指纹传感器，并构建了一个设备来模拟指纹传感器将图像传输到主机CPU。7由于没有安全功能来验证指纹传感器和CPU本身之间的通信，攻击者能够在原始手指不存在的情况下解锁卡片。这个失败说明了为什么在传感器和SP之间存在一个安全通道非常重要，包括验证两者之间所有通信的能力。

最后，还需要一个政策决定:如果用户在手机上添加了新的生物识别登记，您还会继续信任您生成的身份吗?这可能表明该设备存在某种缺陷。这也可能表明用户在生物识别方面遇到了问题，并试图重新注册，或者可能是用户的子女添加了自己的注册，以便更容易地购买游戏内货币。这是需要考虑的安全性和可用性权衡。Android和iOS都启用了一个策略，如果添加了任何生物度量因子，该策略将删除密钥。

信任是一种商业决策。当制造商在生产线上向智能手机注入加密身份时，它已经做出了一个断言:该手机是在一个受信任的环境中生产的，符合指定的标准。在这一点上，企业需要做出决定:他们是否相信这个标准足以满足他们的威胁模型?

他们正在决定是否相信谷歌和苹果对其生产流程的评估。验证设备的真实性是当今开发人员面临的主要挑战之一，但对他们来说，完成注册过程并决定是否信任设备以保持正常使用的秘密是至关重要的。

对于现代Android手机，谷歌提供了这种断言。按照谷歌设定的要求构建的每个Android手机将收到一个X.509证书链，该证书链是为设备上的安全硬件持有的私钥生成的。该链的最终实体是专门针对该设备的证书。因此，可以为外部方提供这个证书链，以便他们可以验证特定智能手机的真实性和可信性。

这个过程也是一种认证——验证特定手机的真实性和唯一性。值得注意的是，谷歌生成一个在多达10,000个设备之间共享的认证密钥，这使得直接跟踪用户非常困难(稍后将详细介绍这一点)。

通过扩展，生成另一个密钥和从属于设备身份证书的相关证书将生成密钥认证证书。如果SP中的软件和硬件的完整性没有受到损害，那么使用安全硬件中保存的秘密密钥签署这个密钥认证证书可以支持证书中保存的所有数据都是真实和有效的声明。这成为了一种经过验证的、防篡改的方式，可以将关于SP看到的世界状态的数据传输到外部世界。除非盗取设备身份的私钥，否则攻击者很难伪造这些密钥认证证书。

这不是万灵药．如前所述，软件漏洞可能允许攻击者提取密钥，并利用它们创建看似有效但却是伪造的证书链。硬件bug可能会将SP的敏感数据暴露给AP或外部攻击者。同样，您必须做出一个业务决策:这个软件和硬件是否设计得足够好，可以信任您的服务的敏感访问凭证?您是否信任谷歌作为权威机构来评估手机是否足够安全，可以存储用于识别您的用户的敏感机密?谷歌是否安全地存储认证密钥，以确保它们不会被窃取?另一个需要考虑的风险是:手机制造商是否篡改了运行在SP中的软件?这将完全破坏信任模式。

密钥认证还有另一个好处:通过证明密钥存储在安全硬件中，您还可以在一定程度上保证攻击者不是简单地模拟受信任的硬件。只要没有一方能够从手机中提取设备认证密钥，这个断言就成立。有足够复杂的恶意软件来模拟加密api并不是闻所未闻的事，而能够窃取应用程序生成的所有密钥的攻击者将允许该攻击者破坏任何类型的信任模型。由于秘密保存在安全的硬件中，即使是应用程序的修改版本也无法窃取这些秘密，从而进一步保护了用户。

不幸的是，虽然苹果在其Secure Enclave中实现了这些功能，但利用这种认证的能力还没有广泛地向第三方应用程序开发者开放。这意味着，在iPhone上注册任何身份的过程中，你都需要在信心上迈出一步，因为验证你的密钥实际上存储在安全硬件中是不可能的。iOS 14开发者版本引入了应用认证，但在撰写本文时，开发者还没有启用该功能。新的API也没有公开控制是否需要生物特征因素才能解锁密钥的方法，这限制了它对许多身份管理应用程序的有用性。

谷歌从Android 7开始就向应用程序公开了这些功能，尽管通常Android 8或更高版本的设备实现了所有所需的功能。由于苹果还没有透露它最终将如何向第三方应用程序公开关键认证和生物识别功能，让我们来探索如何使用Android的功能进行关键认证和建立身份。

回到顶部

建立身份:Android风格

在谷歌Android设备上，硬件管理的标识是使用硬件支持的密钥存储库创建的，通常在TEE (SP的Android实现)中运行。应用程序可以为要使用的密钥对指定许多特征:

• 要使用的非对称加密方案(RSA、EC等)和密钥的大小。
• 用户是否需要PIN码、生物特征因子或其他要求才能生成密钥。
• 无论用户是否需要提供生物特征，或者是否刚刚解锁手机(或根本没有做任何事情)才能使用密钥。
• 密钥的目的或用途(是否应该用于签名、加密等)。
• 验证挑战，一次使用过的数字(现时标志)，它是为您的后端应用程序的这次注册尝试专门生成的，以避免重放攻击。这必须不在注册尝试之间共享，并且必须是密码随机字符串。

生成密钥后，应用程序可以请求对密钥进行认证。这将返回具有以下成员的X.509证书链:

• 密钥认证证书，该链的最终实体证书，包含刚刚生成的密钥、认证挑战nonce以及与该密钥关联的策略。这是用设备认证密钥签名的。只有当设备具有硬件密钥存储库时，才会向设备颁发这种类型的证书。
• 一种中间证书，表示并证明设备认证密钥。这与私钥一起与9,999个其他设备共享。
• 另一个与批处理相关的中间体，用于颁发设备认证密钥证书。
• 谷歌硬件认证根认证，代表Android设备身份的根。这是谷歌保管的，希望在一个非常安全的地方。

然后将这些证书传递给后端服务进行验证，并验证策略和元数据是否符合预期。安全硬件是设备认证密钥驻留的唯一地方;这是生成最终实体证书(密钥认证证书)的唯一方法。如果证书链植根于谷歌硬件认证根，则密钥存储在谷歌认为是安全的硬件中。

关于如何为Android执行关键认证的建议和示例代码可以在Android开发者网站上找到。¹

那其他9,999部持有相同证书的手机呢?从安全的角度来看，在10,000个设备之间共享相同的密钥认证证书显然会适得其反。这意味着来自该组中的任何手机的认证都是不可区分的。你如何保证一个身份是唯一的?几个缓和因素降低了风险。

首先，SP用来包装安全材料的密钥对每一部手机都是唯一的。因此，即使您发现两个具有相同密钥认证证书的手机，也不能将一个设备生成的密钥与另一个设备交换。这满足了身份密钥必须难以提取或克隆的要求。密钥认证证书只能保证硬件支持的密钥存储库保存着您的密钥——它不打算单独用作标识。如前所述，在验证认证是准确的之后，您可能希望为安全硬件中保存的密钥生成自己的X.509证书。

其次，在注册过程中，每个认证都应该与其他一些身份验证操作相关联。例如，当用户第一次登录您的应用程序时，您的应用程序将生成一个独特的挑战。这个挑战的有效时间是有限的——很可能是几十秒的量级。这意味着使用相同的密钥认证证书重放来自另一个设备的密钥认证将是困难的;这一挑战将限制这种认证的有效期。当然，一旦用户成功地向您的服务进行了身份验证，该挑战立即失效，因此即使知道了这个挑战，攻击者也很难在用户不知道发生了什么情况的情况下利用该属性。

---

验证设备的真实性是当今开发人员面临的主要挑战之一，但对他们来说，完成注册过程并决定是否信任设备以保证其正常使用是至关重要的。

---

通过在初始注册阶段的这种谨慎程度，在设备之间共享密钥认证证书应该不会对您的服务构成重大威胁。

回到顶部

重新审视同一性模型

让我们重新审视标识模型，并填充一些关于实现可能如何工作的细节。

首先，有一个核心假设，即用户通过注册指纹、面部识别或其他生物识别因素来个性化他或她的手机。个性化是任何生物特征因子可用的先决条件。

一旦用户完成了个性化过程，您需要在用户的安全硬件中生成应用程序的惟一标识。通常，这是在用户第一次对您的服务进行身份验证时完成的，可能会使用另一个因素。让我们在前面描述的生命周期中回顾一下:

1. 招生．在以其他方式对用户进行身份验证(例如，用户名、密码、一次性密码、屏幕上的二维码挑战)之后，您可以生成一个惟一的非对称密钥对，该密钥对将用于将来对用户进行身份验证。私钥由SP存储，应用程序开发人员需要指定密钥的参数，用户解锁该密钥需要什么，等等。
2. 认证和交付．验证密钥周围的参数(使用策略、密钥长度等)是否满足您的需求，并对服务后端执行最后检查。这是一组全面的检查，为后端应用程序提供了一些保证:密钥保存在哪里;在程序使用密钥之前，用户必须做什么(例如，提供生物特征证明);当手机的参数(如指纹或面部识别模板)发生变化(例如，使密钥失效)时，SP应该做什么;以及什么类型的生物特征参数可以用来解锁使用的钥匙。如果认证检查符合预期，则可以向用户发出身份证书链，并将其存储在设备上以备将来使用。
3. 使用．然后可以根据注册期间定义的策略使用标识，并在认证期间进行验证。这可以与客户端证书一起使用，在连接到后端服务时验证身份(用于TLS会话的相互身份验证)，或者用于签署带外提供的加密挑战。
4. 失效．有些事件可能会使用户的身份失效——例如，更改用户的PIN码、添加生物特征模板或对影响手机安全性的策略进行其他更改。这些变化意味着无法保证最初生成身份的人仍然拥有手机。用户必须重新注册才能摆脱这种状态。回到步骤1。

回到顶部

如何使用数码身份

一旦完成了建立标识的艰苦工作，下一步就是使用该标识。许多用例可能可以直接使用受信任硬件中保存的秘密，作为通过mTLS(相互传输层安全)身份验证对服务进行身份验证的一部分。mTLS的好处是显著的:要求与后端服务的任何通信都使用这个秘密进行身份验证，这意味着没有有效的、经过验证的身份密钥对的设备甚至无法进行连接。当然，这与证书颁发和管理相关的许多其他挑战超出了本文的范围。

此证书是对生成的身份的有效性的认证，由您作为服务提供者提供。当然，这是在手机制造商为此目的对密钥的有效性进行认证之后完成的。这个过程涉及到许多受信任的权威。

在本例中，您颁发X.509证书，通过您自己运行的PKI(公钥基础设施)对用户进行身份验证。证书的私钥只保存在电话的安全硬件中，只能在安全硬件中操作。这意味着您可以一定程度上保证连接到您服务的用户是他们所说的那个人(只要SP的完整性没有受到损害)。

另外，定制协议也是一种选择。一个简单的挑战-响应协议(其中SP负责签署非签名协议)可以工作，特别是对于已经实现了otp(一次性密码)的遗留环境。当然，在实现任何加密协议时通常要注意的一点是:这里是龙。构建这样的协议所面临的挑战和风险太多了，本文无法涵盖，但是如果您没有意识到它可能出现的错误，那么就不应该考虑这种方法。

回到顶部

隐私的挑战

任何一种与硬件绑定的唯一标识符，用户隐私的问题都是不可避免的。一些供应商不希望制造让广告商、黑客或民族国家对手更容易追踪用户的设备。加密身份的优点是它们很难伪造——但这是两面性的，隐私倡导者有理由担心这些身份可能被滥用来识别用户的行为模式。

供应商是一个威胁。记住，整个安全系统都建立在信任电话供应商的基础上。您假定供应商是善意的，不会泄露密钥存储和使用模型，这样恶意用户就可以违反您的安全假设。苹果和谷歌都对如何处理这个信任模型做出了不同的决定，而且两种模型都有权衡。主要的差异出现在关键认证过程中，这对注册阶段至关重要。

谷歌选择在设备上进行验证。这意味着谷歌看不到您正在验证什么，或者您正在执行一个关键的认证—所有的秘密和认证证书生成都是由电话上的TEE执行的。然而，这也意味着，认证密钥可能被恶意应用程序滥用来跟踪用户，因此这种方法有隐私问题。在10,000个其他设备上重用此密钥确实会增加仅根据认证密钥跟踪单个用户的难度。当然，这样做的价值是有限的，因为有关设备的其他因素可以用来进一步消除你是谁的歧义。

相反，苹果拥有中央认证权。最简单的方法是让苹果通过要求其中央授权机构生成证书来验证SEP中的每个密钥。Secure Enclave加密一团数据，其中包含关于密钥属性、公钥本身、请求认证的应用程序和手机的唯一标识符的信息。然后，这个加密的blob被交给苹果的认证权威服务，该服务查找设备、制造细节、是否被标记为被盗(通过“查找我的iPhone”)，以及类似的设备姿态检查。如果一切正常，服务将返回有关密钥的X.509证书链。

这样做的好处是，认证的中间授权与苹果绑定，而不是与存储在手机中的秘密绑定，这对用户隐私来说是一个巨大的好处。这意味着你信任苹果对手机的认证，你知道手机是真的——但你不知道这到底是哪部手机。你不知道不同应用程序的任何认证是否来自同一台设备，这是一个巨大的隐私好处。这种天真的方法可以为苹果提供大量关于用户如何使用iPhone和使用什么应用程序的细粒度信息(超出了App Store的遥测范围)。掌握这些信息是一个巨大的责任。

iOS关键认证的细节还有待探索，因为苹果刚刚宣布将在iOS 14中发布一个功能子集。这对许多用户身份用例没有帮助，因为在使用应用程序认证密钥之前不需要生物特征因子验证。⁵

回到顶部

为用户着想!

你在应用中添加的任何身份管理或安全功能都必须考虑用户体验。虽然生物识别认证等因素让用户的生活更容易，但糟糕的应用策略可能导致令人失望的用户体验。所有这一切的重要部分是做出几次判断——包括你的应用程序是否需要一个生物特征因子来达到它所期望的用户身份证明水平。

一个常见的错误是认为用户每次执行操作都需要身份证明。每次使用密钥时都要求进行生物特征验证将对TLS连接产生副作用，因为用户将不断地多次证明身份。当应用程序处于后台，网络活动超时时，这可能会很尴尬。在这种情况下，最好是在较长一段时间内解锁钥匙，比如用户可能会使用应用程序的会话持续时间。

注册是一件棘手的事情，需要定义良好的用户流，特别是一旦生物特征认证被集成到你的应用程序的用户登录过程中。用户必须确切地知道他们在每个阶段在做什么，特别是如果注册用户涉及带外挑战/响应协议，如网页上的二维码包含了应用程序证明用户在其他地方登录的挑战。确保功能和设备状态检测得到很好的实现，并迅速失败，这样用户就不会陷入一个过程中，出现令人困惑的失败。你需要检查的一些常见状态包括:

• 如果您正在使用这些功能，是否启用了生物特征验证，是否有允许用户进行身份验证的注册计划?这里有生物识别传感器吗?
• 如果您依赖手机中的安全硬件，您是否检查过硬件是否存在、启用并能够提供所需的功能?
• 您能连接到执行注册过程的服务吗?

另一个考虑事项是检查注册是否成功。在注册时进行预演以确保用户知道如何使用生物识别功能总是很有帮助的。

永远不要吓唬你的用户。失败和错误消息应该诚实、简洁而友好。诸如“您的设备不够安全”之类的信息既不准确也不恰当。模糊的信息可能会吓到用户并误导用户。太过技术性的消息会训练用户忽略错误消息，这在将来可能会更糟糕。以以用户为中心的方式解释特定故障的消息是至关重要的，这样用户就可以进行自助，或者知道向谁寻求支持。

请记住，对于生成短期证书的密钥，需要生物测定因子将要求用户提供生物测定因子，仅用于签署证书签名请求。这可能会对证书更新期间的用户体验产生影响，因为每次用户更新证书时，他们都必须提交该因素。发布一个长期存在的证书然后洗手可能很诱人——这未必是错误的做法，但它可能不符合您的安全模型。

在将标识集成到系统中时，请确保仔细考虑这些权衡。对于用户希望每天与之交互的应用程序来说，更长的身份证书可能是有意义的。如果应用程序不经常使用，那么短期授权可能是首选，而认证只需要在这些罕见的交互过程中进行。

回到顶部

这给我们带来了什么?

在创建一个可用的、持久的和安全的用户标识时，没有简单的答案。移动电话提供了一个令人信服的选择，特别是在正确的功能和功能可用的情况下，但这些在今天的主要智能手机平台上并不一致。在构建这些系统时，你总是必须做出取舍，从用户体验挑战到平台本身的局限性。

在构建这样一个系统时，您将发现真正的问题在于细节:您的服务在验证认证证书链时是否正确?随着手机技术的变化(想想苹果从Touch ID向Face ID的转变)，你如何调整你的政策?如何处理各种类型的部分畸形的认证证书?你想信任苹果和谷歌的皇冠宝石——用户如何访问和认证你的服务?如果你想利用智能手机作为身份识别设备，你还有别的选择吗?

用这样的方案窃取用户的凭证现在很困难。如果需要生物特征认证，恶意使用凭证就更加困难。要使用代表用户的键，用户必须得到提示—这有多方便?

不幸的是，除非苹果将这些功能作为iOS的一部分，并在其App Store中为应用提供这些功能，否则我们距离普及强大的、硬件支持的身份标识还有很长的路要走。另一方面，谷歌已经提供该功能好几年了，允许应用程序利用认证功能。

相关文章
在queue.acm.org

为雇佣黑客
阿Mirian
https://queue.acm.org/detail.cfm?id=3365458

RFID护照的威胁分析
艾伦·拉莫斯等人．
https://queue.acm.org/detail.cfm?id=1626175

反思的密码
威廉Cheswick
https://queue.acm.org/detail.cfm?id=2422416

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2021 ACM, Inc.

---

没有发现记录