CN109284622A - 联系人信息处理方法、装置及存储介质 - Google Patents

Abstract

本发明提供了一种联系人信息处理方法，包括：在应用程序的进程中生成密钥，通过密钥库服务将所述密钥存储在授权所述应用程序访问的存储区域；在所述应用程序的宿主设备中初始化使用所述密钥的数据库；当所述应用程序需要操作所述数据库中的目标联系人信息时，向所述密钥库服务提交验证，验证通过后获得预存储的密钥；利用所获得的密钥，对所述目标联系人信息进行解密，对解密后的目标联系人信息进行相应操作。本发明还同时提供了一种联系人信息处理装置、以及存储介质。

Description

联系人信息处理方法、装置及存储介质

技术领域

本发明涉及通信技术，尤其涉及一种联系人信息处理方法、装置及存储介质。

背景技术

随着互联网特别是移动互联网的快速发展，在设备特别是移动设备中可供安装使用的应用程序呈现多样化的趋势，涵盖工作、学习、消费、娱乐等多方面，使应用程序得到前所未有的广泛使用。

在应用程序的使用过程中，不可避免地产生或接收到联系人信息，为了避免应用程序在使用联系人信息的过程中出现联系人信息泄露，涉及到对联系人信息的加密，而相关技术提供的对应用程序的联系人信息进行加密的方案，会对应用程序使用联系人信息的效率产生不利影响。

对于如何保证应用程序的联系人信息安全的同时提高对联系人信息获取的效率，相关技术尚无有效解决方案。

发明内容

有鉴于此，本发明实施例期望提供一种联系人信息处理方法、装置及存储介质，能够保证应用程序的联系人信息安全，同时提高对联系人信息处理的效率。

为达到上述目的，本发明实施例的技术方案是这样实现的：

第一方面，本发明实施例提供一种联系人信息处理方法，包括：

在应用程序的进程中生成密钥，通过密钥库服务将所述密钥存储在授权所述应用程序访问的存储区域；

在所述应用程序的宿主设备中初始化使用所述密钥的数据库；

当所述应用程序需要操作所述数据库中的目标联系人信息时，向所述密钥库服务提交验证，验证通过后获得预存储的密钥；

利用所获得的密钥，对所述目标联系人信息进行解密，对解密后的目标联系人信息进行相应操作。

上述方案中，在第一方面的第五种可能的实现方式中，还包括：当满足同步条件时，将所述缓存中存储的所述应用程序的联系人信息与所述数据库进行同步。

上述方案中，所述在所述应用程序的宿主设备中初始化使用所述密钥的数据库，包括：

在所述数据库中创建以所述应用程序的联系人信息的名称为键，以所述应用程序的联系人信息的内容为值的键值对；

以所述应用程序的密钥对所述应用程序的键值对进行加密。

上述方案中，所述向所述密钥库服务提交验证，验证通过后获得预存储的密钥，包括：

向所述密钥库服务提交应用程序名称的数字签名；

当所述密钥库服务验证所述数字签名与所述应用程序的名称匹配后，获得所述密钥库服务中针对所述应用程序存储的密钥。

第二方面，本发明实施例提供一种联系人信息处理装置，包括：

生成单元，用于在应用程序的进程中生成密钥；

存储单元，用于通过密钥库服务将所述密钥存储在授权所述应用程序访问的存储区域；

初始化单元，用于在所述应用程序的宿主设备中初始化使用所述密钥的数据库；

验证单元，用于当所述应用程序需要操作所述数据库中的目标联系人信息时，向所述密钥库服务提交验证，验证通过后获得预存储的密钥；

解密单元，用于利用所获得的密钥，对所述数据库进行解密；

操作单元，用于对解密后的目标联系人信息进行相应操作。

上述方案中，所述操作单元，具体用于：

当满足同步条件时，将所述缓存中存储的所述应用程序的联系人信息与所述数据库进行同步。

上述方案中，所述生成单元，还用于当满足设定的更新条件时，在所述应用程序的进程中动态更新密钥；

其中，所述更新条件包括以下至少之一：

密钥的生命周期到达预定时长；

密钥的使用次数到达预定使用次数；

密钥的使用频率到达预定使用频率。

上述方案中，所述初始化单元，具体用于：

在所述数据库中创建以所述应用程序的联系人信息的名称为键，以所述应用程序的联系人信息的内容为值的键值对；

以所述应用程序的密钥对所述应用程序的键值对进行加密。

上述方案中，所述验证单元，具体用于：

向所述密钥库服务提交应用程序名称的数字签名；

当所述密钥库服务验证所述数字签名携带的数字签名成功后，获得所述密钥库服务中针对所述应用程序存储的密钥。

第三方面，本发明实施例提供一种存储介质，存储有可执行程序，所述可执行程序被处理器执行时，实现本发明实施例提供的联系人信息处理方法。

第四方面，本发明实施例还提供一种联系人信息处理装置，包括：

存储器，用于存储可执行程序；

处理器，用于执行所述存储器中存储的可执行程序，实现本发明实施例提供的联系人信息处理方法。

本发明上述实施例具有以下有益效果：

一方面，对于应用程序生成的密钥而言，由于密钥由密钥库服务进行存储，而且只能由授权的应用程序访问，对于其他应用程序无法访问，有效避免了应用程序的密钥被其他应用程序如恶意程序监听的情况，保证了密钥安全。

另一方面，对于需要操作的联系人信息而言，在数据库对应用程序的联系人信息进行加密存储，数据库基于密钥有效保证了联系人信息的安全，不会被其他应用程序操作，同时数据库技术本身保证了对联系人信息的操作效率。

附图说明

图1为本发明实施例提供的操作系统安全应用程序环境的一个可选的架构示意图；

图2为本发明实施例提供的联系人信息处理装置的一个可选的硬件结构示意图；

图3为本发明实施例提供的联系人信息处理方法的一个可选的流程示意图；

图4为本发明实施例提供的基于密钥因子生成密钥的一个可选的流程示意图；

图5为本发明实施例提供的联系人信息处理方法的一个可选的流程示意图；

图6为本发明实施例提供的目标联系人信息的读取过程的一个可选的流程示意图；

图7为本发明实施例提供的目标联系人信息的写入过程的一个可选的流程示意图；

图8为本发明实施例提供的目标联系人信息的删除过程的一个可选的流程示意图；

图9为本发明实施例提供的联系人信息处理装置的一个可选的功能结构示意图；

图10为本发明实施例提供的联系人信息获取过程的一个可选的流程示意图；

图11为本发明实施例提供的个人信息操作界面示意图；

图12为本发明实施例提供的部门信息操作界面示意图；

图13为本发明实施例提供的密钥生成过程的一个可选的流程示意图；

图14为本发明实施例提供的联系人信息处理装置的一个可选的功能结构示意图；

图15为本发明实施例提供的联系人信息处理一个可选的示意图。

具体实施方式

以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本发明，并不用于限定本发明。另外，以下所提供的实施例是用于实施本发明的部分实施例，而非提供实施本发明的全部实施例，在不冲突的情况下，本发明实施例记载的技术方案可以任意组合的方式实施。

对本发明进行进一步详细说明之前，对本发明实施例中涉及的名词和术语进行说明，本发明实施例中涉及的名词和术语适用于如下的解释。

1)应用程序，本文中是指在设备中预先安装的客户端，或设备中第三方的客户端，如企业即时通信(IM，Instant Message)和浏览器，等等。

2)设备，支持运行应用程序的电子设备，如智能手机、平板电脑或车载设备等，本文中设备也称为应用程序的宿主设备。

3)沙箱(Sandbox)机制，应用程序只能在设备的文件系统中为该程序设置的特定的存储区域访问，而无法访问为其他应用设置的存储区域，存储区域用于存储应用程序产生的密钥；应用程序针对特定区域的访问请求都要通过验证，假如验证不通过，则访问会被拒绝。

4)密钥库(Key Store)服务，移动操作系统如安卓(Android)和iOS提供的用于存储联系人信息(如密钥)的一种服务。

密钥库服务为每个应用程序设置一个密钥串(Keychain)服务，密钥串是由密钥库服务提供的基于沙箱机制的一种安全容器，可以应用在安卓和iOS等操作系统中为应用程序设置的特定存储区域，基于链表式的方式存储应用程序的密钥。

每个应用程序的密钥串中可以存储应用程序的一个或多个密钥；对于每一个应用程序的密钥串来说，密钥库服务可以通过验证应用程序的数字签名的方式，保证密钥串中存储的密钥不会授权给其他的应用程序访问，确保密钥安全。

5)联系人信息，是指存储于服务器和/或设备中的联系人的通信标识，以IM客户端的联系人信息为例，可以包括联系人的登录账号、手机号码、电子邮箱账号和社交网络账号等。

6)数据库，在设备中运行的组织数据的服务，支持以键值对的方式存储各个应用程序的联系人信息，并使用应用程序所产生的密钥对相应应用程序的联系人信息进行加密。

例如，在数据库中用键(Key)表示联系人信息的名称(或索引，如哈希值形式的索引)，用值(Value)表示联系人信息的具体内容(包括一个或多个的通信标识)；就数据库而言，可以采用如轻量级的SQLite数据库，当然本发明实施例中不排除使用其他任意类型的数据库。

7)数字签名，本文中指对应用程序的名称的数字签名，使用不对称加密算法的私钥对应用程序名称的摘要进行加密得到。数字签名具有唯一标识应用程序的名称的特性；通过使用不对称加密算法如RSA算法或DSA算法的私钥对应用程序名称的摘要进行加密，可以得到应用程序数字签名的数字签名。

8)密钥，本文中指使用对称加密算法(任意种类的对称加密算法)用以对应用程序的联系人信息进行加密或解密所使用的密钥；当然，密钥也可以是不对称加密算法的公钥或者私钥。

现在将参考附图描述实现本发明实施例的联系人信息处理装置的应用程序架构，参见图1，图1为本发明实施例提供的操作系统安全应用程序环境的一个可选的架构示意图，本发明实施例记载设备的操作系统可为移动操作系统，如Android或iOS操作系统，当然，本发明实施例中不排除使用其他任意类型的操作系统。图1所示的操作系统安全应用程序环境用于在开放的同时保证应用程序的联系人信息的安全。该结构采用分层的系统架构，包括：内核层11、服务层12和应用层13。下面分别对这三个层做简要说明。

内核层11，该层可以为使用任意类型的操作系统的内核，如基于Linux内核的操作系统如安卓系统的内核，或者是基于iOS系统和类Unix系统的内核，用于实现硬件设备驱动、进程和内存管理、网络协议栈、电源管理等核心系统功能；且内核层11对应的安全机制为文件访问控制机制，该机制用于确保系统文件和用户联系人信息不受非法访问。

服务层12，包含各种系统程序，例如框架层、核心库层和驱动层等，用于实现各种基础业务以及处理基于内核层11的任务。服务层12中的核心库层(未示出)提供沙箱机制和进程通信机制的支持。应用程序在安装时被赋予独特的用户标识(UID)，并在应用程序的生命周期内保持。

以安卓为例，应用程序及其运行所依赖的Dalvik虚拟机运行在独立的内存进程空间，与其他应用程序完全隔离，每个应用程序运行在Dalvik虚拟机中，各应用程序间无法相互访问在密钥库中其他应用程序的密钥串(用于存储应用程序的密钥)；也就是说，每个应用程序的密钥相当于存储于对应的安全沙箱内，且每个应用程序的安全沙箱不能被其他应用程序所访问。

各应用程序的联系人信息在SQLite数据库中初始化并存储，且该数据库使用密钥串中的密钥进行加密，以保证数据库中应用程序的联系人信息的安全性。

框架层对应的安全机制为应用程序的签名机制，每个应用程序被密钥库服务分配有数字签名，应用程序在向密钥库服务提交验证时可以提交数字签名，通过验证数字签名可以确定应用程序是否是恶意伪装的，因为恶意伪装的应用程序无法通过数字签名的验证。

以密钥库服务向安卓应用程序的数字签名为例，在安装应用程序的安卓安装包(APK，Android Package)时，验证APK的数字签名是否有效，有效时才能被安装；当应用程序升级时，需要检查新版本的应用程序的包名与已安装的应用程序的包名是否相同，若两者不同，则认为是一个新的应用程序。程序开发者有时会将安装包命名为相同的名称，通过不同的版本号可以将它们区分开来，从而对应的数字签名也不同，这样可以避免签名不同的包不被替换，同时防止恶意软件替换安装的应用程序。

应用层13，该层对应的安全机制为权限声明机制，权限声明机制包括：代码安全和接入权限，其中，采用代码安全机制可以避免出现黑客通过反编译手段去源代码中推导出密钥的隐患，在本发明可选实施例中，将应用程序所生成的密钥存储在密钥库服务如KeyStore中；接入权限，主要用来对应用程序的操作增加限制，防止恶意应用程序进行非法操作给用户造成敏感联系人信息泄漏和设备被非法控制，防止恶意收费等。

现在将参考附图描述实现本发明实施例的联系人信息处理装置。联系人信息处理装置可以以各种形式来实施，例如服务器、设备如台式机电脑、笔记本电脑等各种类型的计算机设备。下面对本发明实施例的联系人信息处理装置的硬件结构做进一步说明。

参见图2，图2为本发明实施例提供的联系人信息处理装置的一个可选的硬件结构示意图，实际应用中可以实施为前述的运行应用程序的各种设备，图2所示的联系人信息处理装置200包括：至少一个处理器201、存储器202、用户接口203和至少一个网络接口204。联系人信息处理装置200中的各个组件通过总线系统205耦合在一起。可以理解，总线系统205用于实现这些组件之间的连接通信。总线系统205除包括联系人信息总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统205。

其中，用户接口203可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。

可以理解，存储器202可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。

本发明实施例中的存储器202用于存储各种类型的联系人信息以支持联系人信息处理装置200的操作。这些联系人信息的示例包括：用于在联系人信息处理装置200上操作的任何计算机程序，如应用程序2021、密钥库服务2022和数据库2023，实现本发明实施例方法的程序可以包含在应用程序2021、密钥库服务2022和数据库2023中。

本发明实施例揭示的联系人信息处理方法可以应用程序于处理器201中，或者由处理器201实现。处理器201可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，联系人信息处理方法的各步骤可以通过处理器201中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器201可以是通用处理器、数字信号处理器(DSP，DigitalSignal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器201可以实现或者执行本发明实施例中提供的联系人信息处理方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所提供的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器202，处理器201读取存储器202中的信息，结合其硬件完成本发明实施例提供的联系人信息处理方法的步骤。

至此，已经按照其功能描述了本发明实施例中涉及的联系人信息处理装置，基于上述联系人信息处理装置的可选硬件结构示意图，下面对实现本发明实施例的联系人信息处理方法的处理过程进行详细说明。

参见图3，图3为本发明实施例提供的联系人信息处理方法的一个可选的流程示意图，包括以下步骤：

步骤301，应用程序在自身的进程中生成对应的密钥。

在本发明可选实施例中，应用程序在每次的初始化运行时，向密钥库服务的密钥串中检测是否有该应用程序对应的密钥，如果没有则可以生成密钥并在密钥库服务的密钥串中存储。

例如，当应用程序针对不同的登录用户在与密钥串中存储对应的密钥时(即每个登录用户都有对应的密钥)，那么，在每个用户登录时都检测是否已经针对登录用户生成了对应的密钥，如果没有则针对当前登录用户生成新的密钥。

就密钥来说，可以包括以下几种类型：

1)对称加密算法的密钥

在本发明可选实施例中，对称加密算法的密钥为使用对称加密算法如DES算法或IDEA算法得到的密钥，这里的对称加密算法的类型不做限制。采用对称加密算法得到的密钥能够保证应用程序的安全性，同时提高对联系人信息加密和解密的效率。

2)不对称加密算法的公钥或者私钥

在本发明可选实施例中，可以通过使用RSA算法或DSA算法等不对称加密算法来得到公钥或者私钥，这里对不对称加密算法的类型不做限制。

举例来说，公钥和私钥是成对使用的，用公钥加密的联系人信息应用程序需要使用对应的私钥才可以解密，用私钥加密的联系人信息应用程序需要使用对应的公钥才可以解密；也就是说，如果可以用公钥解密，则必然是对应的私钥加密，如果可以用私钥解密，则必然是对应的公钥加的密；实际应用中加密和解密使用公钥还是可以预先设置，当然，应用程序自身可以记录联系人信息的加密方式(如使用公钥还是私钥加密)，并使用对应的解密方式进行解密。

在本发明可选实施例中，应用程序在进程中生成密钥而非在应用程序之外的进程中生成密钥，可以有效避免生成的密钥被监听的情况，另外，以对称算法的密钥为例，生成密钥可以包括以下两种不同的场景：

场景1)：应用程序在宿主设备首次运行时，生成与应用程序对应的唯一的密钥。

举例来说，每个应用程序只生成一个密钥的场景，适用于应用程序对应仅有一个登录用户或多个登录用户的情况，例如对于多个登录账号应用程序生成唯一的、对不同登录账号全局有效的密钥，对不同登录用户登录期间生产的联系人信息进行加密和解密，密钥能够实现对联系人信息的高效加密和解密。

另外，每个应用程序只生成一个密钥的场景，同样适用于应用程序没有用户账号机制的情况，应用程序可以只生成一个全局的密钥，对应用程序生成的联系人信息进行加密和解密。

在该场景中，每个应用程序只对应生成一个密钥；也就是说，应用程序在宿主设备首次初始化运行时，会生成与该应用程序对应的唯一的密钥，在后续应用程序基于该密钥对生产的联系人信息进行加密或解密。

场景2)：应用程序在宿主设备首次登录时，生成与应用程序的登录账号对应的密钥。

应用程序针对每个登录账号生成密钥的场景适用于应用程序被不同登录账号使用的情况。对于不同的登录账号而言，应用程序在任一登录用户首次登录时，生成与应用程序的当前登录账号对应的密钥，即针对每个登录账号分别对应生成一个密钥。

例如，QQ应用程序有时会被多个用户用来登录，因此，针对每个QQ登录账号，就相应生成一个对应的密钥。可见，即使应用程序的一个登录账号对应生成的密钥被破解，其他登录账号的密钥加密的联系人信息仍然不受影响，安全性较高。

下面对应用程序生成密钥的方式进行说明，在本发明可选实施例中，应用程序生成密钥，可以采用如下方式：获取以下至少一个密钥因子：宿主设备的硬件信息、应用程序的登录账号、地理位置、登录时间和随机数；基于所获取的密钥因子形成密钥。

需要强调的是，密钥因子的类型不限于以上所述，例如，除了上述指出的几个类型的密钥因子之外，还可以结合应用程序的联系人信息的名称、访问应用程序的时间、实时地理位置等密钥因子，进行不同的组合方式形成密钥。这里，可采用各种已有的或新的组合方式，形成各种随机的密钥，在此不做限定。可以理解，所获取的密钥因子的个数越多，对各密钥因子进行组合的方式就越多，从而形成的密钥的随机性就越高，这样可以大大提高应用程序的联系人信息安全性。

在本发明可选实施例中，基于所获取的密钥因子形成密钥，可以采用如下方式：应用程序将各密钥因子包括的字符按照次序进行组合；基于摘要算法对组合得到的字符提取摘要，将提取得到的摘要作为密钥。

这里，次序既可以是预先设定的顺序，也可以是随机的顺序，这里不做限定；例如，在应用程序每次生成密钥时，使用宿主设备的硬件信息、应用程序的登录账号、地理位置、登录时间和随机数的顺序进行组合；又例如，在应用程序每次生成密钥时，采用不同于所采用(如最近一次，或最近多次)的组合顺序的方式，进行动态的组合，能够保证在密钥因子的类型被恶意破解的情况下，也难以组合形成正确的密钥。

另外，随机数的类型可以为时间、地点、应用程序名称版本等，或者可以采用随机数算法保证每次生成不同的随机数，在每次组合形成正确密钥的过程中，将随机数作为密钥因子，由于有可能每次所获取的随机数均不同，这样，即使在密钥生成所使用的密钥因子的类型以及组合方式被破解的情况下，由于每次生成的随机数具有不可预测的特性，因此恶意程序难以组合形成正确的密钥，因此，应用程序生成密钥的该方式的安全性更高，具有很大的实用价值。

这里，使用的摘要算法可采用应用程序的信息摘要算法第五版(MD5，MessageDigest Algorithm 5)，通过将联系人信息运算为另一固定长度的值，用于确保信息传输完整一致。由于两个不同版本的应用程序对应安装包的MD5值相同的概率几乎为零，因此，利用MD5值可以很好地区分不同的应用程序。

结合用户登录应用程序时生成密钥的一个示例进行说明，参见图4，图4为本发明实施例提供的基于密钥因子生成密钥的一个可选的流程示意图，在用户使用登录账号首次登录应用程序时，应用程序获得用户输入的登录账号，并获取宿主设备的硬件信息、地理位置和登录时间，并生成随机数；然后，将随机数与应用程序的登录账号、宿主设备的硬件信息以及登录时间和地理位置中的至少一种按照预定次序进行组合；之后，采用摘要算法如MD5算法对组合得到的字符进行计算摘要，并将获取到的摘要作为密钥。

当然，摘要可以继续进行变换后作为密钥，例如，对摘要再次进行计算得到新的摘要作为密钥；对摘要提取特定位置(如第1/3/5)位的字符作为密钥，等等，方式灵活多样。

本发明可选实施例中，还提供密钥的有效期机制，应用程序根据有效期定期更新密钥，从而能够进一步提升密钥被恶意程序破解的难度；可以理解，有效期可以是针对设备中的全部应用程序统一设定的，也可以是针对不同应用程序有针对设置的，甚至可以是针对应用程序的不同登录用户有针对性设置。

作为示例，密钥可以是根据生命周期、使用次数和使用频率等维度的一种或者多种来进行更新，例如在满足以下条件时更换密钥：

1)在密钥的生命周期到达预定时长时，定时更换密钥能够有效避免被破解的情况，这里，预定时长可以根据实际情况进行设定，本发明实施例中不做具体限定；

2)密钥的使用次数/使用频率对应到达预定使用次数/使用频率时，不管是应用程序生成的全局的密钥，针对不同的登录账号对应生成的密钥，只要使用次数到达预定使用次数即进行更新，因此，恶意程序通常是在应用程序使用密钥操作的过程中进行学习和监听，根据使用次数/使用频率能够有效杜绝恶意程序根据相同密钥操作破解的可能性，这里，预定使用次数和预定使用频率可以根据实际情况进行设定，本发明实施例中不做具体限定。

此外，为了提升密钥被破解的难度，应用程序每次生成新的密钥时，可以部分变换或者全部变换之前所使用的密钥因子，还可以变换形成密钥时密钥因子的次序。

例如，当需要生成密钥时，将会接收服务器发送的用于生成密钥的指示信息，该指示信息携带有首次登录时间和编码后的登录账号，然后根据接收到的信息生成随机数，根据随机数与以下密钥因子至少之一：硬件信息、登录账号和首次登录时间进行排列组合，组合后得到随机字符串，然后根据摘要算法进行运算生成密钥。在满足上述条件进行更新密钥时，例如当密钥的有效期到达时，也会接收服务器发送的用于生成密钥的指示信息，生成随机数，随机数与以下密钥因子至少之一：硬件信息、登录账号和首次登录时间进行排列组合，组合后得到随机字符串，然后根据摘要算法进行运算生成新的密钥，这里，需要注意的是，每次更新密钥的时候，所使用的密钥因子、密钥因子的个数和密钥因子排列顺序尽量保持差异；可见密钥因子的类型部分发生了变换，密钥因子的次序也发生了变换，这种动态生成密钥的方式杜绝了恶意程序破解密钥的可能性。

步骤302，应用程序将所生成的密钥发送至宿主设备的密钥库服务。

步骤303，密钥库服务将密钥存储在仅授权给应用程序访问的存储区域。

密钥库服务针对每个应用程序设置基于沙箱机制的密钥串，在密钥串中存储应用程序密钥；仅授权给应用程序访问的存储区域即为该应用程序创建的文件系统的特定的存储区域，例如，密钥库服务中针对应用程序设置的密钥串，使用沙箱机制，每个应用程序的密钥分别对应的密钥串中，其他应用程序不能访问。

密钥库服务还可以使用数字签名保证对密钥串操作的应用程序的身份的合法性；举例来说，基于沙箱机制存储的密钥将受到密钥库服务的签名保护，密钥串存储在密钥库服务的目录中，而不是在应用程序所安装使用的目录中，因此不会因应用程序被删除而丢失；且在应用程序重装后，密钥库服务中的密钥还能继续被重装的应用程序使用。

另外，密钥库服务中存储的密钥还可以与安全硬件(本发明实施例中为宿主设备的安全硬件，如中央处理器(CPU，Central Processing Unit))绑定的方式进行存储，可以实现一旦生成或导入密钥，就无法导出到宿主设备之外使用，其授权将无法更改。

步骤304，应用程序在宿主设备中初始化使用密钥的数据库。

在本发明可选实施例中，应用程序初始化使用密钥的数据库，可以采用如下方式：应用程序在宿主设备中创建以应用程序的联系人信息的名称为键，以应用程序的联系人信息为值的键值对；将应用程序的键值对在数据库中以应用程序的密钥进行加密并存储。

这里，数据库根据应用程序的密钥对应用程序的联系人信息进行加密存储，每个应用程序具有不同的密钥，并且，如前所述，每个应用可以仅生成一个密钥，则数据库使用应用程序的唯一密钥对应用程序的联系人信息进行加密存储。

另外，当应用程序的不同登录账号生成与登录账号对应的密钥时，使用不同登录账号对应的密钥，对登录账号登录期间生产的联系人信息(如浏览器的浏览记录)在数据库中进行加密存储，能够避免应用使用全局的密钥导致不同登录账号的加密联系人信息被破解的风险。

参见表1，表1为本发明实施例提供的针对不同应用程序生成不同密钥的对应关系表，如表1所示：

表1

应用程序的联系人信息的名称	密钥
		应用程序1	123456
应用程序2	123457
		应用程序3	123789
应用程序4	123678

由表1可见，应用程序1至应用程序4中的每个应用程序只对应生成一个密钥，这样，在后续对某应用程序进行加密或解密时，也只有与该应用程序对应的密钥能够对应用程序的联系人信息进行加密或解密。

参见表2，表2为本发明实施例提供的针对不同登录账号生成不同密钥的对应关系表，如表2所示：

表2

由表2可见，应用程序1和应用程序2都对应有不同的登录账号，这里以用户手机号作为登录账号进行应用程序的登录。例如，对于应用程序1的不同的登录账号来讲，每个登录账号分别对应生成了一个密钥，这样，即使应用程序1的一个登录账号如134********对应生成的密钥123456789被破解，其他登录账号登录时应用程序生产的联系人信息的安全性仍然不受影响，因为使用的密钥不同，从而安全性较高。

举例来说，应用程序在宿主设备中首次登录时，会创建以应用程序的联系人信息的名称为键，以应用程序的联系人信息的具体内容为值的键值对，并将该键值对存储于一数据库表中，参见表3，表3为本发明实施例提供的数据库表的结构示意图，该数据库表的结构如下：

表3

名称	类型	说明
			configKey(键)	varchar	联系人信息的名称
configValue(值)	blob	联系人信息的内容

其中，以键值对的方式存储应用程序的联系人信息，举例来说，configKey作为键，用于表示应用程序的联系人信息的名称，其类型是字符串(varchar)；configValue作为值，用于存储应用程序的联系人信息的具体内容，其类型是二进制大对象(blob)。

需要说明的是，也可以采用varchar类型来存储应用程序的联系人信息，而采用blob类型来存储应用程序的联系人信息，可将宿主设备中应用程序的联系人信息序列化成二进制流存入数据库；blob是一个可以存储较大的二进制文件的容器，可以将blob划分为不同的类型，支持单个文件的体积从256字节到4G字节不等，能够更好地以适用不同的场景的存储需求。

步骤305，应用程序需要操作数据库中的目标联系人信息时，向密钥库服务提交验证。

本发明可选实施例中，应用程序提交的验证携带应用程序的数字签名，用于供密钥库服务验证请求操作的应用程序的合法性，能够有效排除恶意程序伪装应用程序请求操作联系人信息的情况。

步骤306，密钥库服务进行验证，验证通过后向应用程序发送预存储的密钥。

在本发明可选实施例中，应用程序通过向密钥库服务提交携带应用程序名称的数字签名的方式，请求密钥库服务进行验证，当密钥库服务验证数字签名成功后，向应用程序发送密钥库服务中针对应用程序存储的密钥。

作为密钥库服务验证数字签名的示例，密钥库服务对应用程序传递过来的应用程序的名称，使用MD5算法计算其摘要，并使用不对称加密算法的公钥对应用程序在验证中提交的数字签名解密，将计算得到的摘要与解密得到的摘要进行比对，当比对成功后，说明当前提交验证的应用程序合法，可以向应用程序返回在密钥串中所预先存储的密钥。

例如，当应用程序针对不同登录用户对应生成不同的密钥时，密钥库服务器根据验证中携带的登录用户的标识(如名称或序列号)定位密钥串中对应该登录用户的密钥，并返回应用程序。

步骤307，应用程序利用所获得的密钥，对目标联系人进行解密，从而获取到联系人信息。

这里，对目标联系人进行解密，实际上是指对数据库中存储的应用程序的联系人信息进行解密；应用程序利用所获得密钥，将数据库中以所获得密钥加密(当然，在不对称加密时，为密钥对中的另一密钥)的联系人信息置于解密状态，并进行操作，当操作完成后，数据库将联系人信息重新置于加密状态。

步骤308，对解密后的目标联系人信息进行相应操作。

在本发明可选实施例中，在应用程序的宿主设备中提供缓存的机制，应用程序将运行期间曾经操作的联系人信息按照特定策略(如操作时间、操作频率等)在缓存中以未加密的状态存储，根据存储时间和操作频率等缓存中的联系人信息进行删除处理以避免数据溢出，例如当联系人信息在预定时间内未被操作时，或者在预定时间内的操作频率低于预定频率时删除联系人信息。

每次应用程序需要操作目标联系人信息时，首先根据目标联系人信息的键在宿主设备的缓存中查询目标联系人信息，根据查询结果，涉及以下两种情况：

情况1)如果查询到目标联系人信息，则直接在缓存中对目标联系人信息进行操作以提高处理效率。

例如，将以应用程序的键，即应用程序的联系人信息的名称为索引，在缓存中进行查找目标联系人信息，以便对查找到的目标联系人信息的具体内容进行相应操作，可以理解，对目标联系人信息的操作的类型包括：读取、增加、修改和删除。

情况2)如果在缓存中没有查询到目标联系人信息，则对数据库执行针对目标联系人信息的操作，即：应用程序利用从密钥库服务中获得密钥，将数据库中针对应用程序加密存储的联系人信息置于解密状态，进行相应的操作，对数据库操作结束后，由数据库继续加密并存储应用程序操作后的联系人信息。

另外，为了提升应用程序后续在缓存中查找目标联系人信息的命中率，对于在缓存中未查找到的目标联系人信息，在数据库中执行操作后还存储在缓存中，后续不必频繁进行数据库操作，提升应用程序的操作效率。

本发明可选实施例中，当缓存中存储的联系人信息满足同步条件时，应用程序会将缓存中存储的应用程序的联系人信息与数据库同步，保证缓存与数据库联系人信息的一致性。

例如，缓存与数据库的同步可以是全局的同步，即缓存中针对全部应用程序的联系人信息，根据全局的同步条件(如同步时间到达，或缓存的联系人信息达到一定容量)，将缓存中的联系人信息同步到数据库中。

再例如，同步可以是针对应用程序、针对应用程序的登录用户等维度的局部同步，以应用程序的维度来说，某一应用程序在缓存中的联系人信息满足同步条件(如同步时间到达，或缓存的联系人信息达到一定容量)时，应用程序在缓存中的联系人信息同步至数据库中；根据不同维度进行联系人信息同步，适应不同应用程序、不同登录账号生成联系人信息的速度差异的情况，保证联系人信息能够及时写入数据库。

举例说明根据登录账号为维度同步联系人信息的优越性，对于IM客户端，如果用户1登录时IM客户端生产的少量联系人信息被存储在缓存中，用户1退出登录并且用户2登录后，由于用户2长期使用生产了较用户1更多的联系人信息(例如最近一段时间内参与的会话的记录)，如果根据全局同步条件缓存中的联系人信息进行同步，将缓存用户2的大量联系人信息，这就会导致用户2的联系人信息在缓存中无法及时同步到数据库中的情况，这会导致用户2的当前会话与数据库中存储的会话的状态不一样的情况，即出现“脏数据”，容易导致数据冲突和应用程序运行的稳定性；

以登录账号为维度同步联系人信息至数据库的情况恰恰相反，登录用户2在使用IM客户端的过程中生产的联系人信息会及时同步至数据库中，保证了缓存和数据库的数据一致性。

以下再针对操作的不同类型，对缓存中目标联系人信息的操作进行说明，可以理解，当在数据库中对目标联系人信息的操作时，可以根据针对缓存中的操作方式而实施。

1)针对目标联系人信息的操作类型为读取时，读取缓存中存储的相应目标联系人信息。

以应用程序为IM客户端，联系人信息为IM客户端的后台服务器的IP地址为例，IM客户端将后台服务器的IP地址已经预先加密存储到数据库中，在需要根据登录账号登录服务器，首先在缓存中查找是否具有后台服务器的IP地址，若有，则读取后台服务器的IP地址与后台服务器进行三次握手建立连接。

再以应用程序为浏览器，联系人信息为不同网页的cookie为例，在浏览器启动后加载网页1，浏览器首先在缓存中查找相应网页的cookie，若有，则读取缓存中存储的网页1的cookie，恢复用户之前离开网页1的状态。

2)针对目标联系人信息的操作类型为增加时，在缓存中存储的目标联系人信息中写入新数据。

举例来说，应用程序为浏览器，联系人信息为不同网页的cookie，在浏览器启动后加载网页1，浏览器的当前登录用户在当前网页中产生了新的会话状态(例如用户在购物车中添加了商品)，需要在当前网页的会话状态的cookie中添加新的会话状态，浏览器首先在缓存中查找针对当前用户存储的cookie，在查找到的网页的cookie中增加新的会话状态。

3)针对目标联系人信息的操作类型为修改时，在缓存中存储的目标联系人信息修改对应的数据。

举例来说，以应用程序为IM客户端，联系人信息为IM客户端的后台服务器的IP地址为例，IM客户端将后台服务器的IP地址已经预先加密存储到数据库中，当需要修改后台服务器的IP地址时，首先在缓存中查找是否具有后台服务器的IP地址，若有则进行修改。

4)针对目标联系人信息的操作类型为删除时，在缓存和数据库中删除对应的目标联系人信息。

举例来说，应用程序为浏览器，联系人信息为不同网页的cookie，在浏览器启动后加载网页1，浏览器的当前登录用户在浏览器中删除网页1的cookie，则浏览器首先在缓存中查找网页1的cookie，如果查找到则删除，同时删除数据库中查找到的网页1的cookie并删除。

下面以设备中运行密钥库服务为Key Store、数据库为SQLite、应用程序为IM客户端为例，对本发明实施例联系人信息处理方法的具体实现过程做进一步地详细说明，设备运行的操作系统可以为安卓系统或iOS系统，对于其他类型的操作系统，通过实现与上述Key Store、SQLite的服务，仍然可以根据图5的说明进行实施，本发明实施例不排除使用与Key Store和SQLite相同或相似功能的实施。

企业IM客户端特别是企业IM客户端对联系人信息的安全要求远远高于个人IM客户端，设备的丢失可能导致企业IM的联系人信息泄漏，这其中包括了用户账户、服务器IP、服务器端口等信息。

对于联系人信息，可选的数据方式包括：

1)联系人信息都是使用Android/iOS提供的存储类如SharedPreferences/NSUserDefaults进行存储，而这些存储类本质是一个XML文件，对XML元素的操作需要做繁琐的文本解析工作，效率低。

2)在IM客户端的本地生成一个加密文件，在加密文件中存储联系人信息。这种方式本身的数据存取效率仍然满足IM客户端的需求，对某个联系人信息的操作需要遍历整个文件去查找，比较耗时。

本发明实施例提供的基于Key Store和SQLite的数据处理方案用以解决上述问题，参见图5，图5为本发明实施例提供的联系人信息处理方法的一个可选的流程示意图，包括以下步骤：

步骤501，当IM客户端在设备首次初始化运行时，或IM客户端首次根据一个登录账号登录IM客户端时生成密钥。

IM客户端在设备首次初始化运行时生成全局的密钥，用于对后续生产的全部联系人信息进行加密，全局的密钥将有助于提升联系人信息的加密和解密的效率；当然，可以根据不同的登录用户，生成不同的密钥，例如在密钥因子中使用登录账号和随机数以最大程度减小密钥被恶意程序破解的可能性。

步骤502，IM客户端将生成的密钥发送到Key Store中加密存储。

Key Store中设置一专门用于仅授权给IM客户端访问的Keychain，例如，针对每个IM客户端设置一个对应的Keychain，Keychain提供沙箱机制存储IM客户端的密钥，每个IM客户端不能访问Key Store为其他IM客户端所设置的Keychain。

步骤503，IM客户端初始化使用密钥的SQLite数据库。

这里，使用SQLite数据库来存储不同IM客户端的联系人信息，每个IM客户端具有不同的密钥对数据库中的联系人信息进行加密存储；例如，当IM客户端针对不同的登录用户生成密钥时，将使用对应的密钥初始化SQLite数据库，SQLite数据库中针对登录用户的联系人信息将只能使用对应的密钥置于解密状态，并在IM客户端操作结束后重新置于加密状态。

例如，IM客户端初始化使用密钥的SQLite数据库，可以采用如下方式：IM客户端在设备中创建以IM客户端的联系人信息的名称为键，以IM客户端的联系人信息为值的键值对；所创建的键值对存储于数据库中，如前面所描述的表3中，将IM客户端的键值对在SQLite数据库中以IM客户端的密钥进行加密。

步骤504，当IM客户端需要操作目标联系人信息时，在缓存中查询目标联系人信息，如果查找到，执行步骤505；否则，执行步骤506。

步骤505，IM客户端执行对缓存中的目标联系人信息执行操作。

以IM客户端在启动时需要读取后台服务器的IP地址和端口，登录后台服务器为例，IM客户端首先在缓存中查询服务器IP地址和端口，如果查询到，则发起三次握手操作建立套接字连接，将当前登录用户的账号和认证信息传入，在后台服务器认证通过后发送确认，IM客户端将当前登录用户置于登录状态。

步骤506，IM客户端向Key Store提交验证。

例如，IM客户端的验证中携带IM客户端的数字签名，用于供Key Store验证IM客户端的合法性；对于IM客户端根据不同登录用户生成相应密钥的情况，验证请求中还可以携带用于供Key Store定位相应登录用户对应密钥的信息，如登录用户的ID。

步骤507，Key Store验证通过后，将IM客户端预存储的密钥返回给IM客户端。

IM客户端提交验证并获得密钥的过程为：IM客户端通过向Key Store提交IM客户端名称的数字签名的方式请求Key Store进行验证，Key Store根据不对称加密算法的公钥对数字签名解密得到摘要，同时利用摘要算法计算验证中携带的应用程序的名称，将计算得到的摘要与界面得到的摘要进行比较，一致则验证通过；Key Store根据IM客户端和登录用户的名称，定位密钥串中对应的密钥并返回IM客户端。

步骤508，IM客户端基于所获得的密钥，请求对SQLite数据库中存储的IM客户端的联系人信息进行解密。

步骤509，SQLite数据库将以密钥加密的目标联系人信息置于解密状态，以准备接收IM客户端的操作。

IM客户端向数据库提交从密钥库服务获得的密钥，数据库将利用密钥将IM客户端的当前登录用户的联系人信息置于解密状态，IM客户端可以直接操作处于解密状态的目标联系人信息；而对于IM客户端的其他用户的联系人信息，由于密钥不匹配将继续处于加密状态，

步骤510，IM客户端对解密后的数据进行相应操作。

IM客户端可以直接对处于解密状态的联系人信息进行读取、增加、修改和删除的操作；另外，为了提高后续在缓存中命中目标联系人信息的几率，IM客户端将根据操作的目标联系人信息更新缓存。

例如，对于更新缓存来说，当操作的类型为读取时，读取的目标联系人信息不仅返回IM客户端，还将被存储至缓存中，IM客户端后续可以直接从缓存中读取目标联系人信息，操作效率将显著提升；当操作的类型为修改和写入的处理时类似，当操作的类型为删除时，IM客户端除了删除数据库中的目标联系人信息，还删除缓存中的目标联系人信息，以保持数据状态的一致性。

根据操作的不同类型对上述步骤504至步骤509进行说明。

示例1)目标联系人信息的操作类型为读取时，将对步骤504至步骤509进行说明，参见图6，图6为本发明实施例提供的目标联系人信息的读取过程的一个可选的流程示意图，包括以下步骤：

步骤601，IM客户端需要读取目标联系人信息，即对目标联系人信息的操作的类型为读取。

步骤602，IM客户端在设备的缓存中查找是否联系人信息名称的目标联系人信息的键，若命中，则执行步骤603，否则执行步骤604。

例如，缓存中同样可以采用键值对的方式存储联系人信息，IM客户端以目标联系人信息的名称为索引(键)，对目标联系人信息的值进行查找。

步骤603，IM客户端读取缓存中的目标联系人信息的值。

此外，在读取缓存中的目标联系人信息的值后，且在满足同步条件时，IM客户端将缓存中存储的联系人信息与SQLite数据库中存储的联系人信息同步。

例如，应用程序对缓存中应用程序的全部联系人信息进行统一的同步，或者，以用户为维度，对缓存中各登录用户的联系人信息分别进行同步(在各用户的联系人信息满足同步条件时，例如同步时间到达，或者缓存中的联系人信息到达到一定容量)。

步骤604，IM客户端在SQLite数据库中查找目标联系人信息的键，若未命中，则执行步骤605，否则执行步骤606。

步骤605，IM客户端将目标联系人信息的键插入SQLite数据库中，目标联系人信息的值为空，根据需要(例如IM客户端生产了对应的值，例如会话数据)可以增加对应的值。

步骤606，IM客户端在SQLite数据库中读取目标联系人信息的值，并在缓存中存储所读取的目标联系人信息的键值对，操作完成后返回步骤603。

示例2)目标联系人信息的操作类型为写入时，将对步骤504至步骤509进行说明，参见图7，图7为本发明实施例提供的目标联系人信息的写入过程的一个可选的流程示意图，包括以下步骤：

步骤701，IM客户端检测到对目标联系人信息的操作的类型为写入，即对目标联系人信息的操作的类型为写入。

写入目标联系人信息可以是向目标联系人信息的键值对中增加新的值，或修改已有的值；写入的一个示例为，IM客户端向联系人信息中写入新的后台服务器的IP地址和端口；又一个示例为，IM客户端修改联系人信息后台服务器的端口。

步骤702，IM客户端在设备的缓存中查找是否目标联系人信息的键，若命中，则执行步骤703，否则执行步骤704。

步骤703，IM客户端在缓存中的目标联系人信息的键值对中写入值。

在缓存的目标联系人信息的键值对写入值后，且在满足同步条件时，将缓存中IM客户端的联系人信息与SQLite数据库中同步，保持联系人信息的一致性。

步骤704，IM客户端将目标联系人信息的键值对插入SQLite数据库中。

步骤705，IM客户端在缓存中存入目标联系人信息，并返回步骤703，将写入的目标联系人信息存储至缓存中，提高后续操作的命中率。

示例3)目标联系人信息的操作类型为删除时，将对步骤504至步骤509进行说明，参见图8，图8为本发明实施例提供的目标联系人信息的删除过程的一个可选的流程示意图，包括以下步骤：

步骤801，IM客户端需要删除目标联系人信息，即对目标联系人信息的操作的类型为删除。

作为示例，IM客户端删除用户不再使用的一个主题风格，或者是不再使用的一个小程序。

步骤802，IM客户端在设备的缓存中查找目标联系人信息的键，若命中，则执行步骤803，否则执行步骤804。

步骤803，IM客户端在缓存中删除查找到的目标联系人信息的值。

步骤804，IM客户端在缓存中删除目标联系人信息的值。

已经对IM客户端的不同数据库操作进行了说明，IM客户端操作完毕之后，作为示例，可以向SQL数据库通知操作完毕，SQL数据库将根据步骤510将联系人信息置于加密状态，当然，也可以在预定时间内没有接收到IM客户端的操作时，将联系人信息置于加密状态。

步骤511，IM客户端针对目标联系人信息获取完毕后，SQLite数据库将标联系人信息再次置于加密状态。

可见，SQLite数据库中的数据默认处于加密状态，并且对于处于解密状态的联系人信息，根据一定时间内没有接收到IM客户端操作的请求的情况，或者，根据IM客户端已经完成数据库操作的情况，避免解密状态的数据长期处于无操作的状态，保证数据安全。

对于步骤307中联系人信息的获取，可选的操作方式包括：

示例4)结合图10对本发明实施例获取联系人信息过程做详细说明，参见图10，图10为本发明实施例提供的IM客户端获取联系人信息过程的一个可选的流程示意图，包括以下步骤：

步骤1001，IM客户端接收操作联系人信息。

当接收到关于读取联系人信息的指令时，应用程序开始操作该指令指定的联系人信息。这里，联系人信息可以是以用户的个人信息，如图11所示，其中，个人信息包括：手机号、社交网络账号、电子邮箱账号和通信地址等信息；联系人信息也可以是以部门的部门信息，如图12所示，其中，部门信息包括：部门成员、部门结构和工程项目之类的信息。

步骤1002，IM客户端读取Keychain。

当接收到关于读取联系人信息的指令之后，应用程序在Keychain中读取关于联系人信息的密钥，用于对联系人信息的解密操作，这里的联系人信息为加密后的信息。

步骤1003，IM客户端检测Keychain是否存在相应的密钥记录，若是，执行步骤1004；否则，执行步骤1006。

在Keychain中读取关于联系人信息的密钥时，可能会出现以下情况：

1)Keychain中未存储相应的密钥；

2)Keychain中所存储相应的密钥遭到破坏。

当出现上述情况时，则执行步骤1004；否则，执行步骤1006。

步骤1004，IM客户端生成针对联系人信息的密钥，然后进入步骤1005。

这里，生成针对联系人信息的密钥的方法，可以是：将首次登录时间、登录账号、设备串号和设备生成的随机参数拼接成一组字符串，使用信息摘要算法，如MD5算法，对所拼接的字符串进行哈希运算，获得一定长度的哈希值，并将所述哈希值确定为用于联系人信息的密钥。

这里，会出现这样的情况：联系人信息使用原密钥进行加密，而原密钥遭到了破坏。当出现这种情况时，通过对登录用户进行验证，验证成功后，设备向服务器发送初始化联系人信息的指令，从服务器中获取联系人信息，一方面，使用新生成的密钥对获取到的联系人信息进行加密；另一方面，显示该联系人信息，以便登录用户进行相应的操作。

步骤1005，IM客户端保存密钥至Keychain。

这里，将生成的密钥保存至授权所述应用程序访问的存储区域，例如保存至Keychain。

步骤1006，IM客户端获取联系人信息的密钥。

这里，从Keychain中获取关于联系人信息的密钥。

步骤1007，根据密钥操作数据库获得解密的联系人信息。

对于步骤301中密钥的生成，可选的操作方式包括：

示例5)下面结合图13对本发明实施例密钥生成过程做详细说明，参见图13，图13为本发明实施例提供的密钥生成过程的一个可选的流程示意图，包括以下步骤：

步骤1301，用户凭借账号登录IM客户端。

这里，用户在IM客户端发起登录操作。

步骤1302，IM客户端将账户信息发送至IM服务器。

步骤1303，IM服务器验证账户信息。

步骤1304，若通过验证，IM服务器将验证通过的指示信息发送至IM客户端。

这里，所示指示信息携带有登录用户首次通过IM客户端登录到IM服务器的时间和经过编码后的登录账号。

步骤1305，IM客户端进入登录状态。

步骤1306，IM客户端生成随机参数。

步骤1307，IM客户端根据设备串号、随机参数、登录账号和首次登录时间组合随机字符串。

这里，IM客户端根据设备串号和随机参数，以及指示信息中的登录账号和首次登录时间组合成一定长度的随机字符串。

此外，IM客户端也可以根据设备串号、随机参数、登录账号、IM客户端的宿主设备所处的地理位置和首次登录时间组合随机字符串。

步骤1308，IM客户端通过摘要算法对随机字符串进行哈希运算。

这里，可以使用MD5算法对该随机字符串进行哈希运算，获得一定长度的哈希值，并将该哈希值确定为用于加密和解密联系人信息的密钥。

步骤1309，若验证失败，将验证失败的指示信息发送至IM客户端。

步骤1310：提示登录失败。

本发明实施例还提供了一种联系人信息处理装置，参见图13，图13为本发明实施例提供的联系人信息处理装置的一个可选的功能结构示意图，该装置包括生成单元101、存储单元102、初始化单元103、验证单元104、解密单元105、操作单元106；其中，

生成单元101，用于在应用程序的进程中生成密钥；

存储单元102，用于通过密钥库服务将密钥存储在授权应用程序访问的存储区域；

初始化单元103，用于在应用程序的宿主设备中初始化使用密钥的数据库；

验证单元104，用于当应用程序需要操作数据库中的目标联系人信息时，向密钥库服务提交验证，验证通过后获得预存储的密钥；

解密单元105，用于利用所获得的密钥，对目标联系人进行解密；

操作单元106，用于对解密后的目标联系人信息进行相应操作。

这里，生成单元101，具体用于：

当应用程序在宿主设备中初始化运行时，生成与应用程序对应的密钥；或者，

当应用程序在宿主设备中登录时，生成与应用程序的登录账号对应的密钥。

这里，生成单元101，还用于当满足设定的更新条件时，在所述应用程序的进程中动态更新密钥；

其中，所述更新条件包括以下至少之一：

密钥的生命周期到达预定时长；

密钥的使用次数到达预定使用次数；

密钥的使用频率到达预定使用频率。

这里，生成单元101，具体用于：

获取以下至少一个密钥因子：宿主设备的硬件信息、应用程序的登录账号、地理位置、登录时间和随机数；

基于所获取的密钥因子形成密钥。

这里，生成单元101，还用于将各密钥因子包括的字符按照预定次序进行组合；

基于摘要算法对组合得到的字符提取摘要，将提取得到的摘要作为密钥。

这里，初始化单元103，具体用于：

在数据库中创建以应用程序的联系人信息的名称为键，以应用程序的联系人信息的内容为值的键值对；

将应用程序的键值对在数据库中以应用程序的密钥进行加密。

这里，验证单元104，具体用于：

向密钥库服务提交应用程序名称的数字签名；

当密钥库服务验证数字签名成功后，获得密钥库服务中针对应用程序存储的密钥。

这里，操作单元106，具体用于：

在宿主设备的缓存中查询目标联系人信息；

当在缓存中查询到目标联系人信息时，在缓存中执行基于目标联系人信息的操作；

当在缓存中未查询到目标联系人信息时，向数据库执行基于目标数据的操作，并基于目标联系人信息的操作结果进行更新缓存。

这里，操作单元106，具体用于：

当满足同步条件时，将缓存中存储的应用程序的联系人信息与数据库进行同步。

其中，目标联系人信息的操作的类型包括：读取、增加、修改和删除；相应的，操作单元106，具体用于以下至少之一：

当目标联系人信息的操作的类型为读取时，读取缓存中存储的相应的目标联系人信息；

当目标联系人信息的操作的类型为增加时，在缓存中相应的目标联系人信息写入新的数据；

当目标联系人信息的操作的类型为修改时，在缓存中修改相应的目标联系人信息；

当目标联系人信息的操作的类型为删除时，在缓存和数据库中删除相应的目标联系人信息。

在实际应用程序中，生成单元101、存储单元102、初始化单元103、验证单元104、解密单元105、操作单元106、获取单元1011、组合单元1012均可由位于计算机设备上的CPU、微处理器(MPU，Micro Processor Unit)、DSP、或现场可编程门阵列(FPGA，FieldProgrammable Gate Array)等实现。

需要说明的是：上述实施例提供的联系人信息处理装置在进行联系人信息处理时，仅以上述各程序单元的划分进行举例说明，实际应用程序中，可以根据需要而将上述处理分配由不同的程序单元完成，即将装置的内部结构划分成不同的程序单元，以完成以上描述的全部或者部分处理。另外，上述实施例提供的联系人信息处理装置与联系人信息处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本发明实施例还提供了一种存储介质，存储有可执行程序，可执行程序被处理器执行时，实现本发明实施例提供的联系人信息处理方法，本发明实施例提供的存储介质可为光盘、闪存或磁盘等存储介质，可选为非瞬间存储介质。

参见图15，图15是本发明实施例提供的联系人信息处理的一个可选的场景示意图，对本发明实施例提供的联系人信息处理方法的实现过程进行说明。

一、企业IM根据登录用户生成密钥

企业IM根据随机数与以下密钥因子至少之一：用户输入的登录账号、设备的硬件串号、登录时间和地理位置组合形成密钥；当然，作为替换方案，根据企业IM在初始化运行时(如安装后)，结合设备的串号和随机数生成全局的密钥，这里，随机数为客户端随机生成的字符，字符可以包括数字、字母和特殊字符。

二、密钥在密钥库服务中存储

企业IM将当前登录用户的密钥传送至密钥库服务，密钥库服务为企业IM单独设置一个密钥串，在密钥串中存储企业IM生成的密钥，例如可以存储企业针对多个登录用户生成的密钥。

由于密钥库服务为每个应用程序设置一个密钥串服务，而密钥串是由密钥库服务提供的基于沙箱机制的一种安全容器，其它应用程序无法访问企业IM应用程序应用设置的密钥存储区域，即无法访问企业IM应用程序的存储密钥的安全容器，从而保证了密钥的安全性。

三、基于密钥初始化数据库

企业IM将密钥传递至数据库，在数据库中密钥初始化一部分的空间，在这部分空间中设置访问控制，只有提交正确的密钥后空间中存储的数据才会置于解密状态；在长时间没有操作，或获知对空间中的数据操作完成后，空间中的联系人信息会重新置于加密状态。

四、获取密钥进行数据库操作

企业IM首先在设备的缓存中查询当前登录用户的联系人信息，如果查找通信方式对应的键，则获取到相应的通信方式的值，根据实际需求，登录用户的可以对联系人信息进行查看，以及修改和增添相应的信息，如修改或增添通信方式。

如果没有查找到联系人信息对应的键，则根据持有的数字签名从密钥库服务获得针对登录用户预存储的密钥，将数据库中对应登录用户的空间置于解密状态，写入联系人信息的键值对，然后退出数据库操作，从而，登录用户的设定在数据库中持久化存储。这里，当缓存库中无联系人信息时，除了根据密钥从SQL数据库中获取联系人信息，为了更快捷和方便的查找联系人信息，可以将SQL数据库中的联系人信息同步至缓存库中。

这样，当前用户退出登录并再次登录时，根据缓存-数据库这样的顺序查找联系人信息，以便进行查看、修改或通过目标联系人信息与目标联系人建立会话服务。

由于联系人信息的查找是基于数据库操作完成，借助于数据库的特性能够保证处理效率，缓存机制又最大程度减少了数据库操作，进一步提升了处理效率，同时，密钥库服务保证了对联系人信息获取的安全性。

综上所述，本发明实施例可实现以下有益效果：

1)对于应用程序生成的密钥而言，由于密钥由密钥库服务进行存储，而且只能由授权的应用程序访问，对于其他应用程序无法访问，有效避免了应用程序的密钥被其他应用程序如恶意程序监听的情况，保证了密钥安全。

2)对于需要操作的联系人信息而言，在数据库对应用程序的联系人信息进行加密存储，数据库基于密钥有效保证了联系人信息的安全，不会被其他应用程序操作，同时数据库技术本身保证了对联系人信息的操作效率。

3)有效的保证密钥安全，通过密钥更新机制，进行全局或登录账号维度的密钥更新，最大程度降低了密钥被破解的可能性；随机数作为密钥因子，保证了在密钥生成的算法即使被破解也无法得到正确的密钥。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (15)

1.一种联系人信息处理方法，其特征在于，包括：

在应用程序的进程中生成密钥，通过密钥库服务将所述密钥存储在授权所述应用程序访问的存储区域；

在所述应用程序的宿主设备中初始化使用所述密钥的数据库；

当所述应用程序需要操作所述数据库中的目标联系人信息时，向所述密钥库服务提交验证，验证通过后获得预存储的密钥；

利用所获得的密钥，对所述目标联系人信息进行解密，对解密后的目标联系人信息进行相应操作。

2.根据权利要求1所述的方法，其特征在于，所述在应用程序的进程中生成密钥，包括：

当所述应用程序在所述宿主设备中初始化运行时，生成与所述应用程序对应的密钥；或者，

当所述应用程序在所述宿主设备中登录时，生成与所述应用程序的登录账号对应的密钥。

3.根据权利要求1所述的方法，其特征在于，所述在应用程序的进程中生成密钥，包括：

获取以下至少一个密钥因子：所述宿主设备的硬件信息、所述应用程序的登录账号、地理位置、登录时间和随机数；

基于所获取的密钥因子形成所述密钥。

4.根据权利要求3所述的方法，其特征在于，所述基于所获取的密钥因子形成所述密钥，包括：

将各所述密钥因子包括的字符按照次序进行组合；

基于摘要算法对组合得到的字符提取摘要，将提取得到的摘要作为所述密钥。

5.根据权利要求1所述的方法，其特征在于，所述向所述密钥库服务提交验证，包括：

在所述宿主设备的缓存中查询所述目标联系人信息；

当在所述缓存中查询到所述目标联系人信息时，在所述缓存中执行基于所述目标联系人信息的操作；

当在所述缓存中未查询到所述目标联系人信息时，向所述数据库执行基于所述目标数据的操作，并基于所述目标联系人信息的操作结果更新所述缓存。

6.根据权利要求5所述的方法，其特征在于，所述目标联系人信息的操作的类型包括：读取、增加、修改和删除；

所述对解密后的目标联系人信息进行相应操作，包括：

根据所述操作的类型对应执行以下操作：

当所述目标联系人信息的操作的类型为读取时，读取所述缓存中存储的相应的目标联系人信息；

当所述目标联系人信息的操作的类型为增加时，在所述缓存中相应的目标联系人信息写入新的数据；

当所述目标联系人信息的操作的类型为修改时，在所述缓存中修改相应的目标联系人信息；

当所述目标联系人信息的操作的类型为删除时，在所述缓存和所述数据库中删除相应的目标联系人信息。

7.根据权利要求1所述的方法，其特征在于，还包括：

当满足设定的更新条件时，在所述应用程序的进程中动态更新密钥；

其中，所述更新条件包括以下至少之一：

密钥的生命周期到达预定时长；

密钥的使用次数到达预定使用次数；

密钥的使用频率到达预定使用频率。

8.一种联系人信息处理装置，其特征在于，包括：

生成单元，用于在应用程序的进程中生成密钥；

存储单元，用于通过密钥库服务将所述密钥存储在授权所述应用程序访问的存储区域；

初始化单元，用于在所述应用程序的宿主设备中初始化使用所述密钥的数据库；

验证单元，用于当所述应用程序需要操作所述数据库中的目标联系人信息时，向所述密钥库服务提交验证，验证通过后获得预存储的密钥；

解密单元，用于利用所获得的密钥，对所述数据库进行解密；

操作单元，用于对解密后的目标联系人信息进行相应操作。

9.根据权利要求8所述的装置，其特征在于，所述生成单元，具体用于：

当所述应用程序在所述宿主设备中初始化运行时，生成与所述应用程序对应的密钥；或者，

当所述应用程序在所述宿主设备中登录时，生成与所述应用程序的登录账号对应的密钥。

10.根据权利要求8所述的装置，其特征在于，所述生成单元具体用于：

获取以下至少一个密钥因子：所述宿主设备的硬件信息、所述应用程序的登录账号、地理位置、登录时间和随机数；

基于所获取的密钥因子形成所述密钥。

11.根据权利要求10所述的装置，其特征在于，所述生成单元具体用于：

将各所述密钥因子包括的字符按照次序进行组合；

基于摘要算法对组合得到的字符提取摘要，将提取得到的摘要作为所述密钥。

12.根据权利要求8所述的装置，其特征在于，所述操作单元，具体用于：

在所述宿主设备的缓存中查询所述目标联系人信息；

当在所述缓存中查询到所述目标联系人信息时，在所述缓存中执行基于所述目标联系人信息的操作；

当在所述缓存中未查询到所述目标联系人信息时，向所述数据库执行基于所述目标数据的操作，并基于所述目标联系人信息的操作结果进行更新所述缓存。

13.根据权利要求12所述的装置，其特征在于，所述目标联系人信息的操作的类型包括：读取、增加、修改和删除；

所述操作单元，具体用于根据所述操作的类型对应执行以下操作：

当所述目标联系人信息的操作的类型为读取时，读取所述缓存中存储的相应的目标联系人信息；

当所述目标联系人信息的操作的类型为增加时，在所述缓存中相应的目标联系人信息写入新的数据；

当所述目标联系人信息的操作的类型为修改时，在所述缓存中修改相应的目标联系人信息；

当所述目标联系人信息的操作的类型为删除时，在所述缓存和所述数据库中删除相应的目标联系人信息。

14.一种存储介质，其特征在于，存储有可执行程序，所述可执行程序被处理器执行时，实现如权利要求1至7任一项所述的联系人信息处理方法。

15.一种联系人信息处理装置，其特征在于，包括：

存储器，用于存储可执行程序；

处理器，用于执行所述存储器中存储的所述可执行程序时，实现如权利要求1至7任一项所述的联系人信息处理方法。