一种授信管理方法及装置与流程

本发明涉及信息安全技术领域，特别涉及一种授信管理方法及装置。

背景技术：

随着信息技术及互联网技术的发展，现在的智能设备越来越多的与互联网账号相关联。与同一互联网账号关联的设备之间通常需要进行信息交互和数据同步。这就需要一种可靠的机制来在设备之间建立信任关系。

现有技术中，通常在不同设备上进行同一账号的登录，登录成功后即认为该设备与该互联网账号关联，且该设备与其他关联到相同账号的设备互相信任。此方案中存在安全风险：如果账号的密码被恶意攻击者获取，那么恶意攻击者可以将其非法设备关联到此账号，从而与其他合法设备建立信任关系，危害其他合法设备中信息的安全。恶意攻击者也可以在没有获取账号密码的情况下，通过攻击互联网服务器，将其非法设备关联到任意账号下，从而危害其他合法设备中信息的安全。

技术实现要素：

有鉴于此，本发明实施例提出了一种授信管理方法和装置，通过在设备间建立信任关系来屏蔽恶意攻击者对设备安全的威胁。

为此，本发明实施例提出了一种授信管理方法，应用于服务端，所述方法包括：将包括公钥表的授信文件进行存储，所述公钥表包括n个受信任设备的设备公钥，n≥1；接收来自第一设备的加入请求包，所述加入请求包与所述授信文件相关并包括第一设备的设备公钥及第一校验码；将授信文件和所述加入请求包发送给n个受信任设备中的任意m个受信任设备进行验证，1≤m≤n，如从完成验证的受信任设备接收到包括更新后公钥表的更新后授信文件，则用更新后公钥表覆盖原公钥表，更新后公钥表包括第一设备的设备公钥。

可选地，所述授信文件与第一用户账号关联存储。

可选地，所述授信文件中还包括使用所述n个受信任设备中的任意k个受信任设备的设备私钥对公钥表进行签名处理生成的第一数字签名，1≤k≤n。

可选地，所述更新后授信文件包括使用所述m个受信任设备中任意l个受信任设备的设备私钥对所述更新后公钥表进行签名处理生成的第二数字签名，1≤l≤m。

可选地，所述授信文件中包括使用基于第一用户账号的登录信息生成的公私钥对中的私钥对公钥表进行签名处理生成的第三数字签名。

可选地，所述更新后授信文件包括使用基于第一用户账号的登录信息生成的公私钥对中的私钥对所述更新后公钥表进行签名处理生成的第四数字签名。

可选地，所述第一校验码包括通过使用所述第一设备对所述第一设备的设备公钥进行签名处理生成的第五数字签名。

可选地，所述加入请求包中包括使用基于第一用户账号的登录信息生成的公私钥对中的私钥对第一设备的设备公钥进行签名处理生成的第六数字签名。

本发明实施例还提出了一种授信管理装置，应用于服务端，包括：处理单元，其配置为将包括公钥表的授信文件进行存储，所述公钥表包括n个受信任设备的设备公钥，n≥1；通信单元，其配置为接收来自第一设备的加入请求包，将授信文件和所述加入请求包发送给n个受信任设备中的任意m个受信任设备进行验证，1≤m≤n，其中，所述加入请求包与所述授信文件相关并包括第一设备的设备公钥及第一校验码，其中，所述处理单元还配置为，如所述通信单元从完成验证的受信任设备接收到包括更新后公钥表的更新后授信文件，则所述处理单元用更新后公钥表覆盖原公钥表，其中，更新后公钥表包括第一设备的设备公钥。

本发明实施例同时提出了一种授信管理装置，应用于服务端，包括：存储器，其存储有预定的计算机可执行指令；处理器，其配置为运行所述预定的计算机可执行指令以执行上述任一实施例中的授信管理方法。

通过本发明实施例的授信管理方法和装置，能够在关联同一用户账号的设备之间建立可靠的信任关系，即使在恶意攻击者非法获取到该用户账号的登录信息的情况下，由于无法通过已建立信任关系的设备的验证，无法将其非法设备加入到该信任关系中。

附图说明

图1为本发明一个实施例的授信管理方法的示例性流程图；

图2为本发明另一个实施例的授信管理方法的示例性流程图；

图3为本发明一个实施例的授信管理装置的示例性框图。

具体实施方式

下面参照附图对本发明的各个实施例进行详细说明。

图1为本发明一个实施例的授信管理方法的示意性流程图。本发明实施例的授信管理方法应用于服务端。

如图1所示，本发明实施例的授信管理方法包括：

s11、将包括公钥表的授信文件进行存储，所述公钥表包括n个受信任设备的设备公钥，n≥1；

s12、接收来自第一设备的加入请求包，所述加入请求包与所述授信文件相关并包括第一设备的设备公钥及第一校验码；

s13、将授信文件和所述加入请求包发送给n个受信任设备中的任意m个受信任设备进行验证，1≤m≤n；

s14、确认是否从完成验证的受信任设备接收到包括更新后公钥表的更新后授信文件，如是则进行s15，否则结束处理；

s15、用更新后公钥表覆盖原公钥表，更新后公钥表包括第一设备的设备公钥。

授信文件用来记录待建立相互间信任关系的受信任设备的设备公钥，并且新加入授信文件的设备需要经过已加入授信文件的设备的验证。这里，加入同一信任关系群的受信任设备之间可以存在某种关系，或者可以不存在关系。例如，加入同一信任关系群的受信任设备之间存在关系的情况可以包括均属于同一用户、用户均属于同一家庭的成员、用户均属于同一企业的成员的情况等，相应地，服务端可以例如将同一用户的用户id、同一家庭的家庭id、同一企业的企业id或同一工作小组的小组id等与授信文件关联存储。或者服务端也可以将同一家庭或同一企业不同成员的设备要登录的同一用户账号与授信文件关联存储，第一用户账号可以是用户在服务应用或服务网站注册并使用的账号，个人用户或家庭用户可以在不同的设备上使用第一用户账号登录到服务应用或服务网站，或者第一用户账号可以是企业在企业服务器上配置的工作账号，同一公司的多个不同的用户也可以在不同的设备上使用同一个用户账号登录到企业服务器。

首先对n＝1，m＝1时的情形进行说明。

n＝1且m＝1即授信文件的公钥表中只有一个受信任设备的设备公钥。具体而言，例如，注册了第一用户账号的用户在一设备上首次登录第一用户账号时将该设备作为第一个受信任设备关联到第一用户账号，或者企业的一位工作人员需要为企业的准备成立的一个工作小组的设备建立信任关系，此时，由注册了第一用户账号的用户或该工作人员使用其所操作的设备作为第一个受信任设备创建授信文件，在授信文件中包括公钥表，该公钥表中仅包括该第一个受信任设备的设备公钥，然后该用户或该工作人员通过该第一个受信任设备将该创建的授信文件发送到服务端。服务端接收到来自该第一个受信任设备的授信文件后，将该授信文件进行存储，在存储该授信文件时可以将该第一个受信任设备所登录的第一用户账号或者该组工作人员的小组id相关联地进行存储(s11)。

之后，当用户需要在另一个设备上登录上述第一用户账号，或者另一工作人员需要加入上述工作小组，需要将该另一个设备或该另一工作人员的设备加入设备信任关系，在此也即与第一个受信任设备之间建立信任关系时，通过该另一个设备或该另一工作人员的设备向服务端发送加入请求包。这里的该另一个设备或该另一工作人员的设备即为s12中的第一设备。加入请求包中需要包括第一设备的设备公钥和第一校验码，第一校验码用于对第一设备进行验证，第一设备的设备公钥用于在对第一设备进行验证成功后加入到授信文件的公钥表中。加入请求包中还可以包括用于表示该加入请求包与授信文件相关的信息，例如第一用户账号的用户名或者上述工作小组的小组id等。此外，加入请求包中也可以不包括第一用户账号的用户名或小组id，而是可以例如在用户在第一设备上保持登录第一用户账号期间或者上述另一工作人员在以小组组员身份登录企业服务器期间向服务端发送加入请求包，由此服务端能够识别出该加入请求包与上述授信文件相关。

服务端接收到第一设备发来的加入请求包(s12)后，根据加入请求包查找到与加入请求包相关的授信文件，将授信文件和该加入请求包发送给第一个受信任设备进行验证(s13)。这里，服务端可以主动将授信文件和该加入请求包发送给第一个受信任设备，也可以基于第一个受信任设备的要求而发送授信文件和该加入请求包。由于这里描述的是n＝1时的情形，因此m也为1。

第一个受信任设备接收到授信文件和加入请求包后，对加入请求包中的第一校验码进行验证。这里的第一校验码用于验证第一设备是否为已经得到第一个受信任设备的信任的设备。例如，当第一个受信任设备和第一设备为同一位个人用户持有或者为同一家庭的不同成员持有时，第一校验码可以是由用户设定后分别输入到第一个受信任设备和第一设备中的字符串；再例如，当第一个受信任设备和第一设备为同一公司的不同员工持有时，第一校验码可以是由第一个受信任设备生成并显示给第一个受信任设备的用户，并由该用户通过电话、手机短消息、电子邮件等方式告知给第一设备的用户。第一个受信任设备可以通过将所保存的该字符串与加入请求包中的第一校验码进行对比来实现验证，如果对比一致则通过验证，第一个受信任设备将加入请求包中的第一设备的设备公钥添加到服务端发来的授信文件的公钥表中形成更新后授信文件，并将更新后授信文件发送给服务端；如果对比不一致，则验证不通过，告知服务端验证结果。

服务端在从第一个受信任设备接收到更新后授信文件的情况下(s14)，用更新后授信文件中的公钥表覆盖当前存储的原来的公钥表，或者直接用更新后授信文件覆盖当前存储的原来的授信文件，如此完成将第一设备加入到已有的受信任设备的信任关系中的处理过程。

当通过上述方式将更多设备的设备公钥加入授信文件的公钥表中，列在授信文件的公钥表中的公钥对应的设备之间建立起可靠的信任关系。

下面对n大于1的情形进行说明。

n大于1即授信文件的公钥表中有多个受信任设备的设备公钥。下面以n＝5的情形进行举例说明，即服务端存储的当前授信文件已经更新为使得其公钥表中包括了5个受信任设备的设备公钥。

当在这5个受信任设备之外又有一个设备需要加入由授信文件表征的设备间信任关系时，该设备向服务端发送加入请求包。这里该发送加入请求包的设备也对应于s12中的第一设备，但为了描述方便起见这里将该设备称为第二设备以区别于上述n＝1情形下的第一设备。第二设备向服务端发送的加入请求包中包括第二设备的设备公钥和第一校验码，该第一校验码用于对第二设备进行验证，第二设备的设备公钥用于在对第二设备进行验证成功后加入到授信文件的公钥表中。

服务端接收到第二设备发来的加入请求包(s12)后，根据加入请求包查找到与加入请求包相关的授信文件，将授信文件和该第二设备的加入请求包发送给授信文件中记载的5个(即n＝5)受信任设备中的任意m个受信任设备进行验证(s13)，也即，s13中的任意m个受信任设备可以是这5个受信任设备中的任一个、任三个、或全部的5个受信任设备，例如可以是第二个加入公钥表的受信任设备，或者第一个、第三个和四个加入公钥表的受信任设备，等等，或者发送给全部的5个受信任设备进行验证。这里，服务端可以主动将授信文件和该加入请求包发送给受信任设备，也可以基于受信任设备的要求而发送授信文件和该加入请求包。

上述m个受信任设备接收到授信文件和加入请求包后，对加入请求包中的第一校验码进行验证。这里的第一校验码用于验证第二设备是否为已经得到公钥表中的受信任设备的信任的设备。

以m＝2为例，第一校验码例如可以是由公钥表中任意两个加入的受信任设备生成并显示给其用户，并由该用户通过电话、手机短消息、电子邮件等方式告知给第二设备的用户，则该任意两个受信任设备可以通过将所保存的该字符串与加入请求包中的第一校验码进行对比来实现验证。第一校验码例如也可以是通过用已经加入授信文件公钥表的受信任设备的设备私钥对诸如上述字符串、基于约定算法和参数分别生成的字符串、或其他约定数据进行加密或签名处理生成的校验数据，例如通过用第二受信任设备的设备私钥对基于约定算法和参数生成的字符串进行加密或签名生成第一校验码，上述任意两个受信任设备可以基于通过同一约定算法和参数生成的字符串对第一校验码进行校验。如果第一校验码通过验证，则由上述任意两个受信任设备将加入请求包中的第二设备的设备公钥添加到服务端发来的授信文件的公钥表中形成更新后授信文件，并将更新后授信文件发送给服务端；如果对比不一致，则验证不通过，告知服务端验证结果。

服务端在从完成验证的受信任设备接收到包括更新后公钥表的更新后授信文件的情况下(s14)，用更新后授信文件中的公钥表覆盖当前存储的原来的公钥表，或者直接用更新后授信文件覆盖当前存储的原来的授信文件，如此完成将第二设备加入到已有的受信任设备的信任关系中的处理过程。

通过本发明实施例，仅通过成功登录第一用户账号并无法自动成为受信任设备，而是通过创建和更新授信文件来建立设备之间的可靠信任关系，如此，即使在恶意攻击者非法获取了第一用户账号的登录信息或者攻破了服务器获得授信文件的情况下，由于该恶意攻击者无法从受信任设备或其用户获得第一校验码，因而无法借由向服务端发送加入请求包的方式通过受信任设备的验证，无法将其非法设备的设备公钥合法地加入到授信文件的公钥表中，从而无法伪装成合法设备加入到与第一用户账号关联的受信任设备间的信任关系中并从合法设备获取数据，进而确保了合法的受信任设备中数据的安全。

在本发明一些实施例中，授信文件中还可以包括使用n个受信任设备中的k个受信任设备的设备私钥对授信文件中的公钥表进行签名处理生成的k个第一数字签名，1≤k≤n。具体而言，当n＝1时，k＝1，可由第一个受信任设备使用自身的设备私钥对公钥表进行签名处理生成第一数字签名，将公钥表和该数字签名包括在授信文件中，再将该授信文件发送给服务端，此时公钥表中只包含了第一个受信任设备的设备公钥。当n>1时，k也可以为1，例如可以由前一个完成了对第一设备的验证后将第一设备的设备公钥加入公钥表的那个受信任设备对更新后的公钥表(也就是已经包含了第一设备的设备公钥)使用自身的设备私钥进行签名后生成第一数字签名，并将包括更新后公钥表和第一数字签名的更新后授信文件发送给服务端进行更新；或者k可以为n，也即，可以将加入请求包和授信文件发送给公钥表中的每个受信任设备进行验证，每个受信任设备在验证通过后使用自身的设备私钥对更新后公钥表(也就是已经包含了第一设备的设备公钥)进行签名生成一个第一数字签名，将包括更新后公钥表和第一数字签名的更新后授信文件发送给服务端进行更新，服务端可将n个受信任设备返回的更新后授信文件整合为一个包括n个受信任设备各生成的第一数字签名的更新后授信文件；再或者，k也可以小于n，也即，可以将加入请求包和授信文件发送给公钥表中的一部分受信任设备进行验证，每个受信任设备在验证通过后生成第一数字签名并将更新后授信文件返回给服务端，由服务端将k个受信任设备返回的更新后授信文件中的k个第一数字签名写入当前存储的已经更新了公钥表的授信文件。本发明实施例中k的具体取值，也即验证加入请求包的受信任设备的数量可根据应用环境进行配置。本发明实施例的第一数字签名可用于本次验证第一设备时，担任对该第一设备的验证工作的受信任设备能够使用生成第一数字签名的受信任设备的设备公钥(该设备公钥已经列在授信文件的公钥表中)对第一数字签名进行验证，以确保公钥表未被恶意篡改。

在本发明一些实施例中，更新后授信文件还包括使用上述m个受信任设备中任意l个受信任设备的设备私钥对更新后公钥表进行签名处理生成的第二数字签名，1≤l≤m。这里l与上述k之间无关联，也即，每次对新加入设备进行验证时，服务端可以将加入请求包和授信文件发送给n个受信任设备中任意个相同或不同的受信任设备进行验证。本发明实施例中，当有第一设备需要验证时，服务端将第一设备的加入请求包和授信文件发送给n个受信任设备中的m个受信任设备，m个受信任设备在各自完成了对第一设备的验证后将第一设备的设备公钥加入公钥表，并且由这m个设备中的任意l个受信任设备对更新后的公钥表(也就是已经包含了第一设备的设备公钥)使用自身设备私钥进行签名后生成第二数字签名，并将包括更新后公钥表的更新后授信文件或包括更新后公钥表和第二数字签名的更新后授信文件发送给服务端进行更新，由服务端对返回的更新后授信文件进行数字签名的整合。换言之，当m个受信任设备承担了对第一设备的验证工作，可由这m个受信任设备中的一部分受信任设备对更新后公钥表签名生成第二数字签名，也可以由这m个受信任设备均对更新后公钥表签名生成第二数字签名。本发明实施例的第二数字签名可用于下一次验证另一个第一设备时担任对该第一设备的验证工作的受信任设备对每个第二数字签名进行验签，以确保公钥表未被恶意篡改。

本发明另一些实施例中，上述实施例可以结合实施。具体而言，本次担任对第一设备的验证工作的受信任设备从服务端接收到的授信文件中可包括有上述第一数字签名，并且在完成本次验证工作后，该受信任设备可以使用自身私钥对更新后公钥表生成上述第二数字签名，并用第二数字签名替换授信文件中的第一数字签名，使得更新后授信文件中包括的是更新后公钥表和第二数字签名。当然，在本发明一些实施例中，一个受信任设备在上次担任验证工作时进行了数字签名，在下次担任验证工作时可以进行数字签名也可以不进行数字签名。

通过本发明上述实施例，即使恶意攻击者通过通信拦截或攻破服务器的方式得到授信文件并将非法设备的设备公钥强行加入授信文件的公钥表中，下一个担任第一设备验证工作的受信任设备也能够立即通过验证第一数字签名或第二数字签名而发觉授信文件的公钥表遭到篡改，从而立即启动防御和恢复操作，及时避免非法设备加入到合法设备间的信任关系中并从合法设备获取数据，确保了合法设备中数据的安全。

在本发明一些实施例中，授信文件中还包括使用基于第一用户账号的登录信息生成的公私钥对中的私钥对公钥表进行签名处理生成的第三数字签名。具体而言，当n＝1时，可由第一个受信任设备使用约定算法从第一用户账号的登录信息中派生出公私钥对，用派生的公私钥对中的私钥对公钥表进行签名处理生成第三数字签名，将公钥表和该第三数字签名包括在授信文件中，再将该授信文件发送给服务端，此时公钥表中只包含了第一个受信任设备的设备公钥。当n>1时，可以由前一个完成了对第一设备的验证后将第一设备的设备公钥加入公钥表的那个受信任设备使用约定算法从第一用户账号的登录信息中派生出公私钥对，用派生出的公私钥对中的私钥对更新后的公钥表(也就是已经包含了第一设备的设备公钥)进行签名生成第三数字签名，并将包括更新后公钥表和第三数字签名的更新后授信文件发送给服务端进行更新。本发明实施例的第三数字签名可用于本次验证第一设备时，担任对该第一设备的验证工作的受信任设备能够使用从第一用户账号的登录信息派生出的公私钥对中的公钥对第三数字签名进行验证，以进一步确保公钥表未被恶意篡改。

在本发明一些实施例中，更新后授信文件还包括使用基于第一用户账号的登录信息生成的公私钥对中的私钥对所述更新后公钥表进行签名处理生成的第四数字签名。与前一实施例相应地，本发明实施例中，当有第一设备需要验证时，由完成了对第一设备的验证后将第一设备的设备公钥加入公钥表的受信任设备对更新后的公钥表(也就是已经包含了第一设备的设备公钥)使用基于第一用户账号的登录信息生成的公私钥对中的私钥对更新后公钥表进行签名处理生成第四数字签名，并将包括更新后公钥表和第四数字签名的更新后授信文件发送给服务端进行更新。本发明实施例的第四数字签名可用于下一次验证另一个第一设备时担任对该第一设备的验证工作的受信任设备对第四数字签名进行验签，以确保公钥表未被恶意篡改。

本发明另一些实施例中，上述实施例可以结合实施。具体而言，本次担任对第一设备的验证工作的受信任设备从服务端接收到的授信文件中可包括有上述第三数字签名，并且在完成本次验证工作后，该受信任设备可以使用上述派生私钥对更新后公钥表生成上述第四数字签名，并用第四数字签名替换授信文件中的第三数字签名，使得更新后授信文件中包括的是更新后公钥表和第四数字签名。

本发明实施例中，从第一用户账号的登录信息派生出公私钥对的方法可以采用现有的各种kdf方法，例如，先派生出ecc私钥，再计算对应公钥。

通过本发明上述实施例，即使恶意攻击者通过通信拦截或攻破服务器的方式得到授信文件并将非法设备的设备公钥强行加入授信文件的公钥表中，下一个担任第一设备验证工作的受信任设备也能够立即通过验证第三数字签名或第四数字签名而发觉授信文件的公钥表遭到篡改，从而立即启动防御和恢复操作，及时避免非法设备加入到合法设备间的信任关系中并从合法设备获取数据，确保了合法设备中数据的安全。

在本发明上述实施例中，给出了第一校验码的一些例子，但本发明不限于此。并且，在本发明一些实施例中，第一校验码中可以包括两种以上实施例中给出的校验数据。

在本发明一些实施例中，第一校验码可以包括通过使用第一设备的设备私钥对第一设备的设备公钥进行签名处理生成的第五数字签名。具体而言，第一设备需要加入到设备间信任关系时，可使用第一设备的设备私钥对第一设备的设备公钥进行签名处理生成第五数字签名，并将第五数字签名作为第一校验码通过加入请求包发送至服务端。服务端接收到加入请求包后，将授信文件和加入请求包发送给授信文件中的任一个受信任设备进行验证，在验证时，负责验证的受信任设备使用加入请求包中的设备公钥对第五数字签名进行验证，如验证通过，则将第一设备的设备公钥加入到公钥表中，得到更新后授信文件并发送给服务端；否则，结束验证过程。通过本发明实施例，能够确定第一设备真实拥有加入请求包中的设备公钥和对应的设备私钥。

在本发明一些实施例中，第一校验码可以包括通过使用受信任设备中的任一个受信任设备的设备私钥对第一设备的设备公钥进行签名处理生成的第六数字签名。具体而言，第一设备需要加入到设备间信任关系时，可将第一设备的设备公钥发送给已经加入到授信文件中的任一个受信任设备，由该受信任设备使用自身私钥对第一设备的设备公钥进行签名处理生成第六数字签名并返回给第一设备，第一设备在向服务端发送加入请求包时，将第六数字签名作为第一校验码通过加入请求包发送至服务端。服务端接收到加入请求包后，将授信文件和加入请求包发送给授信文件中的任一个受信任设备进行验证，在验证时，负责验证的受信任设备检查第六数字签名对应的设备公钥是否在授信文件公钥表中，如是，则使用该设备公钥对作为第一校验码的第六数字签名进行验证，验证通过，则将第一设备的设备公钥加入到公钥表中，得到更新后授信文件并发送给服务端；否则，结束验证过程。通过本发明实施例，使得无需预先约定由哪个受信任设备进行验证，可以通过加入到授信文件中的随机一个受信任设备进行对第一设备的验证工作，使得验证机制更加高效。

在本发明一些实施例中，第一设备发送给服务端的加入请求包中还可以包括使用基于第一用户账号的登录信息生成的公私钥对中的私钥对第一设备的设备公钥进行签名处理生成的第六数字签名。具体而言，第一设备需要加入到设备间信任关系时，第一设备使用约定算法从第一用户账号的登录信息中派生出公私钥对，使用派生的公私钥对中的私钥对第一设备的设备公钥进行签名处理生成第六数字签名，并在向服务端发送加入请求包时，将第六数字签名也通过加入请求包发送至服务端。服务端接收到加入请求包后，将授信文件和加入请求包发送给授信文件中的一个受信任设备进行验证，在验证时，负责验证的受信任设备除了验证第一校验码，还使用约定算法从第一用户账号的登录信息派生出公私钥对，用派生的公钥对第六数字签名进行验证，两者均验证通过，则将第一设备的设备公钥加入到公钥表中，得到更新后授信文件并发送给服务端。通过本发明实施例，进一步提高了验证的可靠性，避免非法设备加入到设备间信任关系中，提高了合法设备中数据的安全性。

图2为本发明另一个实施例的授信管理方法的示例性流程图。

如图2所示，本发明实施例的授信管理方法包括：

201、在第一用户账号未关联任何设备的情况下，第一个登录第一用户账号的设备建立信任环(对应授信文件)；

信任环的数据结构可以为：

公钥列表|设备签名|密码签名

其中，公钥列表为每个关联到第一用户账号的设备的设备公钥组成的列表；设备签名为使用设备公钥对应的设备私钥对公钥列表进行签名得到的数字签名；密码签名为使用第一用户账号的密码派生的公私钥对中的私钥对公钥列表进行签名得到的数字签名。在第一个设备建立的信任环中，公钥列表中只包含第一个设备自身的设备公钥。

202、将信任环提交到互联网网站，网站将信任环保存在第一用户账号下。

203、新设备申请加入到信任环时，由新设备生成加入请求；

加入请求的数据结构可以为：

新设备公钥|设备签名|密码签名

其中，设备签名为使用信任环中的设备公钥对应私钥对新设备公钥进行签名得到的数字签名；密码签名为使用第一用户账号的密码派生的公私钥对中的私钥对新设备公钥进行签名得到的数字签名。

204、将加入请求提交到互联网网站，网站将加入请求保存在第一用户账号下。

205、已在信任环中的设备从网站获取信任环以及加入请求。

206、该设备验证信任环以及加入请求的签名。验证加入请求中的设备签名时，还需检查与设备签名对应的设备公钥是否在信任环中，如在则使用对应的设备公钥对设备签名进行验证。验证密码签名时，可以提示使用者输入密码或使用设备中缓存的密码派生公私钥对。

207、提示设备使用者是否同意新设备加入信任环，如不同意则结束流程，同意则执行步骤208。

208、将新设备的设备公钥加入到信任环，并重新对公钥列表签名。

209、将更新后的信任环提交到网站，网站将信任环保存在第一用户账号下。

图3为本发明一个实施例的授信管理装置的示例性框图。本发明实施例的授信管理装置应用于服务端。

如图3所示，本发明实施例的授信管理装置包括处理单元11和通信单元12。处理单元11配置为将包括公钥表的授信文件进行存储，所述公钥表包括n个受信任设备的设备公钥，n≥1。通信单元12配置为接收来自第一设备的加入请求包，将授信文件和加入请求包发送给n个受信任设备中的任意m个受信任设备进行验证，1≤m≤n，其中，所述加入请求包与授信文件相关并包括第一设备的设备公钥及第一校验码。处理单元11还配置为，如果通信单元12从完成验证的受信任设备接收到包括更新后公钥表的更新后授信文件，则处理单元11用更新后公钥表覆盖原公钥表，其中，更新后公钥表包括第一设备的设备公钥。

本发明实施例的授信管理装置中上述各个模块的可行的工作过程具体可详见前述的授信管理方法的实施例，在此不再赘述。

本发明实施例的授信管理装置除了可以通过硬件的方式来实现之外，还可以通过软件的方式来实现。例如，本发明一个实施例的授信管理装置可以包括存储器和处理器，存储器存储有预定的计算机可执行指令，处理器可以配置为执行该预定的计算机可执行指令以实施上述任一授信管理方法实施例中进行的处理。

通过本发明实施例，仅通过成功登录第一用户账号并无法自动成为受信任设备，而是通过创建和更新授信文件来建立设备之间的可靠信任关系，如此，即使在恶意攻击者非法获取了第一用户账号的登录信息或者攻破了服务器获得授信文件的情况下，由于该恶意攻击者无法从受信任设备或其用户获得第一校验码，因而无法借由向服务端发送加入请求包的方式通过受信任设备的验证，无法将其非法设备的设备公钥合法地加入到授信文件的公钥表中，从而无法伪装成合法设备加入到与第一用户账号关联的受信任设备间的信任关系中并从合法设备获取数据，进而确保了合法的受信任设备中数据的安全。

以上对本发明的多个实施例进行了详细说明，但需要说明的是，上述实施例仅为示例性的，并不旨在限制本发明，本领域技术人员在不脱离本发明构思的范围内基于上述实施例得出的各种修改、变型实施例均落在本发明要求保护的范围内。