一种应用于全IP远程监控网络系统及安全认证方法

摘要

本发明公开了通信网络安全领域的一种应用于全IP远程监控网络系统及安全认证方法。其中，网络系统包括安全客户端、安全服务器、第一鉴权管理模块、第二鉴权管理模块和授权管理模块；所述安全客户端分别与所述第一鉴权管理模块和安全服务器连接；所述安全服务器分别与所述第二鉴权管理模块和授权管理模块连接；所述第一鉴权管理模块用于对安全服务器的证书和身份进行验证；所述第二鉴权管理模块用于对安全客户端的证书和身份进行验证，通过授权管理模块对通过认证的安全客户端进行访问权限的控制。本发明的安全体系架构和方法针对数据泄露和数据篡改问题，提供数据的完整性保护和私密性保护，以及对通信实体的身份鉴别和授权。

说明书

技术领域

本发明属于通信网络安全领域，尤其涉及一种应用于全IP 远程监控网络系统及安全认证方法。

背景技术

随着互联网和宽带技术的发展，基于IP网络技术的应用在 企业网和公共网络中得到了越来越多的应用。由于IP网络的开 放性，网络技术存在着一些安全性问题，例如账户欺骗、设备欺 骗、信息泄露和窃取等。针对这些问题系统设备需要对相关“用 户”的身份进行验证，以防止由于欺骗而造成的用户信息被窃取。

由于上述通信网络安全问题日益严重，通信网络信息安全技术的 研究已成为目前研究和发展的热点。现有的网络身份识别方法是一般 是通过用户名和密码，这种方法比较简单，对于一般的安全性要求可 以满足；但是对于安全要求性比较高和需要建立不可抵赖性应用的情 况下，这种方法却无法满足。

为了解决上述问题，业界采用数字证书逐渐成为新的发展趋势。 此技术通过第三方的CA认证来鉴别用户身份，使交易双方能够建立 信用关系，且用数字签名来保证记录的不可抵赖性。数字证书通过国 际电信联盟的标准来保证互通性。

发明内容

针对背景技术中提到的目前通信网络安全问题日益严重，现有 的网络身份识别方法简单，对于一般的安全性要求可以满足；但 是对于安全要求性比较高和需要建立不可抵赖性应用的情况下 无法满足的问题，本发明提出了一种应用于全IP远程监控网络系 统及安全认证方法。

一种应用于全IP远程监控网络系统，其特征在于，所述系统包 括安全客户端、安全服务器、第一鉴权管理模块、第二鉴权管理 模块和授权管理模块；

其中，所述安全客户端分别与所述第一鉴权管理模块和安全 服务器连接；所述安全服务器分别与所述第二鉴权管理模块和授 权管理模块连接；

所述第一鉴权管理模块用于对安全服务器的证书和身份进 行验证；所述第二鉴权管理模块用于对安全客户端的证书和身份 进行验证，通过授权管理模块对通过认证的安全客户端进行访问 权限的控制。

所述安全客户端配置有建立HTTP通信连接所需的URI形式 的位置标识，以及预先配置好的X.509证书；所述X.509证书的 SAN作为鉴权和授权时的身份标识。

所述安全服务器配置有建立HTTP通信连接所需的URI形式 的位置标识，以及预先配置好的X.509证书；所述X.509证书的 SAN作为鉴权和授权时的身份标识。

所述安全客户端和安全服务器支持TLS协议。

所述安全客户端内嵌上层应用客户端模块TLS Client。

所述安全服务器内嵌上层应用服务器模块TLS Server。

所述系统还包括第一接口、第二接口和第三接口；所述第一 接口运行TLS标准协议，安全客户端与安全服务器通过第一接口 进行TLS的握手过程；所述第二接口运行鉴权协议，安全客户端 和安全服务器分别通过第二接口与第一鉴权管理模块和第二鉴 权管理模块进行实体通信，实现对通信对端的身份验证和证书验 证；所述第三接口运行访问控制协议，安全服务器通过第三接口 与授权管理模块通信，实现对安全客户端请求的权限判定。

一种应用于全IP远程监控网络系统的安全认证方法，其特征在 于，所述方法具体包括步骤：

步骤1：安全客户端扫描上层应用客户端模块，检测是否有 来自上层应用客户端模块的业务发起请求；如果是，则执行步骤 2；否，则保持原来状态，继续扫描上层应用客户端模块；

步骤2：安全客户端启动内嵌的上层应用客户端模块TLS  Client，发起TLS ClientHello消息，设定TLS定义的 ClientHello消息的扩展选项Extension，并为扩展类型 ExtensionType赋值来要求安全服务器对其证书签名，并提供经 过签名的X.509证书；

步骤3：安全客户端判断是否收到了经过签名的X.509证书； 若收到了签名的证书，则执行步骤4；若没有收到，则执行步骤 5；

步骤4：基于第一鉴权管理模块预置的信任锚列表对步骤3 中所接收的X.509证书进行验证，验证X.509证书是否由可信的 授权中心CA颁发；如果不是，执行步骤5；如果是，则执行步 骤6；

步骤5：根据失败原因，回送失败信息，同时返回步骤1保 持原状态；

步骤6：用X.509证书携带的公钥解密证书后的签名，验证 步骤3所接收的X.509证书的公钥是否与安全服务器签名所使用 的私钥匹配，若不匹配，则返回步骤5；若匹配，则执行步骤7；

步骤7：对安全服务器的标识进行验证；比较步骤3所接收 的证书的SAN域是否与安全服务器的位置标识URI匹配；

步骤8：根据步骤7标识验证的结果判断是否接入了正确的 服务器。若标识匹配，则通过了标识验证，执行步骤9；若未通 过标识验证，则返回步骤5；

步骤9：安全客户端将自己经过签名证书发送给安全服务器； 并向第二鉴权管理模块进行证书验证；

步骤10：安全客户端等待证书是否通过验证；若收到了安 全服务器发送的错误消息，则返回步骤5；若通过了证书验证， 则执行步骤11；

步骤11：安全客户端和安全服务器建立TLS握手，并判断 TLS握手过程是否成功；若收到了标志着成功的Finished消息， 则执行步骤12；若未收到，则返回步骤5；

步骤12：安全客户端发送上层应用业务请求；

步骤13：安全客户端等待对端进行访问权限的判断；若通 过访问控制验证，则执行步骤14；若未通过，则返回步骤5；

步骤14：上层应用的业务执行过程；

步骤15：上层应用的业务成功执行后，返回步骤1保持扫 描上层应用客户端模块状态。

所述标识包括E-Mail形式、FQDN、IPv4地址和IPv6地址。

步骤7中，对安全服务器的标识进行验证的过程为：

对于FQDN、IPv4地址或IPv6地址形式的身份标识，直接与 安全服务器的位置标识的主机部分比较，若匹配则认为通过标识 验证；

对于E-mail形式的身份标识，预先配置绑定信息列表，其 中的绑定表项为E-Mail形式的身份标识、URI形式的位置标识 和该绑定关系的合法存续时间组成的三元组；若在绑定合法存续 时间之内，E-mail形式的身份标识在绑定信息列表中所对应的 URI形式的位置标识，与提供证书的安全服务器的位置标识一致， 则认为通过标识验证。

本发明的效果在于，针对基于全IP网络进行的远程通信过 程，通过为安全客户端和安全服务器之间的通信过程提供完整性 保护和私密性保护，以及对安全客户端和安全服务器提供身份认 证和授权控制，保证了全IP远程监控网络通信过程的安全可靠。

附图说明

图1是本发明提供的安全体系架构图；

图2是本发明提供的信令流程图；

图3是本发明提供的鉴权管理实体的结构图；

图4是本发明提供的安全体系的软件架构和接口；

图5是本发明提供的安全客户端的操作流程图；

其中，1-鉴权管理模块。

具体实施方式

下面结合附图，对优选实施例作详细说明。应该强调的是下述说 明仅仅是示例性的，而不是为了限制本发明的范围及其应用。

图1为本发明提供的安全体系架构图。支持全IP通信网络 客户端-服务器通信模式下的安全体系架构基于HTTP组网，包括 的网络实体有：安全客户端、安全服务器、鉴权管理实体、授权 管理实体。安全客户端内置TLS Client功能，配置有建立HTTP 通信连接所需的URI形式的位置标识，以及经过可信授权中心签 发的X.509证书，对应的SAN域携带有E-mail形式、IPv4地址 形式、IPv6地址形式或是FQDN形式的标识。安全服务器内置有 TLS Server功能，配置有建立HTTP通信连接所需的URI形式的 位置标识，以及经过可信授权中心签发的X.509证书，对应的 SAN域携带有E-mail形式、IPv4地址形式、IPv6地址形式或是 FQDN形式的标识。安全客户端与鉴权管理实体连接，可以对安 全服务器的证书和身份进行验证。安全服务器与鉴权管理实体连 接和授权管理实体连接，通过鉴权管理实体对安全客户端的证书 和身份进行验证，通过授权管理实体对通过认证的安全客户端进 行访问权限的控制。

图2为本发明提供的信令流程图。安全客户端与安全服务器 之间的通信过程需要与鉴权管理实体和授权管理实体之间的交 互，分为TLS会话建立和上层应用消息交互两个部分。TLS会话 建立过程逻辑上分为TLS握手和认证两部分。TLS握手过程遵循 标准的RFC5246标准，安全客户端首先向安全服务器发送HELLO 消息，设置Extension选项，并将Extension Type设置为13， 要求安全服务器对其证书签名。安全服务器返回X.509证书，并 附上签名。安全服务器同时发送Certificate Request消息，要 求安全客户端发送其证书。安全客户端收到安全服务器的经过签 名的证书后，与鉴权管理实体进行证书验证和身份验证。若通过 这两次验证，安全服务器将自己的证书经过签名发送至安全服务 器，由安全服务器向鉴权管理实体进行证书验证。若安全客户端 通过验证，则结束TLS握手过程。此时在安全客户端和安全服务 器之间建立了一条安全传输的通道。

上层应用消息交互承载业务信息。安全客户端发起请求消 息，安全服务器向授权管理实体验证安全客户端是否具有相应的 权限。若通过授权验证，则可选的进行身份验证。通过后安全服 务器向安全客户端提供相应的响应消息。

图3为本发明提供的鉴权管理实体的结构图。鉴权管理实体 维护着信任锚列表和绑定信息列表。信任锚列表用于对X.509证 书的验证，由一串<证书，签名>二元组构成。证书指由授权中心 CA颁发的X.509证书，签名时授权中心CA的签名。安全服务器 通过信任锚列表对安全客户端进行证书验证，安全客户端通过信 任锚列表对安全服务器进行证书验证。

绑定信息列表用于对安全服务器进行身份验证，由<身份标 识，位置标识，有效时间>三元组条目构成。若安全服务器的X.509 证书的身份标识为E-mail形式时，安全客户端通过绑定信息列 表对安全服务器进行身份验证。

图4为本发明提供的安全体系的软件架构和接口。安全客户 端内嵌上层应用客户端，安全服务器内嵌上层应用服务器。安全 客户端与安全服务器通过第一接口进行TLS的握手过程，在该过 程中，安全客户端充当TLS Client，安全服务器充当TLS Server， 第一接口运行TLS标准协议。安全客户端和安全服务器通过第二 接口与鉴权管理实体通信，实现对通信对端的身份验证和证书验 证。在该过程中，安全客户端和安全服务器充当客户端，鉴权管 理实体充当服务器，第二接口可运行各种鉴权协议。安全服务器 通过第三接口与授权管理实体通信，实现对安全客户端请求的权 限判定。在该过程中，安全服务器充当客户端，授权管理实体充 当服务器，第三接口可运行各种访问控制协议方法。安全客户端 与安全服务器之间通过内嵌的上层应用客户端与上层应用服务 器实现由TLS提供安全保护的上层应用消息交互。

图5为本发明提供的的安全客户端的操作流程图，包括以下 步骤：

步骤1-1：扫描上层应用端口，检测是否有来自上层应用的 业务发起请求；

步骤1-2：根据扫描结果，判断是否有上层应用的业务发起 请求。若没有检测到，则返回步骤1-1保持原来状态，继续扫描 上层应用端口；如果检测到有来自上层应用的业务发起请求，则 执行步骤1-3；

步骤1-3：安全客户端启动内嵌的TLS客户端，发起TLS  ClientHello，并通过设置扩展类型ExtensionType=13来要求对 端提供经过签名的证书；

步骤1-4：判断是否收到了经过签名的X.509证书。若没有 收到，则执行步骤1-6；若收到了签名的证书，则执行步骤1-5；

步骤1-5：对步骤1-4中所接收的证书进行验证。基于信任 锚列表，验证X.509证书是否由可信的授权中心CA颁发；

步骤1-6：根据失败原因，回送失败信息，同时返回步骤1-1 保持原状态；

步骤1-7：判断步骤1-4所接收的证书是否可信。若不可信， 则执行步骤1-6；若证书可信，则执行步骤1-8；

步骤1-8：验证步骤1-4所接收的证书的公钥是否与通信对 端的签名所使用的私钥匹配，用证书携带的公钥解密证书后的签 名；

步骤1-9：根据用证书携带的公钥是否能正确解密签名判断 服务器的私钥是否正确。若不正确，则执行步骤1-6；若能正确 解密，则执行步骤1-10；

步骤1-10：对通信对端的标识进行验证。比较步骤1-4所 接收的证书的SAN域是否与对端的位置标识URI匹配。对于 E-mail形式的SAN域，查询绑定信息列表进行标识验证；

步骤1-11：根据标识验证的结果判断是否接入了正确的服 务器。若标识匹配，则通过了标识验证，执行步骤1-12；若未 通过标识验证，则执行步骤1-6；

步骤1-12：安全客户端将证书发送给通信对端；

步骤1-13：安全客户端等待证书是否通过验证的结果。若 收到了对端发送的错误消息，则执行步骤1-6；若通过了证书验 证，则执行步骤1-14；

步骤1-14：判断TLS握手过程是否成功。若收到了标志着 成功的Finished消息，则执行步骤1-15；若未收到，则执行步 骤1-6；

步骤1-15：安全客户端发送上层应用业务请求；

步骤1-16：安全客户端等待对端进行访问权限的判断。若 通过访问控制验证，则执行步骤1-17；若未通过，则执行步骤 1-6；

步骤1-17：上层应用的业务执行过程；

步骤1-18：业务成功执行后，返回步骤1-1保持扫描上层 应用端口的状态。

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