一种GPON设备集中安全鉴权系统

技术领域

本发明涉及信息安全技术领域，尤其涉及一种GPON设备集中安全鉴权系统。

背景技术

传统网络设备鉴权是单机鉴权，密码存储在设备本身。无论密码如何被加密，设置如何复杂如何频繁更改密码，一旦密码被嗅探到，被黑客解密或被黑客攻破，安全就荡然无存设备就被劫持，而且管理者除非主动检查，否则也不知道设备被劫持，也不知道什么时候被劫持。

另外设备监管者为了设备密码不被轻易攻破，或设置长而复杂的密码，并且为了安全起见，每个设备密码都设置成不一样。这导致密码保管和使用都很困难和麻烦。还有设备自身的鉴权模块在使用过程中，当发现安全漏洞需要全网升级，而全网升级的实现需要复杂的处理流程且花费时间较长。

因此，需要提供一种GPON设备集中安全鉴权系统来解决上述技术问题。

发明内容

为解决上述之一技术问题，本发明提供的一种GPON设备集中安全鉴权系统，包括客户端、终端设备、服务器端和服务器设备，并通过多重叠加C/S架构进行部署并提供认证和授权服务；其中，

所述终端设备为网络接入设备，用户通过网页、telnet、ssh和/或串口方式登录终端设备，所述终端设备通过客户端进行用户认证，并在鉴权时各需要鉴权的进程调用鉴权系统的库函数；所述客户端安装在终端设备上；

所述服务器端部署在服务器设备上，所述服务器设备包括公网主服务器，公网备份服务器、内网私钥配置服务器和边缘在线设备；其中，所述服务器设备在接收到鉴权请求后到公网主服务器去鉴权，所述公网主服务器鉴定合法用户后返回授权信息，授权用户事先配置好的对应权限；所述公网备份服务器在鉴权请求规定时间内无响应时启动，切换到所述公网主服务器接收鉴权请求和返回授权信息；

在鉴权过程中，鉴权双方互相产生真随机数作为加密密钥的一部分并且携带当前时间的时间戳生成密钥对；其中，所述终端设备存有公钥，所述公网主服务器在运行时从内网私钥配置服务器获取私钥，且私钥仅存在于公网主服务器的内存中；所述服务器设备之间通过UDP包进行通信，并将通信内容限制在单个UDP包载荷内；当通信内容超出单个UDP包长时，则通过TCP包进行通信且不限制通信内容的长度。

作为更进一步的解决方案，用户账号注册流程通过如下步骤进行：

客户端读取终端设备的硬件唯一特征，通过哈希运算得到Hardware-id并标识用户；

客户端将携带Hardware-id信息和账号信息的注册请求发送至服务器端；

服务器端存储注册请求的相关信息，并用于当前用户账号注册流程直至结束；

当客户端发起下一次用户账号注册流程，则重新生成Hardware-id并发送至服务器端。

作为更进一步的解决方案，客户端通过如下步骤周期性更新密钥和检查软件版本流程：

客户端对系统数据进行加密；其中，客户端从服务器端中获取加密所用AES密钥，并且服务器端每次给出AES密钥的有效时间；

当超过AES密钥的有效时间，客户端则向服务器端申请更新密钥，在服务器端上用算法保证每次更新后的密钥都完全不一样；

在申请更新密钥过程中，服务器端在回复的报文字段中告诉客户端是否有更新版本，当更新版本比客户端当前的版本新时，自动触发客户端软件升级，版本由服务器指定地址下载。

作为更进一步的解决方案，设备登录流程通过如下步骤进行：

Discover阶段：终端设备生成广播包并在局域网内广播；寻找客户端所在设备IP地址；

Offer阶段：客户端收到广播包后发送单播的Offer包给终端设备，并相互交换双方产生的随机数；

客户端Request阶段：用户登录终端设备的账号和密码经过AES加密算法发送给客户端，客户端只用校验密码是否与当前在客户端上配置的账号的密码一致；当不一致，不做任何响应；当一致，则通过AES密钥对系统数据和hardware-id进行加密；

Ack阶段：客户端通过Ack回包将加密后的数据发送给终端设备，终端设备收到Ack回包后解密得到hardware-id和系统数据并再次加密；

服务器Request阶段：终端设备把监控者关心的信息加密后通过服务器Request包发送给客户端，客户端收到后转发给服务器端；

服务器Response阶段：服务器端鉴权通过后使用Response包返回鉴权信息给客户端，再由客户端转发给终端设备鉴权信息；其中，客户端不对包做任何修改并执行纯转发过程，客户端知道服务器端所在设备IP地址，终端设备无需得知服务器端所在设备IP地址。

作为更进一步的解决方案，在终端设备无法与客户端直接通信时，终端设备通过如下步骤获取一次性的临时密钥：

客户端向服务器端发送申请密钥，服务器端配置可进行临时密钥申请和临时密钥使用的范围和时间段；

在安装有客户端的用户设备上申请临时密钥，临时密钥申请后发送给进行登录的终端设备，并用临时密钥来登录；

其中，临时密钥由服务器端生成加密字符串；加密字符串分为两部分，一部分终端设备可以解密，剩余部分终端设备无法解密，并用于作为系统加密信息直接发送给服务器端；

剩余部分信息包括账号、账号的有效期和被限制的登录设备；在此过程中，同样携带设备的其他信息，并通过Request和Response包和服务器进行内容交换；

当鉴权请求在服务器端解密后，发现账号不账号合法或未在有效期内，将不回复；只有账号合法并在有效期内，才回复鉴权通过。

作为更进一步的解决方案，临时密钥通过如下步骤生成：

产生4字节的真随机数，且保证真随机数不重复；

使用AES加密算法加密hardware-id和系统数据；

填充flag，totalLen，serverPort和serverIp字段，填好后计算check值；

由magicNum再拼接特定字符串，特定字符串由内部设置且外部未知；

使用SHA256进行HASH计算得到32字节的HASH值；

从flag字段到serverIp字段的数据与前面32字节的HASH值进行异或计算，并覆盖原来的值；

完成后对整个加密数据进行base64加密，变成可识别的字符串得到临时密钥；

其中，在临时密钥解密时：通过执行临时密钥生成的逆过程，即完成临时密钥解密。

与相关技术相比较，本发明提供的一种GPON设备集中安全鉴权系统具有如下有益效果：

本发明按照使用时序性，分为用户账号注册流程，周期性更新密钥和检查软件版本流程，设备登录流程和一次性密钥获取和使用流程，通过一系列安全技术的巧妙组合和独特的创新解决了传统网络设备在密码鉴权过程中的各种弊端，解决了密码安全问题，无法集中管理，安全模块升级困难，无法感知设备被黑客试探攻击，密码保管和使用都很困难和麻烦等一系列问题。

附图说明

图1为本发明提供的一种GPON设备集中安全鉴权系统的拓扑示意图；

图2为本发明提供的用户账号注册流程示意图；

图3为本发明提供的周期性更新密钥和检查软件版本流程示意图；

图4为本发明提供的设备登录流程示意图；

图5为本发明提供的一次性密钥获取和使用流程示意图。

具体实施方式

下面结合附图和实施方式对本发明作进一步说明。

如图1所示，一种GPON设备集中安全鉴权系统，包括客户端、终端设备、服务器端和服务器设备，并通过多重叠加C/S架构进行部署并提供认证和授权服务；其中，

所述终端设备为网络接入设备，用户通过网页、telnet、ssh和/或串口方式登录终端设备，所述终端设备通过客户端进行用户认证，并在鉴权时各需要鉴权的进程调用鉴权系统的库函数；所述客户端安装在终端设备上；

所述服务器端部署在服务器设备上，所述服务器设备包括公网主服务器，公网备份服务器、内网私钥配置服务器和边缘在线设备；其中，所述服务器设备在接收到鉴权请求后到公网主服务器去鉴权，所述公网主服务器鉴定合法用户后返回授权信息，授权用户事先配置好的对应权限；所述公网备份服务器在鉴权请求规定时间内无响应时启动，切换到所述公网主服务器接收鉴权请求和返回授权信息；

在鉴权过程中，鉴权双方互相产生真随机数作为加密密钥的一部分并且携带当前时间的时间戳生成密钥对；其中，所述终端设备存有公钥，所述公网主服务器在运行时从内网私钥配置服务器获取私钥，且私钥仅存在于公网主服务器的内存中；所述服务器设备之间通过UDP包进行通信，并将通信内容限制在单个UDP包载荷内；当通信内容超出单个UDP包长时，则通过TCP包进行通信且不限制通信内容的长度。

需要说明的是：本系统采用多重叠加的C/S架构，主要功能是认证(Authentication)和授权(Authorization)，后文简称AA系统。

登录电脑(或者其他登录设备，例如手机等)安装有特殊软件(后文为描述简便，大多数情况下仅以电脑登录举例)，在本系统中名称为eKey(客户端)，用户通过网页/telnet/ssh/串口方式等登录设备(例如GPON设备)，设备在鉴权时每个需要鉴权的进程调用AA系统的公共鉴权库函数，库函数通过一系列复杂操作和运算最终到公网AA服务器去鉴权，公网服务器鉴定合法用户后返回授权信息，授权该用户事先配置好的各种权限。

设备和AA服务器的通信，通过RSA，AES,HMAC，真随机数等一系列高强度的加密手段和防篡改识别的组合保证信息不被破解，即使破解了，因为时效性而无法重放攻击，保证数据在公网上通信的安全。这里所谓的防重放攻击，是指在鉴权过程中，鉴权双方互相产生真随机数作为加密密钥的一部分并且携带当前时间的时间戳，保证话的唯一性和不可重复性，杜绝通过抓包模拟客户端的再次重现其过程。

设备端存放AA系统的RSA的公钥，AA服务器在运行时从内网私钥配置服务器获取RSA的私钥，私钥仅存在AA服务器的内存中，并且是高强度加密的，仅在使用解密，保证黑客即使劫持攻破AA服务器也很难拿到RSA的私钥。

eKey是一个运行在用户PC上(或手机上)的软件客户端，同时也是设备在鉴权过程中某些阶段的服务端。eKey上也存放有AA系统的RSA的公钥。

为保证AA服务器的健壮性，AA服务器至少有一个备份服务器，在鉴权请求规定时间内无响应(例如2秒内)，eKey自动切换到备份AA服务器去鉴权。

AA系统的各个节点之间通信优选UDP包进行通信，并且把每次通信的内容尽量控制在一个包的载荷内(1500字节以内)，这是为了处理的效率。但在必要时，可以改成TCP包，并且不限制通信内容的长度。下面章节若无特别说明，均指的是UDP通信。

所谓的多重叠加的C/S架构，是指在本系统中各个交互模块在每个特定阶段角色不停转变，在一个阶段为客户端(Client)，另外一阶段为(Server),这样能充分发挥本系统的潜能，提高破解难度，从而提高系统整体安全性。

作为更进一步的解决方案，参见图2，用户账号注册流程通过如下步骤进行：

客户端读取终端设备的硬件唯一特征，通过哈希运算得到Hardware-id并标识用户；

客户端将携带Hardware-id信息和账号信息的注册请求发送至服务器端；

服务器端存储注册请求的相关信息，并用于当前用户账号注册流程直至结束；

当客户端发起下一次用户账号注册流程，则重新生成Hardware-id并发送至服务器端。

作为更进一步的解决方案，参见图3，客户端通过如下步骤周期性更新密钥和检查软件版本流程：

客户端对系统数据进行加密；其中，客户端从服务器端中获取加密所用AES密钥，并且服务器端每次给出AES密钥的有效时间；

当超过AES密钥的有效时间，客户端则向服务器端申请更新密钥，在服务器端上用算法保证每次更新后的密钥都完全不一样；

在申请更新密钥过程中，服务器端在回复的报文字段中告诉客户端是否有更新版本，当更新版本比客户端当前的版本新时，自动触发客户端软件升级，版本由服务器指定地址下载。

需要说明的是：Hardware-id是eKey软件在PC运行采集例如cpu-id，硬盘序列号，BIOS序列号等硬件唯一特征(在手机上采取的硬件信息有所不同，但原理一样，这里为简便不举例说明)并通过某种HASH算法(例如SHA-256)生成的每台PC唯一的32字节的标识，标识每个用户的ID。由于这些硬件特征的唯一性和HASH算法的不可逆，保证用户账号的唯一性和无法伪造冒充合法账号。

在eKey注册过程中，把hardware-id和用户账户等信息发送给了AA server，AAserver存储相关信息。hardware-id本身在eKey上每次使用相同的算法提取用户PC的硬件标识，由于每台电脑hardware-id都不一样，别人也无法获知hardware-id的生成过程和生成算法(即使知道生成算法因为HASH算法的不可逆，无法还原原始值)，也不保存在除AAserver之外的任何地方，无法被破解，hardware-id本身作为加密密钥的一部分保证系统认证安全。这里注册过程的报文都是经过RSA加密算法加密过的。

作为更进一步的解决方案，设备登录流程通过如下步骤进行：

Discover阶段：终端设备生成广播包并在局域网内广播；寻找客户端所在设备IP地址；

Offer阶段：客户端收到广播包后发送单播的Offer包给终端设备，并相互交换双方产生的随机数；

客户端Request阶段：用户登录终端设备的账号和密码经过AES加密算法发送给客户端，客户端只用校验密码是否与当前在客户端上配置的账号的密码一致；当不一致，不做任何响应；当一致，则通过AES密钥对系统数据和hardware-id进行加密；

Ack阶段：客户端通过Ack回包将加密后的数据发送给终端设备，终端设备收到Ack回包后解密得到hardware-id和系统数据并再次加密；

服务器Request阶段：终端设备把监控者关心的信息加密后通过服务器Request包发送给客户端，客户端收到后转发给服务器端；

服务器Response阶段：服务器端鉴权通过后使用Response包返回鉴权信息给客户端，再由客户端转发给终端设备鉴权信息；其中，客户端不对包做任何修改并执行纯转发过程，客户端知道服务器端所在设备IP地址，终端设备无需得知服务器端所在设备IP地址。

需要说明的是：系统数据为了防止被拦截破解，需要eKey对系统数据(系统数据的概念后文解释)进行加密，加密的AES密钥是eKey从AA server中获取的，并且AAserver每次给出密钥的有效时间(到期时间)，过了有效期，eKey就到server申请更新密钥，在AAserver上用算法保证每次更新后的密钥都完全不一样。在更新密钥的传送过程中，本身也是高强度的RSA密钥加密的，不怕被人拦截破解。典型更新时间是每天更新一次，可以根据需要调整这个更新时间间隔。

在这个过程中，AA server在回复的报文字段中告诉eKey是否有更新版本，当更新版本比eKey当前的版本新时，自动触发eKey软件升级。eKey能及时升级可以迅速堵住将来可能发现新的安全漏洞或者增强安全措施，因为eKey安装在使用者的登录电脑上，所以升级非常方便，而且不是升级网络设备(GPON设备等)本身。

用户在电脑或手机等设备登录设备，登录方式包括页面/telnet/SSH/ftp等等，携带用户名和密码等信息，这些过程无须任何特殊处理，仅仅需要在相关的守护进程httpd/telnetd/sshd/ftpd等账号鉴权时做特殊处理，都统一调用AA鉴权库接口函数即可。

鉴权库用C语言实现，鉴权接口函数声明如下:

int AA_login(const char*password,const char*userData,char*jsonResult)；

参数说明如下:

返回值:int成功是返回0，失败是返回-1。

在库里调用自动实现附录图4的鉴权过程，从设备端开始，详细如下:

Discover阶段是广播包，因为设备并不知道eKey软件所在PC的IP地址，只能在局域网内广播寻找，eKey软件收到广播包后发送单播的Offer包给设备，在Discover和Offer阶段双方交换自己产生的随机数给对方，这在后续的加解密过程中要使用到。产生随机数的目的是拼接双方的随机数和一定的算法产生AES的加密密钥，让每次加密密钥都不一样，从而使每次加密结果都不一样(即使加密的原始数据都一样)，防止重放攻击。

Request阶段登录设备的账号和密码经过AES加密算法发送给eKey，eKey只用校验密码是否与当前在eKey上配置的账号的密码一致。当不一致，不做任何响应，当一致，把hardware-id等系统数据加密，通过Ack回包发送给设备。这里的加密密钥是通过周期性更新密钥从AA server那里取到的，在设备端是无法解密系统数据的(这样设计是保证系统数据的安全)，为进一步提高安全性，可以结合hardware-id与密钥按一定的方法拼接后再HASH生成新的密钥用于加密，这样系统数据仅在本eKey端和服务器端可解密。

设备收到hardware-id解密后再次加密，把账号信息，hardware-id，设备其余信息，如软硬件版本号，GPON SN等等监控者关心的信息加密后通过AA Request包发送给eKey。eKey收到后转发给AA server，AA server鉴权通过后回AA Response给eKey，再由eKey转发给设备鉴权信息，纯转发过程eKey不对包做任何修改，仅转发。eKey是知道AAserver服务器的公网IP地址或域名的，设备是不需要知道内容的。

上面每一步当失败，将不做任何响应，是为了更加安全，避免攻击者试探和重放攻击，在局域网内，丢包可能性很小，在eKey和AA server间丢包可能性要稍微大一些。在丢包稍微大的环节，可以考虑适当次数的超时重传机制。

注意：在AA response中仍然有字段指示eKey软件是否需要升级，这是为了最大限度地保证安全，在万一发现有问题时，能够最快速度地升级eKey软件，及时堵住任何漏洞。

作为更进一步的解决方案，在终端设备无法与客户端直接通信时，终端设备通过如下步骤获取一次性的临时密钥：

参见图5，客户端向服务器端发送申请密钥，服务器端配置可进行临时密钥申请和临时密钥使用的范围和时间段；

在安装有客户端的用户设备上申请临时密钥，临时密钥申请后发送给进行登录的终端设备，并用临时密钥来登录；

其中，临时密钥由服务器端生成加密字符串；加密字符串分为两部分，一部分终端设备可以解密，剩余部分终端设备无法解密，并用于作为系统加密信息直接发送给服务器端；

剩余部分信息包括账号、账号的有效期和被限制的登录设备；在此过程中，同样携带设备的其他信息，并通过Request和Response包和服务器进行内容交换；

当鉴权请求在服务器端解密后，发现账号不账号合法或未在有效期内，将不回复；只有账号合法并在有效期内，才回复鉴权通过。

需要说明的是：在某些情况下，设备无法与eKey直接通信(可能登录电脑没有安装此软件)，可以申请一次性密钥(非常短时间内有效，例如1分钟或2分钟)，然后在安装有eKey电脑上申请临时密钥(AA服务器上可配置哪些用户账号可以申请临时密钥和临时密钥实用的范围和时间段)，临时密钥申请后发送给进行登录的电脑，用临时密钥来登录。临时密钥由server端生成加密字符串(每次生成的字符串都完全不一样)。

这个加密字符串包含了随机数，时间戳和很多校验信息，随机数和时间戳用于保证每次生成一次性密钥都不一样，校验信息用于防止字符串被篡改，篡改后SHA256计算值就完全不一样了，认为是非法数据被直接丢弃。

这个字符串分为两部分，一部分设备端可以解密，例如用于获取AA server的IP地址和端口号，剩余部分设备端无法解密，用于作为系统加密信息直接发送给AA server，这部分信息包括账号和账号的有效期，以及被限制的登录设备(例如设备MAC，用于仅此设备登录)。在此过程中，同样携带设备的其他信息，例如设备的MAC地址，IP地址，GPON的SN,软硬件版本号，运行时长等，这个包和前面的AA request请求内容一样。AA服务器回复内容和前面的AA response内容一样。

当鉴权请求在AA server解密后，发现账号不账号合法或未在有效期内，将不回复，只有账号合法，并且在有效期内，并才回复鉴权通过。

一个申请好的临时密钥示例:

kPYMDCljeLek9aQWUp29hYcAbLdwvgnEOgA6NajLC7xeBbJJZrUHpEL5XsaFrl9NgOsy/FA20PkpiRFVXaneijg0M/9tZrnI3liJQ2wjFNzkl+SWo/YoqBMFOqLoTPzeP99waYoxfKPW74OD9Enr+DyPx7QX8WjpDSkY15BxP3WeOVFgXhcp7TrSSrUkwmjM

临时密钥很长，是随机数，账号，hardware-id,服务器时间，按特殊方式拼接叠加，多种加密方式加密后的结果，为保证全部都是人可读字符串(便于复制发送)，最后一步采用base64加密。临时密钥本身的加密的AES密钥由服务器临时产生，这个AES密钥具有时效性,在短时间内有效，过一段时间后，服务器更新密钥，保证破解者即使在长时间后破解了也没有用。

注意：在发送密钥的过程中仍然有字段指示eKey软件是否需要升级，这是为了最大限度地安全，在万一发现有问题时，能够最快速度地升级eKey软件，及时堵住任何漏洞。

一个典型的临时密钥数据结构设计如下(用C语言描述)：

typedef struct{

unsigned char randNum[4]；//4字节真随机数，保证每次生成都不一样，为了更安全，可以设计成更多字节

unsigned char magicNum；//魔数，一个特定字符用于简易识别是否合法的临时key的数据头

unsigned char flag； //扩展功能flag标识

unsigned short check； //设计一个算法，校验整个头部的是否合法或者有没有被篡改

unsigned short totalLen；//包含头部的全部长度

unsigned short serverPort；//AA服务器的端口

unsigned int serverIp；//AA服务器的IPv4地址，当是IPv6地址，需要做适当修改

unsigned char data[0]；//要加密的其他数据的开头

}AA_TMP_KEY_HDR；/*total 16bytes*/

临时密钥产生过程举例如下:

产生4字节的真随机数，保证真随机数不重复

使用AES加密算法加密hardware-id等系统信息

填充flag，totalLen，serverPort，serverIp等字段，填好后计算check值

由magicNum再拼接某个特定字符串(这个字符串类似于密钥的功能，外界不知道，大幅度增加破解难度)，使用SHA256进行HASH计算得到32字节的HASH值

从flag字段到serverIp字段的数据与前面32字节的HASH值进行异或计算覆盖原来的值(32字节的HASH值超出部分丢弃)

完成后对整个加密数据进行base64加密，变成可识别的字符串

整个过程可逆，解密按上面过程逆向解密即可。

作为更进一步的解决方案，临时密钥通过如下步骤生成：

产生4字节的真随机数，且保证真随机数不重复；

使用AES加密算法加密hardware-id和系统数据；

填充flag，totalLen，serverPort和serverIp字段，填好后计算check值；

由magicNum再拼接特定字符串，特定字符串由内部设置且外部未知；

使用SHA256进行HASH计算得到32字节的HASH值；

从flag字段到serverIp字段的数据与前面32字节的HASH值进行异或计算，并覆盖原来的值；

完成后对整个加密数据进行base64加密，变成可识别的字符串得到临时密钥；

其中，在临时密钥解密时：通过执行临时密钥生成的逆过程，即完成临时密钥解密。

需要说明的是：在每个点对点通信中，为保证数据的安全性，完整一致性，不可破解性，通过一系列加密和数字摘要等技术保证。下面举例说明，举例中任何数字量化或字段只是其中的一个优先结果，并不代表只能用这个具体的值或只限于这个字段，可以根据需要进行增删改。报文格式设计如下：

每个部分详解如下:

AA包头(固定为80字节)

RSA加密数据段(固定为256字节)

AES加密系统数据段(0-512字节)

全部是系统数据，长度由前面的【AES加密系统数据长度】确定。

系统数据是eKey软件携带的硬件摘要信息(例如前面提到的hardware-id)等标识登录者登录电脑的信息。

AES加密用户数据段(0-512字节)

全部是用户数据，长度由前面的【AES加密用户数据长度】确定。

用户数据是设备相关信息，例如mac地址，GPON的SN,软硬件版本号，运行时长等

加密解密包步骤：

1公钥加密数据流程

按以下步骤加密

(1)整个buffer清0

(2)产生32字节真随机数，放入包头随机数字段

(3)把版本号，key id,计算32字节后的data len放入包头

(4)通过SHA256进行对包头和指定salt合并后HASH运算的结果与check,版本号，key id,data len这些字段按顺序进行异或运算并覆盖原值

(5)把版本号，key id,计算32字节后的data len放入包头

(6)产生真随机数填充RSA加密区的HMAC KEY，AES KEY

(7)获取时间戳(自1970-01-01以来的秒数)，填入timestamp字段

(8)拷贝其他需要RSA加密的数据到RSA区(当有的话)

(9)拷贝系统数据到指定的AES区

(10)拷贝用户数据到指定的AES区

(11)使用HAMC对整个包payload计算，HMAC key使用RSA区的HMAC key,把HMAC值放入包头的HMAC字段

(12)使用RSA区的AES key，包头的32字节随机数的后16字节作为AES的IV(initialization vector),对AES区加密

(13)使用公钥对RSA区进行加密

2私钥解密数据流程

按以下步骤顺序解密

(1)通过SHA256进行对包头和指定salt合并后HASH运算的结果与check,版本号，key id,data len这些字段按顺序进行异或运算并覆盖原值

(2)当check字段不为0，判断为非法的包，退出解密流程

(3)使用key id指定的私钥对RSA区进行解密

(4)RSA解密后使用RSA区的AES key和包头的随机数后16字节做为AES的IV对整个AES区进行解密

(5)取出包头的HMAC值，保存到一个变量中，并把包头的HMAC全部清0

(6)使用RSA区的HMAC key对整个包的paylaod进行计算，算出HMAC值与步骤(5)中的HMAC进行比较，当不一致，判定为非法的包，退出解密流程

(7)拷贝解密后的系统数据，用户数据到应用层，解密结束

3私钥加密数据流程

因为在私钥加密仅仅用于服务器对客户端的回包中，为减少系统复杂度，完全复制了客户端的发来的包头，并且加密过程和公钥加密数据流程完全一致。但做了如下微调:

(1)RSA加密使用的私钥，替换前面步骤中的公钥

(2)完成加密后，再次使用AES256加密算法对整个包进行加密，其中AES key来源于私钥解密过程收到的客户端发过来的AES KEY,AES的IV来源于包头的随机数的后16字节，由于AES key是经过RSA加密的，第三方无法获取到AES key，所以这个过程是非常安全可靠的。

4公钥解密数据流程

公钥解密仅用于解密服务器发送回来的包的数据，使用了和私钥解密数据基本一致的解密过程和步骤，但做了如下微调:

(1)收到包后，先用AES256解密，AES的key和IV是和前面公钥加密完全一致

(2)在RSA解密步骤中要使用公钥解密而不是使用私钥解密。

上述加密过程有如下重要特征:

整个加密数据看上去是随机数，几乎无法找到任何规律，即使相同的原始数据也被加密成不同的密文数据，而且每次变化很大，基本上是每个字节都在变动

采用了HAMC技术防止数据被篡改，若有一个bit被篡改，都能检验出来被认为是非法数据而丢弃

在服务端收包解密时，能快速通过算法对前面几十个字节做运算初步确认是否是合法的包，避免对整个包进行解密运算后才能确认数据的合法性，对提高服务器性能和抗饱和攻击有很大好处

RSA和AES两种加密算法配合应用，充分发挥两种算法的优点，避免其缺点，保证算法的安全和性能。RSA加密强度高，非常难于破解，但是运算效率稍低，AES加密的安全性比RSA低一些，但运算效率高。RSA在本系统中用于加密AES的密钥和其他关键信息，在加密数据中只占一小部分，剩余部分由AES加密完成。AES密钥随机生成，在包中由RSA加密传递。因为随机数密钥和采用AES-CTR方式加解密，保证任何相同的数据经过加密后都是不同被加密的数据，让破解者找不到规律，提高系统安全性。

为了安全和难于破解，RSA的密钥长度至少使用2048bit，AES至少使用ASE256。

在一个具体的实施例中，用户通过如下步骤进行鉴权：

用于登录电脑或手机，或其他智能设备(包括U盘插入的智能设备)，安装运行了一个被称为eKey的软件。

eKey软件在安装时要求输入账号密码，此账号密码由AA系统的管理员提供，并且在安装时收集登录终端的硬件信息，例如电脑，收集CPU序列号，BIOS序列号，硬盘序列号等等唯一硬件特征，把这些硬件特征字符串按一定方式拼接然后进行HASH计算(典型地采用SHA-256进行计算)，计算结果作为hardware-id加密发送给AA服务器，AA服务器记录账号和关联的硬件信息。相同硬件(同一个电脑无论多少次)计算出来的hardware-id一定相同，不同硬件(不同电脑)计算出来的hardware-id一定不相同。

eKey安装成功后特定用户账号与硬件特征信息形成绑定关系，已分配账号将限定在此登录设备上使用，无法在其他登录设备上使用，除非AA系统管理员设置解绑此账号的绑定的登录设备。

被登录设备可以设计成多个账号，普通账号授予非常有限的权限，常规处理即可。高级账号使用AA系统鉴权。例如账号使用superadmin作为系统鉴权账号。

在eKey上可以设置本地AA鉴权密码，这个密码可以很复杂，也可以很简单，甚至为空也可以。这取决于使用者对当前登录环境安全的认知，例如登录设备和被登录设备是一根网线直连的，这可以认为是非常安全的，可以设置一位字符的简单密码，或者密码为空都可以。

在通过网页/telnet/ssh/串口等方式登录时，当使用特殊账号(例如前面提到地superadmin)登录调用统一库AA系统函数去鉴权

AA系统鉴权库首先在绑定接口(对于GPON这种网关设备就是在LAN侧的接口),发送广播Discover包，去寻找在LAN侧的安装在电脑或手机上的eKey软件模块。

eKey软件模块收到Discover包，发送offer单播包给设备

设备收到offer单播包后发送单播request包给eKey

eKey收到单播request包后，发送ack包给设备。Ack包中携带hardware-id等信息加密发送给设备。

设备向eKey发送AA request鉴权包请求eKey转发给AA Server。

这个AA request鉴权包被eKey转发到AA鉴权服务器。

AA服务器开始鉴权，检验账号信息，hardware-id和数据库中的数据匹配时，为合法账号，并记录设备鉴权的携带的其他信息(包括设备IP地址，MAC等等)和当前时间戳，以便监控管理者必要时查验或者触发服务器配置的事件规则(例如告警，事件通知等)。可以设置多种规则，例如当设备IP或者登录时间等明显不符合管理者预期时，触发告警或者当作非法。更进一步，部分不符合预期的行为可以先触发告警，通知管理者，先允许时长有限的登录，管理者人工确认后，合法允许继续登录，不合法者管理者通过AA服务器直接把非法登录者踢下线(强制退出登录)。这样可以进行精细化管理，进一步防止eKey软件被合法用户(或者被盗用者)非法使用。不匹配时不做任何回应。根据账号配置的授权信息，携带在AAresponse包里发给eKey。

eKey再把AA response包转发给设备。

eKey把授权信息转发给设备，设备只给允许的权限给登录用户。

以上仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。