CN101073098A

CN101073098A - 多应用程序智能卡上的应用程序管理系统及方法

Info

Publication number: CN101073098A
Application number: CNA2005800419480A
Authority: CN
Inventors: 格特·让·施里恩; 卢茨·帕佩
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2004-12-07
Filing date: 2005-12-02
Publication date: 2007-11-14
Also published as: EP1839282A1; JP2008533547A; US20090235352A1; WO2006061754A1

Abstract

为了提供一种管理系统(100)及其方法，用于管理至少一个安装权限(40a)以便在具体为多应用程序智能卡的智能卡(300)上安装至少一个应用程序(46，42)，其中可能地，具体在智能卡(300)上控制应用程序的具体为智能卡的发行商的第一方或第一单元(10)，能够将此控制转移(44)到至少一个第二方或第二单元(20)，已提出的是，管理系统(100)被设计为，具体在智能卡(300)上管理所述安装权限(40a)，使得授权具体为至少一个第三方应用程序提供商的至少一个第三方或第三单元来发挥具体是在智能卡(300)上安装其应用程序(42)的所述安装权限(40a)的职能，可从具体为智能卡(300)的发行商的至少一个第一方或第一单元(10)转移到至少一个第二方或第二单元(20)。

Description

多应用程序智能卡上的应用程序管理系统及方法

技术领域

本发明涉及一种管理系统及方法，用于管理至少一种安装权限以便在具体为多应用程序智能卡的智能卡上安装至少一个应用程序。

背景技术

在现有的技术文献WO 97/10562 A1中，公开了一种智能卡查询台(kiosk)的程序设计接口。更具体地，现有的技术文献WO 97/10562A1描述了一些查询台，应用程序提供商或供应商可以在该查询台处安装其软件，以便与拥有智能卡的用户进行业务办理。该查询台为这些应用程序提供了标准接口，这样可以不考虑用户所拥有的智能卡的类型，来办理业务以及更新智能卡上的数据结构。然而，这种程序设计接口并不涉及智能卡上的应用程序的委托管理。

在现有技术文献EP 0 798 673 A1中公开了一种在智能卡上安全地加载命令的方法，具体为一种用于确认智能卡上必须加载或执行的应用程序或命令的基本技术，其中两方都必须就智能卡上所允许运行的应用程序达成一致。具体地，现有技术文献EP 0 798 673 A1描述了如何通过首先让诸如智能卡发行商和信任的第三方这样的两独立方批准命令并产生鉴权码，来将该命令和/或应用程序安全地加载到智能卡上。这两方都具有在智能卡中为已知的密钥，这样智能卡在执行命令之前可检查，该命令或应用程序是否确实由这些方所批准。然而，现有技术文献EP 0 798 673 A1没有讨论使一方控制智能卡上的应用程序以及随后能够将此控制转移到第二方的功能性。

在现有技术文献WO 98/43212 A1中，公开了对智能卡上的应用程序的发行后下载。具体地，所描述的方法允许卡发行商在智能卡发行之后增加应用程序，具体是在有效期内。可通过被称为卡域的第二应用程序来安装应用程序。因此，描述了也在GP(全局平台)/OP(开放平台)标准中指定了的所谓SD(安全域)的基本功能。然而，现有技术文献WO 98/43212 A1没有讨论委托管理的可能性，即，让除了卡发行商的任意其他用户在发行之后安装应用程序。此外，现有技术文献WO 98/432 12 A1不涉及可安装在卡上的应用程序的管理转移。

在现有技术文献US 2002/0040936 A1中描述了如何在全局平台/开放平台标准内执行委托管理。委托管理表示应用程序提供商可在发行之后将其自身的应用程序安装在智能卡上，而不需要卡发行商在线；与之相反，在早期的智能卡系统中，应用程序的增加只能由发行商来完成。

然而，在委托管理中，来自第三方应用程序提供商的应用程序首先需要由卡发行商来批准。卡发行商产生用于新应用程序的所谓的数据鉴权模式，其中智能卡可在稍后检查。因此，在这种情况下，卡发行商仍控制可安装到智能卡上的应用程序。

GP(全局平台)规范(参见GlobalPlatform Consortium，Card Specification，Version 2.1.1.，March 2003，在http://www.globalplatform.org/可获得)定义了一种用于动态多应用程序智能卡的体系结构及标准。它们的目标是提供到应用程序以及卡外管理系统的独立于供应商以及硬件的接口。GP标准为当前唯一已知的(并且因此是最先进的)指定了这样的多应用程序卡管理系统的标准。

在GP中，卡发行商对关于智能卡上的应用程序管理具有最有力的控制。卡发行商具有用于智能卡上的卡管理器的主密钥(master key)，以此可以执行加载操作、安装操作以及删除操作。

GP允许其他应用程序提供商获得卡内SD(安全域)的密钥。安全域是一种特定类型的应用程序，可向其拥有者提供诸如密钥处理、加密、解密等的安全服务，并可由应用程序提供商用于将新的应用程序加载并安装到智能卡。应用程序与应用程序提供商的安全域相关联。拥有SD(安全域)密钥的应用程序提供商可为安全域设置安全通道，并且在其应用程序是由卡的发行商预先批准的情况下安装应用程序。这被称作GP(全局平台)内的委托管理。

在可安装应用程序之前，应用程序提供商必须从卡发行商处获得安装权标(token)。此权标，即预鉴权，使用其所允许的权力来唯一地识别从属的应用程序代码，并由卡发行商数字签名。安全域将此权标传递到卡管理器，该卡管理器检验此权标并执行对小应用程序(applet)或应用程序的实际安装。允许应用程序提供商删除与其安全域相关联的应用程序。

此外，GP标准还允许卡发行商之外的另一个实体来共同决定可安装到卡上的应用程序。此实体在GP内称为CA(控制机构)。CA的卡内表征为称为CASD(控制机构安全域)的特定安全域。

如果智能卡上存在CASD，则新的应用程序必须在安装之前另外加上来自CA的加载文件签名。因此，通过具体为应用程序提供商SD的委托管理来加载的应用程序，必须加上来自发行商的加载和/或安装权标以及来自CA的应用程序代码上的签名。因此，在将此应用程序安装到智能卡之前，发行商和控制机构都必须批准此应用程序。

虽然GP(全局平台)规范提供了在多应用程序智能卡上处理卡管理的先进方法，GP系统也有其局限性。例如，GP不支持这样的方案，其中付费机构安装其应用程序，并接管应用程序管理功能。应用程序管理意味着控制哪些应用程序可安装在智能卡上。

此外，GP不允许使应用程序提供商能够安装任意想要的代码的灵活权限。这样的独立于应用程序的安装权限在卡发行商不想要为每个单一的应用程序发行新的安装权限的情况下是有用的(如果大量应用程序提供商都具有其希望安装的应用程序代码的多个版本，这可能是繁重的任务)。

例如，如果两方都已经同意声明应用程序提供商将不安装有害代码，可向应用程序提供商发行独立于应用程序的安装权限。这样可以以合法的方法来加强第三方小应用程序的正确行动。

发明内容

从上面所描述的缺点以及短处出发，并考虑所讨论的现有技术，本发明的目的是进一步发展技术领域中所描述类型的管理系统，以及技术领域中所描述类型的方法，这样控制智能卡上的应用程序的具体为智能卡发行商的至少一个第一方或第一单元能够将此控制转移到至少一个第二方或第二单元。

本发明的目的通过包括权利要求1的特征的管理系统以及包括权利要求12的方法来实现。在权利要求1的从属权利要求中，公开了本发明的有利实施例以及有利改进。

本发明主要是基于可转移的应用程序管理的思想，即，包括使一个单元或一方控制智能卡上的应用程序以及随后能够将此控制转移到至少一个第二单元或第二方的功能。

因此，根据本发明的管理系统使用比传统管理系统更灵活的方法来处理应用程序管理，使得可将应用程序安装到智能卡上的控制从第一方或第一单元转移到第二方或第二单元。例如，具体为智能卡发行商的第一方或第一单元，允许某几方接管关于将应用程序安装到智能卡上的完全控制。

根据本发明的优选实施例，这种应用程序管理方法可通过让第一方或第一单元提供以至少一个数字证书(在下文的章节“附图说明”中将对数字证书进行更详细的描述)为形式的至少一个安装权限来实现。

有利地，在安装新应用程序时，这些安装权限由管理系统或卡管理器来检查，管理系统或卡管理器为第一方或第一单元的卡内表征，具体为卡发行商的卡内表征。

此外，根据有利的实施例，提出了，实现一种特定类型的至少一个应用程序插槽，用于安装诸如至少一个付费应用程序的至少一个管理使能应用程序。这产生了如下的优点：如果第二单元已从第一方或第一单元获得适当的安装权限，则诸如付费机构的第二单元可安装诸如付费小应用程序(applet)的管理使能应用程序。

一旦安装了这个管理使能应用程序，则具体为卡管理器的管理系统强制执行了：此第二单元的公钥而非第一方或第一单元的公钥将被用于校验安装权限。

此外，根据优选实施例，一旦删除了管理使能应用程序，则管理系统将安装权限校验密钥设置回第一方或第一单元的公钥。

例如，接管应用程序管理的能力在以下情况下是有用的：

-第二单元将重要的应用程序安装到智能卡上，必须防止其中的滥用。以及

-智能卡的业务责任转移到第二单元。

在该情况下，第二单元需要加强对可安装到智能卡上的其他应用程序的控制。此特征可通过以下情况进行示例说明：

一旦管理使能应用程序被安装到卡上，则付费机构负责与智能卡的财务往来。付费机构意图控制可安装的其他应用程序，以阻止可能有害的代码(可能滥用付费小应用程序)进入智能卡。

在诸如GP/OP的传统系统中，可以在将某些应用程序加载到智能卡之前，激活必须提供签名的控制机构。然而，还需要来自发行商的加载权标和/或安装权标；因此这仅仅是应用程序提供商必须获得的附加权限。

与此相反，本发明允许将应用程序管理完全转移到可以是付费机构的控制机构。在传统的卡管理系统中，付费机构通常为控制该智能卡的卡发行商。本发明允许卡发行商独立于第二单元(例如独立于付费机构)地发行智能卡。

此外，根据本发明的优选实施例，第二单元可在随后的一个时间点上安装其管理使能应用程序，甚至是在已安装了其他第三方应用程序之后。这样，第二单元需要能够检查智能卡上已存在的其他应用程序。

根据有利的实施例，第二单元可取回可由第二单元经由至少一个中央服务器所检查到的应用程序标识符以及应用程序提供商标识符，或者第二单元可读取已安装的小应用程序或应用程序的准确的应用程序代码。此选项优选地由管理系统提供，并可选地由底层的操作系统支持。

如果第二单元在智能卡上发现第二单元所不信任的第三方应用程序，则第二单元将不安装诸如其付费小应用程序的应用程序。在这种情况下，根据优选实施例，第二单元可发起对智能卡上已存在的具体为不信任应用程序的应用程序的至少一个删除请求。然而，根据本发明的有利改进，第一方或第一单元的应用程序只能由第一方或第一单元删除。

根据本发明的另外优选实施例

-智能卡的第一方或第一单元和/或

-智能卡的第二方或第二单元和/或

-智能卡的第三方或第三单元和/或

-至少一个智能卡的另外一方或另外单元

被允许删除和/或卸载智能卡上已存在的至少一个应用程序，其中，可选地这个删除和/或卸载的行为必须经由用户确认。

从用户的角度，优选地，给予用户确定其智能卡上的可用应用程序的权力。因此，根据本发明的有利实施例，提出了允许所有卡变化，具体为智能卡上所发生的任意安装或删除，都应由经用户确认。

此外，根据本发明的优选实施例，管理系统通过向用户发送至少一个确认请求以便安排用户对于所请求的卡变化的确认。这样的请求优选地通过至少一个智能卡读取设备发送到用户的至少一个主机终端。

例如，根据本发明的有利实施例，用户可通过如下方式确认卡的变化

-通过在主机终端按下至少一个按钮或按键和/或

-通过输入其PIN(个人识别号)和/或

-通过至少一个生物特征来识别。

后者的形式更安全，因为只有指定的用户才能执行这个行为。

本发明还涉及一种集成电路，该集成电路包括至少一个上面所描述的管理系统和/或根据上面所描述的方法进行操作。

此外，本发明还涉及一种智能卡，具体为一种多应用程序智能卡，该智能卡包括至少一个上面所描述的IC(集成电路)。

本发明最后还涉及至少一个上面所描述的管理系统和/或至少一个上面所描述的集成电路和/或上面所描述的方法用于上面所描述的多应用程序智能卡上的灵活且可转移的应用程序的使用。

如上面所讨论的，存在一些以有利的方式来体现以及改善本发明教义的选项。为此，参见权利要求1的从属权利要求；参考作为示例的优选实施例以及附图，对本发明的另外的改进、特征以及优点进行更详细的解释。

附图说明

图1示意性地示出了根据本发明的管理系统及其根据本发明的工作方法的实施例。

具体实施方式

本发明的示例性实施例由此问题开始：传统的多应用程序智能卡采用卡管理系统来使卡发行商10能够控制可安装到用户400的智能卡上的应用程序。然而，这样的系统不够灵活以支持如下商业模型，即其中另一(授权)方必须能够接管应用程序管理功能。

这样的功能在诸如付费机构在智能卡300上安装其付费小应用程序(applet)，并负责与智能卡300的财务往来的情况下是希望的。这样，付费机构20意图控制除了其付费应用程序46以外所允许运行的其他应用程序42，这样可避免可能有害的代码。

根据本发明，提出了基于证书40b的灵活的卡管理系统100，以便实现这样的商业模型。图1描述了，用于在多应用程序智能卡300上的灵活且可转移的应用程序管理的管理系统100以及被布置在智能卡300上并包括该管理系统100的集成电路200的第一实施例。

第一方或第一单元，即智能卡发行商10发行了一个或多个安装权限40a到其他方20、30，具体为

-到第二方或第二单元，即到付费机构20，以及

-到第三方或第三单元，即到第三方应用程序提供商30。

在图1的示例性情况下，智能卡发行商10向付费机构20发行所述安装权限40a。然后，付费机构20可将此安装权限40a呈现给智能卡300，其中卡管理系统(所谓的卡管理器100)可解释并校验该权限；通过这样的解释和校验，管理使能应用程序，即付费应用程序46被允许安装在智能卡300上。

管理系统100被设计为，管理关于智能卡300的所述安装权限40a，使得用于授权(参见图1中的附图标记22)一个或多个应用程序提供商30将其各自的应用程序42安装到智能卡300的职能，可从智能卡发行商10转移(参见图1中的附图标记44)到付费机构20。

可从图1中得到应用程序管理40的转移44，使得安装权限40a不属于智能卡发行商10，而是已经从此智能卡发行商10进入付费机构20。因此，现在为应用程序管理40负责的该付费机构20可授权(参见图1的附图标记22)第三方应用程序提供商来发挥此安装权限40a。

在这个上下文中，一旦所述付费机构20将付费小应用程序46安装到智能卡300上，则将应用程序管理40的职能从智能卡发行商10转移到付费机构20。因此，在付费机构20已安装了其付费应用程序46之后，付费机构20可向第三方或应用程序提供商30发行(参见图1的附图标记22)安装权限40a。应用程序提供商30可将所述安装权限40a呈现给智能卡300，以便安装其应用程序42。

一旦从智能卡300中删除和/或卸载管理使能应用程序46，则应用程序管理40的职能从付费机构20后退(参见图1中的附图标记54)到卡发行商10，例如，由于安全和/或卡应用程序管理40的控制。

管理系统100支持根据应用程序以及独立于应用程序的安装权限40a，其中，以由智能卡发行商10所提供的数字证书40b的形式在智能卡300上实现或表征出安装权限40a。在下文中，描述了如何用这样的数字证书来创建灵活的安装权限40a。

基本上，数字证书40b具备来自作者的数字签名的消息或声明。签名人典型地通过使用其私钥给全部消息的散列(hash)加密来创建这样的数字签名。任何人都可以通过使用签名人的公钥来校验此签名，以取回所包含的散列值，并将此散列值与消息自生的散列值进行比较(对于数字证书，更详细的介绍见B.Schneier，Applied Cryptography，第二版，John Wiley&Sons Inc，1996)。

根据本发明，通过以下列方法定义具有某些字段的数字证书40b，创建了用于授权应用程序42、46安装到智能卡300上的安装权限40a：

C[d_AM]{Type，Date，Valid，e_AM，AppID，CodeID，e_AP，Target，Options} (1)

此构架表示使用应用程序管理器的私钥d_AM签名的证书40b，该应用程序管理器可以是卡发行商10或付费机构20；此证书40b具有以下的字段：

-Type：表示证书的类型；Type表示其是否关系到第三方应用程序提供商(例如Type＝IR)的安装权限40a，或者付费机构(例如Type＝Pay)的安装权限40a；

-Date：表示证书的发行日期；

-Valid：表示直到或者证书有效的时间间隔；

-e_AM：表示作为证书发行商的应用程序管理器10、20的公钥；因此这个密钥可用于校验证书的签名；

-AppID：表示待安装的应用程序42、46的唯一标识符；这个值还可用于表示其涉及独立于应用程序的安装权限(例如，AppID＝0)；

-CodeID：表示用于识别待安装的应用程序42、46的代码的标识符；优选地，通过将散列函数应用到应用程序代码来产生CodeID；

-e_AP：表示应用程序提供商20或30的公钥；可将e_AP用于在应用程序提供商20或30与卡管理器或管理系统100之间设置安全通道；

-Target：表示安装权限40a应用于哪一智能卡300；这里可表示成智能卡识别号的集合；可选地，可以将Target表示成：安装权限40a对于所有的智能卡300都是有效地(Target＝All)；

-Options：保留以表示一些其他的证书选项；例如，可在此字段Options中获得涉及证书撤销的信息(例如，在线撤销服务器的名称)。

在下文中，给出了在灵活的卡管理系统100中可提供的安装权限40a的一些示例。

首先，解释第三方应用程序的安装权限的一些示例：

允许具有公钥e_API的第三方应用程序提供商30安装具有应用程序标识符AP1A1的应用程序42的安装权限40a，是这样的：

C[d_Issuer]{Type＝IR，Date＝05-10-2003，Valid＝till 2004，e_AM＝e_Issuer，AppID＝AP1A1，CodeID＝28264465271182，e_AP＝e_AP1，Target＝(014423-014520)，Options} (2)

安装权限40a由卡发行商10发行，并使能没有安装付费应用程序46的序列号为014423到014520的智能卡300上的安装。例如，如果这些智能卡300之一具有VISA付费小应用程序，则VISA(其功能作为付费机构20)必须为这样的安装权限40a签名，此外，可能的证书可以是：

C[d_VISA]{Type＝IR，Date＝05-10-2003，Valid＝1year，e_AM＝e_VISA，AppID＝AP1A1，CodeID＝28264465271182，e_AP＝e_API，Target＝All，Options}

(3)

可通过忽略应用程序标识符以及代码标识符的规范来使得这样的安装权限40a独立于应用程序。这在下文的证书中进行例证：

C[d_VISA]{Type＝IR，Date＝05-10-2003，Valid＝1year，e_AM＝e_VISA，AppID＝0，CodeID＝0，e_AP＝e_API，Target＝All，Options} (4)

在下文中，给出了付费应用程序46的安装权限40a的示例：

卡发行商10可产生特定安装权限40a，允许付费机构20安装其付费小应用程序46，并且接管(参见附图标记44)此智能卡300上的应用程序管理。在下列示例中，VISA(由公钥e_VISA识别)被赋予安装付费小应用程序46的权限40a，并变成应用程序管理器：

C[d_Issuer]{Type＝PAY，Date＝02-08-2003，Valid＝till 2005，e_AM＝e_Issuer，AppID＝0，CodeID＝0，e_AP＝e_VISA，Target＝All，Options} (5)

在接收到此安装权限40a时，卡管理器检查来自卡发行商10(其中卡管理器知道卡发行商10的公钥)的签名，并与付费机构20设置SAC(安全鉴权通道)。在证书中表示出的公钥e_VISA被用于设置这样的SAC。基于此SAC，VISA可安装其付费应用程序46，并且将公钥传送到卡管理器，从那时起，将公钥用于校验安装权限40a。可选地，将公钥e_VISA用于此目的。

智能卡300上的管理系统或卡管理器100可校验证书，因为它知道卡发行商10的公钥e_Issuer。因此，可检验使用发行商10的私钥d_Issuer签名的证书。上面提出的权限40a允许付费机构20安装其应用程序46。从该时间点，卡管理器100将付费机构20的公钥(在此示例中为e_VISA)存储在其存储器内。

此时，可将此公钥用于检查VISA所发行的安装权限40a，如同具有上面所解释的标号为(2)和(3)的权限。一旦移除了VISA的小应用程序，卡管理器100删除公钥e_VISA，并且从该点开始再次使用卡发行商10的公钥e_Issuer来检查安装权限40a。

智能卡300上出现的任意这样的删除或安装需要由智能卡300的用户400来确认。为此，管理系统100向智能卡300的用户400的主机终端500发送确认请求48。

参考符号列表

100 卡管理器或卡管理系统

10 第一方或第一单元，用于控制智能卡300上的至少一个应用程序，具体为智能卡300的发行商

20 第二方或第二单元，具体为付费机构

22 授权第三方或第三单元30来将其应用程序42安装在智能卡300上，

具体为向第三方或第三单元30发行安装权限40a

30 第三方或第三单元，具体为第三方应用程序提供商

40 应用程序管理

40a 安装权限

40b 数字证书，具体为表征智能卡300上的安装权限40a

42 应用程序，具体为第三方或第三单元30的应用程序

44 鉴权22的职能和/或应用程序管理40的职能从第一方或第一单元10到第二方或第二单元20的转移

46 管理使能应用程序，具体为付费应用程序

48 确认请求

54 鉴权22的职能和/或应用程序管理40的职能从第二方或第二单元20到第一方或第一单元10的后退

200 集成电路

300 智能卡，具体为多应用程序智能卡

400 用户

500 主机终端

Claims

1.一种管理系统(100)，用于管理至少一种安装权限(40a)，以便在具体为多应用程序智能卡的智能卡(300)上安装至少一个应用程序(46，42)，其特征在于

被设计为具体在智能卡(300)上管理所述安装权限(40a)，使得授权(22)具体为至少一个第三方应用程序提供商的至少一个第三方或第三单元(30)来发挥具体在智能卡(300)上安装其应用程序(42)的所述安装权限(40a)的职能，可从具体为智能卡(300)的发行商的至少一个第一方或第一单元(10)转移(44)到至少一个第二方或第二单元(20)。

2.如权利要求1所述的管理系统，其特征在于

-所支持的安装权限(40a)

--与应用程序(42)有关，和/或

--独立于应用程序(42)，和/或

-以具体由第一方或第一单元(10)所提供的至少一个数字证书(40b)的形式，实现所述安装权限(40a)或至少在智能卡(300)上表示所述安装权限(40a)，以及

-所述管理系统(100)被设计为管理所述数字证书(40b)。

3.如权利要求1或2所述的管理系统，其特征在于，一旦第二方或第二单元(20)将至少一个管理使能应用程序(46)安装到智能卡(300)上，应用程序管理(40)的职能从第一方或第一单元(10)转移(44)到所述第二方或第二单元(20)。

4.如权利要求3所述的管理系统，其特征在于至少一个应用程序插槽，其中，所述管理系统(100)被设计为，一旦安装了管理使能应用程序(46)，则强制将第二方或第二单元(20)的至少一个公共密钥用于校验安装权限(40a)。

5.如权利要求3或4所述的管理系统，其特征在于，一旦删除和/或卸载管理使能应用程序(46)，应用程序管理(40)的职能从第二方或第二单元(20)后退到第一方或第一单元(10)。

6.如权利要求1到5的至少之一所述的管理系统，其特征在于，所述第二方或第二单元(20)

-是付费机构，在将至少一个付费应用程序作为管理使能应用程序(46)安装在智能卡(300)上之后，执行应用程序管理(40)的职能，和/或

-可识别智能卡(300)上已存在的其他应用程序，和/或

-被允许检查智能卡(300)上已经可用的其他应用程序的至少一个对应的应用程序代码，和/或

-可对智能卡(300)上已存在的应用程序发起至少一个删除请求。

7.如权利要求1到6的至少之一所述的管理系统，其特征在于，第一方或第一单元(10)和/或第二方或第二单元(20)和/或第三方或第三单元(30)和/或至少一个另外方或另外的单元，被允许删除智能卡(300)上现有的至少一个应用程序，其中此删除和/或卸载行为必须经由用户(400)确认。

8.如权利要求1到7的至少之一所述的管理系统，其特征在于，智能卡(300)的任意变化，具体为智能卡(300)上发生的任意安装或删除，需要由智能卡(300)的用户(400)来确认，其中，用户(400)的确认具体由管理系统(100)来执行。

9.如权利要求8所述的管理系统，其特征在于

-所述管理系统(100)通过至少一个主机终端(500)发送至少一个确认请求(48)，以及

-所述确认请求(48)必须由智能卡(300)的用户(400)来确认，其中，所述确认请求(48)可以通过如下方式被确认

--通过按下主机终端(500)的至少一个按钮或

--通过完成至少一个持卡人验证过程，具体地

---通过输入至少一个个人识别号和/或

---通过至少一个生物特征来识别。

10.一种集成电路(200)，其特征在于至少一个根据权利要求1到9的至少之一所述的管理系统(100)。

11.一种智能卡(300)，具体为多应用程序智能卡，其特征在于至少一个根据权利要求10所述的集成电路(200)。

12.一种用于管理至少一个安装权限(40a)的方法，以便在具体为多应用程序智能卡的智能卡(300)上安装至少一个应用程序(46，42)，其特征在于

管理所述安装权限(40a)，使得授权(22)具体为至少一个第三方应用程序提供商的至少一个第三方或第三单元(30)来发挥具体在智能卡(300)上安装其应用程序(42)的所述安装权限(40a)的职能，可从具体为智能卡(300)的发行商的至少一个第一方或第一单元(10)转移(44)到至少一个第二方或第二单元(20)。

13.根据权利要求1到9的至少之一所述的至少一个管理系统(100)和/或根据权利要求10所述的至少一个集成电路和/或根据权利要求12所述的方法在根据权利要求11所述的多应用程序智能卡(300)上的灵活且可转移的应用程序管理中的使用。