获取电子文件的方法及装置与流程

本申请涉及信息技术领域，尤其涉及一种获取电子文件的方法及装置。

背景技术：

为了确保民众用药安全、有效，药房在销售处方药时需要购买方提供医生开具的纸质处方作为购买凭证。随着互联网在各行业的普及，基于互联网的电子处方也得到电商平台的大力推广，电子处方相对于纸质处方，具有格式规范、内容全面清晰、便于医患查询历史记录等优点，是规模推广处方药在线销售的基础。为了方便用户以及药店使用电子处方，需要在互联网基础上建立电子处方平台(Electronic Prescription Platform，简称为EPP)，从而方便各方查阅和使用处方。由于电子处方包含很多用户隐私信息，例如，患者的姓名、证件号码、手机号码、生日、社保卡号、所患疾病及医生所开具的药品等，由于通过互联网可以随时、随地获取，因此患者的隐私信息容易被恶意攻击和窃取，电子处方中涉及到患者的隐私信息需要更完备的保护手段。

技术实现要素：

有鉴于此，本申请提供一种新的技术方案，可以解决现有技术中对电子文件上涉及到的用户的隐私信息的保护不够完备的技术问题。

为实现上述目的，本申请提供技术方案如下：

根据本发明的第一方面，提出了一种获取电子文件的方法，应用在终端设备上，包括：

根据所述终端设备的用户在登录平台服务器时的登录信息和提供所述电子文件的信息提供服务器对应的第一标识生成第一加密密钥，所述信息提供服务器用于为所述终端设备提供所述电子文件；

向所述平台服务器发送用于获取所述电子文件的第一请求消息，所述第一请求消息中携带有所述第一标识和所述电子文件的第二标识；

接收所述平台服务器根据所述登录信息和所述第一请求消息返回的通过第二加密密钥加密的所述电子文件，所述第二加密密钥由所述第一加密密钥、所述第一标识和所述第二标识生成；

根据所述第一加密密钥生成第一解密密钥，通过所述第一解密密钥对经过所述第二加密密钥加密后的所述电子文件进行解密，得到解密后的所述电子文件。

根据本发明的第二方面，提出了一种获取电子文件的方法，应用在终端设备上，包括：

向平台服务器发送获取电子文件的第二请求消息，所述第二请求消息中携带有提供所述电子文件的信息提供服务器对应的第一标识、所述电子文件的第二标识以及第三方用户的第三标识；

在所述平台服务器确认所述第三标识具有查阅所述电子文件的权限并且所述第一标识与所述登录信息中所包括的用户登录名具有绑定关系后，接收所述平台服务器返回的所述第三方用户的数字证书；

从所述数字证书中获取所述第三方用户的公钥；

根据所述第一加密密钥、所述第一标识和所述第二标识通过哈希运算生成所述第二加密密钥；

通过所述第三方用户的公钥对所述第二加密密钥进行加密，将所述第一标识、所述第二标识以及加密后的所述第二加密密钥发送至所述平台服务器。

根据本发明的第三方面，提出了一种获取电子文件的方法，应用在平台服务器上，包括：

接收来自终端设备的用于获取电子文件的第一请求消息，所述第一请求 消息中携带有提供电子文件的信息提供服务器对应的第一标识和所述电子文件对应的第二标识；

通过所述终端设备的用户在所述平台服务器的登录信息和所述第一标识确定所述用户在所述信息提供服务器的用户注册名；

将所述第一标识、所述第二标识和所述用户注册名进行数字签名后发送至所述信息提供服务器；

接收所述信息提供服务器通过第二加密密钥加密后的电子文件，所述第二加密密钥由第一加密密钥和所述第一标识生成，所述第一加密密钥根据所述终端设备的用户登录所述平台服务器的登录信息和所述第一标识生成；

将通过所述第二加密密钥加密的所述电子文件发送至终端设备。

根据本发明的第四方面，提出了一种获取电子文件的方法，应用在信息提供服务器上，包括：

接收来自平台服务器的用于获取电子文件的第三请求消息，所述第三请求消息中携带有所述信息提供服务器对应的第一标识、所述电子文件的第二标识；

根据所述第二标识查找所述电子文件；

根据所述第一标识、所述第二标识、第一加密密钥生成用于加密所述电子文件的第二加密密钥，所述第一加密密钥由所述终端设备在所述平台服务器的登录信息和所述第一标识生成；

将所述第一标识、所述第二标识和经过所述第二加密密钥加密后的所述电子文件发送至所述平台服务器。

根据本发明的第五方面，提出了一种获取电子文件的装置，应用在终端设备上，包括：

第一生成模块，用于根据所述终端设备的用户在登录平台服务器时的登录信息和提供所述电子文件的信息提供服务器对应的第一标识生成第一加密密钥，所述信息提供服务器用于为所述终端设备提供所述电子文件；

第一发送模块，用于向所述平台服务器发送用于获取所述电子文件的第 一请求消息，所述第一请求消息中携带有所述第一标识和所述电子文件的第二标识；

第一接收模块，用于接收所述平台服务器根据所述登录信息和所述第一发送模块发送的第一请求消息返回的通过第二加密密钥加密的所述电子文件，所述第二加密密钥由所述第一加密密钥、所述第一标识和所述第二标识生成；

第一解密模块，用于根据所述第一生成模块生成的所述第一加密密钥生成第一解密密钥，通过所述第一解密密钥对所述第一接收模块接收到的经过所述第二加密密钥加密后的所述电子文件进行解密，得到解密后的所述电子文件。

根据本发明的第六方面，提出了一种获取电子文件的装置，应用在平台服务器上，包括：

第七接收模块，用于接收来自终端设备的用于获取电子文件的第一请求消息，所述第一请求消息中携带有提供电子文件的信息提供服务器对应的第一标识和所述电子文件对应的第二标识；

第三确定模块，用于通过所述终端设备的用户在所述平台服务器的登录信息和所述第七接收模块接收到的所述第一请求消息中携带的所述第一标识确定所述用户在所述信息提供服务器的用户注册名；

第七发送模块，用于将所述第一标识、所述第二标识和所述用户注册名进行数字签名后发送至所述信息提供服务器；

第八接收模块，用于接收所述信息提供服务器通过第二加密密钥加密后的电子文件，所述第二加密密钥由第一加密密钥和所述第七接收模块接收到的所述第一请求消息中携带的所述第一标识生成，所述第一加密密钥根据所述终端设备的用户登录所述平台服务器的登录信息和所述第一标识生成；

第八发送模块，用于将所述第八接收模块接收到的通过所述第二加密密钥加密的所述电子文件发送至终端设备。

根据本发明的第七方面，提出了一种获取电子文件的装置，应用在信息 提供服务器上，包括：

第十六接收模块，用于接收来自平台服务器的用于获取电子文件的第三请求消息，所述第三请求消息中携带有所述信息提供服务器对应的第一标识、所述电子文件的第二标识；

查找模块，用于根据所述第十六接收模块接收到的所述第二标识查找所述电子文件；

第二生成模块，用于根据所述第十六接收模块接收到的所述第一标识、所述第二标识、第一加密密钥生成用于加密所述电子文件的第二加密密钥，所述第一加密密钥由所述终端设备在所述平台服务器的登录信息和所述第一标识生成；

第十七发送模块，用于将所述第一标识、所述第二标识和经过所述第二生成模块生成的所述第二加密密钥加密后的所述电子文件发送至所述平台服务器。

由以上技术方案可见，本发明实施例通过第二加密密钥加密终端设备所请求的电子文件，由于第二加密密钥由第一加密密钥、第一标识和第二标识生成，因此终端设备可以根据第一加密密钥生成与第二加密密钥相对应的第一解密密钥，通过第一解密密钥对经过第二加密密钥加密的电子文件进行解密，得到解密后的电子文件，从而可以使从信息提供服务器获取到的电子文件中涉及到用户的隐私信息不会被平台服务器泄密，由于信息提供服务器对电子文件进行加密所采用的第二加密密钥由第一加密密钥、第一标识和第二标识生成，因此终端设备不需要与信息提供服务器进行密钥交换即可以获得解密密钥，方便终端设备的用户使用。

附图说明

图1是根据一示例性实施例一示出的获取电子文件的方法的流程图；

图2是根据一示例性实施例二示出的获取电子文件的方法的流程示意图；

图3是根据一示例性实施例三示出的获取电子文件的方法的流程示意图；

图4是根据一示例性实施例四示出的获取电子文件的方法的流程示意图；

图5A是根据又一示例性实施例一示出的获取电子文件的方法的流程图；

图5B是根据又一示例性实施例一示出的获取电子文件的方法所适用的系统结构图；

图5C是根据又一示例性实施例一示出的平台服务器如何存储用户的登录信息的系流程示意图图；

图6是根据又一示例性实施例二示出的获取电子文件的方法的流程图；

图7是根据又一示例性实施例三示出的获取电子文件的方法的流程图；

图8是根据又一示例性实施例四示出的获取电子文件的方法的流程图；

图9是根据另一示例性实施例一示出的获取电子文件的方法的流程图；

图10是根据另一示例性实施例二示出的获取电子文件的方法的流程图；

图11是根据另一示例性实施例三示出的获取电子文件的方法的流程图；

图12是根据一示例性实施例示出的获取电子文件的方法的场景图之一；

图13是根据一示例性实施例示出的获取电子文件的方法的场景图之二；

图14是根据一示例性实施例示出的获取电子文件的方法的场景图之三；

图15示出了根据本发明的一示例性实施例的终端设备的结构示意图；

图16示出了根据本发明的一示例性实施例的平台服务器的结构示意图；

图17示出了根据本发明的一示例性实施例的信息提供服务器的结构示意图；

图18是根据一示例性实施例一示出的获取电子文件的装置的结构示意图；

图19是根据一示例性实施例二示出的获取电子文件的装置的结构示意图；

图20是根据又一示例性实施例一示出的获取电子文件的装置的结构示 意图；

图21是根据又一示例性实施例二示出的获取电子文件的装置的结构示意图；

图22是根据另一示例性实施例一示出的获取电子文件的装置的结构示意图；

图23是根据另一示例性实施例二示出的获取电子文件的装置的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在本发明实施例中，通过第二加密密钥加密终端设备所请求的电子文件，由于第二加密密钥由第一加密密钥、第一标识和第二标识生成，因此终端设 备可以根据第一加密密钥生成与第二加密密钥相对应的第一解密密钥，通过第一解密密钥对经过第二加密密钥加密的电子文件进行解密，得到解密后的电子文件，从而可以使从信息提供服务器获取到的电子文件中涉及到用户的隐私信息不会被平台服务器泄密，由于信息提供服务器对电子文件进行加密所采用的第二加密密钥由第一加密密钥、第一标识和第二标识生成，因此终端设备不需要与信息提供服务器进行密钥交换即可以获得解密密钥，方便终端设备的用户使用。

为对本申请进行进一步说明，提供下列实施例：

请参考图1，为根据一示例性实施例一示出的获取电子文件的方法的流程图，本实施例可以应用在终端设备上，包括如下步骤：

步骤101，根据终端设备的用户在登录平台服务器时的登录信息和提供电子文件的信息提供服务器对应的第一标识生成第一加密密钥，信息提供服务器用于为终端设备提供电子文件。

步骤102，向平台服务器发送用于获取电子文件的第一请求消息，第一请求消息中携带有第一标识和电子文件的第二标识。

步骤103，接收平台服务器根据登录信息和第一请求消息返回的通过第二加密密钥加密的电子文件，第二加密密钥由第一加密密钥、第一标识和第二标识生成。

步骤104，根据第一加密密钥生成第一解密密钥，通过第一解密密钥对经过第二加密密钥加密后的电子文件进行解密，得到解密后的电子文件。

在上述步骤101中，终端设备可以根据用户登录平台服务器的登录信息和提供电子文件的信息提供服务器对应的第一标识生成第一加密密钥，该第一加密密钥可以视为种子密钥(Seed)，与信息提供服务器共享该种子密钥，由于第一加密密钥可以通过登录信息和第一标识生成，因此终端设备不需要保存该种子密钥，从而可以提高被种子密钥加密的电子文件的安全性和用户体验。在一实施例中，种子密钥可以通过哈希运算的方式得到，即，Seed＝Hash(HIS_ID，Username，Password)，其中，HIS_ID为第一标识，Username 为登录信息中的用户登录名，Password为登录信息中的登录密码。在一实施例中，平台服务器可以作为连接终端设备与信息提供服务器的网络平台，可以由电商平台提供，不同的终端设备与不同的信息提供服务器可以通过平台服务器进行电子文件的传输。在一实施例中，电子文件可以为电子处方，信息提供服务器可以为位于医院侧的医院信息系统(Hospital Information System，简称为HIS)，平台服务器可以为位于网络侧的电子处方平台(Electronic Prescription Platform，简称为EPP)，在另一实施例中，电子文件还可以为终端设备侧的用户的社保文件，信息提供服务器可以为社保中心侧的社保服务系统，平台服务器可以为位于网络侧的社保信息平台，在再一实施例中，电子文件还可以为终端设备侧的用户的住房公积金账单，信息提供服务器可以为住房公积金管理中心侧的公积金服务系统，平台服务器可以为位于网络侧的公积金信息平台，由此可知，本申请不对电子文件的具体内容进行限制，只要是需要通过本申请进行加密保护的电子文件均为本申请中的电子文件。

在上述步骤102中，本实施例以电子文件具体为电子处方为例进行示例性说明，在一实施例中，第一请求消息中可以携带有第一标识，此时第一标识为终端设备的用户在HIS对应的医院代码HIS_ID，第二标识为电子处方的处方号P_ID。

在上述步骤103中，EPP在接收到第一请求消息后，EPP验证登录信息中的用户登录名是否与第一标识的绑定关系，如果确定第一标识与用户登录名具有绑定关系，则向HIS获取第二标识对应的电子处方。

在上述步骤104中，终端设备可以根据第一加密密钥生成相应的解密密钥，通过解密密钥对经过第二加密密钥加密后的电子处方的隐私信息进行解密，此外，还可以通过解密后的隐私信息验证电子处方的合法性。

本实施例中，通过第二加密密钥加密终端设备所请求的电子文件，由于第二加密密钥由第一加密密钥、第一标识和第二标识生成，因此终端设备可以根据第一加密密钥生成与第二加密密钥相对应的第一解密密钥，通过第一 解密密钥对经过第二加密密钥加密的电子文件进行解密，得到解密后的电子文件，从而可以使从信息提供服务器获取到的电子文件中涉及到用户的隐私信息不会被平台服务器泄密，由于信息提供服务器对电子文件进行加密所采用的第二加密密钥由第一加密密钥、第一标识和第二标识生成，因此终端设备不需要与信息提供服务器进行密钥交换即可以获得解密密钥，方便终端设备的用户使用。

请参考图2，为根据一示例性实施例二示出的获取电子文件的方法的流程图，包括如下步骤：

步骤201，对登录信息进行哈希运算，得到哈希运算后的登录信息。

步骤202，将哈希运算后的登录信息发送至平台服务器。

步骤203，接收平台服务器根据哈希运算后的登录信息返回的第一确认消息。

步骤204，对登录信息所包括的用户登录名、登录密码和提供电子文件的信息提供服务器对应的第一标识进行哈希运算，生成第一加密密钥。

步骤205，将第一加密密钥、第一标识、第二标识进行哈希运算，得到哈希值。

步骤206，向平台服务器发送用于获取电子文件的第一请求消息，第一请求消息中携带有第一标识、电子文件的第二标识和哈希值，以供平台服务器将哈希值转发给信息提供服务器后根据哈希值验证第一请求消息的合法性。

步骤207，接收平台服务器根据登录信息和第一请求消息返回的通过第二加密密钥加密的电子文件，第二加密密钥由第一加密密钥、第一标识和第二标识生成。

步骤208，根据第一加密密钥生成第一解密密钥，通过第一解密密钥对经过第二加密密钥加密后的电子文件进行解密，得到解密后的电子文件。

步骤209，在得到解密后的电子文件之后，对电子文件中的用户信息进行合法性验证。

步骤201-步骤203中，在一实施例中，登录信息所包括的用户登录名(也可称为用户标识)可以为用户的手机号，终端设备可以对手机号进行哈希运算，从而在通过哈希运算后的用户登录名登录平台服务器时，平台服务器并不能获取到终端设备的用户的真实的登录信息，从而防止窃听者窃取终端设备的用户的登录信息以及平台服务器泄露终端设备的用户的登录信息。

步骤204的描述可以参考上述步骤101的描述，在此不再详述。

在步骤205中，通过将第一标识HIS_ID、第二标识P_ID和第一加密密钥进行哈希运算消息认证码(Hash-based Message Authentication Code，简称为HMAC)的哈希运算，从而得哈希值HMAC，由此可以使HIS对第一请求消息的合法性进行验证。

步骤206-步骤208的描述可以参考上述步骤102-步骤104的描述，在此不再详述。

在步骤209中，在得到解密后的电子文件之后，对电子文件中的用户信息进行合法性验证，从而避免终端设备得到与终端设备的用户不相关的电子文件。

本实施例具有上述实施例的有益技术效果的基础上，通过对登录信息进行哈希运算后登录平台服务器，可以使平台服务器不能获取到真实终端设备的用户的真实的登录信息，防止窃听者窃取终端设备的用户的登录信息以及平台服务器泄露终端设备的用户的登录信息；通过对第一标识、第二标识和第一加密密钥进行哈希运算，得到哈希值，从而可以使信息提供服务器验证此次接收到的第一请求消息的合法性。

请参考图3，为根据一示例性实施例三示出的获取电子文件的方法的流程示意图，在上述图1或图2所示实施例的基础上，本实施例以用户登录名需要绑定信息提供服务器以及在获取电子处方的过程中的授权与认证为例进行示例性说明，在终端设备的用户已经在平台服务器注册，并有其相应的用户登录名以及，终端设备的用户也已经在可信第三方(Trusted Third Party， 简称为TTP)平台注册，并且，终端设备的用户已经在平台服务器登录，如图3所示，包括如下步骤：

步骤301，接收平台服务器验证第一标识与登录信息中的用户登录名之间的绑定关系后返回的第二确认消息，如果第二确认消息表示第一标识和用户登录名不存在绑定关系，执行步骤302，如果第二确认消息表示第一标识和用户登录名具有绑定关系，接收平台服务器根据第一请求消息返回的通过第二加密密钥加密的电子文件，处理流程可参见上述实施例，本实施例对此不再详述。

步骤302，根据第一标识、用户登录名和登录密码生成第一加密密钥。

步骤303，根据第一标识确定信息提供服务器的数字证书对应的数字信封。

步骤304，通过数字信封将第一加密密钥和用户登录名在信息提供服务器对应的卡标识加密后发送至平台服务器。

步骤305，在平台服务器向终端设备返回第三方认证通知时，向可信第三方平台发送登录信息所包括的用户登录名对应的用户信息。

步骤306，在可信第三方平台对用户信息进行验证后，接收来自可信第三方平台的数字签名，数字签名由可信第三方平台通过可信第三方平台的私钥对时间戳、用户信息的哈希值进行签名得到。

步骤307，将可信第三方平台的数字签名的认证结果发送平台服务器。

步骤308，在平台服务器验证认证结果的合法性后，接收平台服务器根据认证结果返回的用户信息和第一加密密钥的哈希值、第一标识和用户登录名绑定成功的通知消息。

步骤309，根据用户信息和第一加密密钥确定用户信息和第一加密密钥的哈希值的真实性，以确认第一标识和登录信息所包括的用户登录名绑定成功，流程结束。

在步骤301-步骤303中，接收平台服务器验证第一标识与登录信息中的用户登录名之间的绑定关系后返回的第二确认消息，如果第二确认消息表示 第一标识和用户登录名不存在绑定关系，终端设备的用户可以基于信息提供服务器对应的第一标识、登录信息的用户登录名和登录密码生成第一加密密钥，终端设备可以基于第一标识向平台服务器请求绑定对应的信息提供服务器的第一标识，并将生成的第一加密密钥以及用户在信息提供服务器对应的卡标识(Card_ID)等信息提供服务器需要的信息通过信息提供服务器提供的数字证书生成的数字信封加密后发给信息提供服务器。

在步骤304中，在一实施例中，如果信息提供服务器为医院信息服务器，则卡标识可以为用户在该医院信息服务器的医疗卡的身份标识(例如，医疗卡的卡号)，如果信息提供服务器为社保信息服务器，则卡标识可以为用户在社保信息服务器的社保卡的身份标识(例如，社保卡的卡号)，如果信息提供服务器为公积金信息服务器，则卡标识可以为用户在公积金信息服务器的银行卡的身份标识(例如，公积金的银行卡号)。

在步骤305中，终端设备可以基于可信第三方超文本传输安全协议(Hypertext Transfer Protocol Secure，简称为HTTPS)连接，向TTP平台提供用户登录名、登录密码，以及期望验证的用户的个人信息，在一实施例中，电子文件为电子处方时，文件信息可以为患者的身份信息(Patient_Info)。

在步骤306和步骤307中，TTP平台验证用户信息后，终端设备接收TTP平台的时间戳、用户实名信息的哈希值以及用户信息的数字签名，终端设备将TTP的验证结果发送给平台服务器。

在步骤308中，在一实施例中，平台服务器可以建立用户登录名与第一标识之间的绑定关系，并保存该绑定关系，此外，平台服务器还可以进一步建立用户登录名与该用户登录名对应的用户在信息提供服务器上的用户注册名之间的绑定关系，在用户通过用户登录名登录到平台服务器后，能够确定该用户登录名在第一标识的信息提供服务器对应的用户注册名。在一实施例中，通过平台服务器向终端设备返回的电子文件的文件信息(在电子文件为电子处方的情形下，该文件信息为病例信息)与第一加密密钥的哈希值，电子文件的第二标识以及绑定成功信息转发至终端设备，终端设备通过第一加 密密钥、文件信息计算哈希值的真实性，从而确认绑定成功。

本实施例中，通过将保存了用户真实信息的TTP平台作为基础对终端设备的用户的身份进行认证，由于TTP平台只向终端设备返回认证结果，终端设备再将认证结果发送给平台服务器，因此平台服务器并不能获取到用户的真实信息，用户的认证过程对于平台服务器而言仍是匿名的；此外，在TTP平台对用户的真实信息进行认证之后，可以在终端设备与信息提供服务器之间共享第一加密密钥，从而简化了终端设备在此后需要获取电子文件时TTP平台介入的复杂性，而且由于终端设备与信息提供服务器通过共享第一加密秘密，而该第一加密密钥基于用户登录平台服务器的登录信息和第一标识生成，不需要要在终端设备上保存该第一加密密钥，提高了电子文件的安全性，由于不需要用户手动通过第一加密密钥对加密后的电子文件进行解密，提高了用户体验。

请参考图4，为根据一示例性实施例四示出的获取电子文件的方法的流程示意图，在上述图1、图2或图3所示实施例的基础上，本实施例以非用户登录名从平台服务器获取电子文件时，通过用户登录名的授权下其他参与者查看电子文件(例如，在电子文件为电子处方时，其他参与者例如为药店、其他医生等)，由于其他参与者需要为平台服务器注册的并能够认可的可信第三方，因此其他参与者需要具有数字证书，例如，药房需要从EPP获取电子处方时，由此，本实施例以第三方用户(例如，药房)获取电子文件为例进行示例性说明。如图4所示，包括如下步骤：

步骤401，向平台服务器发送获取电子文件的第二请求消息，第二请求消息中携带有第一标识、第二标识以及第三方用户的第三标识。

步骤402，在平台服务器确认第三标识具有查阅电子文件的权限并且第一标识与登录信息中所包括的用户登录名具有绑定关系后，接收平台服务器返回的第三方用户的数字证书。

步骤403，从数字证书中获取第三方用户的公钥。

步骤404，根据第一加密密钥、第一标识和第二标识通过哈希运算生成 第二加密密钥。

步骤405，通过第三方用户的公钥对第二加密密钥进行加密，将第一标识、第二标识以及加密后的第二加密密钥发送至平台服务器。

步骤406，在平台服务器根据第二标识查找到电子文件后，接收平台服务器返回的确认第三方授权完成的通知消息。

在步骤401中，终端设备的用户通过其用户登录名登录平台服务器，其登录方式可以参考上述步骤201-步骤203的描述，在此不再详述。与上述步骤201-步骤203不同的是，该第二请求消息中携带有第三方用户的第三标识，平台服务器在对第二请求消息解析后得到第三标识，平台服务器可以通过该第三标识确定该用户登录名需要授权给第三方用户获取该用户登录名对应的电子文件。

在步骤402中，平台服务器通过确认第三方用户是否具有电子文件的查看权限，以及确定该用户登录名与信息提供服务器之间是否具有绑定关系，在确定第三方用户具有电子文件的查看权限以及用户登录名与信息提供服务器具有绑定关系后，向终端设备的用户返回第三方用户的数字证书(B_Cert)。

在步骤403和步骤404中，通过第三方用户的数字证书中确定第三方用户的公钥，并根据第三方用户的公钥生成数字信封，加密处方对应的第二加密密钥KP(本领域技术人员可以理解的是，本实施例可以通过对称加密的方式实现对电子文件的加解密，因此加密密钥与解密密钥相同)，并将第一标识、第二标识，第三方用户的数字证书等一并发送给平台服务器；在一实施例中，终端设备可以通过上述步骤101的描述生成第一加密密钥，基于第一标识、第二标识、第一加密密钥生成电子文件对应的第二加密密钥。

在步骤405和步骤406中，平台服务器可以根据第二标识等信息查找电子文件，并将电子文件和第二加密密钥利用第三方用户的公钥进行加密，将加密后的电子文件和加密密钥发送给第三方用户对应的终端设备，并向终端设备的登陆用户名发送授权已完成的通知消息，第三方用户在通过与其公钥相对应的私钥解密获得第二加密密钥KP，进而利用第二加密密钥KP解密电 子文件，最终可以通过解密后的电子文件验证电子文件的合法性。

本实施例中，用户登录名在发送第二请求消息时，通过将第二请求消息中携带第三方用户的第三标识，从而可以使平台服务器利用第三方用户的数字信封将电子文件以及电子文件的第二加密密钥共享给第三方用户，由于不需要第三方用户重新获取密钥的流程，因此整个过程中平台服务器并没有获得任何的关于电子文件的隐私信息，而且第三方用户也仅具有第二标识的电子文件，因此第三方用户通过该电子文件并不能推断出其他用户登录名在平台服务器上的其它电子文件的密钥进而获得更多的电子文件，因此充分确保了在获取电子文件的过程中的安全性。

请参考图5A，为根据又一示例性实施例一示出的获取电子文件的方法的流程图，本实施例可以应用在平台服务器上，包括如下步骤：

步骤501，接收来自终端设备的用于获取电子文件的第一请求消息，第一请求消息中携带有提供电子文件的信息提供服务器对应的第一标识和电子文件对应的第二标识。

步骤502，通过终端设备的用户在平台服务器的登录信息和第一标识确定用户在信息提供服务器的用户注册名。

步骤503，将第一标识、第二标识和用户注册名进行数字签名后发送至信息提供服务器。

步骤504，接收信息提供服务器通过第二加密密钥加密后的电子文件，第二加密密钥由第一加密密钥和第一标识生成，第一加密密钥根据终端设备的用户登录平台服务器的登录信息和第一标识生成。

步骤505，将经过第二加密密钥加密的电子文件发送至终端设备。

在上述步骤501中，关于电子文件的相关描述请参考上述图1所示实施例，本实施例不再详述。本实施例以电子文件具体为电子处方为例进行示例性说明，在一实施例中，第一请求消息中可以携带有第一标识，此时第一标识为终端设备的用户在HIS对应的医院代码HIS_ID，第二标识为电子处方的处方号P_ID。

在上述步骤502中，在一实施例中，平台服务器可以建立用户登录名与第一标识之间的绑定关系，并保存该绑定关系；在另一实施例中，平台服务器还可以进一步建立登录信息中的用户登录名与该用户登录名对应的用户在信息提供服务器上的用户注册名之间的绑定关系，在用户通过用户登录名登录到平台服务器后，能够确定该用户登录名在第一标识的信息提供服务器对应的用户注册名。

在上述步骤504和步骤505中，信息提供服务器可以对数字签名的合法性进行验证，在验证通过后，根据第二标识查找到电子文件，确定电子文件中需要加密的内容，例如，电子文件为电子处方时，可以去电子处方中涉及到患者的相关隐私信息通过第二加密密钥加密。在一实施例中，信息提供服务器对电子文件进行加密时所采用的第二加密密钥，可以根据信息提供服务器与不同的用户注册名之间约定的第一加密密钥和第一标识通过哈希运算后生成。

本实施例中，通过第二加密密钥对电子文件加密后，平台服务器并不能获取到电子文件的真实内容，由此任何一份电子文件由信息提供服务器发送至平台服务器时，由于电子文件以及相关标识均已通过第二加密密钥进行加密，由于平台服务器没有第二加密密钥，因此平台服务器不能泄露电子文件的相关隐私，而且第二加密密钥由用户在平台服务器的登录信息和第一标识生成，因此用户不需要与信息提供服务器进行第二加密密钥的交换即可以获得第二加密密钥，方便用户使用。

请参见图5B，为根据又一示例性实施例一示出的获取电子文件的方法所适用的系统结构图，如图5B所示，作为一个示例性场景，用户在平台服务器51上的用户登录名为手机号“138”，信息提供服务器52的第一标识为“309医院”，在信息提供服务器53的用户注册名为张三，通过平台服务器51将138与309医院对应的用户注册名“张三”进行绑定；当张三需要查找其在309医院的第二标识为“123”的电子处方时，通过终端设备53采用“138”的用户登录名和相应的登录密码登录到平台服务器51，向平台服务器51发 送第一请求消息，平台服务器51在接收到第一请求消息时，通过138确定对应的医院为309，进而将309、123、张三进行数字签名后发送至309医院对应的信息提供服务器52，信息提供服务器52通过上述信息确定第二标识为123的电子处方。平台服务器51接收信息提供服务器52通过第二加密密钥加密后的电子文件，将经过第二加密密钥加密的电子文件发送至终端设备53。

请参见图5C，是根据又一示例性实施例一示出的平台服务器如何存储用户的登录信息的系流程示意图图，当终端设备的用户需要在平台服务器注册时，平台服务器是如何存储用户的登录信息的，如图5C所示，包括如下步骤：

步骤511，对登录信息中的用户登录名进行第一次哈希运算，得到第一次哈希运算后的登录信息。

步骤512，将第一次哈希运算后的登录信息通过固定密钥进行第二次哈希运算。

步骤513，存储经过第二次哈希运算后的登录信息。

上述步骤511-步骤513中，在一实施例中，可以采用手机号作为用户注册名，用户在平台服务器中的用户登录名以能够标识用户身份为原则，因此平台服务器仅需要保存用户的手机号以及登录口令。根据HIPAA要求，手机号属于个人的标识信息，因此本实施例需要采取数据脱敏处理后进行保存。

在一实施例中，可以对用户登录名进行哈希运算，然后与一个平台服务器保存的固定密钥再进行一次哈希运算，即Hash(Hash(User_Phone)，Seed_EPP)，对于用户的登录密码，可以采用“登录密码+固定密钥+Salt”再进行哈希的方式进行保存，即Hash(User_Passwd，Seed_EPP，Salt)，其中，Salt为一个随机数。

由此，平台服务器所存储的用户信息与用户登录名相关的信息可以表示为表1。

表1

通过对用户的登录信息进行上述处理后，可以确保攻击者无法对用户的登录信息进行推测，由于在进行哈希运算时加入了随机变量Salt，即使攻击者获取了平台服务器存储的用户的登录信息，由于攻击者无法获得固定密钥Seed_EPP，因此攻击者并不能通过哈希运算反推登录信息中的用户登录名，而由于固定密钥为通过平台服务器侧随机产生的一个随机变量，并且数据长度较小，因此本实施例通过引入固定密钥Seed_EPP可以为用户在平台服务器上存储的登录信息增加了一层保护。

请参考图6，为根据又一示例性实施例二示出的获取电子文件的方法的流程图；

步骤601，接收来自终端设备经过哈希运算后的登录信息。

步骤602，对登录信息进行合法性验证后，向终端设备发送第一确认消息。

步骤603，接收来自终端设备的用于获取电子文件的第一请求消息，第一请求消息中携带有提供电子文件的信息提供服务器对应的第一标识和电子文件对应的第二标识、哈希值，该哈希值由第一加密密钥、第一标识、电子文件对应的第二标识进行哈希运算得到。

步骤604，通过终端设备的用户在平台服务器的登录信息和第一标识确定用户在信息提供服务器的用户注册名。

步骤605，将第一标识、第二标识、用户注册名、哈希值进行数字签名后发送至信息提供服务器。

步骤606，接收信息提供服务器通过第二加密密钥加密后的电子文件，第二加密密钥由第一加密密钥和第一标识生成，第一加密密钥根据终端设备的用户登录平台服务器的登录信息和第一标识生成。

步骤607，将通过第二加密密钥加密的电子文件发送至终端设备。

在步骤601-步骤602中，在一实施例中，登录信息所包括的用户登录名(也可称为用户标识)可以为用户的手机号，终端设备可以对手机号进行哈希运算，从而在用户通过哈希运算后的用户登录名登录平台服务器时，平台服务器并不能获取到真实终端设备的用户的真实的登录信息，从而防止窃听者窃取终端设备的用户的登录信息以及平台服务器泄露终端设备的用户的登录信息。

步骤603-步骤607的描述请参考上述图5A所示实施例，在此不再详述。

本实施例在具有上述实施例的有益技术效果的基础上，由于登录信息进是终端设备已经进行了哈希运算，因此平台服务器不能获取到终端设备的用户的真实的登录信息，从而防止窃听者窃取终端设备的用户的登录信息以及平台服务器泄露终端设备的用户的登录信息；通过哈希值，从而可以使信息提供服务器验证此次第一请求消息的合法性。

请参考图7，为根据又一示例性实施例三示出的获取电子文件的方法的流程图；在上述图5A或图6所示实施例的基础上，本实施例以用户登录名需要绑定信息提供服务器以及在获取电子处方的过程中的授权与认证为例进行示例性说明，在终端设备的用户已经在平台服务器注册，并有其相应的用户登录名以及，终端设备的用户也已经在TTP平台注册，并且，终端设备的用户已经在平台服务器登录，如图7所示，包括如下步骤：

步骤701，根据第一请求消息验证第一标识与登录信息中所包括的用户登录名之间的绑定关系。

步骤702，向终端设备返回第二确认消息，如果第二确认消息表示第一标识和用户登录名具有绑定关系，可以通过上述实施例执行获取电子文件的步骤，本实施例在此不再详述，如果第二确认消息表示第一标识和用户登录名不存在绑定关系，执行步骤703。

步骤703，如果第二确认消息表示第一标识和用户登录名不存在绑定关系，接收来自终端设备的数字信封，数字信封中包含有第一加密密钥和用户 登录名在信息提供服务器对应的卡标识，数字信封为终端设备根据信息提供服务器的数字证书生成的。

步骤704，对数字信封进行验证后，向终端设备返回第三方认证通知。

步骤705，接收终端设备根据第三方认证通知在可信第三方平台得到的数字签名，可信第三方平台的数字签名由可信第三方平台通过可信第三方平台的私钥对时间戳、用户信息的哈希值进行签名得到。

步骤706，对可信第三方平台的数字签名进行合法性验证。

步骤707，在可信第三方平台的数字签名的验证通过后，将通过数字信封加密的第一加密密钥和卡标识发送至信息提供服务器。

步骤708，接收信息提供服务器返回的用户登录名在信息提供服务区注册的用户注册名和第一加密密钥的哈希值以及第一标识。

步骤709，建立用户注册名与用户登录名之间的绑定关系。

步骤710，将用户登录名和第一加密密钥的哈希值、第一标识和绑定成功的确认消息发送至终端设备，终端设备用于根据第一加密密钥、用户登录名验证哈希值的真实性。

本实施例中，通过TTP平台二次认证了用户的真实性，进而由信息提供服务器对用户登录名对应的真实用户和已经注册在信息提供服务器中的用户注册名进行对比，避免了恶意用户盗用合法用户的信息与信息提供服务器进行绑定；由于在整个绑定过程中平台服务器并未读取到任何关于用户的真实信息，因此平台服务器仅作为一个代理通道协助终端设备的用户与信息提供服务器之间进行绑定，从而有效地实现了用户的隐私保护；此外，由于信息提供服务器与终端设备用户共享的第一加密密钥，因此可以为之后进行获取电子文件的二次认证提供帮助，减少后续操作的复杂性。此外，在TTP进行认证时，由于TTP加入了时间戳，因此可以避免恶意用户监听到该认证信息后，在其他需要二次认证的场景下(例如，终端设备的用户需要重置其在平台服务器的登录密码)对合法用户进行攻击。

请参考图8，为根据又一示例性实施例四示出的获取电子文件的方法的 流程图；在上述图5A、图6或图7所示实施例的基础上，本实施例以非用户登录名从平台服务器获取电子文件时，通过用户登录名的授权下其他参与者查看电子文件(例如，在电子文件为电子处方时，其他参与者例如为药店、其他医生等)，由于其他参与者需要为平台服务器注册的并能够认可的可信第三方，因此其他参与者需要具有数字证书，例如，药房需要从EPP获取电子处方时，由此，本实施例以第三方用户(例如，药房)获取电子文件为例进行示例性说明，如图8所示，包括如下步骤：

步骤801，接收来自终端设备的用于获取电子文件的第二请求消息，第二请求消息中携带有第一标识、第二标识以及第三方用户的第三标识。

步骤802，确认第三标识是否具有查阅电子文件的权限并且第一标识与用户登录名是否具有绑定关系，在确认第三标识具有查阅电子文件的权限并且第一标识与用户登录名具有绑定关系后，执行步骤803。

步骤803，向终端设备返回第三方用户的数字证书。

步骤804，接收来自终端设备的第一标识、用户登录名以及加密后的第二加密密钥，第二加密密钥根据第一加密密钥、第一标识和用户登录名通过哈希运算生成并通过第三方用户的数字证书中的公钥加密。

步骤805，根据第二标识确定电子文件。

步骤806，将电子文件和第三方用户的公钥加密的第二加密密钥发送给第三方用户，第三方用户的终端根据第三方用户的私钥解密经过第三方用户的公钥加密后的第二加密密钥，得到第二加密密钥，根据第二加密密钥解密电子文件中的隐私信息。

在步骤801中，终端设备的用户通过其用户登录名登录平台服务器，其登录方式可以参考上述步骤601-步骤603的描述，在此不再详述。与上述步骤601-步骤603不同的是，该第二请求消息中携带有第三方用户的第三标识，平台服务器在对第二请求消息解析后得到第三标识，平台服务器可以通过该第三标识确定该用户登录名需要授权给第三方用户获取该用户登录名对应的电子文件。

在步骤802和步骤803中，平台服务器通过确认第三方用户是否具有电子文件的查看权限，以及确定该用户登录名与信息提供服务器之间是否具有绑定关系，在确定第三方用户具有电子文件的查看权限以及用户登录名与信息提供服务器具有绑定关系后，向终端设备的用户返回第三方用户的数字证书(B_Cert)。

在步骤804中，通过第三方用户的数字证书中确定第三方用户的公钥，并根据第三方用户的公钥生成数字信封，加密处方对应的第二加密密钥KP(本领域技术人员可以理解的是，本实施例可以通过对称加密的方式实现对电子文件的加解密，因此加密密钥与解密密钥相同)，并将第一标识、第二标识，第三方用户的数字证书等一并发送给平台服务器；在一实施例中，终端设备可以通过上述步骤101的描述生成第一加密密钥，基于第一标识、第二标识、第一加密密钥生成电子文件对应的第二加密密钥。

在步骤805和步骤806中，在一实施例中，平台服务器可以将第二标识等信息发送至信息提供服务器，信息提供服务器根据第二标识查找电子文件，并将电子文件和第二加密密钥利用第三方用户的公钥进行加密后返回给平台服务器，平台服务器将加密后的电子文件和第二加密密钥发送给第三方用户对应的终端，并告向终端设备的登陆用户名发送授权已完成的通知消息，第三方用户在通过与其公钥相对应的私钥解密获得第二加密密钥KP，进而利用第二加密密钥KP解密电子文件，最终可以通过解密后的电子文件验证电子文件的合法性。

在本实施例中，通过从第二请求消息中解析出第三方用户的第三标识，从而可以使平台服务器利用第三方用户的数字信封将电子文件以及电子文件的第二加密密钥共享给第三方用户，由于不需要第三方用户重新获取密钥的流程，因此整个过程中平台服务器并没有获得任何的关于电子文件的隐私信息，而且第三方用户也仅具有第二标识的电子文件，因此第三方用户通过该电子文件并不能推断出其他用户登录名在平台服务器上的其它电子文件的密钥进而获得更多的电子文件，因此充分确保了在获取电子文件的过程中的安 全性。

请参见图9，为根据另一示例性实施例一示出的获取电子文件的方法的流程图，可应用在信息提供服务器上，包括如下步骤：

步骤901，接收来自平台服务器的用于获取电子文件的第三请求消息，第三请求消息中携带有信息提供服务器对应的第一标识、电子文件的第二标识。

步骤902，根据第二标识查找电子文件。

步骤903，根据第一标识、第二标识、第一加密密钥生成用于加密电子文件的第二加密密钥，第一加密密钥由终端设备在平台服务器的登录信息和所述第一标识生成。

步骤904，将第一标识、第二标识和经过第二加密密钥加密后的电子文件发送至平台服务器。

在上述步骤901中，关于电子文件的相关描述请参考上述图1所示实施例，本实施例不再详述。本实施例以电子文件具体为电子处方为例进行示例性说明，在一实施例中，第三请求消息中可以携带有第一标识，此时第一标识为终端设备的用户在HIS对应的医院代码HIS_ID，第二标识为电子处方的处方号P_ID。

在上述步骤903中，在一实施例中，在信息提供服务器对电子文件进行加密时，可以根据信息提供服务器与不同的用户注册名之间约定的第一加密密钥和第一标识通过哈希运算后生成第二加密密钥。

本实施例中，通过第二加密密钥对电子文件加密后，平台服务器并不能获取到电子文件的真实内容，由此任何一份电子文件由信息提供服务器发送至平台服务器时，由于电子文件以及相关标识均已通过第二加密密钥进行加密，由于平台服务器没有第二加密密钥，因此平台服务器不能泄露电子文件的相关隐私，而且第二加密密钥由用户的用户在平台服务器的登录信息和第一标识生成，因此用户不需要与信息提供服务器进行第二加密密钥的交换即可以获得第二加密密钥，因此方便用户使用。

请参见图10，为根据另一示例性实施例二示出的获取电子文件的方法的流程图，在上述图9所示实施例的基础上，以如何对第三请求消息的合法性进行验证以及如何生成第二加密密钥为例进行示例性说明，如图10所述，包括如下步骤：

步骤1001，接收平台服务器转发的来自终端设备的哈希值，哈希值由第一加密密钥、第一标识、电子文件对应的第二标识进行哈希运算得到。

步骤1002，通过哈希值对第三请求消息进行合法性验证。

步骤1003，在第三请求消息的合法性验证通过后，确定终端设备的用户在信息提供服务器上是否存储有多个电子文件，如果存储一个电子文件，执行步骤1004，如果存储两个以上的电子文件，执行步骤1005。

步骤1004，如果存储一个电子文件，根据第一加密密钥、第一标识、第二标识生成电子文件对应的第二加密密钥。

步骤1005，如果存储两个以上的电子文件，根据第一加密密钥、第一标识、第二标识以及相邻的电子文件对应的第二解密密钥顺次生成两个以上的电子文件各自对应的第二加密密钥。

在上述步骤1001和步骤1002中，通过对第三请求消息进行合法性验证，从而可以防止窃听者通过非法的第三请求消息窃取终端设备的用户的电子文件，确保电子文件的安全性。

在上述步骤1003-步骤1005中，以电子文件为电子处方为例进行示例性说明，由于电子处方需要在用户、医生、药店等多个角色之间流转，因此需要同一个用户的每一份电子处方均采用不同的密钥加密，从而避免因其中一个角色获取用户的一份电子处方的加密密钥之后还可以解密用户的其它电子处方。而且在有些场景下，用户会从平台服务器批量下载电子处方进行查阅，在此情形下，如果对每个电子处方采用同一个加密密钥都要进行解密，运算量较大，考虑到移动终端的计算能力，本实施例可以在批量进行电子处方解密时有效降低获取解密密钥的复杂度。具体方法如下：

在信息提供服务器对电子文件的数据进行加密时，针对同一个患者用户， 其第一份电子处方的第二加密密钥记为KP1，KP1由第一加密密钥Seed和第一标识HIS_ID哈希生成，即：

KP1＝Hash(HIS_ID，Seed)；

第二份电子处方的第二加密密钥记为KP2，由KP1、Seed以及HIS_ID生成，即：

KP2＝Hash(HIS_ID，KP1，Seed)；

同样也可以继续生成第三份电子处方的第二加密密钥KP3直到KPn，即：

KP3＝Hash(HIS_ID，KP2，Seed)；

……

KPn＝Hash(HIS_ID，KPn-1，Seed)。

其中，n为患者的电子处方的个数。

通过上述密钥生成方法，在用户批量解密电子处方时，不需要通过平台服务器共享大量密态的处方加密密钥，由于患者用户可以通过口令生成Seed，因此通过简单的哈希运算即可以推算出一系列的加密密钥，然后进行解密，减少了解密获得密钥的开销；通过批量顺序解密处方可以核查是否存在处方丢失，即如果中间有谋一份电子处方丢失，则可以通过解密密钥与电子处方不匹配发现，提高了对电子处方的审计能力；在需要将电子处方共享给第三方用户查看时，患者用户可以在本地直接推算出电子处方的第二加密密钥然后利用第三方用户的公钥加密后即可实现患者用户与第三方用户的共享，避免与信息提供服务器进行交互，而且终端设备也不需要保存第二加密密钥，简化了密钥共享的流程。

请参见图11，为根据另一示例性实施例三示出的获取电子文件的方法的流程图，包括如下步骤：

步骤1101，在平台服务对可信第三方平台的数字签名进行合法性验证后，接收平台服务器通过数字信封加密后的用户登录名，其中，数字信封为终端设备将用户在信息提供服务器的卡标识通过信息提供服务器对应的数字证书生成的。

步骤1102，在验证终端设备用户的用户信息的合法性以及与卡标识的关联合法性后，保存第一加密密钥，并提取用户登录名在信息提供服务器注册的用户注册名。

步骤1103，将用户注册名、第一加密密钥的哈希值和第二标识发送至平台服务器。

本实施例中，信息提供服务器通过对真实用户和已经注册在信息提供服务器的用户注册名进行对比，避免了恶意用户盗用合法用户的信息与信息提供服务器进行绑定；而且在整个绑定过程中平台服务器并没有读取到任何关于用户的真实信息，平台服务仅作为一个代理通道协助用户通过终端设备与信息提供服务器之间进行绑定，从而可以有效地实现用户的隐私保护；最后，通过信息提供服务器与用户共享的第一加密密钥，可以为之后进行获取电子文件的二次认证提供帮助，减少后续操作的复杂性。

请参见图12，为根据一示例性实施例示出的获取电子文件的方法的场景图之一，本实施例以电子文件为电子处方、平台服务器为EPP以及信息提供服务器为HIS为例并且终端设备的用户已经成为EPP的注册用户(对应用户登录名)以及HIS的注册用户(对应用户注册名)，描述如何对用户在EPP的用户登录名与在HIS的用户注册名进行绑定的。

如图12所示，包括如下步骤：

步骤1201，终端设备基于第一标识(HIS_ID)、用户登录名(Username)、登录密码生成第一加密密钥Seed。本实施例中，可以在用户与HIS之间共享Seed，使HIS在之后的多个加密保护流程中使用Seed，在一实施例中，Seed可以基于用户在EPP平台的用户登录名、登录密码以及第一标识HIS_ID生成，在一实施例中，生成Seed的方法可以为：

Seed＝Hash(HIS_ID，Username，Password)。

本实施例中，由于Seed的生成是由用户知晓的用户登录名、登录密码以及EPP侧知晓的第一标识HIS_ID共同计算得出，因此客户端不需要保存该Seed，避免了在攻击的攻击下或者因客户端丢失而造成的信息泄密；而且EPP 平台中保存的是经过哈希猿猴的登录密码Password，因此EPP不能推算出Seed，从而确保Seed只在用户与HIS之间共享，同理，HIS也无法从Seed中推测出用户在EPP的登录密码以及登录密码的哈希值，因此不会影响用户登录密码的安全性；由于用户不需要记忆更多的相关密码信息，终端设备也无需存储Seed，因此在用户更换终端设备时，不需要将Seed从终端设备中导出或者销毁等操作，因此提高了用户体验。

步骤1202，终端设备基于HIS_ID向EPP请求绑定对应的HIS，将生成的Seed以及卡标识(Card_ID)等HIS需要的信息利用HIS提供的数字证书生成的数字信封加密后发送给EPP；在一实施例中，数字信封是利用数字证书产生的，数字信封的公式可以表示为{Msg}K{K}P，其中，P是HIS的公钥(也可称为数字证书)，K为一个随机密钥，由P和K联合形成一个保护方法，来保护Msg，本实施例中，Msg为Seed和卡标识。

步骤1203，EPP审核HIS_ID、Seed以及卡标识(Card_ID)等信息后要求用户向TTP平台进行二次认证。

步骤1204，终端设备基于可信第三方HTTPS连接，向TTP平台提供用户登录名、登录密码，以及期望验证的电子处方中的个人信息(Patient_Info)，个人信息例如为：用户的身份证号码、手机号、社保卡号。

步骤1205，TTP平台验证用户登录名、登录密码以及电子处方中的个人信息后，将时间戳、用户实名信息的哈希值以及用户实名信息的数字签名发送给用户。

步骤1206，终端设备将验证结果发送给EPP。

步骤1207，EPP验证TTP平台验证结果的合法性。

步骤1208，EPP将步骤1202的加密后的用户信息发送给HIS。在本实施例中，步骤1202的加密后的信息为Seed以及卡标识(Card_ID)等HIS需要的信息。

步骤1209，HIS验证用户信息的合法性以及与卡标识的关联合法性后，保存Seed，并提取用户在HIS注册的用户注册名Patient_ID。

步骤1210，HIS将用户注册名与Seed的哈希值，用户注册名一并发送给EPP。

步骤1211，EPP根据HIS返回的信息建立EPP的用户登录名与用户注册名Patient_ID之间的绑定关系，并保存。

步骤1212，EPP将Patient_Info与Seed的哈希值，Patient_ID以及绑定成功信息转发至终端设备。

步骤1213，终端设备利用Seed、Patient_Info计算哈希值的真实性，确认绑定成功。

本实施例的上述绑定过程，通过第三方认证平台二次认证了用户的真实性，进而由医院对真实用户和已经注册在HIS中的个人信息进行对比，避免了恶意用户盗用他人信息进行医院绑定；由于在整个绑定过程中EPP仅作为一个代理通道协助用户与HIS之间进行绑定，因此EPP平台没有读取到任何关于用户的真实信息，从而可以有效实现用户的隐私保护；最后，通过HIS与用户共享的Seed，可以为之后进行获取处方的二次认证提供帮助，减少后续操作的复杂性。需要注意的是，在可信第三方进行认证时，通过加入时间戳，可以防止恶意用户监听到本次认证信息，从而避免在其他需要二次认证的场景下(例如，用户修改登录密码等)恶意用户进行重放攻击。

请参见图13，为根据一示例性实施例示出的获取电子文件的方法的场景图之二，本实施例以电子文件为电子处方、平台服务器为EPP以及信息提供服务器为HIS为例进行示例性说明，在用户登录名已经与用户在HIS的用户注册名绑定的情况下，用户可以通过终端设备向EPP申请个人在相关HIS的电子处方，如图13所示，包括如下步骤：

步骤1301，用户通过终端设备利用手机号的哈希值，登录密码登录EPP。

步骤1302，EPP验证后返回确认信息，登录成功。

步骤1303，终端设备向EPP发送第一请求消息，以请求获取电子处方，第一请求消息中携带有第一标识HIS_ID、处方号P_ID。

步骤1304，EPP验证用户登录名与用户在HIS的用户注册名的绑定关系， 并验证该电子处方是否存在，如果存在则执行步骤1311，如果不存在，执行步骤1305。

步骤1305，EPP反馈要求输入用户授权信息。

步骤1306，终端设备利用登录信息及第一标识生成Seed。

步骤1307，终端设备将HIS对应的第一标识HIS_ID、电子处方的第二标识P_ID等一并发送给EPP，整个消息利用HIS与用户共享的Seed做哈希运算消息认证码(Hash-based Message Authentication Code，简称为HMAC)。

步骤1308，EPP将步骤1307的数据以及用户注册名Patient_ID进行签名后转发至HIS。

步骤1309，HIS利用HMAC、EPP的签名验证用户此次请求的合法性,基于Patient_ID查找处方，并生成第二加密密钥KP加密电子处方中的个人信息。

步骤1310，HIS将第二号P_ID、用户注册名Patient_ID、加密处理后的处方以及相应的HIS签名发送给EPP。

步骤1311，EPP获取授权后，将电子处方等信息签名后发送给终端设备。

步骤1312，终端设备利用Seed生成解密密钥，解密电子处方中的个人信息，然后通过个人信息验证电子处方的合法性。

在上述过程中，HIS利用与用户之间预先共享的Seed实现了对用户的认证，并且HIS利用HMAC方式实现了对授权信息的完整性验证，从而获得了合法用户获取处方的真实授权，EPP在过程中并没有获得任何个人隐私信息；而且每一份处方采用的密钥均不同，可以限制处方在第三方药店共享时泄露更多信息。

请参见图14，为根据一示例性实施例示出的获取电子文件的方法的场景图之三，在一些情况下，除患者本人，还需要授权其他参与者查看处方，如药店、其他医生等，这些实体应当是EPP平台注册的能够认可的可信第三方，应当具有数字证书。在第三方用户需要获取患者用户的电子处方时，如图6所示，包括如下步骤：

步骤1401，用户通过终端设备利用手机号的哈希值、登录密码登录EPP。

步骤1402，EPP验证后返回确认信息，登录成功。

步骤1403，用户通过终端设备向EPP发送第一请求消息，该第一请求消息中携带有医院代码HIS_ID、处方号P_ID，以及第三方用户的第三标识B_ID。

步骤1404，EPP确认第三方用户是否具有处方查看权限，以及用户登录名与HIS的用户注册名之间是否具有绑定关系。

步骤1405，EPP向终端设备返回第三方用户的数字证书B_Cert。

步骤1406，用户通过终端设备将登录信息和第一标识生成Seed，基于处方编号、Seed、HIS_ID生成电子处方对应的第二加密密钥KP。

步骤1407，终端设备利用第三方用户的公钥生成数字信封，加密电子处方对应的第二加密密钥KP，并将医院编号HIS_ID、处方号P_ID一并发送给EPP。

步骤1408，EPP根据处方号P_ID等信息查找电子处方，将电子处方以及利用第三方用户的公钥P加密的电子处方加密第二加密密钥KP发送给第三方用户，并告知终端设备授权已完成。

步骤1409，第三方用户利用第三方用户的私钥对加密后的第二加密密钥解密获得第二加密密钥KP，利用第二加密密钥KP解密电子处方中的隐私信息，然后通过隐私信息验证电子处方的合法性。

在该过程中，通过第三方用户的数字信封将第二加密密钥共享给第三方用户，避免了第三方用户重新获取第二加密密钥的流程，由于整个流程中EPP并没有获得任何患者用户的个人隐私信息，而且第三方用户也仅获得了一份电子处方的隐私信息，并不能由此推断出患者用户的其他加密密钥进而获得更多患者用户的个人隐私。本领域技术人员可以理解的是，本实施例同样可以适用于将电子处方分发给其他第三方，例如，医生、保险公司等。

在上述图12-图14所示实施例中，由于电子处方内的相关用户的个人信息在必要时是需要发布的第三方，因此个人信息等数据需要采用加密的方式 进行脱敏，任何一份电子处方由HIS转入EPP时，个人信息都应由HIS产生的第二加密密钥进行加密后转给EPP平台。EPP平台保存的脱敏后的电子处方所包含的信息可以如下表示：

HIS_ID：HIS的身份标识(明文)

Patient_ID：用户注册名(也可称为患者标识)(明文)

Pr_ID：电子处方的身份标识(明文)

Patient_Info：电子处方中的个人信息(加密存储)

Prescription_Info：电子处方的内容(明文存储)

……

通过上述加密存储，可以保证电子处方中涉及的个人信息在EPP平台是加密保存的，而且第二加密密钥保存在HIS中，因此仅从EPP平台盗取电子处方是无法获取到用户的个人信息的。

对应于上述的图1-图4所示的获取电子文件的方法，本申请还提出了图15所示的根据本申请的一示例性实施例的终端设备的示意结构图。请参考图15，在硬件层面，该终端设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成获取电子文件的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

对应于上述的图5A-图8所示的获取电子文件的方法，本申请还提出了图16所示的根据本申请的一示例性实施例的平台服务器的示意结构图。请参考图16，在硬件层面，该平台服务器包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成获取电子文件的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处 理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

对应于上述的图9-图11所示的获取电子文件的方法，本申请还提出了图17所示的根据本申请的一示例性实施例的信息提供服务器的示意结构图。请参考图17，在硬件层面，该信息提供服务器包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成获取电子文件的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图18，为根据一示例性实施例一示出的获取电子文件的装置的结构示意图，可应用在终端设备上，在软件实施方式中，该获取电子文件的装置可以包括：第一生成模块1801、第一发送模块1802、第一接收模块1803、第一解密模块1803。其中：

第一生成模块1801，用于根据终端设备的用户在登录平台服务器时的登录信息和提供电子文件的信息提供服务器对应的第一标识生成第一加密密钥，信息提供服务器用于为终端设备提供电子文件；

第一发送模块1802，用于向平台服务器发送用于获取电子文件的第一请求消息，第一请求消息中携带有第一标识和电子文件的第二标识；

第一接收模块1803，用于接收平台服务器根据第一生成模块1801所使用的登录信息和第一发送模块1802发送的第一请求消息返回的通过第二加密密钥加密的电子文件，第二加密密钥由第一加密密钥、第一标识和第二标识生成；

第一解密模块1804，用于根据第一生成模块1801生成的第一加密密钥生成第一解密密钥，通过第一解密密钥对第一接收模块1803接收到的经过第二加密密钥加密后的电子文件进行解密，得到解密后的电子文件。

请参考图19，为根据一示例性实施例二示出的获取电子文件的装置的结 构示意图，在上述图18所示实施例的基础上，第一生成模块1801可包括：

第一生成单元18011，用于对登录信息所包括的用户登录名、登录密码和提供电子文件的信息提供服务器对应的第一标识进行哈希运算，生成第一加密密钥。

在一实施例中，装置还可包括：

第一哈希模块1805，用于将第一生成模块1801生成的第一加密密钥、第一标识、第二标识进行哈希运算，得到哈希值；

第二发送模块1806，用于将第一哈希模块1805得到的哈希值发送至平台服务器，以供平台服务器将哈希值转发给信息提供服务器后根据哈希值验证第一请求消息的合法性。

在一实施例中，装置还可包括：

第一验证模块1807，用于在第一解密模块1804解密得到解密后的电子文件之后，对电子文件中的用户信息进行合法性验证。

在一实施例中，装置还可包括：

第二哈希模块1808，用于对第一生成模块1801所使用的登录信息进行哈希运算，得到哈希运算后的用户登录名；

登录模块1809，用于通过第二哈希模块1808哈希运算后的登录信息登录平台服务器；

第二接收模块1810，用于接收平台服务器根据登录模块1809通过哈希运算后的登录信息返回的第一确认消息。

在一实施例中，装置还包括：

第二接收模块1811，用于在第一发送模块1802向平台服务器发送获取电子文件的第一请求消息之后，接收平台服务器验证第一标识与登录信息中的用户登录名之间的绑定关系后返回的第二确认消息，如果第二确认消息表示第一标识和用户登录名具有绑定关系，第一接收模块1803执行接收平台服务器根据第一请求消息返回的通过第二加密密钥加密的电子文件的步骤。

在一实施例中，装置还可包括：

第一确定模块1812，用于如果第二接收模块1811接收到的第二确认消息表示第一标识和用户登录名不存在绑定关系，根据第一标识确定信息提供服务器的数字证书对应的数字信封；

第三发送模块1813，用于通过第一确定模块1812确定的数字信封将第一加密密钥和用户登录名加密后发送至平台服务器。

在一实施例中，装置还可包括：

第四发送模块1814，用于在平台服务器根据第三发送模块1813发送的加密后的第一加密密钥和用户登录名向终端设备返回第三方认证通知时，向可信第三方平台发送登录信息所包括的用户登录名对应的用户信息；

第三接收模块1815，用于在可信第三方平台对第四发送模块1814发送的用户信息进行验证后，接收来自可信第三方平台的数字签名，数字签名由可信第三方平台通过可信第三方平台的私钥对时间戳、用户信息的哈希值进行签名得到；

第五发送模块1816，用于将第三接收模块1815接收到的可信第三方平台的数字签名的认证结果发送平台服务器。

在一实施例中，装置还可包括：

第四接收模块1817，用于在平台服务器验证第五发送模块1816发送的认证结果的合法性后，接收平台服务器根据认证结果返回的用户信息和第一加密密钥的哈希值、第一标识和用户登录名绑定成功的通知消息；

第二确定模块1818，用于根据第四发送模块1817发送的用户信息和第一生成模块1801生成的第一加密密钥确定用户信息和第一加密密钥的哈希值的真实性，以确认第一标识和登录信息所包括的用户登录名绑定成功。

在一实施例中，装置还可包括：

第六发送模块1819，用于向平台服务器发送获取电子文件的第二请求消息，第二请求消息中携带有第一标识、第二标识以及第三方用户的第三标识；

第五接收模块1820，用于在平台服务器确认第六发送模块1819发送的第三标识具有查阅电子文件的权限并且第一标识与登录信息中所包括的用户 登录名具有绑定关系后，接收平台服务器返回的第三方用户的数字证书；

第一获取模块1821，用于从第五接收模块1820接收到的数字证书中获取第三方用户的公钥；

第三哈希模块1822，用于根据第一生成模块1801生成的第一加密密钥、第一标识和第二标识通过哈希运算生成第二加密密钥；

第一加密模块1823，用于通过第一获取模块1821获取到的第三方用户的公钥对第三哈希模块1822生成的第二加密密钥进行加密，将第一标识、第二标识以及加密后的第二加密密钥发送至平台服务器。

在一实施例中，装置还可包括：

第六接收模块1824，用于在平台服务器根据第二标识查找到电子文件后，接收平台服务器返回的确认第三方授权完成的通知消息。

请参考图20，为根据又一示例性实施例一示出的获取电子文件的装置的结构示意图，可应用在平台服务器上，在软件实施方式中，该获取电子文件的装置可以包括：第七接收模块2001、第三确定模块2002、第七发送模块2003、第八接收模块2004、第八发送模块2005。其中：

第七接收模块2001，用于接收来自终端设备的用于获取电子文件的第一请求消息，第一请求消息中携带有提供电子文件的信息提供服务器对应的第一标识和电子文件对应的第二标识；

第三确定模块2002，用于通过终端设备的用户在平台服务器的登录信息和第七接收模块2001接收到的所述第一请求消息中携带的第一标识确定用户在信息提供服务器的用户注册名；

第七发送模块2003，用于将第七接收模块2001接收到的第一请求消息中携带的第一标识和第二标识、第三确定模块2002确定的用户注册名进行数字签名后发送至信息提供服务器；

第八接收模块2004，用于接收信息提供服务器通过第二加密密钥加密后的电子文件，第二加密密钥由第一加密密钥和第七接收模块2001接收到的第一请求消息中携带的第一标识生成，第一加密密钥根据终端设备的用户登录 平台服务器的登录信息和第一标识生成；

第八发送模块2005，用于将第八接收模块2004接收到的通过第二加密密钥加密的电子文件发送至终端设备。

请参考图21，为根据又一示例性实施例二示出的获取电子文件的装置的结构示意图，在上述图20所示实施例的基础上，装置还可包括：

第九接收模块2006，用于接收来自终端设备的哈希值，哈希值由第一加密密钥、第一标识、电子文件对应的第二标识进行哈希运算得到；

第九发送模块2007，用于对第九接收模块2006接收到的哈希值进行签名后发送至信息提供服务器，以供信息提供服务器根据哈希值验证第七接收模块2001接收到的第一请求消息的合法性。

在一实施例中，装置还可包括：

第十接收模块2008，用于接收来自终端设备经过哈希运算后的登录信息；

第十发送模块2009，用于对第十接收模块2008接收到的登录信息进行合法性验证后，向终端设备发送第一确认消息。

在一实施例中，装置还可包括：

第一验证模块2010，用于在第七发送模块2003对第一加密密钥、第一标识、第二标识进行数字签名后发送至信息提供系统信息提供服务器之前，根据第一请求消息验证第一标识与登录信息中所包括的用户登录名之间的绑定关系；

第十一发送模块2011，用于向终端设备返回第二确认消息，如果第二确认消息表示第一标识和用户登录名具有绑定关系，第七发送模块2003执行对第一加密密钥、第一标识、第二标识进行数字签名后发送至信息提供系统信息提供服务器的步骤。

在一实施例中，装置还可包括：

第十一接收模块2012，用于如果第十一发送模块2011发送的第二确认消息表示第一标识和用户登录名不存在绑定关系，接收来自终端设备的数字 信封，数字信封中包含有第一加密密钥和用户登录名在信息提供服务器对应的卡标识，数字信封为终端设备根据信息提供服务器的数字证书生成的；

第十二发送模块2013，用于对第十一接收模块2012接收到的数字信封进行验证后，向终端设备返回第三方认证通知；

第十二接收模块2014，用于接收终端设备根据第十二发送模块2013向终端设备返回的第三方认证通知在可信第三方平台得到的数字签名，可信第三方平台的数字签名由可信第三方平台通过可信第三方平台的私钥对时间戳、用户信息的哈希值进行签名得到。

在一实施例中，装置还可包括：

第二验证模块2015，用于对第十二接收模块2014接收到的可信第三方平台的数字签名进行合法性验证；

第十三发送模块2016，用于在第二验证模块2015验对可信第三方平台的数字签名的验证通过后，将通过数字信封加密的第一加密密钥和卡标识发送至信息提供服务器。

在一实施例中，装置还可包括：

第十三接收模块2017，用于接收信息提供服务器返回的用户登录名在信息提供服务区注册的用户注册名和第一加密密钥的哈希值以及第一标识；

绑定模块2018，用于建立第十三接收模块2017接收到的用户注册名与用户登录名之间的绑定关系；

第十四发送模块2019，用于将用户登录名和第一加密密钥的哈希值、第一标识和绑定模块2018将绑定关系绑定成功的确认消息发送至终端设备，终端设备用于根据第一加密密钥、用户登录名验证哈希值的真实性。

在一实施例中，装置还可包括：

第十四接收模块2020，用于接收来自终端设备的用于获取电子文件的第二请求消息，第二请求消息中携带有第一标识、第二标识以及第三方用户的第三标识；

第四确定模块2021，用于确认第十四接收模块2020接收到的第三标识 是否具有查阅电子文件的权限并且第一标识与用户登录名是否具有绑定关系；

第十五发送模块2022，用于在第四确定模块2021确认第三标识具有查阅电子文件的权限并且第一标识与用户登录名具有绑定关系后，向终端设备返回第三方用户的数字证书；

第十五接收模块2023，用于接收来自终端设备的第一标识、用户登录名以及加密后的第二加密密钥，第二加密密钥根据第一加密密钥、第一标识和用户登录名通过哈希运算生成，并通过第十五发送模块2022接收到的第三方用户的数字证书中的公钥加密。

在一实施例中，装置还可包括：

第五确定模块2024，用于根据第二标识确定电子文件；

第十六发送模块2025，用于将第五确定模块2024确定的电子文件和第三方用户的公钥加密的第二加密密钥发送给第三方用户，第三方用户的终端根据第三方用户的私钥解密经过第三方用户的公钥加密后的第二加密密钥，得到第二加密密钥，根据第二加密密钥解密电子文件中的隐私信息。

在一实施例中，装置还可包括：

第四哈希模块2026，用于对第十接收模块2008接收到的登录信息中的用户登录名进行第一次哈希运算，得到第一次哈希运算后的登录信息。

第五哈希模块2027，用于将第四哈希模块2026进行第一次哈希运算后的登录信息通过固定密钥进行第二次哈希运算；

存储模块2028，用于存储经过第五哈希模块2027进行第二次哈希运算后的登录信息。

请参考图22，为根据另一示例性实施例一示出的获取电子文件的装置的结构示意图，可应用在信息提供服务器上，在软件实施方式中，该获取电子文件的装置可以包括：第十六接收模块2201、查找模块2202、第二生成模块2203、第十七发送模块2204。其中：

第十六接收模块2201，用于接收来自平台服务器的用于获取电子文件的 第三请求消息，第三请求消息中携带有信息提供服务器对应的第一标识、电子文件的第二标识；

查找模块2202，用于根据第十六接收模块2201接收到的第二标识查找电子文件；

第二生成模块2203，用于根据第十六接收模块2201接收到的第一标识、第二标识、第一加密密钥生成用于加密电子文件的第二加密密钥，第一加密密钥由终端设备在平台服务器的登录信息和第一标识生成；

第十七发送模块2204，用于将第十六接收模块2201接收到的第三请求消息携带的第一标识和第二标识、经过第二生成模块2203生成的第二加密密钥加密后的电子文件发送至平台服务器。

请参考图23，为根据另一示例性实施例二示出的获取电子文件的装置的结构示意图，在上述图22所示实施例的基础上，装置还可包括：

第十七接收模块2205，用于接收平台服务器转发的来自终端设备的哈希值，哈希值由第一加密密钥、第一标识、电子文件对应的第二标识进行哈希运算得到；

第三验证模块2206，用于通过第十七接收模块2205接收到的哈希值对第十六接收模块2201接收到的第三请求消息进行合法性验证。

在一实施例中，第二生成模块2203可包括：

确定单元22031，用于确定终端设备的用户在信息提供服务器上是否存储有多个电子文件；

第二生成单元22032，用于如果确定单元22031确定信息提供服务器上存储一个电子文件，根据第一加密密钥、第一标识、第二标识生成电子文件对应的第二加密密钥；

第三生成单元22033，用于如果确定单元22031确定信息提供服务器上存储两个以上的电子文件，根据第一加密密钥、第一标识、第二标识以及相邻的电子文件对应的第二解密密钥顺次生成两个以上的电子文件各自对应的第二加密密钥。

在一实施例中，装置还可包括：

第十八接收模块2207，用于在平台服务对可信第三方平台的数字签名进行合法性验证后，接收平台服务器通过数字信封加密后的用户登录名，其中，数字信封为终端设备将用户在信息提供服务器的卡标识通过信息提供服务器对应的数字证书生成的；

保存模块2208，用于在验证终端设备用户的用户信息的合法性以及与卡标识的关联合法性后，保存第一加密密钥，并提取用户登录名在信息提供服务器注册的用户注册名；

第十八发送模块2209，用于将保存模块2208所保存的用户注册名、第一加密密钥的哈希值和第二标识发送至平台服务器。

由上述实施例可见，本发明实施例中终端设备基于第一标识、用户登录名以及登录密码等用户知晓的信息生成第一加密密钥，将该第一加密密钥作为种子密钥Seed，与信息提供服务器共享，并且终端设备也不需要保存该第一加密密钥，因此提高了加密的安全性和用户体验；针对电子文件中需要保护的隐私信息，信息提供服务器可以基于第一加密密钥生成第二加密密钥，并在信息提供服务器侧对电子文件中需要加密的数据进行加密，并转存至平台服务器，由此用户无需获取第二加密密钥，可以根据第一加密密钥推断出第二加密密钥，因此降低了设备之间交互的复杂性，并且平台服务器在整个电子文件的获取过程中并不能电子文件中的加密数据。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方 法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。