凭证转移 【技术领域】
本发明一般地涉及通信网络。更具体地说， 本发明涉及转移凭证 （credential） 。背景技术 个人受信设备允许用户安全地存储和使用其凭证。可以使用诸如受信平台模块 （TPM） 、 移动受信模块 （MTM） 、 JavaCard、 M-Shield 以及其他形状因数之类的受信执行环境 （TrEE） 实现个人受信设备上的凭证。 通常可在许多高端个人计算机和移动电话上提供受信 执行环境。
受信执行环境提供受信、 安全的处理环境， 并可以包括至少一个处理器、 存储器和 代码。例如， 受信执行环境可以包括以下一个或多个特性 ： 加密处理器、 密钥存储、 密钥生 成、 伪随机数生成、 密封存储等。可以在级别 2、 版本 1.2、 修订版 103 的 TPM 主规范中找到 受信执行环境及其特性的实例。
当用户要将凭证从一个设备转移到另一个设备时 （例如， 当用户购买新设备以更 换旧的、 丢失的、 损坏或被盗的设备时） ， 可以使用可移动受信执行环境或嵌入式受信执行 环境进行凭证转移。
当用户的凭证存储在诸如 JavaCard 或 SIM 卡之类的可移动受信执行环境中时， 从 用户的角度来看凭证转移是直观的， 例如用户可以简单地从旧设备移除可移动受信执行环 境并将该受信执行环境插入新设备中。但即使在这种情况下， 转移也可能因为不同的形状 因数而受阻， 例如旧的和新的设备可能使用不同大小的卡。
另一方面， 在嵌入式受信执行环境中处理凭证并不是直观的。 尽管不够直观， 但与 可移动受信执行环境相比时， 在某些实施方式中使用嵌入式受信执行环境具有一个或多个 特性。例如， 嵌入式受信执行环境存在于从移动电话到膝上型计算机的各种设备。此外， 可移动受信执行环境通常由设备发行方控制 （例如， 在 SIM 卡的情况下， 移动电话服务提供 商 / 运营商提供 SIM 卡） ， 因此由于发行方强加的限制 （例如， 运营商可能不同意将银行应用 加载到其所发行的卡中） ， 可能始终无法针对第三方凭证授予使用可移动受信执行环境。此 外， 嵌入式受信执行环境更具成本效益， 特别是对于低端、 畅销的设备而言。 此外， 嵌入式受 信执行环境可以与设备操作系统 （OS） 紧密集成， 以便可以实现到用户的受信路径。
与可移动受信执行环境中的凭证转移不同， 使用嵌入式受信执行环境转移凭证更 具挑战性。在嵌入式受信执行环境的情况下， 通常从旧设备的受信执行环境中导出凭证并 将其导入新设备的受信执行环境中。 例如， 如果新设备的身份是已知的， 并且可以以经过认 证的方式将新设备的受信执行环境的公钥传送给旧设备， 则凭证转移很容易 （例如， 可以在 旧设备的受信执行环境中加密凭证， 以便仅可在新设备的受信执行环境内解密凭证） 。为使 此方法有效地工作， 在旧设备不再可用之前， 应知道新设备的加密密钥 （例如， 如果设备丢 失或被盗而用户去商店购买新设备， 则无法应用此方法） 。
但是， 为何这种简单的凭证转移并非始终可行还有其他原因。首先， 用户可能具 有来自多个凭证供应方的凭证， 并且每个凭证供应方可能具有它自己的凭证迁移相关的策
略。虽然特定凭证供应方可能允许用户直接将凭证从一个设备转移到另一个设备， 但其他 凭证供应方可能不允许凭证转移并需要将凭证重新供应到新设备中。
从可用性的角度来看， 必须重新供应来自多个不同供应方的凭证将存在问题， 因 为每个供应操作都需要针对该特定供应方的域进行用户认证， 使得假设所有凭证供应方使 用例如相同的单点登录认证系统变得很困难并且不切实际。 如果用户具有例如来自多个 （n 个） 不允许凭证转移的供应方的凭证， 则使用新设备因此需要 n 次凭证重新供应以及 n 次用 户认证操作。这样的用户体验远非理想。 发明内容 提供了用于凭证转移的方法和装置， 包括计算机程序产品。 在一个方面中， 提供了 一种方法。所述方法可包括 ： 在第一设备处接收授权令牌 ； 在所述第一设备处确定委托令 牌、 一个或多个凭证和元数据 ； 以及由所述第一设备向第二设备提供所述委托令牌、 所述一 个或多个凭证和所述元数据。
在另一个方面中， 提供了一种方法。所述方法可包括 ： 在代理处接收授权令牌 ； 在 所述代理处响应于所接收的授权令牌而确定委托令牌 ； 以及根据所确定的委托令牌向设备 提供一个或多个凭证。
上述方面和特性可以在系统、 装置、 方法和 / 或制品中实现， 具体取决于所需的配 置。在下面的附图和说明书中给出了在此描述的主题的一个或多个变型的详细信息。从说 明书和附图以及从权利要求中， 在此描述的主题的特性和优点将显而易见。附图说明
在附图中，
图 1A 示出了通信系统的方块图 ；
图 1B 示出了直接在两个设备之间转移凭证的过程 ；
图 2 示出了使用诸如服务器之类的代理来转移凭证的过程 ；
图 3 示出了包括受信执行环境的设备的实例实施方式 ；
图 4 示出了用作凭证转移代理的服务器的一个实例 ；
图 5 示出了两个设备之间的直接凭证转移的另一个过程 ； 以及
图 6 示出了代理辅助凭证转移的另一个过程。
在附图中， 相同的标号用于引用相同或相似的项目。 具体实施方式
在此描述的主题涉及凭证转移， 具体地说， 涉及设备之间的直接凭证转移和代理 辅助凭证转移， 其中例如服务器充当设备之间的凭证转移代理。
在使用设备之间 （或之中） 的直接凭证转移的实施方式中， 旧的和新的设备同时可 供用户使用。在这种情况下， 旧设备可以加密一个或多个凭证 （被允许转移） 以允许直接转 移到新设备的受信执行环境 （TrEE） 。因为一个或多个凭证具有不允许在设备之间直接转 移的策略， 所以生成委托令牌以使新设备能够取回来自原始凭证供应方的任何不可转移凭 证， 而不需要用户向每个原始凭证供应方进行重新认证。安全地存储在代理处的委托令牌代表用户对代理授权。具体地说， 委托代表用户授权向新设备启动重新供应。这使得凭证 发行方能够知道向哪个新设备发行凭证， 而代理不存储或处理凭证。
在使用代理辅助凭证转移的实施方式中， 旧设备为代理 （例如， 服务器） 创建可转 移凭证的备份， 并将凭证重新供应委托给服务器。 当新设备可用时， 用户通过口令或其他适 合的认证机制对新设备进行认证。服务器然后将可转移凭证推送到新设备， 并使用委托令 牌将不可转移凭证从原始供应方取回到新设备。在此代理辅助方案中， 一旦旧设备为服务 器创建可转移凭证的备份， 则不再需要旧设备。这样， 如果旧设备丢失、 被盗、 损坏和 / 或不 可用， 则凭证转移仍可继续， 因为充当代理的服务器将凭证推送到新设备。 向每个凭证附加 某些元信息， 所述元信息例如标识凭证可以在服务器上备份还是必须重新发行。如果是后 一种情况， 则还在元数据中包括某些重新发行联系地址 （例如， URL） 。
在设备中包括嵌入式 TrEE 的某些实施方式中， TrEE 为设备提供安全存储和统计 学上唯一的非对称密钥。密钥的公共部分通常由受信机构 （例如设备制造商） 证明为属于有 效的 TrEE。密钥的私有部分 （即， 私钥） 被设计为从不离开 TrEE。此外， TrEE 通常具有仅可 在 TrEE 内部访问的设备特定的对称密钥。TrEE 还可以包括用于安全执行的易失性安全存 储器， 但此存储通常不是永久性安全存储器。此类 TrEE 的实例包括 M-Shield （可从德州仪 器购买） ， 然而也可以使用其他受信执行环境。
如所指出的， 在此描述的主题可以提供在凭证转移中充当代理的服务器。服务器 具备嵌入式 TrEE， 为设备特定的非对称密钥提供安全存储。密钥的公共部分通常由受信 机构证明， 并且此证明的信任根通常以可靠的方式 （例如， 在设备制造期间） 安装到设备的 TrEE 中。密钥的私有部分被设计为从不离开服务器的 TrEE。
在提供直接凭证转移和代理辅助转移的详细实例之前， 下面提供了其中可以实现 凭证转移的实例网络环境， 然而也可以在其他有线和 / 或无线网络中使用在此描述的凭证 转移机制。
图 1A 是无线通信系统 100 的简化功能方块图。尽管示出无线通信系统 100， 但可 以使用任何其他类型的有线和 / 或无线网络作为凭证转移的通信机制 （例如， 因特网） 。图 1A 的无线通信系统 100 作为示例性实例提供。通信系统 100 包括支持对应服务或覆盖区 域 112（也称为小区） 的基站 192。基站 192 能够与其覆盖区域中的无线设备 （例如用户设 备 114A-B） 通信。尽管图 1A 示出了一个基站 192、 小区 112 和用户设备 114A-B， 但无线通 信网络 100 也可以包括其他数量的基站、 小区和用户设备。此外， 无线通信系统 100 也可以 包括 （或耦合到） 其他网络， 包括因特网、 内联网、 公共交换电话网络、 无线局域网以及任何 其他网络 （多个） 。
在 某 些 实 施 方 式 中， 基 站 192 包 括 演 进 节 点 B（eNB）型 基 站 或 家 庭 （e）基 站， 其 符 合 以 下 标 准， 包括长期演进 （LTE）标 准， 例 如 3GPP TS36.201“Evolved Universal Terrestrial Radio Access(E-UTRA);Long TermEvolution(LTE)physical layer;General description” （演 进 型 通 用 陆 地 无 线 接 入 （E-UTRA） ； 长期演进 （LTE） 物 理 层 ；一 般 说 明） 、 3GPP TS 36.211“Evolved Universal Terrestrial Radio Access(E-UTRA);Physicalchannels and modulation” （演 进 型 通 用 陆 地 无 线 接 入 （E-UTRA） ； 物 理 信 道 和 调 制） 、 3GPP TS 36.212“Evolved Universal Terrestrial Ra dioAccess(E-UTRA);Multiplexing and channel coding” （演 进 型 通 用 陆 地 无 线 接 入（E-UTRA） ； 多 路 复 用 和 信 道 编 码） 、 3GPP TS 36.213“EvolvedUniversal Terrestrial Radio Access(E-UTRA);Physical layer procedure” （演 进 型 通 用 陆 地 无 线 接 入 （E-UTRA） ； 物 理 层 过 程） 、 3GPP TS 36.214“Evolved Universal Terrestrial Radio Access(E-UTRA);Physical layer-Measurement” （演进型通用陆地无线接入 （E-UTRA） ； 物 理层 – 测量） ， 以及对这些和其他 3GPP 系列标准 （统称为 LTE/EPS 或 SAE 标准） 的任何后续 添加或修订。
尽管图 1A 示出了基站 192 的配置的一个实例， 但基站 192 可以以其他方式 （包括 例如中继站、 蜂窝基站收发器子系统、 网关、 接入点、 射频 （RF） 中继器、 帧中继器、 节点） 配 置， 并且还包括到其他网络的接入。例如， 基站 192 可以具有到其他网络单元 （例如其他基 站、 无线电网络控制器、 核心网络、 服务网关、 移动管理实体、 服务 GPRS （通用分组无线业务） 支持节点、 网络管理系统等） 的有线和 / 或无线回程链路。
在某些实施方式中， 无线通信系统 100 包括接入链路， 例如链路 122A-B。 接入链路 122A-B 包括用于传输到用户设备 114A-B 的下行链路 116A-B 和用于从用户设备 114A-B 传 输到基站 192 的上行链路 126A-B， 然而在某些实施方式中， 用户设备来回之间的链路也可 以是有线的和 / 或以其他方式实现 （例如， WiFi、 蓝牙等） 。 用户设备 114A-B 可以实现为移动设备和 / 或固定设备。用户设备 114A-B 通常例 如称为移动站、 移动单元、 用户站、 无线终端等。 用户设备可以例如实施为无线手持设备、 无 线插入式附件等。 在某些情况下， 用户设备可以包括处理器、 计算机可读存储介质 （例如， 存 储器、 存储装置等） 、 无线接入机制、 用户接口和 / 或受信执行环境。
图 1B 示出了包括用于直接在设备之间转移凭证的过程和组件的图。图 1B 包括供 应方 105、 第一设备 107 和第二设备 110。第一设备 107 可以包括从其中转移凭证的旧设备 106A 以及旧受信执行环境 （标记为 TrEE） 106B。第二设备 110 可以包括新设备 112A 和新受 信执行环境 （标记为 TrEE） 112B。供应方 105、 第一设备 107 和第二设备 110 可以通过任何 通信信道耦合， 所述通信信道包括因特网、 内联网、 公共交换电话网络、 公共陆地移动网络 以及包括针对图 1A 描述的通信系统的任何其他通信机制 （多种） 。
供应方 105 可以实现为被配置为向设备提供凭证的至少一个处理器和至少一个 存储器。在某些实施方式中， 供应方 105 可以与无线网络的服务提供商关联， 并且可以包括 为家庭用户服务和 / 或授权、 认证和审计服务器的一部分， 然而供应方 105 相反可以位于其 他位置并且可以不与服务提供商 / 网络运营商关联。此外， 尽管图 1B 示出了一个供应方 105， 但也可以实现多个供应方。
此外， 在某些实施方式中， 供应方 105 可以提供凭证， 其具有允许直接在设备之间 转移凭证而不需要在供应方 105 处重新认证的策略。在其他情况下， 供应方 105 可以提供 凭证， 其具有不允许直接在设备之间转移凭证从而需要在供应方 105 处重新认证 （以及重 新供应） 的策略。
供应方 105 提供的凭证可以包括用于验证设备 （多个） 用户的身份的任何信息。凭 证的一个实例是 X.509 证书。例如， 凭证可以包括以下一个或多个项 ： 口令、 数字证书 （例 如， 将公钥与身份绑定在一起的数字签名） 、 一次性令牌、 电话号码等。
第一设备 107 和第二设备 110 均可实现为至少一个处理器、 至少一个存储器、 代码 和 TrEE。在某些实施方式中， 所述第一设备和 / 或所述第二设备均可包括如在此描述的用
户设备。 图 1B 包括用于第一和第二设备 107 和 110 之间的直接凭证转移的三个总体阶段。 这三个阶段是其间用户初始化凭证平台以便凭证转移的初始化 150A、 其间用户从多个供应 方获得凭证的供应 160A， 以及其间将凭证转移或重新供应到新设备 110 的转移和重新供应 170A。
在 150B， 要求旧设备 106A 的用户进行认证。认证的形式可以为请求来自旧设备 106A 的用户的口令 （标记为 Pwd） 。例如， 当第一次使用旧设备 106A 时， 可要求用户定义用 于凭证转移的转移口令。使用词组 “旧设备” 指从其中转移凭证的设备， 词组 “新设备” 指 向其提供凭证的设备。
在 150C， 将转移口令加载到 TrEE 106B 中并使用设备特定的对称密钥 K0（仅可在 TrEE 106B 内部访问） 将其密封在本地。术语 “密封” 指使用 TrEE 中的密钥加密转移口令。 然后将加密后的口令发送到旧设备 106A， 以便在 150D， 将得到的密封后的转移口令永久地 存储在设备 106A 的操作系统文件系统中。因此， 使用转移口令有助于确保凭证转移仅被转 移到正确的新设备， 例如属于同一用户的新设备。
在某些实施方式中， 在 150B 处设置转移口令需要用户输入。但是， 某些 TrEE 不支 持到设备用户的受信路径以允许在 150B 处的上述交互。在这种情况下， 应在设备清理完任 何恶意软件时执行初始化 150A ； 否则， 初始化 150A 可能易受恶意软件 （例如， 其可修改或窃 取用户的转移口令） 的攻击。此外， 一旦用户定义了转移口令， 转移口令 Pwd 即可被固定以 避免因恶意软件攻击而修改。因为 TrEE 106B 通常没有永久性安全存储器， 所以转移口令 不会直接存储在 TrEE 106B 内。相反， 如上面所指出那样， 将密封后的转移口令存储在旧设 备 106A 处。此外， 可以在设备上安装任何凭证之前定义转移口令， 因此允许将转移口令绑 定到设备上安装的每个凭证。
下一个阶段是供应 160A。凭证供应通常始于在 160B 处的用户认证。每个凭证供 应方 （例如， 供应方 105） 可以具有它自己的用户认证机制， 从而定义如何执行用户认证。
在任何情况下， 在 160B 处的用户供应认证通常均绑定到所使用的供应协议 （例 如， 通过使用基于传输层安全性 （TLS） 的连接） 。在图 1B 的实例中， 旧设备 106A 在 160C 处 提供其 TrEE 106B 的证书 （例如， 数字证书 CertO） 和密钥 （例如， 公钥 PKO） 。
在 160E， 供应方 105 验证数字证书 CertO， 然后存储旧设备 106A 的用户身份与公 钥 PKO 之间的映射。供应方 105 然后使用旧设备 106A 的公钥 PKO 加密 （在图 1B 中标记为 “Enc” ） 凭证 Cred。
在 160D， 供应方 105 然后通过发送一个或多个已在 160E 处加密的已供应凭证 （例 如已供应的凭证 PC） 来响应旧设备 106A。在 160F， 旧设备 106A 将加密后的已供应凭证 （多 个） PC 和密封后的转移口令 SP 转发到 TrEE 106B。
不同的凭证平台可以使用不同的凭证安装机制， 并且凭证安装的详细信息与凭证 转移无关， 除了在 106G 将转移口令绑定到已安装的凭证以外。这例如通过将所供应的凭证 PC 连同密封后的转移口令 SP 一起导入 TrEE106B 中来完成。在 TrEE 106B 内部， 可以使用 密钥对的私有部分解密凭证并使用设备特定的对称密钥 KO 在本地密封凭证。可以通过将 密封后的口令的散列与密封后的凭证包括在一起而将本地密封后的凭证 SC 绑定到转移口 令。可以在 160H 发送密封后的凭证以允许在 160I 存储在旧设备 106A 的操作系统侧。
每个凭证可以包括诸如密钥 （例如， 加密密钥） 之类的机密数据和关联的元数据 （例如凭证类型） 。例如， 凭证元数据可以指示凭证可转移还是不可转移。在不可转移凭证 的情况下， 在凭证的元数据中还包括重新供应标识符， 例如统一资源定位器 （URL） 。URL 标 识不可转移凭证的供应方以允许使用委托令牌获得凭证 （如下面所描述） 。
尽管图 1B 在 160A-I 示出了供应协议方案的一个实例， 但也可以使用其他凭证供 应协议。
下一个阶段 170A 包括转移和重新供应。
为了将凭证从第一设备 107 转移到第二设备 110， 用户可以在 170B-C 在设备 107 和 110 两者中触发凭证转移操作。此外， 设备 107 和 110 可以包括无线连接， 例如短距离无 线连接 （例如， 蓝牙等） ， 以允许在 170D 设备 107 和 110 相互发现。
在 170E， 一旦在两个设备 107 和 110 之间建立连接， 旧设备 106A 随即将旧设备 106A 的公钥 PKO 和旧设备 106A 的证书 CertO 发送到新设备 112A。
在 170F， 新设备 112A 验证证书并要求设备 107 和 110 的用户提供转移口令。
此外， 新设备 112A 在 170F 创建授权令牌 （标记为 AT） 。认证令牌包括基于散列的 消息认证代码 （HMAC） ， 其通过新设备 112A 的公钥 PKN 和转移口令 Pwd 来计算。然后使用旧 设备 106A 的公钥 PKO 加密得到的 HMAC， 以便例如防止因可能较短的口令长度而由能够窃听 网络通信的攻击者发起的暴力攻击。 在某些实施方式中， 当新设备清理完任何恶意软件 （可 能篡改或窃取转移口令） 时， 可以以可信的方式从用户获得转移口令。
在 170G， 新设备 112A 将新设备 112A 的授权令牌 （标记为 AT） 、 公钥 （PKN） 和新设备 112A 的证书 （CertN） 发送到旧设备 106A。
在 170H， 旧设备 106A 将在 170G 收到的项目以及密封后的口令 SP 和密封后的凭证 SC 加载并密封到 TrEE 106B 中。
在 170I， TrEE 106B 验证新设备的证书 CertN、 认证令牌 AT 和密封后的口令 （SP） 。 然后， 解密所有在本地密封的凭证。根据所加载的转移口令验证在密封后的凭证内绑定的 转移口令， 以确保转移口令在凭证安装之后未被更改。 可以通过以下方式完成验证 ： 比较所 接收和所存储的机密信息的散列、 或者在纯文本存储的情况下或在公钥加密的情况下直接 比较值、 向所接收的消息应用加密密钥并验证计算提供预期结果。 针对新设备 112A， 使用旧 设备 106A 的公钥加密每一个可转移凭证 （包括可以从凭证元数据确定的凭证类型） 。对于 每个不可转移凭证， 从凭证元数据提取重新供应 URL 以标识不允许在设备之间直接转移凭 证的供应方的位置。
此外， 在 170I， 旧设备 106A 和 / 或 TrEE 106B 为新设备 112A 创建委托令牌 （标记 为 DT） 。委托令牌 DT 包括使用旧设备 106A 的私钥 SKO 通过新设备 112A 的公钥 PKN 计算签 名 （例如， 数字签名） 。
在 170I， 如果凭证 Cred 相对较大， 则可以使用混合加密， 例如供应方 105 首先创建 新的对称密钥 k， 使用公钥加密来加密 k， 然后使用对称认证加密模式通过对称密钥 k 来加 密实际凭证。
在 170J， 旧 TrEE 106B 将委托令牌 DT、 一个或多个密封后的凭证 PCALL 以及诸如统 一资源定位器 （URL） （标识不允许直接在设备之间转移凭证的供应方） 之类的任何元数据发 送到旧设备 106A。在 170K， 旧设备 106A 将其公钥 PKO、 所有加密后的可转移凭证 PCALL、 委托令牌 DT 以 及重新供应 URL 的列表发送到新设备 112A。在 170L， 新设备 112A 然后可以将可转移凭证 安装到其凭证平台 （例如 TrEE112B） 中。
在 170M， 新设备 112A 然后可以使用所接收的 URL 列表联系每个不可转移凭证的供 应方 105（以及其他供应方） 。在 170O， 所联系的供应方可以验证新设备 112A 的证书 CertN 和委托令牌 DT。一旦被验证， 供应方就可以根据旧设备 106A 的公钥 PKO 标识凭证 （多个） 。 在 170N-O， 密封 （例如， 加密） 所标识的凭证并将其发送到新设备 112A 以便在新 TrEE112B 处安装。因此， 将凭证发送到新设备 112 而无需用户提供认证。
上一节中描述的委托式凭证重新供应方案基于旧的和新的设备 107 和 110 均可同 时供用户使用的假设。但是， 可能不会始终是这种情况。例如， 用户可能丢弃、 遗失、 损坏旧 设备等， 从而获得新设备。 在这些情况下， 无法直接执行凭证转移过程， 而是要包括代理。 通 常在新设备可用之前以及在旧设备知道新设备的身份之前， 启动使用代理 （例如， 服务器） 转移凭证的过程。
图 2 示出了使用代理辅助凭证转移过程的图。 图 2 包括第一和第二设备 107 和 110 以及代理 205。代理 205 可以实现为处理器 （例如， 包括存储器的计算机） 。此外， 代理 205 可以包括服务器 207A 和 TrEE 207B。设备 107、 110 和 205 可以通过任何通信信道耦合， 所 述通信信道包括因特网、 内联网、 公共交换电话网络、 公共陆地移动网络以及诸如针对图 1A 描述的通信系统之类的任何其他通信机制。
在某些实施方式中， 代理 （例如， 设备 205） 可以例如位于因特网 （其可以由通信系 统 100 访问和 / 或耦合到通信系统 100） 。代理可以由用户设备 （例如， 设备 110） 以多种 方式访问。但是， 在某些实施方式中， 诸如移动电话之类的用户设备按如下方式访问代理。 用户设备通过有线和 / 或无线连接 （例如， 蓝牙） 访问网络接入点， 然后使用诸如 HTTPS 或 IPSEC 之类的安全协议连接到代理。可以以各种方式实现将凭证从供应方重新发行到代理 或设备， 所述方式例如包括通过短消息服务 （SMS） 、 无线接入协议 （WAP） 推送、 通用引导架 构 （GBA） 推送和 / 或开放移动联盟 （OMA） 设备管理推送。可以使用 HTTP URL（可以从中 取回凭证） 发送 （例如， 推送） 凭证。此外， 供应方可以按照 3GPP TR 33.812“Feasibility study onthe security aspects of remote provisioning and change of subscription forMachine to Machine(M2M)equipment （关于机器对机器 （M2M） 设备的远程供应和预订更 改的安全方面的可行性研究） ” 发送凭证。
图 2 的代理辅助凭证转移可以包括与上面描述的初始化 150A 和供应 160A 类似的 凭证转移初始化和供应。但是， 代理辅助 （在此也称为服务器辅助） 凭证转移还可以包括备 份和委托阶段 250A（例如， 从旧设备提供凭证备份和委托） 以及恢复阶段 260A（例如， 提供 从服务器到新设备的凭证恢复） 。
在 250B， 当用户从第一设备 107（包括旧设备 106A 和 TrEE 106B） 触发凭证转移 时， 凭证转移过程可以开始。旧设备 106A 连接到服务器 207A， 并在 250C 向服务器 207A 标 识旧设备 106A 的用户。此用户标识可以例如基于运行服务器 207A 的服务提供商使用的单 点登录系统。 因此， 凭证转移的安全性并不依赖于此用户认证， 因为它仅用于将存储在服务 器 207A 处的凭证映射到正确的用户。
在 250D， 一旦标识了用户， 服务器 207A 随即将服务器 207 的公钥 PKs 和证书 Certs发送到旧设备 106A。
在 250E， 旧设备 106A 将服务器 207A 的公钥 PKs、 服务器 207A 的证书 Certs、 密封 后的转移口令 SP 以及一个或多个密封后的凭证 SCALL 加载到 TrEE 106B 中。
在 250F， 旧设备 106A 和 / 或旧 TrEE 106B 验证服务器证书 Certs， 并通过使用旧 设备 106A 的密钥 SKo 对服务器 207A 的公钥 PKs 进行数字签名来为服务器 207A 创建委托 令牌 DTs。旧设备 106A 和 / 或旧 TrEE 106B 还解密密封后的转移口令， 并通过使用服务器 的公钥 PKs 加密转移口令 Pwd 来创建授权验证器 AV。然后如在此针对直接凭证转移描述的 那样处理每个密封后的凭证， 例如， 针对每个凭证检查转移口令、 针对服务器加密可转移凭 证， 并针对不可转移凭证提取重新供应 URL 以允许定位不允许设备之间的直接凭证转移的 供应方。
在 205G， 旧 TrEE 106B 将服务器 207A 的授权验证器 AV、 委托令牌 DTs、 重新供应 URL 和所供应的凭证 PC 发送到旧设备 106A。
在 250H， 旧设备 106A 将其公钥 PKO、 服务器 207A 的授权验证器 AV、 委托令牌 DTs、 加 密后的可转移凭证 PC 以及重新供应 URL 列表发送到服务器 207A， 服务器 207A 然后在 250I 为转移凭证的用户存储这些信息。 下一个阶段 260A 涉及将凭证恢复到新设备 （例如设备 110） 。
在 260B， 用户从新设备 112A 触发凭证恢复 （导致建立到服务器 207A 的连接） ， 并在 260C 以与针对 250C 描述的上一个阶段类似的方式标识用户。
在 260D， 服务器 207A 将服务器 207A 的公钥 PKs 和服务器 207A 的证书 Certs 发送 到新设备 112A。
在 260E， 新设备 112A 验证服务器 207A 的证书 Certs 并要求新设备 112A 的用户提 供转移口令。新设备 112A 和 / 或新 TrEE 112B 还创建授权令牌 AT。在 260E 创建的授权 令牌 AT 类似于在针对图 1B 描述的直接转移过程中使用的授权令牌。为了避免对转移的攻 击， 新设备 112A 可以处于其中它不受可能危及转移口令的恶意软件的感染的状况下。
在 260F， 新设备 112A 将新设备 112A 的公钥 PKN、 新设备 112A 的证书 CertN 和授权 令牌 AT 发送到服务器 207A。
在 206H， 服务器 207 针对实施凭证转移的用户 （例如， 通过用户名标识） 查找授权 验证器 AV 以及一个或多个凭证 PCALL。
在 260I， 服务器 207A 将以下一个或多个项目发送到或加载到 TrEE207B 中 ： 授权 验证器 AV、 授权令牌 AT、 新设备 112A 的公钥 PKN、 新设备 112A 的证书 CertN 以及一个或多 个凭证 PCALL。
在 260J， TrEE 207B 验证新设备 112A 的证书 CertN， 并检查已使用与授权验证器 AV 相同的转移口令创建了授权令牌 AT。 如果是这种情况， 则服务器 207A 通过使用服务器 207A 的密钥 SKs 对新设备 112A 的公钥 PKN 进行签名来为新设备 112A 创建委托令牌 DT。TrEE 207B 还为新设备 112A 加密一个或多个可转移凭证 PCi。
在 260K， TrEE 207B 将委托令牌 DTN 发送到服务器 207A。
在 260L， 服务器 207A 将一个或多个凭证 PCALL 发送到新设备 112A， 以便可以在 260M 将凭证 PCALL 安装在 TrEE 112B 上。
在 260N， 服务器 207A 可以连接到一个或多个凭证供应方， 例如供应方 105。 服务器
207A 然后将以下一个或多个项目发送到供应方 （例如， 供应方 105） ： 旧设备的公钥 PKO（用 于查找正确的用户凭证） ； 服务器 207A 的公钥 PKs ； 服务器 207A 的证书 Certs ； 服务器 207A 的委托令牌 DTs ； 新设备 112A 的公钥 PKN ； 新设备 112A 的证书 CertN ； 以及新设备 112A 的委 托令牌 DTN。
在 260Z， 供应方 105 验证旧设备 106A 已委托服务器 207A， 然后验证服务器 207A 已委托新设备 112A。如果是这种情况， 则供应方 105 然后可以为新设备 112A 加密凭证 PC。 在 260O-Q， 将加密后的凭证 PC 返回到服务器 207A， 服务器 207A 将其转发到新设备 112A， 在 新设备 112A 中可以将其安装到 TrEE 112B。
图 3 示出了可以用作旧设备 107 和 / 或新设备 110 的示例性设备 300。 在设备 107 和 110 实现为用户设备的实施方式中， 设备 300 可以包括天线 320 和诸如 TrEE 350 之类的 受信平台， 然而设备 300 可能不包括天线而是包括有线网络接口 （例如处理器， 例如具有网 络接口的计算机， 例如 WiFi 或蓝牙、 到因特网或其他网络的连接） 。在设备包括天线 320 的 情况下， 设备 300 还可以包括无线电接口 340， 其可以包括诸如滤波器、 转换器 （例如， 数模 转换器等） 、 符号解映射器 （symbol demapper） 、 快速傅里叶逆变换 （IFFT） 模块之类的其他 组件， 以便处理由下行链路或上行链路承载的符号 （例如， OFDMA 符号） 。 在某些实施方式中， 用户设备还可以与 IEEE 802.16、 LTE、 LTE-Advanced 等兼容。设备 300 还可以包括处理器 330， 其用于控制用户设备并用于访问和执行存储在存储器 335（其配置处理器以便如上面 针对图 1B、 2、 5 和 6 描述的那样执行操作） 中的程序代码。 图 4 示出了可以在服务器 205 处实现的示例性服务器 400。服务器 400 可以包括 网络接口 440， 其用于耦合到无线 （例如， 根据诸如 IEEE 802.16、 LTE、 LTE-Advanced 之类的 标准） 和 / 或有线网络。服务器 400 还包括处理器 430， 其用于如上面针对图 1B、 2、 5和6 描述的那样控制服务器并用于访问和执行存储在存储器 435（其配置处理器以便如上面针 对图 1B、 2、 5 和 6 描述的那样执行操作） 中的程序代码。
图 5 示出了两个设备之间的直接凭证转移的另一个过程。参考图 5， 在 592， 第一 设备 （例如旧设备 107） 从另一个设备 （例如新设备 110） 至少接收认证令牌。在某些实施方 式中， 旧设备 107 还可以接收其他信息 （例如， 上面针对 170G 描述的信息） 。
在 594， 旧设备响应于所接收的认证令牌而确定委托令牌。旧设备还可以确定其 他信息， 包括检索凭证和元数据， 所述元数据表示必须直接联系以获得凭证的凭证供应方 的位置 （例如， 在不与供应方进行重新认证时无法在设备之间转移的不可转移凭证的情况 下） 。在某些实施方式中， 旧设备 107 还可以确定其他信息 （例如， 上面针对 170I 描述的信 息） 。
在 596， 旧设备向新设备至少提供委托令牌、 一个或多个所供应的凭证和元数据。 在某些实施方式中， 旧设备 107 可以如上面在 170K 所述的那样提供此信息。
图 6 示出了两个设备之间的代理辅助凭证转移的另一个过程。参考图 6， 在 692， 诸如服务器 205（充当代理） 之类的第一设备从另一个设备 （例如设备 110） 至少接收认证 令牌。在某些实施方式中， 服务器 205 还可以接收其他信息 （例如， 上面针对 260F 描述的信 息） 。
在 694， 服务器 205 响应于所接收的认证令牌而确定委托令牌。 旧设备还可以确定 其他信息， 包括上面针对 260J 描述的信息。
在 696， 服务器 205 根据委托令牌向新设备 112 提供一个或多个所供应的凭证。 在 某些实施方式中， 服务器 205 可以如上面在 260L 所述的那样提供此信息。 此外， 服务器 205 可以向一个或多个供应方提供委托令牌 （以及其他信息） ， 以便如上面在 260N-P 描述的那样 启动不可转移凭证 （例如， 需要在供应方处重新认证的凭证） 的转移。
在此描述的主题可以体现在系统、 装置、 方法和 / 或制品中， 具体取决于所需的配 置。例如， 在此描述的基站和用户设备 （或其中的一个或多个组件） 和 / 或过程可以使用 以下一个或多个项实现 ： 执行程序代码的处理器、 专用集成电路 （ASIC） 、 数字信号处理器 （DSP） 、 嵌入式处理器、 现场可编程门阵列 （FPGA） 和 / 或它们的组合。这些不同的实施方式 可以包括采用可在可编程系统上执行和 / 或解释的一个或多个计算机程序的实施方式， 所 述可编程系统包括至少一个可编程处理器 （可以是专用或通用的， 被耦合以便从存储系统 接收数据和指令并将数据和指令传输到存储系统） 、 至少一个输入设备以及至少一个输出 设备。这些计算机程序 （也称为程序、 软件、 软件应用、 应用、 组件、 程序代码或代码） 包括用 于可编程处理器的机器指令， 并且可以在高级过程和 / 或面向对象的编程语言中实现， 和/ 或在汇编 / 机器语言中实现。如在此使用的， 术语 “机器可读介质” 指任何用于为可编程处 理器提供机器指令和 / 或数据的计算机程序产品、 计算机可读介质、 装置和 / 或设备 （例如， 磁盘、 光盘、 存储器、 可编程逻辑器件 （PLD） ） ， 包括接收机器指令的机器可读介质。类似地， 在此还描述了可以包括处理器和耦合到处理器的存储器的系统。 存储器可以包括一个或多 个程序， 所述程序导致处理器执行在此描述的一个或多个操作。 尽管上面详细描述了几种变型， 但可以进行其他修改或添加。 具体地说， 除了在此 给出的特性和变型之外， 可以提供其他特性和 / 或变型。例如， 上面描述的实施方式可以涉 及公开的特性的各种组合和子组合和 / 或上面公开的若干进一步特性的组合和子组合。此 外， 在附图中示出和 / 或在此描述的逻辑流无需示出的特定顺序或连续顺序即可获得所需 结果。其他实施例可以在以下权利要求的范围之内。