本申请公开了一种智能卡及其个人化数据的存储管理方法，涉及信息安全领域，所述智能卡包括：用户应用和服务应用；用户应用为当前需要接受个人化数据独立存储服务的应用，服务应用用来存储当前应用的个人化数据，当用户应用被删除时，服务应用内的个人化数据不会被同时删除。所述智能卡个人化数据的存储方法包括用户应用将个人化数据写入服务应用；服务应用在验证用户应用合法后，允许用户应用访问或修改个人化数据。采用本申请的智能卡及其个人化数据存储方法，不用担心删除Java智能卡中用户应用以后对个人化数据的影响，方便卡中应用代码升级，同时不影响修改后的应用代码在运行时数据的缺失，无需担心无法重新个人化的问题。
1.一种智能卡个人化数据的存储管理方法，其特征在于，应用于包括用户应用和服务应用的智能卡中；所述用户应用为当前需要接受个人化数据独立存储服务的应用，所述服务应用用来存储当前应用的个人化数据，当用户应用被删除时，服务应用内的个人化数据不会被同时删除；
服务应用在验证用户应用合法后，允许用户应用访问或修改个人化数据；
所述用户应用在初次进行个人化时，将个人化数据写入所述服务应用，只允许第一个个人化的用户应用有权访问服务应用；
用户应用将个人化数据写入服务应用，具体包括如下子步骤：
用户应用获取或保存服务应用的句柄；用户应用只在个人化指令时获取服务应用的句柄，并保存在非易失性存储器中，且在用户应用的代码或对象删除之前不需要再重复获取句柄；
在服务应用验证用户应用合法性后，服务应用接收并存储用户应用发送的个人化数据；
当用户应用被删除或修改，并重新实例化为新对象时，用户应用重新进行个人化，具体包括：步骤41：用户应用判断内部是否存储有服务应用的句柄，如果是，则用户应用调用服务应用提供的接口函数，获取或修改存储在服务应用中的个人化数据，否则执行步骤42；
步骤42：用户应用根据用户应用的应用标识AID向服务应用请求获取服务应用的句柄；
步骤43：服务应用判断接收到的用户应用的应用标识AID与内部存储的应用标识AID是否一致，如果是，则将句柄返回用户应用，执行步骤44，否则返回应用不匹配响应；
步骤45：用户应用生成随机数，使用认证密钥对随机数进行加密，生成密文，将密文和随机数发送至服务应用；
步骤46：服务应用使用内部存储的认证密钥对接收到的密文和随机数进行验证，当验证成功后，将密文验证成功标识置位，并将成功响应返回用户应用，执行步骤47，否则将密文验证成功标识复位，返回错误响应；
步骤47：用户应用接收到成功响应后，调用服务应用的接口函数，获取或修改存储在服务应用中的个人化数据。
2.如权利要求1所述的智能卡个人化数据的存储管理方法，其特征在于，用户应用在获取服务应用的句柄前，服务应用先判断是否已经存储有应用标识，如果是，则不允许用户应用写入个人化数据，否则将句柄返回给用户应用。
3.如权利要求1所述的智能卡个人化数据的存储管理方法，其特征在于，服务应用验证用户应用合法性，具体包括如下子步骤：用户应用向服务应用发送加密的认证密钥和校验码；
服务应用若解密认证密钥成功且验证校验码成功后，存储认证密钥，用户应用合法。
4.如权利要求1所述的智能卡个人化数据的存储管理方法，其特征在于，用户应用访问或修改个人化数据，具体包括如下子步骤：服务应用在获取密文验证成功标识为置位状态后，用户应用调用服务应用提供的接口函数，获取或修改存储在服务应用中的个人化数据。
5.如权利要求1所述的智能卡个人化数据的存储管理方法，其特征在于，若用户应用需要重新进行个人化，则在服务应用重新验证用户应用合法性后，用户应用调用服务应用提供的接口函数，用户应用获取或修改存储在服务应用中的个人化数据。
6.如权利要求5所述的智能卡个人化数据的存储管理方法，其特征在于，验证用户应用合法性，具体包括如下子步骤：用户应用生成随机数，使用认证密钥对随机数进行加密，生成密文，将密文和随机数发送至服务应用；
服务应用使用内部存储的认证密钥对接收到的密文和随机数进行解密验证，验证成功则验证用户应用合法。
7.如权利要求6所述的智能卡个人化数据的存储管理方法，其特征在于，在服务应用重新验证用户应用合法性前，还包括用户应用判断内部是否存储有服务应用的句柄，如果是，则用户应用调用服务应用提供的接口函数，获取或修改存储在服务应用中的个人化数据，否则根据用户应用的应用标识向服务应用请求获取服务应用的句柄。
8.如权利要求7所述的智能卡个人化数据的存储管理方法，其特征在于，服务应用判断接收到的用户应用的应用标识与内部存储的应用标识是否一致，如果是，则将服务应用的句柄返回用户应用，否则返回应用不匹配响应，不允许用户应用访问个人化数据。
一种智能卡及其个人化数据的存储管理方法
技术领域
[0001] 本申请涉及信息安全领域，尤其涉及一种智能卡及其个人化数据的存储管理方法。
背景技术
[0002] 现有Java智能卡中的应用以Applet对象的形式存在。在卡片个人化过程中，卡中的Applet在接收到安装指令时会实例化为一个对象，而对象在个人化时会创建若干个数组或变量等非易失性存储空间用来存储个人化数据，以方便在接下来的应用流程中使用这些数据。
[0003] 当智能卡中的Applet对象或代码被删除时，存储在对象中的个人化数据也会被删除。如果想要再次使用此Applet对象时，需要重新进行实例化和个人化。想象一个测试场景，如果卡片个人化以后又发现卡片中Applet代码有小的BUG需要修改，而此时个人化又不能重新进行(如对于涉及到安全方面的智能卡，个人化过程需要连接加密机等，重新个人化的条件很难再现时)，基于此，本申请应运而生。
发明内容
[0004] 本申请的目的在于提供一种智能卡及其个人化数据的存储管理方法，降低运维成本，简化费用管理方式，方便联合经营和大面积推广应用。
[0005] 为达到上述目的，本申请提供一种智能卡，包括：用户应用和服务应用；用户应用为当前需要接受个人化数据独立存储服务的应用，服务应用用来存储当前应用的个人化数据，当用户应用被删除时，服务应用内的个人化数据不会被同时删除。
[0006] 本申请还提供一种智能卡个人化数据的存储管理方法，应用于上述智能卡，包括：
[0007] 用户应用将个人化数据写入服务应用；
[0008] 服务应用在验证用户应用合法后，允许用户应用访问或修改个人化数据。
[0009] 如上的，其中，用户应用将个人化数据写入服务应用，具体包括如下子步骤：
[0010] 用户应用获取或保存服务应用的句柄；
[0011] 服务应用接收并存储用户应用的应用标识；
[0012] 在服务应用验证用户应用合法性后，服务应用接收并存储用户应用发送的个人化数据。
[0013] 如上的，其中，用户应用在获取服务应用的句柄前，服务应用先判断是否已经存储有应用标识，如果是，则不允许用户应用写入个人化数据，否则将句柄返回给用户应用。
[0014] 如上的，其中，服务应用验证用户应用合法性，具体包括如下子步骤：
[0015] 用用户应用向服务应用发送加密的认证密钥和校验码；
[0016] 服务应用若解密认证密钥成功且验证校验码成功后，存储认证密钥，用户应用合法。
[0017] 如上的，其中，用户应用访问或修改个人化数据，具体包括如下子步骤：
[0018] 用户应用将个人化数据写入服务应用时，置位密文验证成功标识；
[0019] 服务应用在获取密文验证成功标识为置位状态后，用户应用调用服务应用提供的接口函数，获取或修改存储在服务应用中的个人化数据。
[0020] 如上的，其中，若用户应用需要重新进行个人化，则在服务应用重新验证用户应用合法性后，用户应用调用服务应用提供的接口函数，用户应用获取或修改存储在服务应用中的个人化数据。
[0021] 如上的，其中，验证用户应用合法性，具体包括如下子步骤：
[0022] 用户应用生成随机数，使用认证密钥对随机数进行加密，生成密文，将密文和随机数发送至服务应用；
[0023] 服务应用使用内部存储的认证密钥对接收到的密文和随机数进行解密验证，验证成功则验证用户应用合法。
[0024] 如上的，其中，在服务应用重新验证用户应用合法性前，还包括用户应用判断内部是否存储有服务应用的句柄，如果是，则用户应用调用服务应用提供的接口函数，获取或修改存储在服务应用中的个人化数据，否则根据用户应用的应用标识向服务应用请求获取服务应用的句柄。
[0025] 如上的，其中，服务应用判断接收到的用户应用的应用标识与内部存储的应用标识是否一致，如果是，则将服务应用的句柄返回用户应用，否则返回应用不匹配响应，不允许用户应用访问个人化数据。
[0026] 本申请实现的有益效果如下：采用本申请提供的智能卡存储方法，不用担心删除Java智能卡中用户应用以后对个人化数据的影响，方便卡中应用代码升级，同时不影响修改后的应用代码在运行时数据的缺失，无需担心无法重新个人化的问题。
附图说明
[0027] 为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
[0028] 图1为一种智能卡个人化数据的存储管理方法流程图；
[0029] 图2为用户应用进行个人化存储的方法流程图；
[0030] 图3为用户应用进行个人化数据访问或修改方法流程图；
[0031] 图4为用户应用重新进行个人化方法流程图。
具体实施方式
[0032] 下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0033] 实施例一
[0034] 为了方便卡中Applet代码升级，同时不影响修改后的Applet代码在运行时数据的缺失，本申请提供一种智能卡，在本申请的智能卡中包括用户应用(Client Applet)和服务应用(Sever Applet)；用户应用为当前需要接受个人化数据独立存储服务的应用，服务应用用来实现存储当前应用的个人化数据，服务应用独立于用户应用，即当用户应用被删除时，服务应用内的个人化数据不会被同时删除。
[0035] 当用户应用需要使用个人化数据时，需要调用服务应用提供的访问接口进行数据访问和操作，优选的，使用Java卡JCRE提供的共享机制(即实现Sharable接口)进行访问，确保数据访问的安全性，防止被其他应用恶意访问或修改。
[0036] 实施例二
[0037] 本申请实施例二提供一种智能卡个人化数据的存储管理方法，如图1所示，包括：
[0038] 步骤11：用户应用将个人化数据写入服务应用；
[0039] 具体的，用户应用是在初次进行个人化时，将个人化数据写入服务应用，因此也只允许第一个个人化的用户应用有权访问此服务应用。
[0040] 参见图2，用户应用进行个人化存储的方式如下：
[0041] 步骤21：用户应用在接收到个人化指令后，获取服务应用的句柄；
[0042] 具体的，用户应用(Client Applet)通过调用Java智能卡的两个API接口函数JCSystem.lookupAID()和JCSystem.getAppletShareableInterfaceObject()，获取服务应用的句柄，句柄即为服务应用的对象；
[0043] 需要说明的是，在进行初次个人化存储之前，服务应用已经实例化为一个对象；
[0044] 本步骤中，用户应用在获取服务应用句柄前，服务应用先判断是否已经存储有用户应用的应用标识AID或个人化数据，如果是，则返回已个人化响应，否则执行获取句柄操作。
[0045] 步骤22：用户应用存储获取到的服务应用的句柄；
[0046] 优选的，用户应用将服务应用的句柄保存在用户应用的非易失性存储器中；
[0047] 其中，为了使用户应用访问服务应用的性能更高，用户应用只在个人化指令时获取服务应用的句柄，并保存在非易失性存储器中，且在用户应用的代码或对象删除之前不需要再重复获取句柄。
[0048] 步骤23：用户应用调用服务应用提供的传入应用标识的接口函数；
[0049] 其中，服务应用提供的接口函数为setAID()函数，调用此函数，用户应用将用户应用的应用标识AID传送至服务应用。
[0050] 步骤24：服务应用接收到应用标识AID后，判断内部是否已经存储有应用标识AID，如果是，则向用户应用返回已存储响应，否则将接收到的用户应用的应用标识AID保存在服务应用的非易失性存储器中，向用户应用返回成功响应，执行步骤25；
[0051] 可选的，服务应用中如已存储有应用标识AID，则返回0，表示传送失败，如未存储应用标识AID，则返回1，表示传送成功；
[0052] 需要说明的是，用户应用的应用标识AID为用户应用的特定标识，因此将用户应用的应用标识存储在服务应用中，以说明服务应用与用户应用为一对一的关系，当服务应用中已存储有应用标识AID时，表示该服务应用已与该应用标识AID对应的用户应用进行了个人化数据存储关联，该服务应用将不再接受其他用户应用传来的个人化数据。
[0053] 步骤25：用户应用在接收到服务应用返回的成功响应后，向服务应用发送认证密钥和校验码；
[0054] 优选的，在对象化用户应用和服务应用时，在两者内部均使用相同的GP过程密钥，用户应用根据认证密钥生成校验码，然后使用GP过程密钥对认证密钥进行加密，将加密后的认证密钥和校验码发送至服务应用；
[0055] 为了方便服务应用删除后重新获取认证密钥，认证密钥可以是一个常量值固定到代码中，也可以是一个与服务应用关联的变量值，如对用户应用的应用标识AID值计算哈希值，取计算结果的最左边16字节为认证密钥。
[0056] 步骤26：服务应用验证接收到的认证密钥和校验码，如果认证通过，则将认证密钥保存至服务应用的非易失性存储器中，并置密文验证成功标识为置位状态，返回成功响应，执行步骤27，如果认证不通过，则返回失败响应，并置密文验证成功标识为复位状态；
[0057] 服务应用调用GP API decryptData()函数，获取与用户应用相同的GP过程密钥，使用该GP过程密钥对接收到的加密的认证密钥进行解密，若解密成功，根据解密得到的认证密钥验证校验码，若验证校验码正确，则说明解密得到的认证密钥合法，存储此认证密钥；
[0058] 其中，在验证校验码正确并存储认证密钥后，将密文验证成功标识置为1，如果验证校验码错误，则将密文验证成功标识置为0。
[0059] 步骤27：用户应用在接收到成功响应后，调用服务应用提供的个人化存储接口函数，将个人化数据传送至服务应用；
[0060] 具体的，用户应用接收上层应用发送的个人化指令，在处理个人化指令时，逐条调用服务应用提供的storeData()函数，将个人化数据传送至服务应用。
[0061] 步骤28：服务应用存储接收到的个人化数据，全部个人化数据存储完成后向用户应用返回成功响应；
[0062] 具体的，服务应用从个人化指令中提取个人化数据，逐条将其中的个人化数据存储在非易失性存储器中。
[0063] 返回参见图1，步骤12：服务应用在验证用户应用合法后，用户应用调用服务应用安全接口，访问或修改个人化数据；
[0064] 参见图3，用户应用进行个人化数据访问或修改流程如下：
[0065] 步骤31：用户应用调用服务应用的接口函数，获取或修改存储在服务应用中的个人化数据；
[0066] 具体的，用户应用调用服务应用提供的getData()或setData()函数，访问或修改个人化数据。
[0067] 步骤32：服务应用获取密文验证成功标识，若该密文验证成功标识为置位状态，则允许用户应用进行个人化数据访问或修改，若该密文验证成功标识为复位状态，则返回失败响应。
[0068] 参见图4，当用户应用因为某些原因被删除或修改，并重新实例化为新对象时，服务应用中仍存储有最初保存的用户应用的个人化数据，为了保证用户应用能再次访问最初的个人化数据，
[0069] 用户应用重新进行个人化流程如下：
[0070] 步骤41：用户应用判断内部是否存储有服务应用的句柄，如果是，则用户应用调用服务应用提供的接口函数，获取或修改存储在服务应用中的个人化数据，否则执行步骤42。
[0071] 步骤42：用户应用根据用户应用的应用标识AID向服务应用请求获取服务应用的句柄；
[0072] 具体的，用户应用对象调用服务应用提供的JCSystem.lookupAID()和JCSystem.getAppletShareableInterfaceObject()两个Java卡API接口函数来获取服务应用的句柄。
[0073] 步骤43：服务应用判断接收到的用户应用的应用标识AID与内部存储的应用标识AID是否一致，如果是，则将句柄返回用户应用，执行步骤44，否则返回应用不匹配响应；
[0074] 本实施例中，服务应用与用户应用为一对一关系，服务应用只允许自身存储的应用标识AID对应的用户应用访问或修改，其他用户应用不可访问，更不可修改，保证个人化数据的安全性。
[0075] 步骤44：用户应用存储服务应用句柄；
[0076] 步骤45：用户应用生成随机数，使用认证密钥对随机数进行加密，生成密文，将密文和随机数发送至服务应用；
[0077] 步骤46：服务应用使用内部存储的认证密钥对接收到的密文和随机数进行验证，当验证成功后，将密文验证成功标识置位，并将成功响应返回用户应用，执行步骤47，否则将密文验证成功标识复位，返回错误响应；
[0078] 具体的，服务应用使用内部存储的认证密钥对接收到的随机数进行加密，判断加密得到的数据与接收到的密文是否一致，如果是，则验证成功，否则验证失败。
[0079] 步骤47：用户应用接收到成功响应后，调用服务应用的接口函数，获取或修改存储在服务应用中的个人化数据；
[0080] 具体的，用户应用调用服务应用提供的getData()或setData()函数，访问或修改个人化数据；
[0081] 优选的，服务应用在执行getData()或setData()函数的过程之前，需要先检查密文验证成功标识，如密文验证成功标识为0，则返回失败状态给用户应用；如果密文验证成功标识为1，则执行对应的获取或修改操作，并返回成功状态给用户应用。
[0082] 本申请实现的有益效果如下：采用本申请提供的智能卡存储方法，不用担心删除Java智能卡中用户应用以后对个人化数据的影响，方便卡中应用代码升级，同时不影响修改后的应用代码在运行时数据的缺失，无需担心无法重新个人化的问题。
[0083] 尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
