CN117616389A - 安全元件中可执行加载文件的替换 - Google Patents

Abstract

本发明涉及用于升级对安全元件SE具有依赖性的可执行加载文件ELF的方法和设备。该方法包括在第一步骤中接收升级ELF的请求，该请求包括标识在SE上加载的第一ELF版本的第一标识符、标识在SE上加载的第二ELF版本的第二标识符、以及升级选项。在接收到请求时，确定第一ELF版本与在SE上加载或存储的其他ELF的依赖性。随后，如果已经确定了依赖性，则检查是否允许升级请求。如果允许升级请求，则启动升级会话，并且用第二ELF版本替换第一ELF版本。然后将第一ELF版本的依赖性链接到第二ELF版本。

Description

安全元件中可执行加载文件的替换

技术领域

本发明总体上涉及智能卡，并且具体地涉及用于替换安全元件中的可执行加载文件的方法和设备。

背景技术

智能卡广泛用于诸如移动电话、支付卡、访问卡的各种系统中，以提供识别、认证、数据存储和应用处理。

在智能卡包含安全关键应用和敏感数据的情况下，诸如在支付卡等的情况下，使用安全元件来存储数据。安全元件是防篡改芯片，其提供安全的存储器和执行环境，其中可以安全地存储和管理应用代码和应用数据。安全元件确保仅在被授权时才提供对存储在卡上的数据的访问。

这样的安全元件可以以任何形状因子存在，诸如UICC、嵌入式SE、智能SD、智能微型SD等。GlobalPlatform卡片规范定义了用于管理安全元件的若干机制。

安全元件可以包括一个或多个安全域(SD)，每个安全域包括使用安全密钥进行认证的数据集合，诸如包、小应用程序、应用等。

安全域可以与服务提供商相关联，并且可以包括服务提供商小应用程序或应用，诸如忠诚度、优惠券和信用卡。

可执行加载文件(ELF)存在于安全元件中。ELF是包含在安全元件上安装和修改应用所需的一个或多个可执行模块的包。为了在安全元件上安装应用，必须首先将包含与应用相关的可执行模块的ELF加载并存储在安全元件上。可执行模块也被称为小应用程序，其可以被实例化为一个或多个应用实例。

特别地，GlobalPlatform卡片规范版本2.3.1将ELF定义为一个或多个应用的可执行代码(可执行模块)的“实际卡上容器”。它可以驻留在不可变的持久存储器中，或者可以在可变的持久存储器中创建为加载文件数据块的结果图像。

如今，所有现代数字设备(膝上型计算机、手机等)都允许软件升级过程，特别是在存在可用的网络连接的情况下。升级软件的原因很多：修复错误、添加新功能等。在部署了数十亿件的情况下，智能卡肯定需要自己的软件升级机制。

在GlobalPlatform技术可执行加载文件升级卡片规范2.3版本-修正H版本1.1(在下文中也称为“修正H”)中，提出了GlobalPlatform卡片规范的扩展，以促进安全元件上存在的EIF的升级。特别地，修正H提供用于ELF的升级的背景，提供两个选项，即，在移除旧ELF之后加载新ELF，以及在移除旧ELF之前加载新ELF。

然而，升级过程仅适用于不具有任何(静态或动态)依赖性的ELF，并且在检测到这种依赖性的情况下，升级ELF过程将被中止。

因此，期望提供一种解决上述缺点的用于升级ELF的方案。

发明内容

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

根据本发明的第一方面，提供了一种用于升级安全元件SE上的可执行加载文件ELF的方法。该方法包括在第一步骤中接收升级ELF的请求，该请求包括标识在SE上加载的ELF的第一版本的第一标识符、标识在SE上加载的ELF的第二版本的第二标识符、以及升级选项。在接收到请求时，确定第一ELF版本与在SE上加载或存储的其他ELF的依赖性。随后，如果已经确定了依赖性，则检查是否允许升级请求。如果允许升级请求，则启动升级会话，并且用第二ELF版本替换第一ELF版本。然后将第一ELF版本的依赖性链接到第二ELF版本。

所提出的方法提供了升级ELF的有效方案，即使当存在对其他ELF的依赖性时也是如此。更具体地，所提出的方法允许独立于升级与正在升级的ELF处于静态或动态依赖性的其他ELF来升级ELF。这允许将SE上依赖于ELF(即，第一ELF)的所有ELF内部链接到替换ELF(即，第二ELF)，从而确保始终满足静态和动态依赖性。

所提出的方案适用于由修正H提供的第二选项，即，在移除旧ELF之前加载新ELF。因此，当所提出的方法被调用时，存在被加载到SE上的ELF的两个版本，第一版本(即，旧ELF)和第二版本(即，新ELF)。

在本发明的一些实施例中，升级选项是包括多个比特位的标签长度值TLV字段，一个比特位被保留用于在已经确定依赖性的情况下向SE指示执行热替换。

通过该应用，热替换可以指代通过用另一个ELF版本替换ELF版本来更新ELF版本的过程，而既不停止在其上执行ELF版本的系统，也不停止应用本身。

通过将用于向SE指示允许热替换的升级选项结合到升级请求中，建立了用于在存在依赖性的情况下允许ELF升级的基础。通过该升级标志，SE被显式地发信号通知不拒绝升级会话，或者如果已经检测到依赖性则不中止已经开始的升级会话，并且允许执行升级方法。换句话说，即使更新的ELF是对其它ELF的动态或静态依赖性，实施方式也将接受ELF升级请求。在GlobalPlatform卡片规范和GlobalPlatform修正H两者的背景中，不支持这种热替换，并且相应的升级请求将被拒绝，相应地，正在运行的升级会话将被终止。

优选地，检查升级请求是否被允许包括检查被保留用于指示热替换的一个比特位的值等于1。

在本发明的一些实施例中，检查升级请求是否被允许包括检查第二ELF版本是否满足第一ELF版本的依赖性。

这确保了如果新ELF未能满足现有的动态或静态依赖性，则实施方式将拒绝ELF升级请求。

优选地，如果保留用于指示热替换的一个比特位的值是1和/或第二ELF满足第一ELF的依赖性，则允许升级请求，否则，拒绝升级请求。

这确保不允许用不满足现有依赖性的ELF版本进行热替换，并且因此存储在安全元件上的ELF和应用的完整性不被篡改。

在本发明的一些实施例中，SE上加载的每一个ELF包括列出由一个ELF中的类导入的一组其他ELF的第一组件，以及列出由其他ELF存储或寻址的一个ELF实例的第二组件。优选地，第一组件和第二组件持久地存储在SE的存储器中。

优选地，确定第一ELF版本与SE上加载的其他ELF的依赖性是基于第一ELF的第一组件和第二组件中包含的信息。

在本发明的一些实施例中，将所述第一ELF版本的所述依赖性链接到所述第二ELF版本包括：针对具有所述第一ELF版本作为依赖性的所述SE上的每个其他ELF，执行重新链接过程以使所述每个其他ELF依赖于所述第二ELF版本。

优选地，使用包含在第一ELF版本的第一组件和第二组件中的信息来执行重新链接过程。

在本发明的一些实施例中，所述方法还包括：在将所述第一ELF版本的所述依赖性链接到所述第二ELF版本之后，用所述第一标识符替换所述第二标识符，以用所述第一ELF版本的所述第一标识符来标识所述第二ELF版本。

优选地，在用第二ELF版本替换之后，即在热替换之后，删除第一ELF版本。

根据前述权利要求中任一项所述的方法，其中，在所述SE处在应用协议数据单元APDU命令内接收用于升级所述ELF的所述请求。

根据本发明的第二方面，提供了一种用于升级安全元件SE上的可执行加载文件ELF的应用协议数据单元APDU命令。所述命令包括升级选项，其中，所述升级选项是包括多个比特位的标签长度值TLV字段，一个比特位被保留用于向所述SE指示执行热替换。

根据本发明的第三方面，提供了一种用于升级安全元件SE上的可执行加载文件ELF的设备。该设备包括接收单元和处理单元。所述接收单元被配置为接收用于升级ELF的请求，所述请求包括标识在所述SE上加载的所述ELF的第一版本的第一标识符、标识在所述SE上加载的所述ELF的第二版本的第二标识符、以及升级选项。所述处理单元被配置为访问所述SE的存储器并且确定所述第一ELF版本与加载在所述存储器中的其他ELF的依赖性。如果依赖性已经被确定，则处理器还被配置为检查升级请求是否被允许，并且如果升级请求被允许，则开始升级会话，用第二ELF版本替换第一ELF版本，并且将第一ELF版本的依赖性链接到第二ELF版本。

在根据第三方面的本发明的一些实施例中，通过根据第二方面的APDU命令接收升级请求，并且该设备被配置为执行根据第一方面的方法。

根据本发明的第三方面，提供了一种计算机程序产品，包括指令，当计算机执行程序时，指令使计算机执行根据第一方面的方法。

本文描述的方面和实施例将允许服务提供商即使在存在对其他ELF的依赖性时也有效且高效地升级ELF。

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

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

附图说明

现在将参考附图，其中：

图1示出了如在GlobalPlatform卡片规范中定义的ELF、可执行模块和应用之间的关系；

图2示出了根据实施例的用于升级可执行加载文件的方法的流程图；

图3示出了根据实施例的用于升级可执行加载文件的方法的进一步步骤；

图4示出了根据实施例的ELF及其依赖性的升级场景；

图5示出了根据实施例的ELF及其依赖性的进一步升级场景；

图6示出了适于执行该方法的实施例的设备的功能描述。

具体实施方式

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

图1示出了如在GlobalPlatform技术卡片规范中规定的ELF、可执行模块和应用之间的关系。

智能卡上的内容最初以可执行加载文件100的形式在卡的安全元件SE 1上可用，该可执行加载文件100是包含在安全元件上安装和修改应用所需的一个或多个可执行模块110的包，例如Java卡的包。可执行加载文件100可以存在于不可变持久存储器10(如图1所示)中，在这种情况下，它在制造阶段期间被加载到安全元件上并且不能被改变(除了被禁用之外)，或者存在于可变持久存储器20(未示出)中，在这种情况下，它可以在预发布或后发布期间被加载或移除。

每个可执行加载文件100可以包含作为应用代码的一个或多个可执行模块110。应用的安装从可执行模块110创建实例210，例如Java卡小应用程序类，以及可能的可变持久存储器20内的应用数据。GlobalPlatform卡片旨在支持多个可执行加载文件和多个可执行模块，并且因此多个应用可以共存于GlobalPlatform卡片上。

可以通过由安全单元内的安全域调用的APDU命令来启用ELF升级过程。特别地，ELF过程可以用管理ELF升级命令开始，该命令在GlobalPlatform技术可执行加载文件升级卡片规范版本2.3-修正H版本1.1中定义，并且允许开始、恢复或中止ELF升级会话。

如在GlobalPlatform卡片规范的上述修正H中所述，管理ELF升级[开始]命令通常被错误地拒绝，并且如果存在将阻止旧ELF版本被删除的静态相关性，或者如果当前选择或暂停从旧ELF版本创建的任何应用实例，则ELF升级过程被中止。换句话说，常规升级过程仅适用于不具有任何(静态或动态)依赖性的ELF，并且在检测到这种依赖性的情况下，升级ELF过程将被中止。

本发明提出了一种用于解决上述缺点的方案，特别是一种即使在存在对/来自其他ELF的依赖性时也升级ELF的有效方案。

静态相关性是当来自包(即，ELF)“A”的类链接到来自包(即，ELF)“B”的类、方法或项时出现的相关性。动态相关性是指由包“B”存储或寻址的包“A”的实例。换句话说，ELF的静态依赖性存在于ELF上的(一个或多个)可执行模块内的可执行代码中。另一方面，动态依赖性不是来自应用程序的可执行代码，而是来自其在执行期间的数据。存储来自ELF B的构造的数据块的ELF A对B具有动态依赖性。

在下文中，要替换的ELF将可互换地称为第一ELF版本，而替换ELF将可互换地称为第二ELF版本。

图2示出了根据实施例的用于升级可执行加载文件(ELF)的方法的流程图。图6示出了适于执行图2的用于升级可执行加载文件的方法的对应设备200的功能描述。

参考图2，在第一步骤S10中，在安全元件SE处(例如在图1的SE 1处)接收用于升级ELF的请求。可以从服务提供商(未示出)接收请求。

参考图6，可以通过APDU命令240在设备200的接收单元210处接收请求。

优选地，在图2的步骤S10中接收的请求包括标识存储或加载在SE 1上的ELF的第一版本101的第一标识符、标识存储或加载在SE 1上的ELF的第二版本102的第二标识符、以及升级选项。

在另一步骤S20中，确定第一ELF版本101与在SE 1上存储/加载的其他ELF之间的依赖性，即，确定是否存在在安全元件上加载/存储的与第一ELF处于依赖性关系的其他ELF。

图4(a)中描绘了这种依赖关系的示例。其中，第一ELF B 101与另一ELF A 100静态依赖。

如果已经确定S21依赖性，则在进一步的步骤S30中检查升级请求是否被允许。下面将参考图3进一步描述该步骤的实施方式。

在上述检查是肯定的情况下，图2中的步骤S33，执行用第二ELF版本实际替换第一ELF版本。优选地，这通过图2的步骤S40、S50和S60来实现。特别地，在步骤S40中开始升级会话，此时在步骤S50中用第二ELF版本替换第一ELF版本。在替换之后，在步骤S60中将已经在步骤S20中确定的第一ELF版本的依赖性(重新)链接到第二ELF版本。

如果在步骤S20中没有确定涉及第一ELF版本的依赖性(“否”分支S22)，则在步骤S23中执行如在GlobalPlatform修正H中定义的常规替换方法。

如在GlobalPlatform卡片规范的修正H中定义的管理ELF升级命令期望ELF升级请求标签，其中给出了旧ELF AID(第一ELF标识符)和新ELF AID(第二ELF标识符)。

管理ELF升级命令消息包括数据字段，其是TLV(标签长度值)编码的。具体地，标签“80”根据表1设置升级选项。

b8	b7	b6	b5	b4	b3	b2	b1	含义
									-	-	-	-	-	-	-	0	遗产应设置为0。
-	-	-	-	-	-	x	-	RFU
									-	-	-	-	-	1	-	-	自动触发还原阶段
1	-	-	-	-	-	-	-	断电后自动恢复
									-	x	x	x	X	-	-	-	RFU

表1：升级选项TLV的编码

如上所述，在本节开始时，常规升级过程仅适用于不具有任何(静态或动态)依赖性的ELF，并且在检测到这种依赖性的情况下，升级ELF过程将被中止。

为了向底层实施方式指示应当允许热替换，根据本发明实施例，向表1的升级选项添加新标志。这可以通过固定RFU位中的一个RFU位(其是保留用于将来使用的位)来实现，以指示“热替换”，以向安全元件(SE)的处理单元发信号通知在要替换的ELF与安全元件上的其他ELF之间已经检测到依赖性的情况下不拒绝/中止替换过程。可替代地，可以将新比特位添加到修正H中定义的8比特位长的升级选项。

根据优选实施例，升级选项可以在用于升级安全元件SE上的可执行加载文件ELF的应用协议数据单元APDU命令内发送。APDU命令优选地由服务提供商经由SE的安全域发送。

图3示出了根据本发明的实施例的用于实现检查是否允许升级请求的步骤S30的另外的步骤。

参考图3，在步骤S31中，由处理单元220(参见图6)检查在步骤S10中与升级请求一起接收的升级选项是否相应地被设置为允许热替换。更具体地，检查被保留用于指示热替换的一个位的值等于1(或真)。

如果不是这种情况，则在步骤S34中拒绝升级请求。

如果已经请求了热更新，则在进一步的步骤S32中，检查第二ELF版本是否满足第一ELF的依赖性。优选地，如果新ELF未能满足要替换的ELF的现有动态或静态依赖性，则处理单元220将拒绝(步骤S34)ELF升级请求。

如果步骤S31和步骤S32中的检查都是肯定的，则在步骤S33中允许升级请求。以这种方式，SE上的应用的完整性得以保留。

图3示出了一个实施例，其中执行步骤S31和S32中的两个检查以确定升级请求是否被允许。可替代地，根据另外的优选实施例，可以仅基于一个检查(步骤S31中的检查或步骤S32中的检查)来允许升级请求。

用于升级ELF的上述方法利用存储在安全元件上的ELF之间的依赖性。可以基于ELF中可用的信息在ELF的加载和链接期间确定这些依赖性。

优选地，加载在SE 1上的每个ELF 100包括列出由一个ELF中的类导入的一组其他ELF的第一组件，以及列出由其他ELF存储或寻址的一个ELF实例的第二组件。

第一组件内的信息可以列在Java卡3平台虚拟机规范3.0.5版中定义的导入组件内。导入组件列出了由该包中的类导入的一组包，并由以下结构表示：

ELF的第二组件内的信息可以例如在常量池组件内列出，也在Java卡3平台虚拟机规范3.0.5版中定义。常量池组件由以下结构描述：

通常，包含在导入组件和常量池组件内的信息在链接之后被丢弃。然而，在旧(第一)ELF已经被新(第二)ELF替换之后，在用于执行重新链接过程的热替换的情况下，需要该信息。

因此，根据本发明实施例，第一组件和第二组件(相应地，其中包含的信息)持久地存储在安全元件的存储器中。这可以是图1中描绘的SE 1的不可变持久存储器10或可变持久存储器20。

基于持久存储的ELF的第一和第二组件中可用的信息，只要ELF存储在SE上，就可以一直确定ELF(ELF版本)的所有依赖性，并且用于在替换之后将旧ELF的依赖性重新链接到新ELF。

这允许使那些ELF现在依赖于新加载的ELF，留下没有任何依赖ELF的旧ELF并准备好被删除。

最后，在旧(第一)ELF版本被新(第二)ELF版本替换之后，可以删除旧(第一)ELF版本，并且相应地重新链接依赖性。

优选地，在将第一ELF版本101的依赖性链接到第二ELF版本102之后，用第一标识符替换第二标识符。这允许利用第一ELF版本101的第一标识符来标识第二ELF版本102。以这种方式，ELF AID在替换之后保持不变。

下面将参考图4和图5描述应用根据本发明的方法的ELF及其依赖性的各种升级场景。具体地，图4涵盖了ELF之间存在静态依赖性的情况，而图5示出了如何处理动态依赖性。

图4(a)示出了两个ELF A 100和B 101，而ELF A具有ELF B作为静态依赖性。也就是说，来自A的可执行代码显式地调用或使用来自ELF B的可执行代码的元素。

在图4(b)中，选择ELF B用于升级。升级ELF B(即，第一ELF)意味着删除它并加载它的不同版本。在GP卡片规范的背景中，删除ELF B而不删除ELF A将失败，因为它将留下孤立依赖关系。在GP修正H的背景中，出于相同的原因，预期这种情况也会失败(参见修正H规范，第3.2.1节)。

根据如图2所示的实施例的方法旨在将ELF上的所有依赖项内部链接到替换ELF，从而确保始终满足静态依赖性。这使得来自图4(a)的升级过程成为可能，而不被迫也删除依赖项ELF A。

图4(c)描绘了在来自图4(a)的场景上执行根据本发明的方法的结果。来自ELF A的静态依赖关系被切换到替换ELF B'102(即，第二ELF)，因此当删除ELF B时，也不存在需要删除ELF A的更多约束。

图5涵盖了除了静态依赖关系之外还涉及动态依赖关系的情况。

图5(a)示出了在对之间具有静态的相应动态依赖性的三个ELF。来自ELF A 100的可执行代码显式地调用或使用来自ELF B 101的可执行代码的元素，并将来自ELF B的一些数据/对象存储到ELF C中。ELF A还调用ELF C 103。换句话说，ELF A具有ELF B和ELF C作为静态依赖项104、105。另一方面，ELF C将ELF B作为动态依赖项106。ELF C不静态地依赖于ELF B。

图5(b)示出了在图5(a)的场景中同时升级ELF A和B的尝试。

尽管来自ELF C的可执行代码不知道关于ELF B的任何内容(因为ELF C对ELF B没有静态依赖性)，但是存储在C中的对象确实知道。在GP卡片规范的背景中，删除ELF B而不删除ELF C将失败，因为它将留下孤立依赖关系。在GP修正H的背景中，出于相同的原因，预期这种情况也会失败(参见修正H规范，第3.2.2节)。此外，根据修正H，当应用可以要求系统保留与升级的ELF中的一个相关的对象时，还可以在数据保存阶段期间创建动态依赖性，这将使所涉及的ELF不可删除，从而破坏升级过程。

根据如图2所示的实施例的方法旨在将ELF上的所有依赖项内部链接到替换ELF，从而确保所有依赖项始终得到满足。这使得来自图5(a)的升级过程成为可能，而不被迫也删除依赖的ELF C(其进而也将需要删除ELF A)。

通过实现所要求保护的方法，ELF C(重新)链接到ELF B的替换，即链接到ELF B'。通过对ELF C执行链接过程，ELF B'变成ELF C的动态依赖性(线107)，从而保证在用ELF B'替换ELF B之后满足所有动态依赖性，如图6(c)所示。由于ELF B的动态依赖关系被切换到替换ELF B'，因此在删除ELF B时，ELF C和ELF A都不需要被删除。

如通过上述实施例描述的方法、接口和装置允许独立于升级与正在升级的ELF处于静态或动态依赖性的其他ELF来升级ELF，同时确保保留所有依赖性关系。

利用所提出的方案，具有静态和动态依赖性的ELF因此可以被升级并与其背景重新链接，而没有关于功能和与其他包的关系的进一步影响。

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

Claims (15)

1.一种用于升级安全元件SE(1)上的可执行加载文件ELF(100)的方法，所述方法包括：

-接收(S10)用于升级ELF(100)的请求，所述请求包括标识加载在所述SE(1)上的第一ELF版本(101)的第一标识符、标识加载在所述SE(1)上的第二ELF版本(102)的第二标识符、以及升级选项；

-确定(S20)所述第一ELF版本(101)与加载在所述SE(1)上的其他ELF(100)的依赖性；

-如果已经确定了依赖性(S21)，则检查(S30)是否允许升级请求；以及

-如果所述升级请求被允许(S33)：

-开始(S40)升级会话；

-用所述第二ELF版本(102)替换(S50)所述第一ELF版本(101)；以及

-将所述第一ELF(101)版本的所述依赖性链接(S60)到所述第二ELF版本(102)。

2.根据权利要求1所述的方法，其中，所述升级选项是包括多个比特位的标签长度值TLV字段，一个比特位被保留用于指示所述SE(1)执行热替换，即，如果已经确定依赖性，则允许所述升级会话。

3.根据权利要求2所述的方法，其中，检查(S30)所述升级请求是否被允许包括：检查(S31)被保留用于指示热替换的所述一个比特位的值等于1。

4.根据权利要求2或3所述的方法，其中，检查(S30)所述升级请求是否被允许包括检查(S32)所述第二ELF版本(102)是否满足所述第一ELF版本(101)的依赖性。

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

如果被保留用于指示热替换的所述一个比特位的所述值是1和/或所述第二ELF版本(102)满足所述第一ELF版本(101)的所述依赖性，则允许(S33)所述升级请求，否则，拒绝(S34、S70)所述升级请求。

6.根据前述权利要求中任一项所述的方法，其中，加载在所述SE(1)上的每一个ELF(100)包括列出由所述一个ELF中的类导入的一组其他ELF的第一组件，以及针对由其他ELF存储或寻址的所述一个ELF实例的第二组件，其中，所述第一组件和所述第二组件持久地存储在所述SE(1)的存储器(10；20)中。

7.根据权利要求6所述的方法，其中，确定(S20)所述第一ELF版本(101)与加载在所述SE(1)上的其他ELF(100)的依赖性是基于包含在所述第一ELF版本(101)的所述第一组件和所述第二组件中的所述信息。

8.根据前述权利要求中任一项所述的方法，其中，将所述第一ELF版本(101)的所述依赖性链接到所述第二ELF版本(102)包括：

对于所述SE(1)上的具有所述第一ELF版本(101)作为依赖项的每个其他ELF，执行重新链接过程，以使所述每个其他ELF依赖于所述第二ELF版本(102)。

9.根据权利要求8所述的方法，其中，使用包含在所述第一ELF版本(101)的所述第一组件和所述第二组件中的信息来执行所述重新链接过程。

10.根据前述权利要求中任一项所述的方法，还包括：在将所述第一ELF版本(101)的所述依赖性链接到所述第二ELF版本(102)之后，用所述第一标识符替换所述第二标识符。

11.根据前述权利要求中任一项所述的方法，还包括在用所述第二ELF版本(102)替换所述第一ELF版本之后删除所述第一ELF版本(101)。

12.一种用于升级安全元件SE上的可执行加载文件ELF的应用协议数据单元APDU命令，所述命令包括升级选项，其中，所述升级选项是包括多个比特位的标签长度值TLV字段，保留一个比特位用于指示所述SE执行热替换。

13.一种用于升级安全元件SE(1)上的可执行加载文件ELF(100)的设备(200)，所述设备(200)包括：

-接收单元(210)，被配置为接收用于升级ELF(100)的请求，所述请求包括标识在所述SE上加载的第一ELF版本(101)的第一标识符、标识在所述SE上加载的第二ELF版本(102)的第二标识符、以及升级选项；

-处理单元(220)，被配置为：

-访问所述SE(1)的存储器(10；20)，并且确定所述第一ELF版本(101)与加载在所述存储器(10；20)中的其他ELF的依赖性；

-如果已经确定了依赖性，则检查升级请求是否被允许；以及

-如果所述升级请求被允许，则开始升级会话，用所述第二ELF版本(102)替换所述第一ELF版本(101)，并且将所述第一ELF版本(101)的所述依赖性链接到所述第二ELF版本(102)。

14.根据权利要求13所述的设备(200)，其中，通过根据权利要求12所述的APDU命令(240)接收所述请求，并且其中，所述设备(200)还被配置为执行根据权利要求2至11中任一项所述的方法。

15.一种计算机程序产品，包括指令，当由计算机执行所述程序时，所述指令使所述计算机执行：

-接收用于升级ELF(100)的请求，所述请求包括标识加载在SE(1)上的第一ELF版本(101)的第一标识符、标识加载在所述SE(1)上的第二ELF版本(102)的第二标识符、以及升级选项；

-确定所述第一ELF版本(101)与存储在所述SE上的其他ELF的依赖性；

-如果已经确定了依赖性，则检查升级请求是否被允许；以及

-如果所述升级请求被允许，则开始升级会话，用所述第二ELF版本(102)替换所述第一ELF版本(101)，并且将所述第一ELF版本(101)的依赖性链接到所述第二ELF版本(102)。