软件防火墙的制作方法

文档序号:16815405发布日期:2019-02-10 14:23阅读:591来源:国知局
软件防火墙的制作方法

本发明涉及安装在诸如智能卡之类的电子卡上的软件防火墙,在所述电子卡上有多个使用简档共存。本发明还涉及由这种软件防火墙实现的方法。



背景技术:

智能卡包括能够包含和处理信息的至少一个集成电路。所述集成电路——即芯片——包含能够处理被存储在非易失性存储器中的信息的微处理器或微控制器。微处理器或微控制器使得能够实现确保在智能卡内实行的信息交换和处理的进行的操作系统。操作系统独立于智能卡硬件来定义用于执行中间代码(英语称为“字节码(bytecode)”)的环境,藉此来执行称为小应用程序(“applet”)的应用程序。这种执行环境在javacard术语中称为jcre(英语为“javacardruntimeenvironment(javacard运行时环境)”),这是一种在智能卡设计中广泛传播的技术。操作系统包括解译器,其使得能够执行安装在智能卡上的非易失性存储器中的小应用程序的中间代码。该解译器在javacard术语中称为虚拟机,jcvm(英语为“javacardvirtualmachine(javacard虚拟机)”)。操作系统还包括一组库,其中包含用于开发智能卡小应用程序的基本功能(api,英语为“applicationprogramminginterfaces(应用程序编程接口)”)。有关javacard技术的更丰富的详细信息,可特别参考“javacardclassicplatform(javacard经典平台)”规范3.0.4版。

智能卡主要用作个人识别或支付的手段,或者预付费服务的订阅证明。因此,智能卡通常包含被认为是机密的数据。智能卡也可能受到攻击,其目的是恢复这些机密数据。这些攻击可能是物理的或逻辑的。逻辑攻击包括使得由操作系统、且更具体地说是解译器执行恶意应用程序,其例如包含欺诈性中间代码序列。

存在确保在小应用程序的执行上下文之间验证访问权限的软件防火墙,以便仅在目标小应用程序提供可共享接口的情况下才授权另一上下文中的另一小应用程序访问一上下文中的目标小应用程序。然而,这样的软件防火墙没有被适配成将目标小应用程序仅向智能卡上执行的其它小应用程序的子集提供可共享接口的情形纳入考虑。特别是,这种软件防火墙没有被适配成将必须控制对静态数据的访问的情形纳入考虑。这些情况尤其是在不同运营商的多个服务共享智能卡的使用——如在euicc(英语为“embeddeduniversalintegratedcircuitcard(嵌入式通用集成电路卡)”)型电子卡中是这种情况——时发生。例如,可以列举sim(英语为“subscriberidentitymodule(订户身份模块)”)卡的情况,该卡使得能够访问由不同运营商提供的电话服务。于是,通过由小应用程序供给的可共享接口提供的访问权限将是不同的,这取决于小应用程序是经由来自同一运营商的另一小应用程序被访问还是小应用程序是经由来自另一运营商的另一小应用程序被访问,在这种情况下必须确保某种密封性以避免产生一个运营商恢复或污染另一运营商的数据的可能性。可以在同一模型上构建在多服务情境中使用euicc型电子卡的其它示例。

另外,上述问题不限于euicc型电子卡的上下文。实际上,关于iuicc(英语为“integrateduniversalintegratedcircuitcard(集成式通用集成电路卡)”)电子组件存在同样的问题。



技术实现要素:

期望缓解现有技术的这些缺点。更具体来说,期望提供抵抗上述逻辑攻击的、具有增强的可靠性的解决方案。

为此,本发明涉及一种用于验证小应用程序的执行的方法,所述小应用程序是以面向对象的语言开发并以中间代码编译的,所述方法由安装在iuicc型电子组件中或在euicc型电子卡上的操作系统的软件防火墙实现,所述操作系统包括解译器,所述解译器是解译并执行所述小应用程序的中间代码的软件,每个小应用程序与单个上下文相关联,每个上下文与一个或多个小应用程序相关联。每个上下文与多个使用简档中的单个使用简档相关联,每个使用简档与一个或多个上下文相关联。当所述解译器向所述软件防火墙通知从第一小应用程序向第二小应用程序的对静态数据的访问时,所述软件防火墙实施以下步骤:确定所述静态数据访问的源简档,其为与跟第一小应用程序相关联的上下文相关联的简档;确定所述静态数据访问的目的地简档,其为与跟第二小应用程序相关联的上下文相关联的简档;验证所述静态数据访问的源简档是否与所述静态数据访问的目的地简档相同;当所述静态数据访问的源简档与所述静态数据访问的目的地简档不同时,拒绝所述静态数据访问;以及,当所述静态数据访问的源简档与所述静态数据访问的目的地简档相同时,应用上下文间访问验证规则。

因此,借助于整合了上下文概念的使用简档概念的定义,并且借助于面向小应用程序之间的静态数据访问的软件防火墙的行为,保护使用简档的静态数据免于来自另一使用简档的访问,即便对此类静态数据的访问不牵涉到上下文变更。

根据特定实施例,所述使用简档中的一个是特定简档,称为“系统简档”,其被所述软件防火墙与其它使用简档分开管理,以便当所述静态数据访问的源简档是所述系统简档时,所述软件防火墙应用上下文间访问验证规则,并且当所述静态数据访问的目的地简档是所述系统简档时,所述软件防火墙拒绝所述静态数据访问。

根据特定实施例,当所述解译器向所述软件防火墙通知从第一小应用程序向第二小应用程序的对非静态数据或对方法(méthode)的访问时,所述软件防火墙实施以下步骤:确定所述非静态数据或方法访问的源简档;确定所述非静态数据或方法访问的目的地简档;验证所述非静态数据或方法访问的源简档是否与所述非静态数据或方法访问的目的地简档相同;当所述非静态数据或方法访问的源简档与所述非静态数据或方法访问的目的地简档不同时,拒绝所述非静态数据或方法访问;以及,当所述非静态数据或方法访问的源简档与所述非静态数据或方法访问的目的地简档相同时,应用上下文间访问验证规则。因此,非静态数据和/或方法得益于与静态数据相同的保护级别。

根据特定实施例,当所述非静态数据或方法访问的源简档是所述系统简档时,所述软件防火墙应用上下文间访问验证规则,并且当所述非静态数据或方法访问的目的地简档是所述系统简档时,所述软件防火墙(fw)拒绝所述非静态数据或方法访问。

本发明还涉及一种软件防火墙,其被配置成实施对小应用程序的执行验证,所述小应用程序是以面向对象的语言开发并以中间代码编译的,所述软件防火墙旨在属于旨在被安装在iuicc型电子组件中或在euicc型电子卡上的操作系统,所述操作系统包括解译器,所述解译器是解译并执行所述小应用程序的中间代码的软件,每个小应用程序与单个上下文相关联,每个上下文与一个或多个小应用程序相关联。每个上下文与多个使用简档中的单个使用简档相关联,每个使用简档与一个或多个上下文相关联。当所述解译器向所述软件防火墙通知从第一小应用程序向第二小应用程序的对静态数据的访问时,所述软件防火墙实施以下步骤:确定所述静态数据访问的源简档,其为与跟第一小应用程序相关联的上下文相关联的简档;确定所述静态数据访问的目的地简档,其为与跟第二小应用程序相关联的上下文相关联的简档;验证所述静态数据访问的源简档是否与所述静态数据访问的目的地简档相同;当所述静态数据访问的源简档与所述静态数据访问的目的地简档不同时,拒绝所述静态数据访问;以及,当所述静态数据访问的源简档与所述静态数据访问的目的地简档相同时,应用上下文间访问验证规则。

本发明还涉及一种euicc型电子卡,其包括集成了如上文论述的软件防火墙的操作系统,所述软件防火墙被配置成实施以面向对象的语言开发并以中间代码编译的小应用程序的执行验证。

根据特定实施例,所述euicc型电子卡是sim卡,并且使用简档分别与不同运营商的电话服务相关联。

本发明还涉及一种iuicc型电子组件,其包括集成了如上文论述的软件防火墙的操作系统,所述软件防火墙被配置成实施以面向对象的语言开发并以中间代码编译的小应用程序的执行验证。

附图说明

通过阅读以下对示例实施例的描述,上文提到的本发明的特征以及其它特征将更清楚地显现,所述描述是结合附图给出的,在附图中:

-图1a示意性地示出了其中可以实现本发明的智能卡的硬件架构;

-图1b示意性地示出了其中可以实现本发明的电子组件的硬件架构;

-图2示意性地示出了由智能卡实现的软件组织;

-图3示意性地示出了根据第一实施例的属于不同上下文的小应用程序之间的访问管理;

-图4示意性地示出了根据第二实施例的属于不同上下文的小应用程序之间的访问管理;

-图5a示意性地示出了根据第一实施例的由软件防火墙实现的用于处理小应用程序间的访问的算法;以及

-图5b示意性地示出了根据第二实施例的由软件防火墙实现的用于处理小应用程序间的访问的算法。

具体实施方式

图1a示意性地示出了其中可以实现本发明的euicc型智能卡(即,电子卡)的硬件架构。

智能卡euicc包括接口if,其被配置成将智能卡euicc连接到读卡器(图1a中未示出)。智能卡euicc例如是多运营商sim(英语为“subscriberidentitymodule(订户身份模块)”)卡,并且读卡器被包括在移动电话终端中。智能卡euicc也可以是多服务银行卡,并且读卡器被包括在银行终端中,或者智能卡euicc可以是多供应商忠诚卡,并且读卡器被包括在收银机系统中。一般而言,本发明可以被实现在针对其需要各种并行的使用简档的电子卡内,优选地是智能卡。

接口if因此被配置成使得能够在读卡器和智能卡euicc之间实施数据交换,特别是使得读卡器能够向智能卡euicc发送命令,并且还使得读卡器能够为智能卡euicc供能。

智能卡euicc还包括处理器,其通常是以微控制器μc或微处理器的形式,负责实施智能卡euicc内的处理:数据的计算、处理和传输等。

智能卡euicc还包括易失性存储器,诸如随机存取存储器ram(英语为“randomaccessmemory”),以及至少一个非易失性存储器,诸如只读存储器rom(英语为“readonlymemory”)和eeprom存储器(英语为“electronicallyerasableprogrammablerom(电可擦可编程只读存储器)”)或闪存。

当读卡器经由接口if对智能卡euicc供能时,微控制器μc能够从只读存储器rom和/或eeprom存储器执行指令,特别是以中间代码的形式的指令。

只读存储器rom和/或eeprom存储器通常包含促使操作系统的实现的指令,优选地是根据javacard技术的jcre环境,其利用非易失性存储器来创建至少执行堆栈并且临时存储数据,诸如应用程序的数据。

eeprom存储器通常包含安装在智能卡euicc上的应用程序(称为小应用程序)的指令,并且更具体来说,当应用程序被实例化时,包含所述应用程序的对象。小应用程序是以面向对象的语言开发的,并且是以中间代码编译的。对这些对象的创建的控制以及用于操纵这些对象的存储器空间的赋予是由解译器实现的,所述解译器优选地是根据javacard技术的jcre环境的jcvm虚拟机(英语为“javacardvirtualmachine(javacard虚拟机)”),其负责确保微控制器μc执行应用程序的从eeprom存储器中读取的中间代码。

要注意到,当操作系统被实现在除智能卡之外的电子卡上时,一旦对所述电子卡供能,微控制器μc就能够从只读存储器rom和/或从eeprom存储器执行加载在随机存取存储器ram中的指令。

图1b示意性地示出了其中可以实现本发明的电子组件iuicc的硬件架构。图1b对应于名为soc(英语为“systemonchip(片上系统)”)的已知架构。图1b中呈现的架构与图1a中呈现的架构非常相似,并且主要区别在于它被集成在单个电子组件中。因此,电子组件iuicc包括接口if2,其被配置成通常经由通信总线将电子组件iuicc连接到电子卡上的其它电子组件。

电子组件iuicc还包括处理核心,其通常是以微控制器核心μc2的形式,负责实施电子组件iuicc内的处理:数据的计算、处理和传输等。

电子组件iuicc还包括易失性存储器,诸如随机存取存储器ram2,以及至少一个非易失性存储器,诸如只读存储器rom2。

当对电子组件iuicc供能时,微控制器核心μc2能够从只读存储器rom2执行指令,特别是以中间代码的形式的指令。只读存储器rom2通常包含促使操作系统的实现的指令,优选地是根据javacard技术的jcre环境,其利用非易失性存储器ram2来创建至少执行堆栈并且临时存储数据,诸如应用程序的数据。存储器rom2通常包含应用程序(称为小应用程)的指令,并且更具体来说,当应用程序被实例化时,所述应用程序的对象被存储在随机存取存储器ram2中。

图2示意性地示出了由智能卡euicc或由电子组件iuicc实现的软件组织。硬件-软件接口250使得能够借助于来自所述软件组织的软件指令来控制作为硬件实体的智能卡euicc或电子组件iuicc。

所述软件组织包括被适配至硬件实体的操作系统部分host_os,以便使得由jcre环境构成的操作系统的另一部分能够使智能卡euicc运行。操作系统部分host_os允许呈现jcre环境,而与硬件实体的实际结构无关。

jcre环境特别包含虚拟机jcvm以及软件防火墙fw(英语为“softwarefirewall”)。jcre环境的服务由应用程序app(称为小应用程序)使用,每个小应用程序都是在给定的上下文内创建的。每个上下文包括一个或多个小应用程序。在javacard术语中,上下文称为程序包。换言之,小应用程序被组织在名称空间中,所述名称空间因此定义用于执行所述小应用程序的上下文。

根据javacard技术,当第一小应用程序试图访问(调用、读取或写入)属于不同上下文(或程序包)的第二小应用程序时,软件防火墙fw应用某些访问验证规则。软件防火墙fw然后特别针对第二小应用程序来验证所述第二小应用程序提供可共享接口并且因此授权来自第一小应用程序的访问。可以定义其它的上下文间访问验证规则。

在本发明的情境中,软件防火墙fw部署了互补的功能,以便使得能够实现多简档管理并防止从第一使用简档的小应用程序向第二使用简档的小应用程序执行不期望的访问。下面在第一实施例中结合图5a来详述软件防火墙fw的行为。然而,可能存在由软件防火墙fw分开管理的特定使用简档(系统简档),其具有对其它使用简档(普通简档)的特定的访问权限。该方面对应于下面结合图5b详述的第二实施例。

在本发明的情境中,通过“第一小应用程序试图访问第二小应用程序”意指以下动作中的任何一个:第一小应用程序的对象试图读取或写入第二小应用程序的对象的静态数据的事实;第一小应用程序的对象试图读取或写入第二小应用程序的对象的非静态数据的事实;以及第一小应用程序的对象试图调用第二小应用程序的对象的方法的事实。因此,访问可以是指静态数据,也可以是指非静态数据或方法。要注意到,控制对静态数据的访问的尝试是本发明方法与javacard技术相比的差异之处。例如,在2005年的规范“javacard规范2.2.2最终版本-运行时环境规范”的章节6.1.6中,指出必须使用具有可共享接口的对象来跨多个上下文共享数据。但是,用具有可共享接口的对象来替换静态数据在编程复杂度方面、以及在使用时在执行性能方面成本要高得多。本发明使得能够在不必在编程时将静态数据转换成具有可共享接口的对象的情况下保护静态数据。

在euicc型电子卡或iuicc型电子组件的上下文中,保护“参考”型静态数据产生特定的问题。本发明确保了恶意操作者不能修改将作为安装在同一euicc型电子卡上或同一iuicc型电子组件上的竞争的使用简档的静态数据的参考,并且从而使得能够避免拒绝服务dos(英语为“denyofservice”)攻击干扰被攻击的使用简档的正确运行。

因此,软件防火墙fw使得能够管理多简档的情形,即当多个使用简档共存于同一euicc型电子卡或同一iuicc型电子组件内的情况。这样的多简档情形例如当sim卡允许访问由不同运营商提供的电话服务时出现。然后,使用简档与sim卡上的每个运营商相关联,并且可以在各种使用简档中选择性地激活使用简档,以便能够访问与所述使用简档相关联的运营商的电话服务。软件防火墙fw使得能够确保活动简档的小应用程序无法访问或修改其它使用简档的数据,特别是关于静态数据的数据。

应当注意到,在智能卡euicc上或在电子组件iuicc中,仅一个上下文且仅一个简档(所讨论的上下文所在的简档)同时活动。其它上下文和其它简档已被创建,但不活动。在智能卡euicc或电子组件iuicc的使用期间,例如当所述智能卡euicc或组件iuicc的用户从向一个运营商订购的电话服务切换到向另一个运营商订购的另一个电话服务时,或者当所述智能卡euicc或电子组件iuicc的用户从第一供应商提供的服务切换到另一供应商提供的服务时,发生简档的选择性变更。还要注意到,可以手动或自动地实现简档切换。在此之前活动的简档将变为不活动,并且在此之前不活动的简档将变为活动。

图3示意性地示出了根据第一实施例的属于不同上下文的小应用程序之间的访问管理。

在图3中以例示的方式呈现了两个使用简档pa和pb。例如,考虑使用简档pa和pb被用在智能卡euicc的上下文中,并且智能卡euicc是sim卡。于是,简档pa和pb对应于对不同运营商的电话服务的订阅或对针对不同用户名的电话服务的订阅。

简档pa包含第一上下文ca1和第二上下文ca2。第一上下文ca1包含小应用程序aa1和小应用程序aa2。第二上下文ca2包含小应用程序aa4和小应用程序aa5。简档pa还包含第三上下文ja,其是用于当简档pa为活动时由jcre环境实例化的小应用程序。在图3中,第三上下文ja包含小应用程序aa3。简档pa还包含用于简档pa的各种上下文的静态数据sa。

简档pb包含第四上下文cb1和第五上下文cb2。第四上下文cb1包含小应用程序ab1和小应用程序ab2。第五上下文cb2包含小应用程序ab5。简档pb还包含第六上下文jb,其是用于当简档pb为活动时由jcre环境实例化的小应用程序。在图3中,第六上下文jb包含小应用程序ab3和小应用程序ab4。简档pb还包含用于简档pb的各种上下文的静态数据sb。

当在同一使用简档内在小应用程序之间实施访问时(简档内),软件防火墙fw应用上下文间访问验证规则,即特别是javacard技术已经提及的通常访问验证规则(诸如在规范“javacard经典平台”例如版本3.0.4中可见)。软件防火墙fw然后针对目标小应用程序验证所述目标小应用程序提供可共享接口,并且所述目标小应用程序因此授权来自另一小应用程序的访问。

当从属于第一使用简档(例如,简档pb)的第一小应用程序向属于第二使用简档(例如,简档pa)的第二小应用程序实施访问时,软件防火墙fw拒绝访问,即使第二小应用程序提供了可共享接口并且因此授权了来自另一小应用程序的访问。这使得能够确保使用简档之间的密封性,即使该访问涉及了静态数据。

因此,图3示出了软件防火墙fw拒绝从简档pa向简档pb发生的任何访问(并且同样适用于从简档pb向简档pa发生的任何访问)。特别是,图3显示出软件防火墙fw拒绝以下访问,而与该访问意图去往的小应用程序的任何可共享接口无关:

-从上下文cb1的小应用程序向上下文ca1的小应用程序的访问(同样适用于目的地为上下文ca2的访问);

-从上下文cb1的小应用程序向上下文ja的小应用程序的访问(同样适用于来自上下文cb2的访问);

-从上下文jb的小应用程序向上下文ja的小应用程序的访问;

-从上下文jb的小应用程序向静态数据sa的访问;

-从上下文jb的小应用程序向上下文ca2的小应用程序的访问(同样适用于目的地为上下文ca1的访问);

-从上下文cb2的小应用程序向上下文ca2的小应用程序的访问(同样适用于目的地为上下文ca1的访问);以及

-从上下文cb2的小应用程序向静态数据sa的访问(同样适用于来自上下文cb1的访问)。

因此,借助于软件防火墙fw保护了对简档pa和pb的静态数据的访问。因此,不需要变更上下文以便确保该保护。如上面列出的,此保护还扩展到涉及上下文变更的访问。

一种实现可能是在解译器中存储使用简档标识表,其将使用简档与每个实例标识符相关联。对于给定对象,解译器发现相关的实例标识符,并且从而找到相关的使用简档。

然而,在优选实施例中,编程对象具有包含关于这样的使用简档或其归属的信息的相应头部。此处指出与静态数据有关。因此,与javacard技术相比,这假定在存储器模型级别进行修改,因为当激活使用简档时,操作系统应存储标识所述使用简档(称为活动简档)的信息。操作系统随着使用智能卡euicc或电子组件iuicc而存储并保存该信息。另外,由于解译器包括负责存储器分配的分配器,因此也相比于javacard技术修改了分配器,以便在每个新创建的对象的头部中告知活动简档。通过将使用简档的信息直接存储在属于所述使用简档的对象中,在解译试图访问所述对象的中间代码期间,对使用简档的信息的访问特别快。实际上,使用简档的信息与要验证的相同数据位于同一位置的事实使得对其的访问更快。优选实施例使得能够避免在访问对象时与验证使用简档识别表有关的两次迂回。因此,优选实施例执行起来更快,并且避免了必须确保同一实例标识符用于不同的使用简档。

因此,在特定实施例中,其解译相对于javacard技术被修改的中间代码是:

-针对静态数据:getstatic、putstatic;以及

-针对非静态数据和方法:getfield、putfield、athrow、<t>aload、<t>astore、arraylength、checkcast、instanceof、invokevirtual、invokeinterface、invokespecial、invokestatic,其中上面的<t>是指各种类型的数组中间代码(英语为“arraybytecode(阵列字节码)”)。

图4示意性地示出了根据第二实施例的属于不同上下文的小应用程序之间的访问管理。

在第二实施例的情境中,定义了特定的使用简档。它被称为系统简档ps。系统简档具有对其它使用简档(于是称为普通简档)的特定的访问权限。因此在图4中以例示的方式再次看到已经在图3中呈现的简档pa(同样可以示出简档pb代替简档pa)。

在特定实施例中,系统简档是与由智能卡euicc或电子组件iuicc的制造商实例化的小应用程序相关联的使用简档。系统简档负责下载、安装和设置普通简档。例如,考虑智能卡euicc是sim卡的情况,系统简档与sim卡的制造商相关联,并且普通简档与智能卡euicc的用户向其实施服务订阅的不同的电话运营商相关联。因此,系统简档尤其使得能够集中所有普通简档共有的任何数据,诸如智能卡euicc本身的管理数据,例如,ecasd(英语为“euicccontrollingauthoritysecuredomain(euicc控制机构安全域)”)和isd-r(英语为“issuersecuritydomain-root(发行商安全域-根部)”)。每个普通简档还可以包括特定于其的管理数据,例如,casd(英语为“controllingauthoritysecuredomain(控制机构安全域)”)。在使用电子组件iuicc的情境下也是如此。

简档ps包含第七上下文cs1和第八上下文cs2。第七上下文cs1包含小应用程序as1。第八上下文cs2包含小应用程序as4。简档ps还包含第九上下文js,其是用于当简档ps为活动时由jcre环境实例化的小应用程序。在图4中,第九上下文js包含小应用程序as2和小应用程序as3。简档ps还可以包含对简档ps的各种上下文共有的静态数据ss。

当在同一使用简档内在小应用程序之间实施访问时(简档内),软件防火墙fw应用上下文间访问验证规则,即特别是javacard技术已经提及的通常访问验证规则(诸如在规范“javacard经典平台”例如版本3.0.4中可见)。软件防火墙fw然后针对目标小应用程序验证所述目标小应用程序提供可共享接口,并且所述目标小应用程序因此授权来自另一小应用程序的访问。

另外,当从属于简档ps的第一小应用程序向属于简档pa的第二小应用程序实施访问时,软件防火墙fw接受该访问,并且还应用上下文间访问验证规则。因此,软件防火墙fw尤其是验证第二小应用程序是否提供可共享接口并且因此授权来自另一小应用程序的访问。因此,简档ps可以访问普通简档pa和pb。换言之,这意味着软件防火墙fw如该访问是简档内访问那样应用上下文间访问验证规则。

因此,图4示出了软件防火墙fw接受从简档ps向简档pa发生的任何访问(并且同样适用于从简档ps向简档pb发生的任何访问)。特别是,图4显示出软件防火墙fw接受以下访问:

-从上下文cs1的小应用程序向上下文ca1的小应用程序的访问(同样适用于目的地为上下文ca2的访问);

-从上下文cs1的小应用程序向上下文ja的小应用程序的访问(同样适用于来自上下文cs2的访问);

-从上下文js的小应用程序向上下文ja的小应用程序的访问;

-从上下文js的小应用程序向上下文ca2的小应用程序的访问(同样适用于目的地为上下文ca1的访问);

-从上下文cs2的小应用程序向上下文ca2的小应用程序的访问(同样适用于目的地为上下文ca1的访问);以及

-从上下文cs2的小应用程序向静态数据sa的访问(同样适用于来自上下文cs1的访问)。

相反,软件防火墙fw拒绝从简档pa发出的(同样适用于来自简档pb的访问)、目的地为简档ps的访问,而与该访问意图去往的小应用程序的任何可共享接口无关。

因此,借助于软件防火墙fw保护了对简档ps的静态数据的访问。因此,不需要变更上下文以便确保该保护。如上面列出的,此保护还扩展到涉及上下文变更的访问。

通过阅读图3和4的描述要指出,每个小应用程序与单个上下文相关联,并且每个上下文与一个或多个小应用程序相关联。还要指出,每个上下文与单个使用简档相关联,并且每个使用简档与一个或多个上下文相关联。

图5a示意性地示出了根据第一实施例的由软件防火墙fw实现的用于处理小应用程序间的访问的算法。

在步骤501中,软件防火墙fw接收要验证的访问。由解译器——即虚拟机jcvm——向软件防火墙fw通知要验证的访问。优选地,实施访问涉及静态数据。然而,相同的原理也优选地应用于非静态数据和/或方法。

在步骤502中,软件防火墙fw确定访问的源简档。换言之,软件防火墙fw验证发起所讨论的访问的小应用程序属于哪个使用简档。代表活动简档的信息与要验证的访问并行地提供给软件防火墙fw。

在步骤503中,软件防火墙fw确定访问的目的地简档。换言之,软件防火墙fw验证所讨论的访问的目标小应用程序属于哪个使用简档。该访问是去往与在所述目的地简档中实例化的给定小应用程序有关的对象。该对象优选地包含关于所述对象在其中被实例化的所述目的地简档的信息。因此,每个对象都是自动描述的,如前文详述的那样。

此处还要指出,另一种方法包括在软件防火墙fw中包括表格,所述表格列出存在于智能卡euicc或电子组件iuicc上的使用简档、以及存在于每个使用简档内的上下文、以及存在于每个上下文内的小应用程序。每次实例化使用简档、上下文和小应用程序时更新此表格。因此,软件防火墙fw在所述表格中找到所讨论的访问的目标小应用程序属于哪个使用简档。

在步骤504中,软件防火墙fw验证在步骤502处确定的访问的源简档是否与在步骤503处确定的访问的目的地简档相同。通常,活动的使用简档——即源简档——被保存在软件防火墙fw可以访问的持久变量中。当访问的源简档与访问的目的地简档相同时,实施步骤506;否则实施步骤505。

在步骤505中,软件防火墙fw拒绝访问,而与访问的目标小应用程序是否提供可共享接口的事实无关。因此,不允许对该访问的目标小应用程序的任何访问。然后结束图5a中的算法。

在步骤506中,软件防火墙fw应用上文提及的上下文间访问验证规则。换言之,软件防火墙fw特别验证该访问的目标小应用程序是否提供可共享接口。因此,如果该访问的目标小应用程序提供了可共享接口,则允许对该访问的目标小应用程序的访问;否则拒绝访问,并且不允许对该访问的目标小应用程序的任何访问。然后结束图5a中的算法。

图5b示意性地示出了根据第二实施例的由软件防火墙实现的用于处理小应用程序间的访问的算法。

在步骤551中,软件防火墙fw接收要验证的访问。步骤551与步骤501相同。因此,优选地,该访问涉及静态数据。然而,相同的原理也优选地应用于非静态数据和/或方法。

在步骤552中,软件防火墙fw确定访问的源简档。步骤552与步骤502相同。

在步骤553中,软件防火墙fw确定访问的目的地简档。步骤553与步骤503相同。

在步骤554中,软件防火墙fw验证在步骤552处确定的访问的源简档是否与在步骤553处确定的访问的目的地简档相同。步骤554与步骤504相同。当访问的源简档与访问的目的地简档相同时,实施步骤556;否则实施步骤560。

在步骤556中,软件防火墙fw应用上文提及的上下文间访问验证规则。换言之,软件防火墙fw验证该访问的目标小应用程序是否提供可共享接口。因此,如果该访问的目标小应用程序提供了可共享接口,则允许对该访问的目标小应用程序的访问;否则拒绝访问,并且不允许对该访问的目标小应用程序的任何访问。然后结束图5b中的算法。

在步骤560中,软件防火墙fw验证访问的源简档是否是系统简档ps。如果是这种情况,则实施步骤556;否则实施步骤561。换言之,当此处实施步骤556时,软件防火墙fw验证访问的目标小应用程序是否提供可共享接口。因此,如果该访问的目标小应用程序提供了可共享接口,则允许对该访问的目标小应用程序的访问;否则拒绝访问,并且不允许对该访问的目标小应用程序的任何访问。然后结束图5b中的算法。因此,与普通简档不同,如果所述小应用程序分别提供可共享接口,则系统简档ps可以实施对其它简档的小应用程序的访问。

在步骤561中,软件防火墙fw拒绝访问,而与该访问的目标小应用程序是否提供可共享接口的事实无关。因此,不允许对该访问的目标小应用程序的任何访问。然后结束图5b中的算法。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1