PDF人人都拥有的身份标识
通过智能手机保障用户安全
Phil Vachon
几乎每位技术从业者都拥有一部智能手机。在全球范围内，蜂窝网络的普及程度甚至超过了清洁的自来水。借助智能手机，用户可以进行银行业务、与当地政府互动、购买日常必需品，或者仅仅与全球各地的亲人保持联系。
正是这种普遍性带来了有趣的安全挑战和机遇。甚至在 10 年前，像生物特征认证这样的概念还是一种新奇事物，仅限于政府和金融服务行业的专业应用。今天，你很难找到没有体验过用指纹或最近只需看着屏幕就能解锁手机的用户。但其背后蕴含的内容远比（摄像头）看到的要多：在华丽的用户界面之下，存在着安全处理器、硬件支持的密钥存储和用户身份管理的世界，这些共同驱动着这种看似简单的功能。
较新的手机以多种不同的方式和组合使用这些安全功能。然而，与任何安全技术一样，不正确地使用某项功能可能会产生虚假的安全感。因此，如今许多应用程序开发者和服务提供商并没有使用现代手机提供的任何安全身份管理工具。对于你们中属于这一阵营的人来说，本文旨在为你们提供关于如何将硬件支持和基于生物特征的用户身份概念引入你们的生态系统的想法。
目标很简单：尽可能让攻击者难以窃取凭据并在他们方便时使用。甚至要让用户难以克隆自己的凭据以与其他用户共享。除了这种保护之外，我们还要确保添加额外的因素（例如生物特征认证）能够更强有力地保证用户的身份。将密钥和其他机密信息越来越靠近物理连接到用户的东西，可以更强有力地保证刚刚通过设备身份验证的用户的身份。
什么是数字身份？
在物理世界中，证明你的身份可能需要检查身份证明文件，例如护照、签证或驾驶执照，并将照片或其他生物特征与该文件上印刷的内容进行匹配。伪造这些文件的价值非常高，因此国家和其它身份签发机构会竭尽全力使其难以伪造。与此同时，他们必须让验证者能够轻松地发现即使是最精密的伪造品。在设计安全文档（例如，https://www.jura.hu）、开发防伪技术（https://www.muehlbauer.de）以及大规模生产这些文档的背后，存在着一个完整的产业。当然，这些努力并非万无一失，有时最敏感的用例需要更仔细地检查身份证明文件，使用嵌入在文档本身中的“秘密”安全功能。
在技术领域，身份是通过某种加密方案来证明的，身份本身体现在用户持有的密钥中。然而，仅仅拥有这个密钥通常是不够的：就像没有照片来识别持有者的实体身份证明文件一样，一些加密密钥可能会被盗，并被任何人使用。对于大多数用例，围绕密钥存储方式的策略变得至关重要。存储在笔记本电脑硬盘上的私钥可能不如存储在智能卡中的私钥那样值得信赖。
例如，考虑一下经典的邪恶女仆攻击，其中攻击者利用对物理空间（例如私人住宅）的特权访问权限来更改、窃取或简单地以所有者无法检测到的方式使用设备或凭据。私钥的存储位置可能至关重要。虽然邪恶女仆可能能够简单地复制存储在笔记本电脑磁盘上的私钥，但他或她却无法轻易地在智能卡上做到这一点，因为智能卡很难克隆并且难以从中提取材料。邪恶女仆无法在您没有注意到的情况下带走智能卡，并且在短时间内克隆卡在大多数现代实现中是一项艰巨的任务。而且，将智能卡随时放在身上也更容易，从而使其远离邪恶女仆的魔爪。
移动电话作为安全密钥库
多年的开发、惨痛的安全工程经验和实践经验促成了大多数现代智能手机中广泛的安全功能。在讨论将移动电话用作身份管理设备之前，让我们先从高层次定义一下这个设备的外观。
图 1 显示了理想化的智能手机。请注意 AP（应用处理器）和 SP（安全处理器）之间的划分，以及它们如何控制手机的不同方面。
智能手机的组成部分相当简单
• 显示屏。
• 生物特征传感器（面部识别、指纹识别）。
• “安全”处理环境，或 SP。（GlobalPlatform 更喜欢使用术语可信执行环境，或 TEE。从架构上讲，这些概念相似，但使用 SP 避免了与通常用于指代 Android 特定实现的术语混淆）。SP 是专门的安全软件运行的地方，例如 Apple 的 SEPOS（安全 Enclave 处理器操作系统）或 Qualcomm 的 QTEE；与 SP 环境关联的所有包含内存的程序代码和数据都受到保护，以至于即使是同一芯片上的其他 CPU 也无法访问 SP 数据（稍后会详细介绍）。
• 安全存储环境，用于存储 SP 的机密信息和其他敏感信息。
• “应用”处理环境，或 AP，应用程序和手机的操作系统（例如 iOS 或 Android）在此环境中运行。AP 只能通过有限的通道与 SP 通信。
这里做出的一个假设是设备通常由用户持有。此外，还假设 PIN 等附加保护措施足以保护设备免受攻击者的侵害。虽然思考拥有无限资源的国家可能发动的攻击很有趣，但按照如此高的标准进行设计并不总是实际的。
借助此智能手机模型，您可以开始推理如何构建安全系统。将 SP 和 AP 视为一部手机上的两个独立世界。对于 iPhone，Apple 引入了 SEP。大多数 Android 手机要么有一个完全独立的芯片（即 Pixel 3 及更高版本中的 Google Titan M 芯片），要么使用 TrustZone9（ARM 专有的应用处理器 CPU 安全虚拟化状态）将 SP 实现为 TEE。
SP 具有专用的安全内存区域，该区域已加密且通常经过身份验证。3,6 这种加密还可以保护安全内存免受物理持有手机的攻击者的侵害，并防止 AP 更改或恢复 SP 的状态。在无法访问用于加密内存的密钥的情况下，任何人都会很难恢复原始内存内容。这是对现代 SoC（片上系统）的硬件强制控制，例如 Apple 或 Qualcomm 的 SoC。任何违反此控制的行为都将是灾难性的，从而使 AP 可以自由访问 SP 内存中的任何敏感数据。（SP 软件中的漏洞将允许攻击者以类似于安全硬件尝试阻止的方式访问 SP 的内存。如果这给您的应用程序带来了过大的风险，您可能需要考虑其他硬件安全令牌，例如 YubiKeys，甚至构建自己的令牌。）
SP 还可以访问其自己的一组外围设备（例如指纹传感器或用于支付处理或安全数据存储的安全外部设备），AP 无法访问这些外围设备。SoC 的某些功能（例如，赋予智能手机唯一身份的加密密钥）也只能由 SP 专用的硬件访问。用于加密安全处理器所有长期存储的密钥通常使用此类机制进行存储。
SP 的持久存储包括许多重要的数据，包括应用程序生成的密钥、代表授权用户的生物特征模板以及唯一标识手机的密钥。在大多数实现中，这些数据位都使用长期存储密钥进行加密包装，从而使它们只能由在 SP 中运行的软件访问。然后，将持久数据交还给 AP，以便长期存储在闪存中。这种包装过程可以确保此信息的安全，并确保在 AP 上运行的任何应用程序都无法假装自己是 SP。更重要的是，包装可以防止恶意方从手机中提取机密信息并克隆它们（或更糟糕的是，巧妙地破坏这些机密信息）。
与 AP 相比，SP 运行的是极其简单、最小化的操作系统。通常，第三方应用程序无法安装在此环境中，并且运行的代码是专门构建的？仅用于设备所需的安全应用程序。这是为了最大限度地减少暴露的攻击面，并降低软件漏洞损害 SP 完整性的可能性。如您所知，软件，即使在 SP 中，也永远不是真正完美的。10
SP 和 AP 之间的所有通信都受到高度规范。根据设计，AP 无法访问 SP 的内存，但 SP 可能能够看到 AP 的一些内存。两个世界之间的所有通信都通过 RPC（远程过程调用）进行，序列化要从不安全的世界传递到安全世界（或反之亦然）的所有参数和数据。
使用此 RPC 机制定义的操作通常级别很高。例如：“生成密钥对”使用命令中指定的参数生成新的密钥对；然后，它返回公钥和密钥 ID 作为响应，“使用密钥对签名 blob”，它接受密钥 ID 和指向数据 blob 的指针，然后返回签名作为响应。这些操作不灵活，但这是设计使然：灵活性会引入更多可能出错的方式。
图 2 显示了 SP 和 AP 之间的逻辑划分。请注意 SP 如何拥有自己的私有加密硬件，以及该硬件是访问制造过程中生成的密钥材料的唯一途径。这可以保护密钥免受软件泄露。大多数 SP 没有足够的闪存来存储所有需要的密钥，而是将其数据（使用只有 SP 才能访问的密钥加密）传递给 AP 以进行长期存储。安全内存保护可防止 AP 能够“看到”SP 内存空间中发生的情况，但允许 SP 读取和写入 AP 的内存空间。
图 3 显示了 SP 生成和持有的任何密钥的使用顺序。请注意 AP 如何只能通过特定的 RPC 请求使用密钥，而永远无法访问私钥本身。
一个重要的经验是，在 AP 和 SP 上运行的硬件和软件之间正在进行精心编排的舞蹈，以实现现代手机的安全功能。一个错误，整个安全模型都可能受到损害。
需要考虑的最后一个难题是手机身份的来源。建立信任需要一些证据来证明手机是按照预期的安全标准制造的。可追溯到安全制造过程需要设备在制造过程中被编程写入加密密钥，该密钥可以追溯到制造商。使用此制造密钥签名的身份证明，结合对持有密钥的设备的物理安全知识以及围绕如何以及在何处使用您生成的密钥的软件策略，使您可以决定在设备上生成的身份的真实可信度。
基本身份模型
到目前为止，应该清楚的是，大多数最新的手机都具备创建数字身份所需的所有组件。开发人员如何使用这些组件来构建身份，使其能够对在手机上运行的应用程序的用户进行身份验证，以访问在云端或某些本地基础设施中运行的服务？
您生成的任何身份都具有通用的生命周期，以支持对应用程序的用户进行身份验证。基本步骤（无论是对于智能手机、独立的生物特征令牌还是其他设备）是
1. 注册。这启动了生成所需密钥的过程。
2. 证明和交付。这验证密钥是否安全、安全存储且难以提取和克隆。如果成功，您可以将某种形式的身份交付到设备以供将来使用。
3. 使用。密钥被使用，可能是用于相互 TLS（传输层安全）身份验证或某些其他带外身份验证协议。
4. 失效。当用户或手机的某些方面以某种方式发生变化时，应擦除用户身份密钥，迫使用户重新注册。
当我们研究使这种身份模型工作的各种技术时，我们将扩展每个步骤对您的应用程序意味着什么。
密钥对
在实际应用中，加密身份使用非对称密钥对表示。虽然非对称加密的细节远远超出了本文的范围，但作者推荐 Jeffrey Hoffstein、Jill Pipher 和 J.H. Silverman 合著的数学密码学导论（Springer 2008），以深入了解加密方案的工作原理；Niels Ferguson 和 Bruce Schneier 合著的实用密码学（Wiley，2003）也是一本很棒的参考书，尽管有点过时。
无需深入细节，非对称密钥可以说由两部分组成：必须保密的私钥（可用于生成加密证明，以数字签名的形式）和公钥（可供另一方用于验证这些签名）。私钥必须在最受控制的环境下使用？使用最受保护的硬件，确保没有人可以捕获私钥。在图 1 的智能手机模型中，这意味着使用私钥执行的所有操作都在 SP 的环境中完成。
密钥和证明
在没有办法验证这些属性的情况下，很难考虑私钥的可信度和存储策略。您如何才能确信您生成的密钥已存储在实际的 SP 中？
密钥证明过程使用另一个私钥（通常是在制造过程中安装的私钥）来形成证明。此证明采用结构化数据的形式，其中包含您生成的公钥以及密钥的属性，包括是否需要生物特征因素才能访问此密钥以及围绕其使用的其他策略。当此数据连同硬件唯一的密钥有效性证明以及设备的详细安全策略一起考虑时，您就拥有了决定是否信任密钥是否以指定的策略存储在安全硬件中所需的一切。让我们回顾一下表达此证明的机制。
身份机密信息和证书
任何身份验证者都需要一个公钥来执行某种形式的验证。该密钥可以自由共享，这与作为机密信息保存在设备 SP 中的私钥不同。某些平台（例如 Apple 的 SEP）允许用户在 NIST P-256 椭圆曲线上生成密钥对。相反，Android 的硬件支持的密钥库实现了 RSA（Rivest-Shamir-Adleman）方案。2
公钥本身是含糊不清的，很难了解任何信息；公钥的全部内容只是一个大的整数（或一对整数，在椭圆曲线密码学的一般情况下），没有其他唯一的元数据。为了显示密钥的用途并显示作为创建密钥一部分完成的任何策略检查，必须有一个容器来携带有关密钥的元数据，以及一个包装此容器的签名，以允许接收者验证此信息的真实性。
这种验证最常见的形式是 X.509 证书，它是 ASN.1（抽象语法表示法一）DER（可分辨编码规则）编码的对象，其中包含许多字段，包括
• 证书何时开始有效使用。
• 证书何时不再有效。
• 谁验证了持有证书私钥方的真实性。
• 公钥本身。
• 来自可信机构的签名，该机构验证了密钥的属性并创建了证书，显示了证书内容的真实性。
通常，X.509 证书与一组代表谁验证证书内容的可信机构证书分组在一起。这组完整的可信机构证书以及正在验证的最终实体构成了证书链。
密钥证明过程依赖于 SP 执行一系列步骤，从而生成一个 X.509 证书链，该链显示了设备到某个机构的出处。iPhone 绑定到由 Apple 运行的机构，而对于 Android，此机构是 Google。图 4 显示了示例密钥证明 X.509 证书链。
当然，X.509 证书随处可见。密钥证明只是一个有限的用途。X.509 证书链可以用于唯一地标识服务或用户，这在 Web 应用程序中经常这样做。为用户颁发的 X.509 证书将与存储在硬件中的私钥结合使用。在验证密钥是否保存在安全硬件中以及该密钥的策略是否符合预期后，您将为您刚刚证明的密钥向用户颁发您自己的 X.509 证书。这意味着您无需在每次想要验证用户身份时都验证密钥证明；它还允许信任您作为身份提供商的其他方验证您用户的身份。
生物特征因素
大多数智能手机都包含生物特征因素：现在最起码的是指纹传感器。面部识别越来越多地出现在高端设备中，但在 COVID-19 时代，大多数人都戴着口罩，面部识别的便利性有所降低。事实上，为了保持安全保证，Apple 使密码解锁更容易执行。4
必须针对生物特征因素对手机进行个性化设置，才能供应用程序使用。这意味着用户必须通过系统的机制注册至少一个生物特征因素。应用程序开发人员必须做出关键假设，即对手机进行个性化设置的用户是手机的所有者或授权用户。
对于许多用例，生物特征因素的存在是为了方便。用户每次想要解锁设备时，无需键入长密码，只需出示生物特征因素即可证明自己的身份。大多数设备要求用户至少每七天提供一次密码，以及在重启或其他系统事件后提供密码。降低输入长密码的频率意味着用户更有可能选择长而复杂的密码，从而提高整体设备安全性。
iOS 和 Android 都允许设置一个标志，以便只有在用户成功执行生物特征认证后才能使用密钥？提供额外的信任级别并强制证明拥有生物特征因素。（马来西亚发生的一起事件表明，汽车盗窃犯为了窃取生物特征因素来解锁梅赛德斯 S 级轿车，不惜采取极端手段。8 今天的大多数指纹传感器都具有某种形式的活体检测功能，以阻止这种可怕的攻击。）
生物特征认证可以确保某人不会在多个用户之间共享密码，或者在解锁手机时没有被肩窥密码。要求用户在执行加密操作之前证明自己的身份，可以提供一定的保证，即他们至少在场并且被授权使用该设备。SP 执行整个生物特征认证过程，确保任何涉及生物特征模板的操作都在安全环境中进行，并且篡改模板是不切实际的。
大多数实现都在 SP 和生物特征传感器之间建立了安全通道。这使得窃取生物特征因素并在以后重放变得难以实现。将测量的生物特征值包装在安全、经过身份验证的通道中，使得重放攻击（即捕获传感器和 SP 之间的通信）变得不切实际。这提供了更强的保证，证明传感器确实物理存在。
对于为什么这个安全通道如此重要的证据，您无需远求。2018 年，柏林工业大学的研究人员演示了一种攻击，他们从实体卡中恢复了潜在的指纹图像，然后移除了指纹传感器，并构建了一个设备来模拟指纹传感器将该图像传输到主机 CPU。7 由于没有任何安全功能来验证指纹传感器和 CPU 本身之间的通信，攻击者能够在没有原始手指在场的情况下解锁卡。此失败表明，为什么在传感器和 SP 之间存在安全通道（包括验证两者之间所有通信的能力）非常重要。
最后，需要做出策略决定：如果用户在其手机上添加了新的生物特征注册，您是否继续信任您生成的身份？这可能表明设备受到了某种程度的损害。这也可能表明用户在生物特征因素方面遇到问题并尝试重新注册，或者可能用户的孩子添加了自己的注册，以便他们可以更轻松地购买游戏内货币。这是一个需要权衡的安全性和可用性问题。Android 和 iOS 都启用了一项策略，如果添加了任何生物特征因素，该策略将删除密钥。
信任是一项商业决策
当制造商在制造线上将加密身份注入智能手机时，它就做出了一项断言：这款手机是在受信任的环境中按照指定的标准制造的。此时，企业需要做出决定：他们是否相信此标准足以满足其威胁模型？
他们正在决定是否信任 Google 和 Apple 对其制造过程的评估。证明设备的真实性是当今开发人员面临的主要挑战之一，但这对于他们完成注册过程并决定是否信任设备保管正常使用的机密信息至关重要。
对于现代 Android 手机，Google 提供了此断言。每部按照 Google 设定的要求构建的 Android 手机都将收到一个 X.509 证书链，该链是为设备上安全硬件持有的私钥生成的。此链的最终实体是专门针对此设备的证书。因此，可以为外部方提供此证书链，以便他们可以验证特定智能手机的真实性和可信度。
此过程也是一种证明？证明特定手机的真实性和唯一性。值得注意的是，Google 生成了一个证明密钥，该密钥在多达 10,000 个设备之间共享，从而难以直接跟踪用户（稍后会详细介绍）。
通过扩展，生成另一个密钥和关联的证书（从属于设备身份证书）将生成密钥证明证书。使用安全硬件中持有的密钥对该密钥证明证书进行签名可以支持以下声明：证书中持有的所有数据都是真实有效的，前提是 SP 中软件和硬件的完整性没有受到损害。这成为将 SP 看到的世界状态数据以经过身份验证的、防篡改的方式传输到外部世界的一种方式。在不窃取设备身份私钥的情况下，攻击者将很难伪造这些密钥证明证书之一。
这不是万能药。 如前所述，软件错误可能允许攻击者提取机密密钥并使用它们来创建看似有效但伪造的证书链。硬件错误可能会将 SP 中的敏感数据暴露给 AP 或外部攻击者。同样，您必须做出商业决策：此软件和硬件的设计是否足够完善，可以信任您的服务的高度敏感访问凭据？您是否信任 Google 作为权威机构来评估手机是否足够安全以存储用于识别用户的敏感机密信息？Google 存储证明密钥是否足够安全以确保它们不会被盗？需要考虑的另一个风险是：手机制造商是否可能篡改了在 SP 中运行的软件？这将完全破坏信任模型。
密钥证明还有另一个好处：通过证明密钥存储在安全硬件中，您还可以确信攻击者不仅仅是在模拟受信任的硬件。只要没有任何一方能够从手机中提取设备证明密钥，此断言就将成立。具有足够复杂性来模拟加密 API 的恶意软件并非闻所未闻，并且能够窃取应用程序生成的所有密钥的攻击者将允许该攻击者颠覆任何形式的信任模型。由于机密信息保存在安全硬件中，即使是应用程序的修改版本也无法窃取这些机密信息，从而进一步保护您的用户。
不幸的是，虽然 Apple 在其安全 Enclave 中实现了这些功能，但利用此证明的能力尚未广泛向第三方应用程序开发人员公开。这意味着您需要在 iPhone 上任何类型身份的注册过程中采取信仰飞跃，因为无法验证您的密钥是否实际存储在安全硬件中。iOS 14 开发者版本引入了应用程序证明，但在撰写本文时，此功能尚未为开发人员实验启用。新的 API 也没有公开控制是否需要生物特征因素来解锁密钥的方法，这限制了其在许多身份管理应用程序中的实用性。
自 Android 7 以来，Google 已向应用程序公开了这些功能，尽管通常使用 Android 8 或更高版本出厂的设备实现了所有必需的功能。由于 Apple 尚未透露它最终将如何向第三方应用程序公开密钥证明和生物特征身份功能，因此让我们探讨如何使用 Android 的功能进行密钥证明和建立身份。
建立身份：Android 风格
在 Google Android 设备上，硬件管理的身份是使用硬件支持的密钥库创建的，该密钥库通常在 TEE（SP 的 Android 实现）中运行。应用程序可以为要使用的密钥对指定许多特性
• 要使用的非对称加密方案（RSA、EC 等）和密钥的大小。
• 用户是否需要具有 PIN 码、生物特征因素或其他要求才能完全生成密钥。
• 用户是否需要出示生物特征因素或只是最近解锁了手机（或根本没有做任何事情）才能使用密钥。
• 密钥的用途或用法（是用于签名、加密等）。
• 证明质询，一个专为此注册尝试生成的现时数（nonce），以避免重放攻击。这不得在注册尝试之间共享，并且必须是加密随机字符串。
密钥生成后，应用程序可以请求密钥的证明。这将返回一个 X.509 证书链，其中包含以下成员
• 密钥证明证书，此链的终端实体证书，包含刚刚生成的密钥、证明质询现时数以及与密钥关联的策略。这使用设备证明密钥签名。仅当设备具有硬件密钥库时，才会向设备颁发此类证书。
• 中间证书，代表和证明设备证明密钥。这与私钥一起与 9,999 个其他设备共享。
• 另一个中间证书，与用于颁发设备证明密钥证书的批次关联。
• Google 硬件证明根证书，代表 Android 设备身份的根。这由 Google 持有，希望是在非常安全的位置。
然后将这些证书传递到您的后端服务进行验证，并验证策略和元数据是否与预期匹配。安全硬件是设备证明密钥驻留的唯一位置；这是生成终端实体证书（密钥证明证书）的唯一方法。如果证书链以 Google 硬件证明根为根，则密钥存储在 Google 认为安全的硬件中。
有关如何为 Android 执行密钥证明的建议和示例代码，请访问 Android 开发者网站。1
具有相同证书的其他 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 中的每个密钥。安全隔离区加密包含有关密钥属性、公钥本身、请求证明的应用以及手机的唯一标识符的数据 blob。然后，将此加密的 blob 移交给苹果的证明机构服务，该服务查找设备、制造详细信息、是否已标记为被盗（通过“查找我的 iPhone”）以及类似的设备状态检查。如果一切正常，该服务将返回所讨论密钥的 X.509 证书链。
这样做的好处是，证明中间机构与苹果绑定，而不是与存储在手机中的密钥绑定，这对用户隐私来说是一个巨大的好处。这意味着您将信任根植于苹果对手机的身份验证，并且您知道手机是真实的？但您不确切知道这是哪部手机。您不知道来自不同应用的任何证明是否来自同一设备，这是一个巨大的隐私优势。这种简单的方法可能会让苹果获得大量关于您如何使用 iPhone 以及您正在使用哪些应用的细粒度信息（超出 App Store 遥测的范围）。持有这些信息是一项巨大的责任。
iOS 的密钥证明细节仍有待探索，因为苹果刚刚宣布在 iOS 14 中发布部分功能。这对于许多用户身份用例来说没有帮助，因为在用户使用应用证明密钥之前，无法要求生物识别因素验证。5
为用户着想！
您添加到应用中的任何身份管理或安全功能都必须考虑用户体验。虽然生物识别身份验证等因素使用户的生活更轻松，但为您的应用制定的计划不周的策略可能会导致令人失望的用户体验。所有这一切的重要部分是做出多项判断？包括您的应用是否需要生物识别因素才能达到其所需的证明用户身份的级别。
一个常见的错误是认为每次用户执行操作都需要身份证明。每次使用密钥时都要求进行生物识别验证会对 TLS 连接产生副作用，用户将不得不不断地证明身份，而且会多次重复。当应用在后台运行时及其网络活动超时时，这可能会变得很尴尬。在这些情况下，最好在更长的时间段内解锁密钥，例如用户可能使用该应用的会话持续时间。
注册很棘手？需要明确定义的用户流程，尤其是在将生物识别身份验证集成到用户应用的登录过程之后。用户必须确切地知道他们在每个阶段都在做什么，尤其是在注册用户时涉及到带外挑战/响应协议（例如，网页上的二维码，其中包含一个挑战，供应用证明用户在其他地方登录）时。此外，请确保功能和设备状态检测得到良好实施并快速失败，这样用户就不会进入一个流程并遇到令人困惑的失败。您需要检查的一些常见状态包括
• 如果您正在使用这些功能，是否启用了生物识别身份验证，并且是否有允许用户进行身份验证的注册？甚至是否存在生物识别传感器？
• 如果您依赖手机中的安全硬件，您是否已检查硬件是否存在、已启用并且能够提供您需要的功能？
• 您是否可以连接到将执行注册过程的服务？
另一个需要考虑的因素是检查注册是否成功。进行注册的试运行以确保用户知道如何使用生物识别功能始终是有帮助的。
永远不要吓唬您的用户。失败和错误消息应诚实、简洁但友好。诸如“您的设备不够安全”之类的消息既不准确也不恰当。含糊不清的消息可能会吓到和误导用户。过于技术性的消息会训练用户忽略错误消息，这可能会在未来变得更糟。以用户为中心的方式解释特定失败的消息至关重要，这样用户可以自助解决问题或知道联系谁寻求支持。
请记住，对于您要为其生成短期证书的密钥，要求使用生物识别因素将要求用户出示生物识别因素才能签署证书签名请求。这可能会对证书续订期间的用户体验产生影响，因为每次用户续订证书时，他们都必须出示该因素。仅仅颁发长期证书并对此事不闻不问可能很诱人？这不一定是错误的，但它可能不符合您的安全模型。
在将身份集成到您的系统时，请确保仔细考虑此类权衡。对于用户期望每天与之交互的应用，长期有效的身份证书可能更有意义。如果应用不经常使用，则最好使用短期授权，并且证明只需在这些罕见的交互期间发生。
我们现在的情况如何？
在创建可用、持久且安全的用户身份方面，没有简单的答案。移动电话提供了一个引人注目的选择，尤其是在合适的特性和功能可用的情况下，但这些特性和功能在当今主要的智能手机平台上并不一致。在构建这些系统时，您始终必须做出权衡，从用户体验挑战到平台本身的限制。
当您构建这样的系统时，您会发现魔鬼真的在细节中：您的服务在验证证明证书链方面有多正确？随着移动电话技术的变化（想想苹果从 Touch ID 迁移到 Face ID），您如何调整您的策略？您如何处理各种类型的格式不正确的证明证书？您是否想将王冠珠宝（用户访问和验证您的服务的方式）委托给苹果和谷歌？如果您想利用智能手机作为身份设备，您甚至有选择吗？
使用这种方案窃取用户的凭据现在变得很困难。如果您要求进行生物识别身份验证，恶意使用凭据就更加困难。要使用代表用户的密钥，必须提示用户？这有多方便？
不幸的是，在苹果提供此类功能作为 iOS 的一部分并使这些功能在 App Store 中可供应用使用之前，我们离实现强大的、硬件支持的普遍身份还有很长的路要走。另一方面，谷歌已经提供了这项功能好几年，允许应用利用证明功能。
参考文献
1. Android Developers. 2020. 使用密钥证明验证硬件支持的密钥对； https://developer.android.com.cn/training/articles/security-key-attestation.
2. Android Open Source Project. 2020 硬件支持的密钥库； https://source.android.com/security/keystore
3. Apple Inc. 2020. Apple 平台安全；? https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/apple-platform-security-guide.pdf.
4. Apple Inc. 2020. 关于 iOS 13 更新：iOS 13.5； https://support.apple.com/en-us/HT210393#135.
5. Apple Inc. 建立您的应用的完整性； https://developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity.
6. Cai, L. 2019. 使用 Qualcomm Snapdragon 移动平台保护您的数据。Qualcomm； https://www.qualcomm.com/media/documents/files/guard-your-data-with-the-qualcomm-snapdragon-mobile-platform.pdf.
7. Fietkau, J., Starbug, Seifert, J.-P. 2018. 刷指纹！生物识别身份验证如何简化支付、访问和身份欺诈。在第 12 届 Usenix 进攻性技术研讨会论文集中； https://www.usenix.org/conference/woot18/presentation/fietkau.
8. Kent, J. 2005. 马来西亚窃车贼偷手指。BBC 新闻； http://news.bbc.co.uk/2/hi/asia-pacific/4396831.stm.
9. Ngabonziza, B., Martin, D., Bailey, A., Cho, H., Martin, S. 2016. TrustZone 解释：架构特性和用例。IEEE 第二届国际合作与互联网计算会议，445-451； https://ieeexplore.ieee.org/document/7809736/definitions.
10. Ryan, K. 2019. 硬件支持的抢劫：从 Qualcomm TrustZone 中提取 ECDSA 密钥。NCC Group； https://www.nccgroup.com/globalassets/our-research/us/whitepapers/2019/hardwarebackedhesit.pdf.
相关文章
雇佣黑客
调查零售电子邮件帐户黑客服务的新兴黑市
Ariana Mirian
https://queue.org.cn/detail.cfm?id=3365458
RFID 护照的威胁分析
RFID 护照是否使我们容易遭受身份盗窃？
Alan Ramos 等人。
https://queue.org.cn/detail.cfm?id=1626175
重新思考密码
我们的身份验证系统不足。改进是否可能？
William Cheswick
https://queue.org.cn/detail.cfm?id=2422416
Phil Vachon 是 Bloomberg 首席技术官办公室安全分析和身份架构团队的经理。他领导一个工程师团队，致力于解决与网络和基础设施安全、人员和机器身份管理以及数据科学（因为它适用于新兴威胁和恶意行为者的行为）相关的问题。在重返 Bloomberg 之前，Vachon 共同创立了一家专注于高速数据包捕获和分析的初创公司，开发了高频交易系统，为身份和安全基础设施设备设计并实施了固件，构建了合成孔径雷达数据处理工具，并从事运营商路由器的数据平面流量工程。他的主要兴趣是开发与业务问题相关的威胁模型、设计安全的嵌入式系统以及努力改善日益互联的世界中用户隐私保护。
版权所有 © 2020，归所有者/作者所有。出版权已许可给 。
最初发表于 Queue vol. 18, no. 4—
在 数字图书馆 中评论本文
更多相关文章
Mark Russinovich, Cédric Fournet, Greg Zaverucha, Josh Benaloh, Brandon Murdoch, Manuel Costa - 机密计算证明
证明是用于完整性和隐私的强大工具，使验证者能够委托计算并仍然验证其正确执行，并使证明者能够对计算的细节保密。CCP 和 ZKP 都可以实现健全性和零知识，但存在重要差异。CCP 依赖于硬件信任假设，这会产生高性能和对证明者的额外机密性保护，但对于某些应用程序来说可能是不可接受的。CCP 通常也更易于使用，特别是使用现有代码，而 ZKP 带有大量的证明者开销，对于某些应用程序来说可能是不切实际的。
Raphael Auer, Rainer Böhme, Jeremy Clark, Didem Demirag - 央行数字货币的隐私格局
随着世界各地的中央银行转向现金数字化，隐私问题需要提到首位。所采取的路径可能取决于每个利益相关者群体的需求：具有隐私意识的用户、数据持有者和执法部门。
Sutapa Mondal, Mangesh S. Gharote, Sachin P. Lodha - 个人信息隐私
每次与外部服务的在线交互都会创建有关用户的数据，这些数据会被数字记录和存储。这些外部服务可能是信用卡交易、医疗咨询、人口普查数据收集、选民登记等。尽管表面上收集数据是为了向公民提供更好的服务，但个人隐私不可避免地会面临风险。随着互联网的普及和生成的数据量不断增加，数据保护，特别是保护个人隐私，已变得尤为重要。
Kallista Bonawitz, Peter Kairouz, Brendan McMahan, Daniel Ramage - 联邦学习和隐私
如果数据管理不当，集中式数据收集可能会使个人面临隐私风险，并使组织面临法律风险。联邦学习是一种机器学习设置，其中多个实体在中央服务器或服务提供商的协调下协作解决机器学习问题。每个客户端的原始数据都本地存储，不进行交换或传输；相反，使用旨在立即聚合的重点更新来实现学习目标。
© 保留所有权利。