应用程序完整性证实

背景技术

技术领域

本公开整体涉及计算设备，并且更具体地涉及验证在计算设备上执行的应用程序。

在一些情况下，不良行动者可能尝试修改在计算设备上运行的应用程序，使得其不按开发者的预期进行操作。例如，在不良行动者购买许可证之前，应用程序可对应用程序所支持的各种功能施加限制。为了避免购买许可证，不良行动者可修改应用程序以规避这些限制。作为另一示例，应用程序可基于由设备提供的位置数据来提供各种奖励。不良行动者然后可尝试修改应用程序(或安装应用程序的修改版本)，这允许不良行动者伪造位置信息以便获得附加奖励。

附图说明

图1A是示出了用于为经验证的应用程序生成证实的系统的示例的框图。

图1B是示出了用于为经验证的应用程序生成证实的系统的另一示例的框图。

图2A是示出了从系统的计算设备内的安全区域处理器请求证实的应用程序的示例的框图。

图2B是示出了从系统的证实服务器请求证实的应用程序的示例的框图。

图2C是示出了请求与应用程序生成的密钥相关联的证实的应用程序的示例的框图。

图2D是示出了请求由系统内的计算设备的操作系统生成的证实的应用程序的示例的框图。

图2E是示出了请求使用经证明密钥生成的证实的应用程序的示例的框图。

图3是示出了安全区域处理器的示例的框图。

图4A至图4D是示出了用于使用证实的方法的示例的流程图。

图5是示出了示例性计算机系统的框图。

本公开包括对“一个实施方案”或“实施方案”的标引。出现短语“在一个实施方案中”或“在实施方案中”并不一定是指同一个实施方案。特定特征、结构或特性可以与本公开一致的任何合适的方式被组合。

在本公开内，不同实体(其可被不同地称为“单元”、“电路”、其他部件等)可被描述或声称成“被配置为”执行一个或多个任务或操作。此表达方式—被配置为[执行一个或多个任务]的[实体]—在本文中用于指代结构(即，物理的事物，诸如电子电路)。更具体地，此表达方式用于指示此结构被布置成在操作期间执行一个或多个任务。结构可被说成“被配置为”执行某个任务，即使该结构当前并非正被操作。“被配置为生成证实的安全电路”旨在涵盖例如具有在操作期间执行该功能的电路系统的集成电路，即使所涉及的集成电路当前并非正被使用(例如电源未连接到它)。因此，被描述或表述成“被配置为”执行某个任务的实体是指用于实施该任务的物理的事物，诸如设备、电路、存储有可执行程序指令的存储器等等。该短语在本文中不被用于指代无形的事物。因此，“被配置为”结构在本文中不被用于指代软件实体，诸如应用编程接口(API)。

术语“被配置为”并不旨在意指“可配置为”。例如，未经编程的FPGA不会被认为是“被配置为”执行某个特定功能，虽然其可能“能被配置为”执行该功能并且在编程之后可以“被配置为”执行该功能。

所附权利要求书中的表述结构“被配置为”执行一个或多个任务明确地旨在对该权利要求要素

如本文所用，术语“第一”、“第二”等充当其之后的名词的标签，并且不暗指任何类型的排序(例如，空间的、时间的、逻辑的等)，除非有明确指出。例如，移动设备可具有第一用户和第二用户。术语“第一”并不限于设备的初始用户。在移动设备只有一个用户存在时也可使用术语“第一”。

如本文所用，术语“基于”用于描述影响确定的一个或多个因素。该术语不排除可能有附加因素可影响确定。也就是说，确定可仅基于指定的因素或基于所指定的因素及其他未指定的因素。考虑短语“基于B确定A”。此短语指定B是用于确定A的因素或者B影响A的确定。此短语并不排除A的确定也可基于某个其他因素诸如C。该短语还旨在涵盖A仅基于B来确定的实施方案。如本文所用，短语“基于”因此与短语“至少部分地基于”是同义的。

具体实施方式

本公开描述了计算设备可提供指示应用程序的完整性/有效性的证实的实施方案。如本文所用，术语“完整性”用于描述未以未授权方式被修改的应用程序。因此，如果例如应用程序已被不良行动者修改为以开发者未预期的方式操作，则该应用程序将被认为缺乏完整性。如将在下文更详细地讨论的，在计算设备上执行的应用程序可连接到远程服务以便执行某些功能。为了证实其完整性，在各种实施方案中，应用程序可从基于应用程序的验证而提供的计算设备请求证实。在一些实施方案中，该验证部分地由计算设备的安全电路执行。如果验证成功，则安全电路生成所请求的证实，该证实利用由安全电路维护的加密密钥进行签署。在各种实施方案中，该加密密钥特定于应用程序和/或应用程序的当前用户。在证实已由安全电路发出之后，应用程序可将证实提供给远程服务，以便证实该应用程序尚未被不正确地修改。在下文所讨论的其他实施方案中，验证和证实生成可由计算设备的操作系统、远程服务器、安全电路或它们的组合来处理。在许多情况下，以这种方式实现验证系统可降低计算设备正在执行不正确修改的应用程序的可能性。

现在转向图1A，其示出了验证系统10A的框图。在例示的实施方案中，系统10A包括计算设备100，该计算设备包括经由互连器140耦接在一起的中央处理单元(CPU)110、存储器120和安全区域处理器(SEP)130。存储器120包括应用程序122和操作系统(OS)126。系统10A还包括远程服务器150。在一些实施方案中，系统10A可与所示以不同方式实现——例如，系统10A可包括如下文相对于图1B所讨论的证实服务器，计算设备100可包括下文相对于图5所讨论的一个或多个部件等。

在各种实施方案中，应用程序122能够执行以连接到远程服务，该远程服务在例示的实施方案中由远程服务器150提供。应用程序122可对应于任何合适的应用程序，该应用程序可能易受不希望的修改的影响。类似地，远程服务器150可对应于任何合适的计算机系统并且可提供任何合适的服务。例如，应用程序122可为尝试从服务器150检索内容以便将该内容呈现给用户的应用程序。作为另一示例，应用程序122可为尝试连接到服务器150的多人游戏，因此用户可与其他用户进行游戏。在一些实施方案中，远程服务器150由应用程序122的开发者操作；在其他实施方案中，服务器150可由一些其他实体操作。

如上所述，在各种实施方案中，应用程序122可向远程服务器150提供证实134以便证实其完整性——例如，其未以某种未授权方式被修改。在一些实施方案中，远程服务器150可请求证实134作为与应用程序122建立连接(或提供应用程序122所请求的任何服务)的先决条件。如将在下文讨论的，在一些实施方案中，证实134是由远程服务器150发出并且使用由SEP 130维护的应用程序密钥132进行签署的已签署质询。在接收到证实134之后，远程服务器150然后可尝试验证证实134。在一些实施方案中，远程服务器150还可执行与所接收的证实134的验证不同的用户认证。如图所示，应用程序122可向OS 126发出请求124，以便生成证实134。

在各种实施方案中，OS 126能够执行以管理计算设备100的各种操作。在例示的实施方案中，OS 126促进将应用程序122与SEP 130接口，这可由OS 126所支持的应用编程接口(API)提供。因此，应用程序122可向OS 126发出请求124作为API调用，该OS继而可将请求124提供给SEP 130。OS 126还可经由API将通过对请求作出响应而生成的证实134返回给应用程序122以用于递送到远程服务器150。在一些实施方案中，OS126还参与应用程序122的验证，如将在下文讨论的，并且在一些实施方案中，甚至生成证实134。

在各种实施方案中，SEP 130是被配置为执行计算设备100的加密服务的安全电路。如本文所用，术语“安全电路”是指被配置为执行一个或多个服务并将已认证响应返回至外部请求者的一类电路之一。安全电路返回的结果被认为具有超过仅返回结果而无任何形式认证的电路的信任标记。在一些实施方案中，来自SEP 130的响应是通过诸如提供数字签名或加密数据等密码术的使用来认证。在一些实施方案中，来自SEP 130的响应是通过经由诸如SEP 130与另一方之间的专用总线或下文讨论的邮箱机构等可信通信信道进行通信来认证。相比之下，仅在某些接收值上操作并且返回结果的诸如硬件加速器等电路将不被认为是本公开含义内的安全电路。通过认证返回的结果，诸如通过利用能够验证的数字签名进行签署，安全电路因此可提供反欺骗功能。另外，在一些情况下，安全电路可被称为“防篡改的”，其是指防止安全电路的执行一个或多个服务的部分受损的机制的专门术语。

在一些实施方案中，SEP 130被配置为为应用程序122生成证实134以及在提供证实134之前验证应用程序122。如将在下文相对于图2A至图2E更详细地讨论的，该验证可包括从应用程序122接收各种元数据以证实应用程序122的身份及其完整性。在各种实施方案中，该元数据包括应用程序证书，该应用程序证书由开发者提供并且包括从应用程序122的有效副本生成的一个或多个已签署散列值。在一些实施方案中，证书还可包括应用程序的身份以及由开发者定义的各种其他标准。因此，响应于接收到该元数据，SEP 130可验证应用程序证书并且验证从应用程序122生成的散列值与应用程序证书中的那些散列值匹配。在一些实施方案中，该验证可部分地(或完全地)由操作系统126执行。例如，在一个实施方案中，OS126可从应用程序122生成一个或多个散列值并且将它们提供给SEP 130，该SEP将它们与开发者提供的已签署散列值进行比较。在另一实施方案中，OS 126执行该比较并且将比较的结果指示给SEP 130，该SEP在生成证实134之前验证该结果。(在仍其他实施方案中，验证和/或生成可由证实服务器处理，如将在下文相对于图1B所讨论的。)在各种实施方案中，该验证可在应用程序122的登记期间和/或在证实134的生成期间执行。

在一些实施方案中，在可发出对证实的请求124之前，应用程序122可执行初始登记，在该初始登记中SEP 130生成应用程序密钥132以供证实134的后续生成使用。在一些实施方案中，可在安装或更新应用程序122时(或者在添加新用户的情况下)执行该登记。在登记期间，SEP 130可导出对应于应用程序密钥132的具有公钥和私钥的公钥对。在一些实施方案中，这些导出的密钥对于给定设备100(或SEP 130)是唯一的——因此，两个设备100将包括不同的密钥。在一些实施方案中，这些导出的密钥对于设备100上的应用程序122是唯一的(或者甚至对于应用程序122的版本是唯一的)。在下文讨论的一些实施方案中，所导出的密钥对于特定用户也是唯一的——因此，具有两个用户的应用程序122将提供使用单独的密钥132生成的证实134。在各种实施方案中，登记还可包括SEP 130生成用于公钥对的证书——在这样做时，SEP 130可充当证书授权机构(CA)。该证书可包括公钥并且连同证实134一起被传送到远程服务器150，使得远程服务器150可使用公钥来验证证实134。在一些实施方案中，该证书可包括附加内容，诸如对验证中使用的开发者证书的引用、来自证书的已签署散列值等。在一些实施方案中，该证书(以及本文所描述的其他证书)符合X.509的要求。

在登记之后，应用程序122可发出对证实134的请求124——例如，在其打算与远程服务器150建立连接时。响应于应用程序122的成功验证，在一些实施方案中，SEP 130被配置为检索对应的应用程序密钥132以及生成对应的证实134。如上所述，在一些实施方案中，该生成包括签署由远程服务器150发出的质询。然而，SEP 130可签署其他信息以生成证实134，诸如从应用程序122生成的散列值、时间戳等。尽管为简单起见未在图1A中示出，但SEP130可经由OS 126将证实134提供给应用程序122，该应用程序可将该证实递送给远程服务器150以进行验证。应用程序122还可提供证书，该证书在登记期间获得并且包括不能用于验证证实134的公钥。在一些实施方案中，应用程序证书和/或与设备100的制造商相关联的根证书也可被传送到远程服务器150以促进证实134的验证。

现在转向图1B，其示出了验证系统10B的框图。如上所述，应用程序验证和/或证实生成可由外部服务器执行。因此，在例示的实施方案中，验证系统10B包括如上文相对于图1A讨论的元件100-150，并且还包括被配置为执行应用程序验证和/或证实生成的证实服务器160。在一些实施方案中，系统10B可与所示以不同方式实现。尽管被标记为服务器，但计算系统160可对应于任何合适的计算设备，诸如计算设备100的相邻设备、与设备100关联到相同基于云的账户的设备、下文相对于图5列出的计算设备中的任何计算设备等。

在证实服务器160执行验证的实施方案中，证实服务器160可接收请求124，该请求包括关于要由服务器160验证的应用程序122的元数据。在例示的实施方案中，SEP 130使用请求密钥136来签署请求124，以便证实请求124来自有效设备100(以及还有包括SEP 130的设备)。在此类实施方案中，证实服务器160验证请求124的签名以及伴随的元数据，该签名以及伴随的元数据可与上文所讨论和下文更详细地讨论的方式类似的方式进行验证。在一些实施方案中，提供给服务器160的元数据可被模糊，使得服务器160能够验证该元数据而不知道该元数据的完整内容。例如，请求124中的元数据可包括应用程序122的名称的散列值(而不是实际名称)，以便使该名称对服务器160模糊。在各种实施方案中，传送到服务器160的任何元数据都是以符合公认的隐私政策和/或隐私实践的方式进行传送的。用户也可“选择退出”参与，如下文所讨论的。在服务器160不负责生成证实134的一些实施方案中，服务器160可将验证的结果发送到SEP 130(或更一般地，设备100)，该SEP可基于所接收的结果生成证实134。在仍其他实施方案中，SEP 130(或OS 126)可维护应用程序密钥132，但服务器160可响应于接收并验证请求124而证明那些密钥132。具体地，请求124可为证书签署请求(CSR)，其包括对应于应用程序密钥132(在此类实施方案中，密钥132是私钥)的公钥以及从密钥132生成的签名。在验证请求124中的信息之后，服务器160可为密钥132发行对应证书。该证书可随后与证实134一起被呈现给服务器150，该服务器可使用该证书来验证证实134。

在证实服务器160执行证实134的生成的实施方案中，证实服务器160可检索应用程序密钥132并且通过使用密钥132生成数字签名来产生证实134，如上文所讨论和下文更详细地讨论的。在服务器160执行应用程序验证的实施方案中，该证实134可基于服务器160的验证结果来产生。在其他实施方案中，SEP 130和/或OS 126可执行该验证并且向服务器160指示验证的结果以使其提供证实134。在下文相对于图2C讨论的仍其他实施方案中，服务器160可生成公钥对并且将该对提供给设备100(具体地，OS126)以使其能够生成证实134。

现在转向图2A，其示出了用于获得由SEP 130生成的证实134的交互200A的框图。在例示的实施方案中，应用程序122包括程序指令210、数据220和元数据230，它们可用于验证应用程序122并且获得证实134，如将在下文讨论的。在一些实施方案中，交互200A可以不同方式实现——例如，元数据230可不被包括在应用程序122中，元数据230可包括更多(或更少)元素，请求124可包括元数据230，等等。

在各种实施方案中，元数据230是关于应用程序122并且能够用于验证应用程序122的信息。在例示的实施方案中，元数据230包括应用程序标识符232和应用程序证书234，该应用程序证书包括一个或多个已签署散列值236和密钥阈值238。在各种实施方案中，应用程序标识符232是唯一地识别应用程序122(诸如应用程序122的名称、版本号、随机值或它们的组合)的值。在一些实施方案中，标识符232可被包括在证书234中。在各种实施方案中，应用程序证书234是由应用程序122的开发者(或销售应用程序122的应用商店)发出的具有散列值236的证书，该散列值是通过将散列函数应用于应用程序122的有效副本的程序指令210并且使用私钥签署散列值而生成，该私钥可具有包括在证书234中的对应公钥。因此，如果程序指令210随后被修改，则来自指令210的任何随后生成的散列值于是可偏离已签署散列值236。

在各种实施方案中，密钥阈值238是与应用程序密钥132有关的一个或多个标准的集合。如上所述，在一些实施方案中，可为特定应用程序122的每个用户生成应用程序密钥132。在此类实施方案中，密钥阈值238可限制可为应用程序122的用户生成的密钥132的数量。例如，阈值238可指定可为最多五个用户生成密钥132。如果接收到为第六用户生成第六密钥132的请求242，则SEP 130可拒绝该请求(或替换已生成的密钥132中的一个密钥，诸如响应于接收到为特定用户生成新密钥的请求而移除特定用户的先前生成的密钥132)。在另一实施方案中，密钥阈值238可限制可基于应用程序122的版本数量生成的密钥132的数量。例如，如果开发者已发布应用程序的两个版本(例如，版本1.0和版本2.0)，则密钥阈值238可指示可生成最多两个密钥132——假设版本1.0被初始安装并且然后更新为版本2.0。在一些实施方案中，密钥阈值238还可用于限制在给定时间点对应用程序122有效的已发行证书的数量。在一些情况下，对密钥132(和/或证书246)施加限制可防止恶意行动者通过创建多个密钥132(诸如与欺骗性用户账户版本绑定的那些密钥)等来实现某些利益。

如上所述，可执行登记交换202A以建立能够用于生成后续证实134的应用程序密钥132。如图所示，交换202A可包括向SEP 130发送登记请求242的应用程序122。在例示的实施方案中，该请求242包括元数据230和用户标识符244。在一些实施方案中，用户标识符244是索引值，该索引值用于在已为多个用户生成多个密钥时查找应将哪个密钥136用于给定应用程序122。因此，用户标识符244可对应于能够用于区分一个用户的密钥136与另一个用户的密钥136的任何合适值。例如，在一个实施方案中，标识符244是分配给用户以将其与其他用户区分开的随机值。在其他实施方案中，标识符244可为服务器150已知的某个值。例如，在一个实施方案中，标识符244是应用程序122的用户用来访问远程服务器150的用户账户的散列值。在其他实施方案中，可使用其他类型的索引值来查找与特定应用程序122相关联的密钥136。响应于接收到元数据230，SEP 130可验证其正确地对应于应用程序122。如上所述，这可包括SEP 130(或OS126)读取程序指令和/或数据220以生成一个或多个散列值，该一个或多个散列值与已签署散列值236进行比较。在一些实施方案中，SEP 130还可确认生成新密钥132符合密钥阈值238。如果验证成功，则SEP 130可生成公钥对并且返回对应的密钥证书246。在各种实施方案中，密钥证书246包括公钥对中的公钥和利用私钥生成的签名，该私钥是应用程序密钥132。在一些实施方案中，密钥证书246还可包括元数据230的至少一部分，诸如应用程序标识符232和/或已签署散列值236。在一些实施方案中，证书246可包括对应用程序证书234的引用，诸如来自证书234的数字签名。在一些实施方案中，证书246可包括用户标识符244——例如，以使远程服务器150能够也依赖于证实134来认证与应用程序密钥132相关联的特定用户。在许多情况下，登记202A可仅执行一次，以便允许使用交换204A的多次后续执行。

一旦已执行登记交换202A，应用程序122就可在其想要证实134时执行使用交换204A。在一些实施方案中，交换202A可从应用程序接收质询252开始，该质询可包括随机数据或由远程服务器150提供的一些其他值，以便防止潜在的重放攻击。如图所示，应用程序122然后可在请求124中传送质询252以及用户标识符244以获得证实134。在例示的实施方案中，请求124不包括元数据230，因为其在登记中被验证。然而，在其他实施方案中，元数据230可被包括在请求124中并且由SEP 130验证。响应于接收到请求124，SEP 130可基于用户标识符244(或一些其他类型的密钥索引)来检索用于应用程序122的适当密钥132。SEP 130然后可使用密钥132来从质询252生成数字签名并且将该签名作为证实134提供给应用程序122。应用程序122然后可将密钥证书246和证实134提供给远程服务器150，该远程服务器使用密钥证书246来验证证实134。如果验证成功(意味着应用程序122已被SEP 130验证为对应于应用程序证书234)，则远程服务器150可继续将所请求的服务提供给应用程序122。

现在转向图2B，其示出了用于获得由服务器160生成的证实134的交互200B的框图。如同上文关于交互200A所讨论的，交互200B可包括登记交换202B和一个或多个使用交换204B。在例示的实施方案中，登记交换202B包括应用程序122向SEP 130发送登记请求242，该SEP使用请求密钥136来签署请求242并且将该请求发送到服务器160。如图所示，在一些实施方案中，请求242包括由服务器160验证的元数据230和用户标识符244。如上所述，在一些实施方案中，元数据230和/或用户标识符244可被模糊(例如，通过散列该信息)，以防止服务器160知道例如应用程序标识符232。响应于成功验证，服务器160可将密钥证书246返回给应用程序122。在例示的实施方案中，使用交换204B包括应用程序122向SEP130发送请求124，该SEP使用请求密钥136来签署该请求并且将其发送到服务器160。在一些实施方案中，该请求124包括用户标识符244和质询252(以及在一些实施方案中包括可被模糊的元数据230)。响应于接收到请求124(以及在一些实施方案中执行另一验证)，服务器160可通过签署质询252(或包括信息的质询252)来生成证实134。服务器160然后可将所生成的证实134返回给应用程序122，该应用程序可将证实134连同密钥证书246一起递送到远程服务器150。

现在转向图2C，其示出了用于获得由SEP 130生成并且与应用程序生成的密钥相关联的证实134的交互200C的框图。在例示的实施方案中，交互200C包括登记交换202C，在该登记交换中，应用程序122如上所述发送登记请求242，并且SEP 130使用密钥请求136来签署请求242中的内容，诸如元数据230和用户ID 244。然后可将该已签署内容传送到服务器160进行验证。响应于成功验证，服务器160可发出证书证明应用程序密钥132。然而，作为执行登记交换202C的一部分，应用程序122还可生成加密密钥(示出为应用程序生成的密钥222)，该应用程序可在其与远程服务器150的交互中使用该加密密钥。在例示的实施方案中，应用程序122进一步发送证书请求224，要求SEP 130为应用程序生成的密钥222发行对应证书226。(尽管出于例示目的而单独地示出，但在一些实施方案中，证书请求224可为登记请求242的一部分或者与登记请求242一起被发送。)在一些实施方案中，SEP 130使用新证明的应用程序密钥132来签署所请求的密钥证书226。在使用交换204C期间，SEP 130可如上所述使用应用程序密钥132来为所发出的质询252生成证实134。然而，使用交换204C还可包括应用程序122为应用程序生成的密钥222提供证书226并且出于某种目的使用密钥222。在例示的实施方案中，应用程序生成的密钥222用于建立与远程服务器150的安全交换254，诸如在椭圆曲线Diffie-Hellman(ECDH)交换中使用密钥222来建立共享密钥；然而，在其他实施方案中，应用程序生成的密钥222可由应用程序122用于各种其他目的。

现在转向图2D，其示出了用于获得由OS 126生成的证实134的交互200D的框图。在例示的实施方案中，证实服务器160执行元数据230的验证，但OS 126生成证实134。如图所示，交互200D可包括登记交换202D，该登记交换可按与交换202B类似的方式进行请求242和密钥证书246的传送。然而，在例示的实施方案中，证实服务器160生成公钥对并且提供私有应用程序密钥132以用于后续使用交换204D中。因此，当应用程序122在交换204D中发出后续请求124时，OS 126使用私钥132来生成证实134，诸如上文所讨论。

现在转向图2E，其示出了用于获得由OS 126生成并且使用经证明的应用程序密钥132的证实134的交互200E的框图。在例示的实施方案中，OS 126(或在其他实施方案中，SEP130)生成公钥对，使得应用程序密钥132是该对的私钥。在交换202E期间，OS 126在请求242中包括请求242中的该对的公钥262以及从私有应用程序密钥132生成的签名。尽管未示出，但该请求242可进一步由SEP 130签署。服务器160然后可验证请求242并且响应于验证成功而为应用程序122发行对应证书246。该验证可按与上文相对于其他附图所讨论的方式类似的方式来实现。在一些实施方案中，服务器160限制在给定时间针对特定应用程序122向设备100发行的有效证书246的数量。因此，该验证可包括验证已发行证书246的数量在发行新证书246之前不超过阈值(诸如由密钥阈值238识别的阈值)。在一些实施方案中，当应用程序私钥132由OS 126维护时，证书246可被分配较短有效期，以进一步限制有效证书246的数量。当稍后执行使用交换204E时，OS 126使用经证明的应用程序密钥132来生成证实134并且将其连同证书246一起提供给服务器150以进行验证。

在各种实施方案中，当应用程序122发出请求242和/或较旧的已发行密钥证书246到期时，可按需执行登记交换202。在一些情况下，当多个设备100上的多个应用程序122正在请求证实134时，这可导致大量请求242被发送到服务器160。在其他实施方案中，多个请求242可被分组在一起并且作为周期性批处理请求被发出到服务器160。例如，OS 126可针对应用程序122所请求的所有密钥证书246每天一次地传送单个批处理请求。该异步方法可导致服务器160接收到更少的请求。在一些实施方案中，OS126可进一步跟踪与特定应用程序密钥132相关联的证实134最后是何时生成的。如果自发出与特定应用程序密钥132相关联的证实134以来已经过了特定时间量(例如，三十天)，则OS 126可放弃请求在即将到来的批处理请求中更新证书246。如果对应的应用程序122稍后在证书246已到期和/或其对应的私钥132已被潜在地删除之后请求证实134，则OS 126可针对更新的证书246按需发出请求242(或者，在另一实施方案中，计划将该请求包括在发送到服务器160的下一批处理请求中)。在一些实施方案中，OS 126可针对已经存在的先前证明的应用程序密钥132请求更新的证书246，而不是生成新的应用程序密钥132，以便减少生成新密钥132的实例的数量——假设此类密钥132仍可用并且未被删除。然而，如果密钥132已被删除，则OS 126可生成新密钥132并且请求新证书246。

现在转向图3，其示出了SEP 130的框图。在例示的实施方案中，SEP130包括经由互连器380耦接在一起的过滤器310、安全邮箱机构320、处理器330、安全ROM 340、密码引擎350、密钥存储装置360和生物传感器流水线370。在一些实施方案中，SEP 130可包括比图3所示更多(或更少)的部件。如上所述，SEP 130是具有防篡改性的安全电路。如下文所讨论的，SEP 130通过使用过滤器310和安全邮箱320来实现防篡改性。

过滤器310是被配置为严密控制对SEP 130的访问以增大SEP 130相对于计算设备100的其余部分的隔离性，并且因此提高设备100的总体安全性的电路系统。更具体地，在一个实施方案中，过滤器310可仅在来自CPU 110(或耦接到互连部140的其他外围设备)的读/写操作寻址到安全邮箱320的情况下才允许这些操作进入SEP 130。其他操作可不从互连器140前进到SEP 130中。甚至更特别地，过滤器310可允许对分配给安全邮箱320的收件箱部分的地址的写操作以及对分配给安全邮箱320的发件箱部分的地址的读操作。过滤器310可阻止/过滤所有其他读/写操作。在一些实施方案中，过滤器310可用错误对其他读/写操作进行响应。在一个实施方案中，过滤器310可接收与过滤后的写操作相关联的写数据，而不将该写数据传递给本地互连器380。在一个实施方案中，过滤器310可提供现时数据作为用于过滤后的读操作的读数据。现时数据(例如“无用数据”)可一般为不与SEP 130内的被寻址资源相关联的数据。过滤器310可提供任何数据作为现时数据(例如全零、全一、来自随机数生成器的随机数据、被编程到过滤器310中以作为读数据进行响应的数据、读事务的地址等等)。

在各种实施方案中，过滤器310可以只过滤传入读/写操作。因此，SEP 130的部件可具有对计算设备100的其他部件(诸如存储器120)的完全访问权限。因此，过滤器310可不过滤响应于SEP 130所发出的读/写操作而提供的来自互连器140的响应。

安全邮箱320是在一些实施方案中包括收件箱和发件箱的电路系统。收件箱和发件箱二者可以是数据的先进先出缓冲器(FIFO)。缓冲器可具有任意尺寸(例如任意数量的条目，其中每个条目能够存储来自读/写操作的数据)。特别地，收件箱可被配置为存储来自源于互连器140的写操作的写数据。发件箱可存储来自源于处理器330的写操作的写数据。(如本文所用，“邮箱机构”是指暂时存储1)安全电路的输入直到其能被该电路检索和/或2)安全电路的输出直到其能被外部电路检索的存储器电路。)

在一些实施方案中，在CPU 110上执行的软件可经由OS 126所支持的应用编程接口(API)请求SEP 130的服务——即，请求者可进行请求SEP130的服务的API调用。这些调用可使相应请求被写到邮箱机构320，其然后被从邮箱320检索并被处理器330分析以确定其是否应对请求提供服务。因此，该API可用于促进例如经由邮箱320的交换202和204。通过以这种方式隔离SEP 130，SEP 130的完整性可得到增强。

SEP处理器330被配置为处理从计算设备100中的各种来源接收的命令。处理器330然后可执行存储在ROM 340中的指令以便实现本文相对于SEP 130所描述的功能，这可包括使用各种安全外围设备来实现命令。因此，ROM 340可包括能够执行以使用上文所讨论的密钥132或136来执行操作的程序指令。例如，ROM 340可对能够执行的指令进行编程以验证应用程序122和/或生成证实134。在例示的实施方案中，SEP处理器330可执行认证应用程序342以执行用户的认证以及向生物传感器传感器流水线370提供适当的命令，以便验证由设备100的生物传感器收集的生物计量数据302。可执行此类认证，例如以解锁设备100、向应用程序122认证设备100的用户等。在对一些实施方案能够执行的程序指令中，由SEP处理器330执行的程序指令由可信授权机构(例如，设备10的制造商)签署以便确保它们的完整性。

安全ROM 340是被配置为存储用于引导SEP 130的程序指令的存储器。在一些实施方案中，ROM 340可只对分配给本地互连器380上安全ROM 340的特定地址范围进行响应。所述地址范围可以是硬连线的，并且处理器330可被硬连线以在引导时从该地址范围进行取操作以便从安全ROM 340引导。过滤器310可过滤分配给安全ROM 340的地址范围(如上所述)内的地址，从而阻止从SEP 130外部的部件对安全ROM 340的访问。在一些实施方案中，安全ROM 340可包括SEP处理器330在使用期间执行的其他软件。这个软件可包括用于处理收件箱消息和生成发件箱消息等的程序指令。

密码引擎350是被配置为为SEP 130执行密码操作的电路系统，包括密钥生成以及利用密钥存储装置360中的密钥的加密和解密。密码引擎350可实施任何合适的加密算法，诸如数据加密标准(DES)、高级加密标准(AES)、不对称密码算法(Rivest Shamir Adleman(RSA))等。在一些实施方案中，引擎350还可实施椭圆曲线密码术(ECC)。在一些实施方案中，引擎350被配置为使用密钥132来生成证实134。在其他实施方案中，引擎350被配置为使用密钥136来签署请求242和/或124，如上文所讨论的。

密钥存储装置360是被配置为存储密码密钥的本地存储器(即内部存储器)。如图所示，在一些实施方案中，存储装置360包括密钥132或136。存储装置360还可包括关于密钥132或136并且能够用于检索密钥132或136的各种元数据362，诸如其相关联的应用程序标识符、用户标识符等。密钥存储装置360可包括任何类型的存储器，诸如下文相对于图5列出的易失性或非易失性存储器的各种示例。在一些实施方案中，存储装置360还可包括一组熔断器，该组熔断器在SEP 130(或更一般地，设备100)的制造期间被烧掉，以便记录诸如UID密钥等密钥。尽管被示出为驻留在存储装置360中，但是密钥132或136可被存储在SEP 130的外部，但由可被存储在存储装置360中的SEP 130所维护的一个或多个密钥加密。

在一个实施方案中，生物传感器传感器流水线370是被配置为将由生物传感器从正被认证的用户捕获的生物计量数据302与被授权用户的生物计量数据372进行比较的电路系统。(在另一实施方案中，可通过诸如认证应用程序342等软件来比较数据302和327。)生物计量数据可以是基于用户的身体或行为特点在其他人中唯一地(至少以高准确度)识别用户的数据。在从用户的面部收集数据302的一些实施方案中，流水线370可使用流水线370中包括的神经网络集合来执行比较，每个网络被配置为将在单个帧中捕获的生物计量数据302与被授权用户的在多个帧中捕获的生物计量数据372进行比较。如图所示，流水线370可被配置为从存储器120读取生物计量数据372，该生物计量数据可在一些实施方案中通过加密进行保护和/或被存储在只能由SEP 130访问的存储器120的相关联部分中。(在另一实施方案中，SEP 130可内部地存储数据372。)基于生物计量数据302和372的比较，SEP130可提供认证结果，该认证结果指示认证是成功还是失败。

现在转向图4A，其示出了方法400的流程图。方法400是由执行应用程序的计算设备(诸如计算设备100)执行的方法的一个实施方案。在许多情况下，方法400的执行可确保有效应用程序的执行。

在步骤405中，计算设备从应用程序(例如，应用程序122)接收对能够用于确认应用程序的完整性的证实(例如，证实134)的请求(例如，请求124)。

在步骤410中，计算设备指导安全电路(例如，SEP 130)使用多个经维护的加密密钥中的一个加密密钥(例如，应用程序密钥132或请求密钥136)来为应用程序提供证实。在一些实施方案中，安全电路验证与应用程序的完整性有关的所接收的元数据(例如，元数据230)并且使用加密密钥来生成指示应用程序的完整性的证实。在各种实施方案中，元数据包括证书(例如，应用程序证书234)，该证书识别由应用程序的开发者签署的散列值(例如，散列值236)。在一些实施方案中，安全电路响应于所接收的请求而执行已签署散列值与从应用程序生成的散列值的比较。在一些实施方案中，安全电路生成对于应用程序唯一的公钥对，使得加密密钥是公钥对中的私钥。在一些实施方案中，安全电路向应用程序提供包括公钥对中的公钥的证书(例如，密钥证书246)，该公钥能够由远程计算系统用来验证证实。在一些实施方案中，证书包括应用程序的标识符(例如，应用程序标识符232)和从应用程序生成的散列值(例如，散列值236)。在一些实施方案中，安全电路接收由远程计算系统向应用程序发出的质询(例如，质询252)以认证应用程序，并且通过用私钥签署质询来生成证实。在一些实施方案中，公钥对用于计算设备的特定用户，并且对证实的请求识别该特定用户。在一些实施方案中，安全电路从应用程序的开发者接收应用程序证书(例如，应用程序证书234)，并且该应用程序证书识别允许为其生成公钥对的阈值用户数量(例如，密钥阈值238)。在此类实施方案中，安全电路验证生成公钥对符合阈值用户数量。在一些实施方案中，操作系统验证从应用程序获得并且与应用程序的完整性有关的元数据(例如，元数据230)，并且操作系统基于所验证的元数据执行指导。在一些实施方案中，安全电路使用加密密钥来(例如，通过签署请求124)与被配置为生成证实的服务器建立连接，并且从服务器接收所生成的证实。

在步骤415中，计算设备将证实提供给与应用程序通信的远程计算系统(例如，远程服务器150)。

现在转向图4B，其示出了方法430的流程图。方法430是由证实其有效性的应用程序(诸如应用程序122)执行的方法的一个实施方案。在许多情况下，方法430的执行可确保有效应用程序的执行。

在步骤435中，应用程序发送对指示应用程序已被验证的证实(例如，证实134)的请求(例如，请求124)。

在步骤440中，应用程序提供指示应用程序的身份的元数据(例如，元数据230)。在一些实施方案中，元数据被提供给安全电路(例如，SEP130)，并且安全电路被配置为响应于请求而验证元数据。在一些实施方案中，该提供包括为应用程序的授权副本提供由开发者生成的已签署散列值(例如，已签署散列值236)，并且安全电路被配置为在生成证实之前验证散列值。

在步骤445中，应用程序从计算设备的安全电路接收所请求的证实，该安全电路被配置为基于所提供的元数据的验证来提供所请求的证实。在一些实施方案中，所接收的证实是使用由安全电路为应用程序维护的加密密钥(例如，应用程序密钥132)来签署。在一些实施方案中，加密密钥是由安全电路维护的多个密钥之一，并且对证实的请求包括能够由安全电路用来识别加密密钥的索引值(例如，用户标识符244)。

在步骤450中，应用程序使用所接收的证实来与远程服务器(例如，远程服务器150)建立连接。

现在转向图4C，其示出了方法460的流程图。方法460是由为应用程序生成证实的服务器系统(诸如证实服务器160)执行的方法的一个实施方案。在许多情况下，方法460的执行可确保有效应用程序的执行。

在步骤465中，服务器系统从计算设备(例如，设备100)中的安全电路(例如，SEP130)接收已签署请求(例如，已签署请求124)以便为在计算设备上执行的应用程序(例如，应用程序122)提供证实(例如，证实134)。在各种实施方案中，证实能够用于确认应用程序是有效的。在各种实施方案中，服务器系统维护用于为计算设备生成证实的多个加密密钥(例如，应用程序密钥132)。在一些实施方案中，多个加密密钥中的每个加密密钥与在计算设备上执行的相应应用程序相关联。在一些实施方案中，服务器系统从安全电路接收请求(例如，已签署请求242)以便为应用程序生成加密密钥，并且在生成加密密钥之前，服务器系统验证生成加密密钥符合由应用程序的开发者设置的限制。在此类实施方案中，限制(例如，密钥阈值238)是允许为应用程序生成的加密密钥数量。

在步骤470中，服务器系统使用由服务器系统维护的加密密钥生成所请求的证实。在一些实施方案中，在生成所请求的证实之前，服务器系统验证与请求一起提供并且与应用程序的身份有关的元数据(例如，元数据230)。在一些实施方案中，服务器系统从安全电路接收表明由应用程序提供的与应用程序的身份有关的元数据已被验证的指示，并且响应于该指示而生成证实。

在步骤475中，服务器系统将所生成的证实发送到计算设备。在各种实施方案中，证实由应用程序用于建立与服务(例如，由远程服务器150提供)的通信。

现在转向图4D，其示出了方法490的流程图。方法490是由计算设备执行的方法的一个实施方案，该计算设备使用由另一计算机系统证明的密钥来生成证实。在许多情况下，方法490的执行可确保有效应用程序的执行。

在步骤492中，计算设备从第一计算系统(例如，证实服务器160)接收用于加密密钥(例如，应用程序密钥132)的证书(例如，证书246)，该加密密钥能够用于生成证实(例如，证实134)，该证实指示应用程序(例如，应用程序122)已被验证。在各种实施方案中，计算设备执行应用程序的登记(例如，登记202)，包括：为应用程序生成公钥对，该公钥对包括作为公钥对中的私钥的加密密钥，以及将对证书的请求发送到第一计算系统，该请求包括公钥对中的公钥(例如，公钥262)和由私钥生成的签名。在一些实施方案中，该执行包括在将请求发送到第一计算系统之前请求安全电路(例如，SEP 130)(例如，使用请求密钥136)来签署该请求。

在步骤494中，计算设备从应用程序接收请求(例如，请求124)以生成证实。

在步骤496中，响应于应用程序的验证，计算设备使用加密密钥来生成所请求的证实。在一些实施方案中，证实由计算设备的操作系统(例如，OS 126)生成。在一些实施方案中，证实由计算设备的安全电路(例如，SEP 130)生成。

在步骤498中，计算设备将所生成的证实和所接收的证书提供给与应用程序接口的第二计算系统(例如，远程系统150)。在一些实施方案中，方法490包括生成能够用于为应用程序生成证实的多个加密密钥，该多个加密密钥中的每个加密密钥与应用程序的相应用户相关联。在一些实施方案中，计算设备基于由应用程序的开发者指定的阈值(例如，密钥阈值238)来限制为应用程序的用户生成的加密密钥数量。在一些实施方案中，该限制包括响应于确定为特定用户生成新密钥而移除先前为特定用户生成的密钥。在一些实施方案中，计算设备(或第一计算系统)限制在给定时间相对于应用程序发行的证书数量。

现在转向图5，其示出了例示计算设备500的示例性实施方案的框图，该计算设备可实现计算设备100、服务器150和/或服务器160的功能。设备500可对应于任何合适的计算设备，诸如服务器系统、个人计算机系统、台式计算机、膝上型计算机或笔记本计算机、大型计算机系统、平板电脑、手持式计算机、工作站、网络计算机、移动电话、音乐播放器、个人数据助理(PDA)、可穿戴设备、物联网(IoT)设备等。在一些实施方案中，设备500的元件可被包括在片上系统(SOC)内。在例示的实施方案中，设备500包括结构体510、处理器复合体520、图形单元530、显示单元540、高速缓存/存储器控制器550、输入/输出(I/O)桥560。

结构体510可以包括各种互连器、总线、MUX、控制器等，并且可以被配置为促进设备500的各种元件之间的通信。在一些实施方案中，结构体510的各部分可以被配置为实现各种不同的通信协议。在其他实施方案中，结构体510可以实现单个通信协议，并且耦接到结构体510的元件可以在内部从单个通信协议转换为其他通信协议。如本文所用，术语“耦接到”可指示元件之间的一个或多个连接，并且耦接可包括中间元件。例如，在图5中，图形单元530可被描述为通过结构体510和高速缓存/存储器控制器550“耦接到”存储器。相比之下，在图5的例示的实施方案中，图形单元530“直接耦接”到结构体510，因为不存在中间元件。

在例示的实施方案中，处理器复合体520包括总线接口单元(BIU)522、高速缓存524和核心526A和526B。在各种实施方案中，处理器复合体520可包括各种数量的处理器、处理器核心和/或高速缓存。例如，处理器复合体520可以包括1个、2个或4个处理器核心，或任何其他合适的数量。在一个实施方案中，高速缓存524是组关联L2高速缓存。在一些实施方案中，核心526A和/或526B可以包括内部指令和/或数据高速缓存。在一些实施方案中，结构体510、高速缓存524或设备500中的其他地方的一致性单元(未示出)可被配置为维持设备500的各个高速缓存之间的一致性。BIU 522可以被配置为管理处理器复合体520与设备500的其他元件之间的通信。诸如核心526的处理器核心可被配置为执行特定指令集架构(ISA)的指令，该指令可包括用于OS 126的操作系统指令和用于应用程序122的用户应用指令。这些指令可存储在计算机可读介质，诸如耦接到下面论述的存储器控制器550的存储器中。在一些实施方案中，复合体520对应于CPU 110。

图形单元530可包括一个或多个处理器和/或一个或多个图形处理单元(GPU)。例如，图形单元530可接收面向图形的指令，诸如

显示单元540可被配置为从帧缓冲器读取数据并且提供像素值流以用于显示。在一些实施方案中，显示单元540可被配置为显示流水线。另外，显示单元540可被配置为将多个帧混合以产生输出帧。此外，显示单元540可以包括用于耦接到用户显示器(例如，触摸屏或外部显示器)的一个或多个接口(例如，

高速缓存/存储器控制器550可被配置为管理结构体510与一个或多个高速缓存和/或存储器之间的数据传输。例如，高速缓存/存储器控制器550可耦接到L3高速缓存，该L3高速缓存继而可耦接到系统存储器。在其他实施方案中，高速缓存/存储器控制器550可直接耦接到存储器。在一些实施方案中，高速缓存/存储器控制器550可包括一个或多个内部高速缓存。耦接到存储器550的存储器可以是任何类型的易失性存储器，诸如动态随机存取存储器(DRAM)、同步DRAM(SDRAM)、双数据速率(DDR、DDR2、DDR3等)SDRAM(包括SDRAM的移动版本，诸如mDDR3等，或SDRAM的低功率版本，诸如LPDDR4等)、RAMBUS DRAM(RDRAM)、静态RAM(SRAM)等。一个或多个存储器设备可以耦接到电路板上以形成存储器模块，诸如单列直插存储器模块(SIMM)、双列直插存储器模块(DIMM)等。另选地，设备可以与集成电路在芯片堆叠(chip-on-chip)结构、封装堆叠(package-on-package)结构或者多芯片模块结构中安装。耦接到控制器550的存储器可以是任何类型的非易失性存储器，诸如NAND闪存存储器、NOR闪存存储器、纳米RAM(NRAM),、磁阻RAM(MRAM)、相变RAM(PRAM)、赛道存储器、忆阻器存储器等。如上所述，该存储器可存储可由处理器复合体520执行的程序指令，以使设备500执行本文描述的功能。

I/O桥接部560可以包括被配置为实现例如通用串行总线(USB)通信、安全性、音频和/或低功率始终接通功能的各种元件。I/O桥接部560还可以包括例如脉冲宽度调制(PWM)、通用输入/输出(GPIO)、串行外围接口(SPI)和/或内部集成电路(I2C)的接口。可将各种类型的外围设备和设备经由I/O桥接部560耦接到设备500。例如，这些设备可包括各种类型的无线通信(例如，wifi、蓝牙、蜂窝、全球定位系统等)、附加存储装置(例如，RAM存储装置、固态存储装置或磁盘存储装置)、用户接口设备(例如，键盘、麦克风、扬声器等)等。

***

尽管上文已经描述了具体实施方案，但这些实施方案并非要限制本公开的范围，即使仅相对于特定特征描述单个实施方案的情况下也是如此。本公开中提供的特征示例意在进行例示，而非限制，除非做出不同表述。上述说明书意在涵盖此类替代形式、修改形式和等价形式，这对知晓本公开有效效果的本领域技术人员将是显而易见的。

本公开的范围包括本文(明确或暗示)公开的任意特征或特征的组合或其任意概括，而无论其是否减轻本文解决的任何或所有问题。因此，在本专利申请(或要求享有其优先权的专利申请)进行期间可针对特征的任何此类组合作出新的权利要求。具体地，参考所附权利要求书，可将从属权利要求的特征与独立权利要求的特征进行组合，并可通过任何适当的方式而不是仅通过所附权利要求书中所列举的特定组合来组合来自相应独立权利要求的特征。

本文所述的各种实施方案可采集和/或使用得自具体和合法来源的数据，以改善向用户递送其可能感兴趣的启发内容或任何其他内容。本公开设想，在一些实例中，该所采集的数据可包括唯一地识别或可用于识别具体人员的个人信息数据。此类个人信息数据可包括人口统计数据、基于位置的数据、在线标识符、电话号码、电子邮件地址、家庭地址、与用户的健康或健身级别相关的数据或记录(例如，生命特征测量、药物信息、锻炼信息)、出生日期或任何其他个人信息。

本公开认识到在本发明技术中使用此类个人信息数据可用于使用户受益。例如，个人信息数据可用于递送用户根据其偏好可能较感兴趣的目标内容。因此，使用此类个人信息数据使得用户能够对所递送的内容具有更大的控制。此外，本公开还预期个人信息数据有益于用户的其他用途。例如，健康和健身数据可根据用户的偏好来使用以提供对其总体健康状况的见解，或者可用作对使用技术来追求健康目标的个体的积极反馈。

本公开设想负责收集、分析、公开、传输、存储或其他使用此类个人信息数据的实体将遵守既定的隐私政策和/或隐私实践。具体地，将期望此类实体实现和一贯地应用一般公认为满足或超过维护用户隐私的行业或政府所要求的隐私实践。关于使用个人数据的此类信息应当被突出地并能够被用户方便地访问，并应当随数据的收集和/或使用变化而被更新。用户的个人信息应被收集仅用于合法使用。另外，此类收集/共享应仅发生在接收到用户同意或在适用法律中所规定的其他合法根据之后。此外，此类实体应考虑采取任何必要步骤，保卫和保障对此类个人信息数据的访问，并确保有权访问个人信息数据的其他人遵守其隐私政策和流程。另外，这种实体可使其本身经受第三方评估以证明其遵守广泛接受的隐私政策和实践。此外，应针对被收集和/或访问的特定类型的个人信息数据调整政策和实践，并使其适用于适用法律和标准，包括可用于施加较高标准的辖区专有的具体考虑因素。例如，在美国，对某些健康数据的收集或获取可能受联邦和/或州法律的管辖，诸如健康保险流通和责任法案(HIPAA)；而其他国家的健康数据可能受到其他法规和政策的约束并应相应处理。

不管前述情况如何，本公开还预期用户选择性地阻止使用或访问个人信息数据的实施方案。即本公开预期可提供硬件元件和/或软件元件，以防止或阻止对此类个人信息数据的访问。例如，就广告递送服务而言，本发明的技术可被配置为在注册服务期间或之后任何时候允许用户选择“选择加入”或“选择退出”参与对个人信息数据的收集。在另一示例中，用户可以选择不为目标内容递送服务提供情绪相关数据。又如，用户可选择限制情绪相关数据被保持的时间长度，或完全阻止基础情绪状况的开发。除了提供“选择加入”和“选择退出”选项外，本公开设想提供与访问或使用个人信息相关的通知。例如，可在下载应用时向用户通知其个人信息数据将被访问，然后就在个人信息数据被应用访问之前再次提醒用户。

此外，本公开的目的是应管理和处理个人信息数据以最小化无意或未经授权访问或使用的风险。一旦不再需要数据，通过限制数据收集和删除数据可最小化风险。此外，并且当适用时，包括在某些健康相关应用程序中，数据去标识可用于保护用户的隐私。可在适当时通过移除标识符、控制所存储数据的量或特异性(例如，在城市级别而不是在地址级别收集位置数据)、控制数据如何被存储(例如，在用户间汇集数据)和/或其他方法诸如差异化隐私来促进去标识。

因此，虽然本公开可广泛地覆盖使用个人信息数据来实现一个或多个各种所公开的实施方案，但本公开还预期各种实施方案也可在无需访问此类个人信息数据的情况下被实现。即，本发明技术的各种实施方案不会由于缺少此类个人信息数据的全部或一部分而无法正常进行。例如，可基于汇集的非个人信息数据或绝对最低数量的个人信息，诸如仅在用户设备上处理的内容或可用于内容递送服务的其他非个人信息，来选择内容并递送给用户。