CN115362696A - 用于远程文件管理的离线脚本 - Google Patents

Abstract

本发明涉及用于在安全元件SE处执行远程文件管理RFM操作的方法、设备和系统。在位于SE内的OfflineRFMAgent处从卡外实体OCE接收安全文件更新脚本。安全文件更新脚本已经由管理OCE的SE发行方使用分散式远程文件管理DRFM平台离线生成，并且包括用于在SE上实施文件管理操作的多个远程管理命令。在进一步的步骤中，基于安全文件更新脚本执行OCE和SE之间的安全级别认证。如果安全级别认证成功，则在随后的步骤中，通过OfflineRFMAgent建立OCE和SE之间的安全通道会话。最后，处理多个远程管理命令以远程地管理SE上的文件系统。

Description

用于远程文件管理的离线脚本

技术领域

本发明总体上涉及移动通信，并且具体地涉及用于离线创建用于移动终端的订阅管理的远程文件管理脚本的方法和设备，该移动终端包括安全元件，诸如订户身份模块(SIM)、通用集成电路卡(UICC)等。

背景技术

借助于诸如移动电话的移动终端经由由移动网络运营商(MNO)操作的公共陆地移动网络(PLMN，在本文中也称为移动或蜂窝通信网络)进行通信通常要求移动终端配备有用于安全地存储唯一地标识移动终端的用户(也称为订户)的数据的安全元件(SE)。安全元件基本上是微处理器芯片，其可以存储敏感数据并运行安全应用，诸如支付、交通或电信应用。

在被配置为根据全球移动通信系统(GSM)进行通信的移动终端的上下文中，安全元件被称为订户身份模块(SIM)或通用集成电路卡(UICC)，并且通常以智能卡的形式被提供。如GSM标准中所规定的，SIM包含用于认证和识别移动终端的用户的订户凭证，特别包括国际移动订户身份(IMSI)和认证密钥。在向移动终端的用户提供他的SIM之前，在SIM个性化处理期间，这些订户凭证(IMSI和相关密钥)通常由SIM制造商/供应商或MNO存储在SIM上。订阅凭证用于识别和认证移动终端上的订户以附接到MNO网络。

图1示出了符合ETSI 102 221 V11.0.0智能卡标准规范的SIM/UICC文件系统结构100的示例。文件系统驻留在智能卡的EEPROM中，并且包括作为文件系统的根的主文件(MF)110、多个专用文件(DF)或目录122以及基本文件(EF)121。应用DF(ADF)120是包含应用的所有DF和EF的特定DF。

类似于文件系统，安全元件可以包含安全应用，其可能旨在用于多个用例，诸如建筑物访问控制、运输票务或支付方案。

安全元件的一个特定应用领域是M2M(机器到机器)通信，即在没有人为干预的情况下通过蜂窝通信网络的机器之间的通信。在M2M通信中，数据在配备有M2M模块形式的安全元件的许多不同类型的机器(诸如TV系统、机顶盒、自动售货机、车辆、交通灯、监控摄像机、传感器设备等)之间自动传输。M2M设备可设置有嵌入式通用集成电路卡(eUICC)。eUICC执行与由个人无线设备中的订户身份模块(SIM)卡执行的功能类似的功能。然而，eUICC并不容易移除，因为它被嵌入设备中，例如被焊接到设备的电路板上。

对于这些设备中的一些设备，预先向安全元件提供必要的订阅凭证(包括例如IMSI)，这是不可能的或至少是非常困难的，因为安全元件将很可能以表面安装芯片的形式实现。因此，一旦部署在现场，这些设备及其非个性化安全元件就需要通过空中提供订阅凭证。

通过空中(Over-The-Air，OTA)是允许SE发布者(或SE的所有者)更新或改变SE中的数据而不必重新发行新样本的技术。特别地，OTA技术提供用于更新SIM/UICC/eUICC卡的目录和文件(远程文件管理，RFM)以及用于管理SE上的应用(远程应用管理，RAM)的功能。

全球平台卡技术规范为将在智能卡内实现的卡和/或安全元件发行方建立了全球标准。其中，安全通道协议(SCP)被定义为可以由SE发行方管理的卡外实体(off-cardentity，OCE)与向一个或两个实体提供一定级别的保证的卡(或SE)之间的通信机制。最近在全球平台技术安全通道协议'11'卡规范中引入了一种新的安全通道协议，该安全通道协议被称为安全通道协议'11'(SCP11)，其基于椭圆曲线密码学(ECC)以用于相互认证和安全通道启动。

在GlobalPlatform规范中定义了不同类型的安全通道协议(SCP)，即基于利用对称密码学的认证和基于利用非对称密码学的认证。在第一种情况下，经认证的卡外实体是知道发起安全通道会话所需的秘密安全通道密钥的实体。例如，基于DES的SCP02(被认为是不推荐的)、基于AES的SCP03或者基于DES或AES的SCP80，SCP80是用于OTA操作的最常见SCP之一。在利用非对称密码学进行认证的情况下，可以成功地认证拥有一对非对称密钥并获得由SE认可的机构认证的其公钥的证书的任何卡外实体。遵循这种认证的协议包括例如基于RSA的SCP10，或基于ECC的SCP11。SCP11具有针对不同目的的三种不同变体。SCP11a提供卡外实体(OCE)和卡之间的相互认证。SCP11b仅向OCE提供卡的认证。SCP11c(也称为分散式安全元件管理(DSEM))提供OCE和卡之间的相互认证，仅使用静态密钥来认证卡。

通常，SCP11及其变体旨在用于由GlobalPlatform定义的卡内容管理，诸如在SE上安装新应用、更新应用内容等。所有这些都基于BSI TR-03111“BSI技术指南TR-03111:椭圆曲线密码学”版本2.0中定义的椭圆曲线密钥协商算法(ECKA)。根据规范NIST 800-56A“使用离散对数密码学的成对密钥建立方案的推荐”修订版2，每个变体使用不同的方案。

在当前标准中定义的现有RFM解决方案具有一些约束，这意味着为了构建和设置基于OTA的解决方案的相当大的经济成本。必须提供复杂的密钥管理系统来以安全的方式管理各个SE密钥。作为OTA平台与SE之间的端到端安全通信中涉及的安全通道协议(SCP)的结果，应为每个SE生成单独的OTA脚本。这不仅是因为单独的密钥，而且还因为其他SCP参数，诸如SCP80 OTA计数器，其可能根据SE状态而不同。因此，由SE发行方提供的用于更新SE的脚本是单独的OTA脚本，因为相同的脚本只能由一个单个SE执行一次，并且不能由任何其他SE重复使用。此外，必须建立和部署具有特定保证可用性(例如99.997％)的在线OTA平台以处理多个请求。

因此，期望提供一种解决方案，该解决方案将使SE发行方和/或卡外实体(OCE)能够远程更新SE文件系统而不需要在线OTA平台系统，并且允许SE发行方/OCE向若干SE发送相同的脚本。

发明内容

本发明通过由独立权利要求所涵盖的主题来解决上述目的。本发明的优选实施例在从属权利要求中限定。

根据本发明的第一方面，提供了一种用于由代理OfflineRFMAgent在安全元件SE处执行远程文件管理RFM操作的方法，所述OfflineRFMAgent位于所述SE内。该方法包括在从卡外实体OCE接收安全文件更新脚本的步骤中，该安全文件更新脚本包括用于在安全元件上实施文件管理操作的多个远程管理命令。在进一步的步骤中，基于安全文件更新脚本的安全级别执行OCE与SE的安全级别认证。如果认证成功，则在随后的步骤中建立OCE和SE之间的安全通道会话。最后，处理多个远程管理命令以管理SE上的文件系统。

OfflineRFMAgent是安装在SE中的应用，并且充当OCE(以及相应地管理OCE的SE发行方)与SE文件系统之间的代理，并且允许以安全的方式远程地执行文件管理操作。OTA平台不需要由SE发行方维护，从而降低了用于远程文件管理操作的基础设施的复杂性。由于相同的安全文件脚本可用于在若干安全元件SE处执行文件管理操作，因此为SE发行方提供了用于以快速且有效的方式更新若干SE的方法。

在本发明的一些实施例中，使用安全通道通信协议，特别是基于OCE的一对临时密钥提供相互认证的安全通道通信协议来实施该方法。

优选地，所使用的安全通道通信协议是在全球平台卡技术规范修订F中定义的SCP11c版本。

使用安全通道协议SCP11的SCP11c变体，允许离线脚本使用，即离线创建安全命令序列。

在一些实施例中，OfflineRFMAgent通过来自OCE的多个消息接收安全文件更新脚本，每个消息包括来自多个远程管理命令中的一个命令。

在本发明的一些实施例中，执行安全级别认证包括检查安全文件更新脚本的安全级别是否被设置为已认证。

在本发明的一些实施例中，所述方法还包括：如果安全级别未认证，则拒绝安全文件更新脚本。

这确保了由OfflineRFMAgent保证全球平台卡技术规范中所请求的认证安全级别。特别地，要由OfflineRFMAgent处理的任何脚本应当优选地至少在安全级别被认证的情况下被发送。否则，它将被OfflineRFMAgent拒绝。

在本发明的一些实施例中，安全文件更新脚本至少包括执行安全操作(PERFORMSECURITY OPERATION)命令和相互认证(MUTUAL AUTHENTICATE)命令，其中执行安全操作命令包括OCE证书，并且相互认证命令包括OCE的临时公钥。

本文提供了简化的远程文件管理解决方案，因为OfflineRFMAgent不需要实现完整的SCP11逻辑，而是仅支持主要SCP11c APDU命令(执行安全操作和相互认证)的接收和处理。特别地，执行安全操作命令用于提交OCE证书，其包含OCE的公钥并且用于密钥协商，并且用于确定用于所有后续命令所需的安全级别。这是启动SCP11C安全通道会话的先决条件所需要的。相互认证命令用于通过OfflineRFMAgent将OCE的临时公钥发送到安全域，以触发密钥建立并向OCE提供卡认证信息。

优选地，建立安全通道会话包括由OfflineRFMAgent请求位于安全元件的操作系统OS处的安全域(SD)，以执行用于验证OCE证书的安全操作，并且优选地，还包括请求安全域以从OCE证书中提取公钥，然后在相互认证操作期间，请求SD来执行密钥协商处理。

安全域SD是卡内实体，其为卡外实体的控制、安全和通信要求提供支持。优选地，根据本发明的OfflineRFMAgent被配置为从安全元件SE的对应SD请求这样的支持。

特别地，OfflineRFMAgent将通过Java卡全球平台(Card GlobalPlatform)API将执行安全操作和相互认证命令转发到相关联的安全域，以便处理命令。

在本发明的一些实施例中，安全文件更新脚本还包括选择(SELECT)命令，该选择命令指示用于在所建立的安全通道会话期间在安全元件的文件系统上执行远程管理命令的远程管理应用，并且其中OfflineRFMAagent在不关闭所建立的安全通道会话的情况下处理选择命令。

这防止了在所建立的会话内使用选择命令时通常发生的情况，即关闭会话并因此中断与SE的任何进一步通信。

在本发明的一些实施例中，处理多个远程管理命令包括通过使用文件访问应用编程接口在安全元件上创建和/或更新文件系统的内容。

根据本发明的第二方面，提供了一种位于安全元件SE处的离线远程文件管理RFM代理OfflineRFMAgent。所述OfflineRFMAgent包括用于从卡外实体OCE接收安全文件更新脚本的部件，安全文件更新脚本包括用于在安全元件上实施文件管理操作的多个远程管理命令；用于基于安全文件更新脚本的安全级别来执行OCE与SE的安全级别认证的部件；用于如果安全级别认证成功则在OCE与所述SE之间建立安全通道会话的部件；以及用于通过调用相应的方法来处理多个远程管理命令以管理SE上的文件系统的部件。

在本发明的一些实施例中，OfflineRFMAgent被配置为执行根据第一方面的方法或根据第一方面的任何一个优选实施例的方法。

在本发明的一些实施例中，OfflineRFMAgent包括访问域配置和/或应用提供商标识符，该访问域配置定义用于控制到SE的文件系统的应用实例的至少一个访问域参数，该应用提供商标识符定义OfflineRFMAgent与安全元件之间的所有权关系，其中应用提供商标识符的值对应于在认证处理期间使用的OCE证书中的主体标识符。

这将向OfflineRFMAgent保证对SE上的文件系统的适当访问，以便成功运行。这避免了验证PIN的需要，因为PIN通常是多样化的，并且因此不可能嵌入到DSEM脚本中。

在一些实施例中，OfflineRFMAgent还包括用于限制远程管理命令的集合的执行的部件，特别地，该集合包括验证PIN/PUK、更改PIN/PUK、禁用PIN/PUK、使能PIN/PUK、和解除阻止PIN/PUK。

SCP11c允许生成离线构建的静态脚本，并且这些脚本可以执行若干次是可能的。但是SCP11c不提供前向保密性，因为仅使用OCE临时密钥。包括更新PIN/PUK值的命令的任何脚本将在命令被执行的任何时候连续失败，因为原始PIN/PUK值已经被更新。因此，一些命令被限制在SCP11c会话期间执行。此外，通过利用用于限制远程管理命令的执行的部件来配置OfflineRFMAgent，可以容易地禁用由SCP11c协议的GlobalPlatform卡规范所不允许的诸如PUT KEY或SET STATUS之类的敏感命令。

在本发明的一些实施例中，OfflineRFMAgent还包括定义OfflineRFMAgent与安全元件之间的所有权关系的应用提供商标识符，其中应用提供商标识符的值对应于在认证处理期间使用的OCE证书中的主体标识符。

这确保了必要的安全级别，特别是认证的安全级别，该安全级别由OfflineRFMAgent实现。

根据本发明的第三方面，提供了一种用于离线生成用于多个安全元件SE的安全文件更新脚本的分散式远程文件管理DRFM平台。该平台包括用于存储卡外实体OCE的凭证的存储器和用于生成安全文件更新脚本的处理器。所述处理器被配置为从SE发行方接收文件更新脚本；使用存储在存储器中的凭证来保护文件更新脚本，以获得安全文件更新脚本；以及将所述安全文件更新脚本发送到所述SE发行方。

优选地，对于每个OCE，凭证包括静态OCE密钥对和临时密钥对。

优选地，安全文件更新脚本还包括识别具有相同OCE凭证的多个SE的卡组ID。

DRFM平台提供用于利用目标SE的SCP11c密钥保护由SE发行方提供的脚本内容的部件，然而该部件具有比常规OTA平台简单得多的结构，因为仅使用OCE的两个密钥对。此外，由于保护脚本内容的处理对于由卡组ID标识的所有SE仅进行一次，因此可以将相同的安全文件更新脚本部署到这些SE中的任何一个中。换句话说，在内容对于所有SE都相同的情况下，保护脚本内容的处理将仅发生一次。否则，如果内容对于每个SE是多样化和唯一的，则应该对每个单独的内容重复该处理。以相同的方式，对于在SE个性化期间定义的每个卡组ID，应重复保护脚本内容的处理。

DRFM平台的主要功能是存储和管理DSEM(即SCP11c)凭证和离线脚本准备。两个功能可以由单个实体实施，或者在负责每个功能的不同实体之间拆分。由于DSEM凭证通过多个SE共享，并且特别是由具有相同卡组ID的所有SE共享，因此在这种情况下的密钥管理比由可信服务管理(TSM)执行的传统密钥管理简单得多。此外，使用卡组ID，可以定义应用具体脚本的卡或SE的目标组。这可以具体针对具有不同简档配置的MNO。在这种情况下，DRFM平台允许构建仅适合于由他的卡组ID(根据[GPAmdF])定义的单个简档配置的脚本。同时，支持跨共享相同凭证的所有SE广播脚本的可用性。这在脚本处理方面给出了巨大的灵活性。

DRFM平台可以是基于输入数据和目标SE组生成按需离线脚本的离线平台。一旦脚本由DRFM平台生成，它就可以通过任何方式传递到SE，例如通过互联网传递到智能手机应用，智能手机应用随后将其转发到SE。

具体地，根据本发明的第二方面，安全文件更新脚本可以经由相应的OfflineRFMAgent被递送到目标SE组。特别地，OfflineRFMAgent是安装在SE中的应用，诸如Java Card应用，其逐个命令地接收和处理安全文件更新脚本。

根据本发明的第四方面，提供了一种分散式远程文件管理系统。所述分散式远程文件管理系统包括：安全元件SE发行方；卡外实体OCE；根据本发明的第三方面的分散式远程文件管理DRFM平台；以及至少一个安全元件SE。SE包括根据本发明的第二方面的OfflineRFMAgent。SE发行方被配置成从DRFM平台获得包括多个远程文件管理命令的安全文件更新脚本，并将安全文件更新脚本递送到OCE。所述OCE被配置为通过与所述SE相对应的OfflineRFMAgent向所述至少一个SE提供安全文件更新脚本。OfflineRFMAgent被配置为在OCE和对应的SE之间建立安全通道会话，并且在安全元件处执行根据本发明的第一方面的用于远程文件管理RFM的方法。

必须注意，本申请中描述的所有设备、元件、单元和部件可以以软件或硬件元件或其组合来实现。由本申请中描述的各种实体执行的所有步骤以及所描述的功能旨在表示相应的实体适于或被配置为执行相应的步骤和功能。

在结合附图阅读本发明的优选实施例和变体的以下详细描述时，本发明的其他方面、特征和优点对于本领域普通技术人员将变得显而易见。

附图说明

现在将参照附图，其中：

图1示出了SIM/UICC文件系统结构的示例；

图2示出了OTA管理系统的示例；

图3示出了根据实施例的分散式远程文件管理系统的示例；

图4示出了根据另一实施例的分散式远程文件管理系统的示例；

图5示出了根据实施例的用于执行远程文件管理操作的方法；

图6示出了根据实施例的用于执行远程文件管理操作的方法的序列图。

具体实施方式

下面参照示出本发明的具体实施例示例的附图给出本发明的详细解释。这些实施例被足够详细地描述，以使本领域技术人员能够实践本发明。应当理解，本发明的各种实施例尽管不同，但不一定是相互排斥的。例如，在不脱离本发明的范围的情况下，本文结合一个实施例描述的特定特征、结构或特性可以在其他实施例内实现。另外，应当理解，在不脱离本发明的范围的情况下，可以修改每个公开的实施例内的各个元件的位置或布置。因此，以下详细描述不应被视为具有限制意义，并且本发明的范围仅由适当解释的所附权利要求以及权利要求所赋予的等同物的全部范围来限定。在附图中，相同的附图标记在若干视图中指代相同或相似的功能。

考虑到规范，使用以下缩写和符号：

表1：缩写和符号

考虑到规范，参考以下智能卡的标准：

表2：智能卡的标准

图2示出了常规OTA管理生态系统200的示例。SE发行方210(其可以是电信环境中的MNO)将“文件更新脚本”212提供给OTA平台214。文件更新脚本212包括一组用于更新SE中的具体文件的APDU命令。OTA平台214为特定SE准备单独的“安全文件更新脚本”216。这是通过使用安全地存储在HSM 218中的单独OTA SE密钥来保护如ETSI 102 225(智能卡；用于基于UICC的应用的安全分组结构)和ETSI 102 226(智能卡；用于基于UICC的应用的远程APDU结构)的智能卡标准规范中规定的脚本内容来完成的。最后，“安全文件更新脚本”通过网络220传送到移动设备222的SE 224。SE能够解开脚本，读取和处理其中包含的ADPU命令。

图2所示的RFM处理只能应用于单个SE。在要更新若干不同SE的情况下，在所谓的OTA活动内，SE发行方向OTA平台指示要更新哪些SE，例如，通过使用单独的SE标识符或SE密钥(例如，用于SIM/UICC的ICCID、用于eUICC的EID、用于eSE的SEID)。OTA平台为每个SE准备“安全文件更新脚本”，然后将其传送到相应的SE。换句话说，图2中所描绘的处理必须重复与要更新的SE的数量一样多的次数。

为了实施如上所描述的OTA操作，常规解决方案采用单独的密钥管理系统，这意味着将SE标识符(例如，用于SIM/UICC的ICCID、用于eUICC的EID、或用于eSE的SEID)与HSM密钥标签链接的巨大数据库，以便安全地包裹OTA脚本内容。

为了解决常规的基于OTA的解决方案的上面所指出的缺点，本发明引入了分散式远程文件管理平台、远程文件管理代理和分散式远程文件管理系统，其允许借助于安全通道协议SCP11C的变体以安全的方式远程地执行文件管理操作。

SCP11c(也称为分散式安全元件管理(DSEM))提供OCE和SE之间的相互认证，仅使用静态密钥来认证SE，这使得该协议适合于离线脚本使用。特别地，SCP11C支持用于SE的组的离线脚本创建，因为所有计算可以预先预计算并稍后部署。

SCP11C基于椭圆曲线密钥协商算法(ECKA)。具体地，它基于如[NIST800-56A]规范的第6.2.1.2节中所定义的一遍统一模型C(1e，2s，ECC CDH)方案。遵循NIST推荐，计算的共享秘密不直接用作加密的密钥，而是用作密钥导出处理的输入。该方案使用单个临时密钥对而不是两对。在该方案中仅使用OCE临时密钥对，而来自SE侧的临时密钥对被移除，并且SD ECKA密钥(即，SD的静态密钥对)被使用两次。这允许离线预计算所计算的会话密钥，而不需要知道SE的当前状态。一旦计算了会话密钥，就可以构建利用这些密钥保护和使其安全的任何脚本。

下面参照图3至图6描述分散式远程文件管理系统的示例实施例。

图3示出了根据本发明的实施例的远程文件管理系统的基本操作。

在图3所示的实施例中，SE发行方(例如图2的SE发行方210)将“文件更新脚本”212提供给DRFM平台314。DRFM平台314从如图2所示的常规的基于OTA的解决方案中替换OTA平台214，并且负责利用目标SE 224的SCP11c密钥来保护由SE发行方210提供的脚本内容。作为与常规的基于OTA的方法的主要区别，该处理对于所有SE仅进行一次，因为可以将相同的“安全文件更新脚本”部署到任何SE中。

DRFM平台314执行主要功能，包括DSEM凭证的存储和管理以及离线脚本准备。两个功能可以由DRFM平台的单个实体实施，或者拆分成负责每个功能的不同实体。

SCP11规范[GPAmdF]允许定义应用具体文件更新脚本的SE目标组。这可能是具有不同简档配置的MNO的情况。在这种情况下，将可以构建仅适合于由其卡组ID(根据[GPAmdF])定义的单个简档配置的脚本。同时，跨共享相同凭证的所有SE广播脚本的可用性是可能的。由于DSEM凭证由卡组ID中的所有SE共享，因此在这种情况下的密钥管理与由TSM执行的传统密钥管理一样简单得多。这在脚本处理方面给出了巨大的灵活性。

DRFM平台314可以是基于输入数据(例如，文件更新脚本212)和目标SE组224生成按需离线脚本的离线平台。一旦安全文件更新脚本316由DRFM 314平台生成，就可以通过任何方式将其递送到SE 224，例如通过互联网220递送到智能电话应用222，智能电话应用222之后将其转发到SE224。

图4示出了根据本发明的实施例的远程文件管理系统500。

参照图4，远程文件管理系统500包括SE发行方210、DRFM平台314、卡外实体OCE211，卡外实体OCE 211通过有线或无线通信部件220将安全文件更新脚本316传送到设备222的SE 224。DRFM平台314从SE发行方接收文件更新脚本212并生成安全文件更新脚本316，如上面参照图3所描述的。安全文件更新脚本可以由DRFM平台预先离线生成，即，在更新SES处的文件系统的实际任务之前。

安全文件更新脚本316包括用于对安全元件SE 224实施文件管理操作的多个远程管理命令410。这些命令在位于SE 224内的OfflineRFMAgent 400处逐一被接收。

OfflineRFMAgent 400被包含在SE 224内，并且可以充当SE发行方210与SE 224的文件系统450之间的代理。优选地，OfflineRFMAgent 400是Java Card^TM应用。

安全文件更新脚本316以预设的认证安全级别被发送到SE。GlobalPlatform技术安全通道协议“11”卡规范定义了认证安全级别，并将认证的安全级别分配给由SD所有者实现的认证。可以至少在安全级别被认证的情况下发送要由OfflineRFMAgent处理的任何脚本。否则，它可以被OfflineRFMAgent拒绝。

OfflineRFMAgent 400可以使用如由GlobalPlatform定义的安全通道JavaCard^TMAPI来在OCE设备应用(由SE发行方拥有)和SE之间建立SCP11c会话。安全通道API定义了用于管理实体认证以及保护APDU命令和响应的基本服务。它通常由安全域暴露给其相关联的应用。安全域是卡内(on-card)实体，其为卡外实体的控制、安全和通信要求提供支持。

使用该安全通道接口的实例不需要了解用于执行实体认证并提供APDU命令和响应的完整性和机密性的底层协议、算法和秘密，这仅需要实例的提供者知道。此外，它允许在OfflineRFMAgent的部署中重新使用当前的生态系统和标准。

优选地，OfflineRFMAgent 400不实现完整的SCP11c逻辑，因为它可以被委派到其相关联的安全域中，但是可以至少支持主要SCP11c APDU命令(执行安全操作和相互认证以及适当的接入域配置)的接收。在它们的接收时，OfflineRFMAgent 400可以来回转发传入数据。

除此之外，OfflineRFMAgent 400可以使用由ETSI在[ETSI_102241]中定义的文件视图API，以便能够创建和/或更新文件系统450的内容。

下面将参考示出基本步骤的图5和提供根据优选实施例的实现细节的图6来示出由OfflineRFMAgent 400执行的用于对安全元件SE的文件系统450执行远程文件管理操作的方法。

参照图5，当在第一步骤S10中从OCE 211接收到安全文件更新脚本时，OfflineRFMAgent 400在步骤S20中基于安全文件更新脚本的安全级别来执行OCE 211与SE224的安全级别认证，以用于认证所接收的脚本的所有权。如上文参照图4所描述的，将由OfflineRFMAgent处理的任何脚本由具有经认证的安全级别的OCE发送。以不同安全认证级别发送的任何其他脚本将被OfflineRFMAgent 400拒绝。

优选地，如果SCP11相关操作由OfflineRFMAgent直接管理，则应用提供商标识符应在小应用程序内配置。否则，如果SD负责管理SCP11操作，则应在安装OfflineRFMAgent的安全域中配置应用提供商标识符。

在步骤S30中，如果安全级别认证成功，则OfflineRFMAgent 400在卡外实体OCE211和安全元件SE 224之间建立安全通道会话。

在已经建立安全通道会话之后，OfflineRFMAgent 400在步骤S40中处理包括在安全文件更新脚本内并且从OCE 211逐一接收的多个远程管理命令，以远程地管理安全元件224上的文件系统450。

将参照图6描述步骤S30和S40的优选实现，图6示出了通过在图3和图4的生态系统的各种组件之间传递消息来进行分散式远程文件管理的序列图。

如图6所示，OfflineRFMAgent 400从OCE 211接收包含在安全文件更新脚本316中的多个APDU命令。安全文件更新脚本316可以包括若干APDU命令，包括但不限于选择、执行安全操作和相互认证。在图6所示的实施例中，这些命令由OCE 211逐一发送到OfflineRFMAgent 400，并在它们到达OfflineRFMAgent时被逐一处理。

安全文件更新脚本包括用于指示要在SE处管理(例如，更新、删除)的应用(或文件)的ID(OfflineRFMAgent AID)的选择命令421。

在根据图5中的步骤S20执行安全级别认证时，OfflineRFMAgent 400通过向OCE420发送回所谓的状态字(SW)来确认431所接收的消息，SW是指示如ISO 7816-4中定义的命令处理状态的确认。

如参考图5所述，在步骤S30中，OfflineRFMAgent 400在卡外实体OCE211和安全元件SE 224之间建立安全通道会话。该步骤可以通过(1)执行安全操作，然后(2)执行相互认证来实现。

通过从OCE 211接收执行安全操作命令，422，在OfflineRFMAgent 400处启动执行安全操作。可以由OCE使用该命令来提交OCE证书，该指令包括OCE的公钥。

优选地，OfflineRFMAgent 400请求432安全元件224的操作系统OS 450的安全域以执行用于验证OCE证书的上述安全操作，并从OCE证书中提取公钥并存储公钥。在这种情况下，OfflineRFMAgent 400可以从OS 450接收响应451。

在接收422执行安全操作命令之后，OfflineRFMAgent 400将响应与确认(状态字)一起发送433到OCE 211。响应消息可以指示安全操作是否成功，并且如果适用，可以指示一个或多个错误状况。

相互认证命令423用于将OCE 211的临时密钥传送到SE 224，并且还可以包含用于SD的风格(flavor)认证信息。SE将完成OCE密钥和SD密钥之间的密钥协商，并将密钥协商结果的收据(receipt)返回给OCE。

OfflineRFMAgent 400向OS 450委派434相互认证的操作，并且在从OS接收到响应452时，将响应与状态字(SW)一起转发435到OCE。状态字(SW)是指示如ISO 7816-4中定义的命令处理状态的确认。特别地，状态字将取决于认证的状态。如果成功实现认证，则将由SE向OCE发布SW＝9000。否则，指示特定错误的不同SW将被发送回OCE。此外，可以返回SD公钥和收据。OCE可以检查收据值以确认在他一侧计算出相同的值。

OfflineRFMAgent 400可以通过调用SecureChannel.processSecurity(APDU)来将要执行的安全认证和相互认证两者委派给其相关联的安全域432、434。

在图5的步骤S30中执行安全操作和相互认证命令以完成安全通道会话的建立的上述步骤。

一旦建立了安全通道会话，OfflineRFMAgent可以继续步骤S40，如图5所示，以处理从OCE接收的多个远程管理命令。特别地，参考图6，OfflineRFMAgent 400调用SecureChannel.unwrap(APDU)436，以便根据当前安全通道会话的安全级别来处理和验证传入APDU命令的安全消息传送。当前安全通道会话的安全级别优选地被设置为在步骤423中在OfflineRFMAgent处接收的相互认证命令中指示的安全级别。

一旦安全已经被处理，OfflineRFMAgent 400可以自己处理文件管理APDU命令，并且可以调用相关的文件视图方法437、440，以便创建、删除、搜索或更新文件系统内容。优选地，OfflineRFMAgent在处理安全性之后(在步骤456中)和/或在SE处执行远程文件管理操作之后(在步骤457中)向OCE 441发送响应消息。

表3给出了OfflineRFMAgent可以支持以执行远程文件管理操作的APDU命令的概述，如[ETSI_102226]中所定义的。一些限制可以应用于某些命令，如下面将结合表5描述的。

表3：APDU命令

根据[GPAmdF]规范，允许在SCP11c会话内部使用选择APDU的任何尝试，但是它导致已经打开的安全通道会话的终止。在传统的OTA RFM会话上，RFM应用由作为OTA命令的一部分包括的工具包应用参考(TAR)隐式地选择，因此不需要选择任何应用。

为了防止当在RFM脚本期间发送选择命令以选择文件系统中的任何文件时导致安全通道会话关闭的上述情况，OfflineRFMAgent 400可以被配置为处理嵌入在SCP11c脚本中的任何选择命令而不关闭安全通道会话。

优选地，OfflineRFMAgent被配置有如在[ETSI_102221]和[ETSI_102226]中定义的访问域参数，其指示用于控制应用实例对文件系统的访问的机制，即授予应用的访问权限。

这将向OfflineRFMAgent保证对文件系统的适当访问，以便成功地运行。这避免了验证PIN的需要，因为PIN通常是多样化的，因此不可能嵌入到DSEM脚本中。

优选地，OfflineRFMAgent 400还包括用于限制远程管理命令的集合的执行的部件。特别地，OfflineRFMAgent可以被配置为限制下表5中列出的来自[ETSI_102226]的命令的使用。

表5：不允许的APDU命令

不允许的命令
	验证PIN
更改PIN
	禁用PIN
使能PIN
	解除阻止PIN

此限制支持结合SCP11c协议定义的会话重现要求。SCP11c允许生成离线构建的静态脚本，这些脚本可以执行若干次是可能的。因此，一些命令被限制在SCP11c会话期间执行，如PUT KEY和SET STATUS命令。OfflineRFMAgent可以被配置为限制来自[ETSI_102226]的某些命令的使用。

优选地，OfflineRFMAgent被配置为满足SPC11c协议规范[GPAmdF]中定义的进一步限制。

由于SCP11c变体能够进入远程文件管理生态系统，本发明的上述实施例提供了若干优点。所提出的解决方案通过重新使用现有的API和GlobalPlatform标准的架构来简化现有的SE文件管理。特别地：

-离线脚本：

可以创建和部署RFM脚本，而不需要与OTA平台的主动在线连接。由于会话密钥可以预先预计算，因此在不需要来自SE的任何响应的情况下构建任何脚本是可能的。

-广播/多播脚本：

它允许基于卡组ID将相同的安全RFM脚本部署到一批或具体子集的所有SE中的可能性。

-高安全性解决方案：

RFM脚本将使用最新的标准和规范来保护。每个命令都受到SCP11c凭证的保护，从而保证E2E加密通信。因此，除了凭证的所有者之外，没有人能够访问脚本，并且没有人能够以任何方式修改或更改脚本。此外，凭证被安全地存储在SE的SD中。

-当前标准的内联：

本发明提供的解决方案重新使用当前标准，以便最小化对文件系统管理的现有部署的影响。

-不需要特定的基础设施：

事实上，用于远程文件管理解决方案的离线脚本试图简化集成和部署要求，以改善上市时间和相关成本。

除此之外，值得注意的是，整个解决方案的经济成本显著低于现有解决方案，因为OTA平台复杂性被显著地降低。

在前述说明书中，已经参考本发明的具体实施例描述了本发明。然而，显而易见的是，在不脱离本发明的更宽范围的情况下，可以对其进行各种修改和改变。例如，参考处理动作的特定顺序来描述上述处理流程。然而，在不影响本发明的范围或操作的情况下，可以改变许多所描述的处理动作的顺序。因此，说明书和附图被认为是说明性的而不是限制性的。

Claims (16)

1.一种用于由离线远程文件管理代理OfflineRFMAgent(400)在安全元件SE(224)处执行远程文件管理RFM操作的方法，所述OfflineRFMAgent(400)位于所述SE(224)内，所述方法包括：

-从卡外实体OCE(211)接收(S10)安全文件更新脚本(316)，所述安全文件更新脚本包括用于在所述安全元件(224)上实施文件管理操作的多个远程管理命令(410)；

-基于所述安全文件更新脚本的安全级别，执行(S20)所述OCE(211)与所述SE(224)的安全级别认证；

-如果所述安全级别认证成功，则在所述OCE(211)与所述SE(224)之间建立(S30)安全通道会话；以及

-处理(S40)所述多个远程管理命令以管理所述安全元件(224)上的文件系统(450)。

2.根据权利要求1所述的方法，其中，所述方法使用安全通道通信协议来执行，特别是使用基于所述OCE的一对临时密钥提供相互认证的安全通道通信协议来执行。

3.根据权利要求1或2所述的方法，其中所述OfflineRFMAgent(400)通过来自所述OCE(211)的多个消息(421；422；423；424；425)接收所述安全文件更新脚本，每个消息包括来自所述多个远程管理命令(410)中的一个命令。

4.根据前述权利要求中任一项所述的方法，其中，执行安全级别认证(S20)包括检查(432)所述安全文件更新脚本的安全级别是否被设置为已认证。

5.根据权利要求4所述的方法，其中，所述方法还包括：

-如果所述安全级别为未认证，则拒绝所述安全文件更新脚本。

6.根据前述权利要求中任一项所述的方法，其中，所述安全文件更新脚本(411)包括执行安全操作命令和相互认证命令，其中，所述执行安全操作命令包括OCE证书，并且所述相互认证命令包括所述OCE的临时公钥。

7.根据权利要求6所述的方法，其中建立安全通道会话(S30)包括请求(432)位于所述安全元件(224)的操作系统OS(450)处的安全域以执行用于验证所述OCE证书的安全操作，并且优选地还包括请求(434)所述安全域从所述OCE证书提取所述公钥并执行相互认证操作。

8.根据前述权利要求中任一项所述的方法，

其中，所述安全文件更新脚本(316)还包括选择命令，所述选择命令指示用于在所建立的安全通道会话期间在所述安全元件的所述文件系统上执行所述多个远程管理命令的远程管理应用，并且其中，所述OfflineRFMAgent(400)在不关闭所建立的安全通道会话的情况下处理所述选择命令。

9.根据前述权利要求中任一项所述的方法，其中处理所述多个远程管理命令(410)包括通过使用文件访问应用编程接口在所述安全元件(224)上创建和/或更新所述文件系统(450)的内容。

10.一种位于安全元件SE(22)处的离线远程文件管理RFM代理OfflineRFMAgent(400)，所述OfflineRFMAgent(400)包括：

-用于从卡外实体OCE(211)接收安全文件更新脚本(316)的部件，所述安全文件更新脚本包括用于在所述安全元件(224)上实施文件管理操作的多个远程管理命令(410)；

-用于基于所述安全文件更新脚本(316)的安全级别来执行所述OCE(211)与所述SE(224)的安全级别认证的部件；

-用于如果所述安全级别认证成功则在所述OCE(211)与所述SE(224)之间建立安全通道会话的部件；

-用于通过调用对应的方法来处理所述多个远程管理命令以管理所述SE(224)上的文件系统(450)的部件。

11.根据权利要求10所述的OfflineRFMAgent(400)，其中

所述OfflineRFMAgent(400)被配置为通过来自所述OCE(211)的多个消息(421；422；423；424；425)接收所述安全文件更新脚本，每个消息包括来自所述多个远程管理命令中的一个命令，并且，

优选地，所述OfflineRFMAgent(400)还被配置为执行根据权利要求3至9中任一项所述的方法。

12.根据权利要求10或11所述的OfflineRFMAgent(400)，还包括用于限制远程管理命令的集合的执行的部件，特别地，所述远程管理命令的集合包括验证PIN、更改PIN、禁用PIN、使能PIN和解除阻止PIN。

13.根据权利要求10至12中任一项所述的OfflineRFMAgent(400)，还包括访问域配置和/或应用提供商标识符，所述访问域配置定义用于控制到所述SE的所述文件系统的应用实例的至少一个访问域参数，所述应用提供商标识符定义所述OfflineRFMAgent(400)与所述安全元件(224)之间的所有权关系，其中所述应用提供商标识符的值对应于在认证处理期间使用的OCE证书中的主体标识符。

14.一种用于离线生成用于多个安全元件SE(224)的安全文件更新脚本的分散式远程文件管理DRFM平台(314)，所述平台包括：

-存储器，用于存储卡外实体OCE(211)的凭证；

-处理器，用于生成安全文件更新脚本(316)，所述处理器被配置为：

-从SE发行方(210)接收文件更新脚本(212)；

-使用存储在所述存储器中的凭证来保护所述文件更新脚本(212)，以获得安全文件更新脚本(316)；以及

-将所述安全文件更新脚本(316)发送到所述SE发行方(210)。

15.根据权利要求14所述的DRFM平台(314)，其中，对于每个OCE(211)，所述凭证包括静态OCE密钥对和临时密钥对，和/或所述安全文件更新脚本(316)还包括识别具有相同OCE凭证的多个SE的卡组ID。

16.一种分散式远程文件管理系统(500)，包括：

-安全元件SE发行方(210)；

-卡外实体OCE(211)；

-根据权利要求14和15中任一项所述的分散式远程文件管理DRFM平台(314)；以及

-至少一个安全元件SE(224)，所述至少一个安全元件(224)包括根据权利要求10至13中任一项所述的OfflineRFMAgent(400)；

其中，所述SE发行方(210)配置为从所述DRFM平台(314)获得包括多个远程文件管理命令的安全文件更新脚本(316)，并且将所述安全文件更新脚本(316)递送到所述OCE(211)；

其中，所述OCE(211)被配置为通过与所述SE(224)相对应的所述OfflineRFMAgent(400)向所述至少一个SE提供所述安全文件更新脚本(316)；以及

其中，所述OfflineRFMAgent(400)被配置为在所述OCE(211)和所述对应的SE(224)之间建立安全通道会话，并且在所述安全元件(224)处执行根据权利要求1至9中任一项所述的用于远程文件管理RFM的方法。

Images