CN114884667A - 一种通信鉴权方法、设备及存储介质 - Google Patents
一种通信鉴权方法、设备及存储介质 Download PDFInfo
- Publication number
- CN114884667A CN114884667A CN202110163146.8A CN202110163146A CN114884667A CN 114884667 A CN114884667 A CN 114884667A CN 202110163146 A CN202110163146 A CN 202110163146A CN 114884667 A CN114884667 A CN 114884667A
- Authority
- CN
- China
- Prior art keywords
- message
- signature
- information
- gateway
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 84
- 238000004891 communication Methods 0.000 title claims abstract description 33
- 238000004806 packaging method and process Methods 0.000 claims abstract description 4
- 230000006870 function Effects 0.000 claims description 117
- 230000008569 process Effects 0.000 claims description 13
- 238000004458 analytical method Methods 0.000 claims description 11
- 238000004590 computer program Methods 0.000 claims description 10
- 238000012544 monitoring process Methods 0.000 claims description 9
- 238000013475 authorization Methods 0.000 claims description 2
- 230000011664 signaling Effects 0.000 description 42
- 238000010586 diagram Methods 0.000 description 28
- 230000007246 mechanism Effects 0.000 description 24
- 238000012545 processing Methods 0.000 description 13
- 238000003780 insertion Methods 0.000 description 11
- 230000037431 insertion Effects 0.000 description 11
- 230000003993 interaction Effects 0.000 description 6
- 238000013461 design Methods 0.000 description 5
- 238000011160 research Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000012795 verification Methods 0.000 description 4
- 238000013507 mapping Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 230000002093 peripheral effect Effects 0.000 description 3
- 238000005538 encapsulation Methods 0.000 description 2
- 101000823100 Homo sapiens Putative alpha-1-antitrypsin-related protein Proteins 0.000 description 1
- 102100022709 Putative alpha-1-antitrypsin-related protein Human genes 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种通信鉴权方法、设备及存储介质,包括:UE向Headend发出第一报文;接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;向网关节点发送第二报文。Headend获取第一报文中携带的网关ID和网关的私钥签名,使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的信息是可信任的信息;使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息。网关节点接收UE发送的第二报文;根据SRv6的代理签名FUNCT和/或密钥确认UE的信息可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend。采用本发明,能够使得APP与Headend,在网关节点的协助下,更容易建立互信关系。
Description
技术领域
本发明涉及无线通信技术领域,特别涉及一种通信鉴权方法、设备及存储介质。
背景技术
“网络可编程”是未来网络的一个重要发展趋势。在网络可编程的环境中,网络支持对于业务需求的感知,以实现更好的服务提供。但是,网络可编程目前缺乏成熟的安全保障相关的机制。
在传统的安全机制中,安全保障机制一般用在点到点的通信上,用于保护一些相对开放的环境下的通信,例如4G、WiFi的空口,或者通过IPSec(因特网协议安全,InternetProtocol Security)做E2E(端到端,End to End)的安全保障。
但现有技术的不足在于,现有的网络设计和安全机制下,APP不容易与网络节点建立互信关系。
发明内容
本发明提供了一种通信鉴权方法、设备及存储介质,用以解决现有的安全机制下APP不容易与节点建立互信关系的问题。
本发明提供以下技术方案:
一种通信鉴权方法,包括:
UE向Headend发出第一报文;
UE接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;
UE向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数。
实施中,所述第二报文中进一步包含有用以供网关节点判断报文可信性的使用与网关节点约定的密钥做的签名。
实施中,所述的第一报文是APN报文,和/或,第二报文是APN报文。
实施中,所述UE进行报文的可信性判断,包括:
UE接收网络侧发送的包含有Headend ID以及签名的信息;
UE使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,确定来自该网络侧的报文携带的信息是可信任的信息。
实施中,Headend ID及其对应的公钥是通过网关节点和/或AAA获得的。
实施中,所述SRv6的FUNCT从网关获取的。
一种通信鉴权方法,包括:
Headend接收UE发出的第一报文;
Headend解析所述第一报文,获取其中携带的网关ID和网关的私钥签名,Headend使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的信息是可信任的信息;
Headend向网络转发第一报文;
Headend接收UE发出的第二报文;
Headend使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息;
Headend向网络转发第二报文。
实施中,所述的第一报文是APN报文,和/或,第二报文是APN报文。
实施中,进一步包括:
根据第一报文中的要求在第一报文中插入信息,并进行签名。
实施中,签名时,进一步包括:
加入Headend自己的ID。
一种通信鉴权方法,包括:
网关节点接收UE发送的第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
网关节点根据SRv6的代理签名FUNCT和/或密钥确认UE的信息是否是可信任的信息,在可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend。
实施中,所述第二报文中进一步包含有用以供网关节点判断报文可信性的使用UE与网关节点约定的密钥做的签名。
实施中,所述的第二报文是APN报文。
实施中,进一步包括:
对报文进行监控,在判断包含Headend签名,且要求网关进行验证时,进行解析和验证签名。
实施中,进一步包括:
接收到网络侧发送信息后,使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,转发至UE。
实施中,网关节点根据SRv6的代理签名FUNCT和/或密钥确认UE是否可信,在可信时,进一步包括:
将报文转发到预定的IPSec。
实施中,将报文转发到预定的IPSec,是根据第二报文中的参数确定预定的IPSec的。
一种用户设备,包括:
处理器,用于读取存储器中的程序,执行下列过程:
向Headend发出第一报文;
接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;
向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
收发机,用于在处理器的控制下接收和发送数据。
实施中,所述第二报文中进一步包含有用以供网关节点判断报文可信性的使用与网关节点约定的密钥做的签名。
实施中,Headend ID及其对应的公钥是通过网关节点和/或AAA获得的。
实施中,所述的第一报文是APN报文,和/或,第二报文是APN报文。
实施中,所述UE进行报文的可信性判断,包括:
UE接收网络侧发送的包含有Headend ID以及签名的信息;
UE使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,确定来自该网络侧的报文携带的信息是可信任的信息。
实施中,Headend ID及其对应的公钥是通过网关节点和/或AAA获得的。
实施中,所述SRv6的FUNCT从网关获取的。
一种用户设备,包括:
UE发送模块,用于向Headend发出第一报文;
UE接收模块,用于接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;
UE发送模块,用于向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数。
实施中,所述第二报文中进一步包含有用以供网关节点判断报文可信性的使用与网关节点约定的密钥做的签名。
实施中,所述的第一报文是APN报文,和/或,第二报文是APN报文。
实施中,UE接收模块进一步用于在所述UE进行报文的可信性判断时,包括:
接收网络侧发送的包含有Headend ID以及签名的信息;
使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,确定来自该网络侧的报文携带的信息是可信任的信息。
实施中,进一步包括:
UE获取模块,用于通过网关节点和/或AAA获得Headend ID及其对应的公钥。
实施中,进一步包括:
UE获取模块,用于从网关获取所述SRv6的FUNCT。
一种网络节点,包括:
处理器,用于读取存储器中的程序,执行下列过程:
接收UE发出的第一报文;
解析所述第一报文,获取其中携带的网关ID和网关的私钥签名,使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的信息是可信任的信息;
向网络转发第一报文;
接收UE发出的第二报文;
使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息;
向网络转发第二报文;
收发机,用于在处理器的控制下接收和发送数据。
实施中,进一步包括:
根据第一报文中的要求在第一报文中插入信息,并进行签名。
实施中,签名时,进一步包括:
加入Headend自己的ID。
一种网络节点,包括:
Headend接收模块,用于接收UE发出的第一报文;
Headend解析模块,用于解析所述第一报文,获取其中携带的网关ID和网关的私钥签名,使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的信息是可信任的信息;
Headend发送模块,用于向网络转发第一报文;
Headend接收模块,用于接收UE发出的第二报文;
Headend解析模块,用于使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息;
Headend发送模块,用于向网络转发第二报文。
实施中,Headend解析模块进一步用于根据第一报文中的要求在第一报文中插入信息,并进行签名。
实施中,Headend解析模块进一步用于签名时,加入Headend自己的ID。
一种网关节点,包括:
处理器,用于读取存储器中的程序,执行下列过程:
接收UE发送的第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
根据SRv6的代理签名FUNCT和/或密钥确认UE的信息是否是可信任的信息,在可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend;
收发机,用于在处理器的控制下接收和发送数据。
实施中,所述第二报文中进一步包含有用以供网关节点判断报文可信性的使用UE与网关节点约定的密钥做的签名。
实施中,所述的第二报文是APN报文。
实施中,进一步包括:
对报文进行监控,在判断包含Headend签名,且要求网关进行验证时,进行解析和验证签名。
实施中,进一步包括:
接收到网络侧发送信息后,使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,转发至UE。
实施中,根据SRv6的代理签名FUNCT和/或密钥确认UE是否可信,在可信时,进一步包括:
将报文转发到预定的IPSec。
实施中,将报文转发到预定的IPSec,是根据第二报文中的参数确定预定的IPSec的。
一种网关节点,包括:
网关节点接收模块,用于接收UE发送的第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
网关节点解析模块,用于根据SRv6的代理签名FUNCT和/或密钥确认UE的信息是否是可信任的信息,在可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend。
实施中,所述第二报文中进一步包含有用以供网关节点判断报文可信性的使用UE与网关节点约定的密钥做的签名。
实施中,所述的第二报文是APN报文。
实施中,网关节点解析模块进一步用于对报文进行监控,在判断包含Headend签名,且要求网关进行验证时,进行解析和验证签名。
实施中,网关节点解析模块进一步用于接收到网络侧发送信息后,使用与HeadendID对应的公钥对信息中的签名进行解析,若签名正确,转发至UE。
实施中,网关节点解析模块进一步用于根据SRv6的代理签名FUNCT和/或密钥确认UE是否可信,在可信时,将报文转发到预定的IPSec。
实施中,网关节点解析模块进一步用于根据第二报文中的参数将报文转发到预定的IPSec的。
一种计算机可读存储介质,所述计算机可读存储介质存储有执行上述通信鉴权方法的计算机程序。
本发明有益效果如下:
在本发明实施例提供的技术方案中,由于采用了用户网关向UE通告相关的SRv6FUNCT,允许用户进行相关的代理签名功能调用,因此能够使得网关节点更容易与APP建立互信关系,也更容易与Headend建立互信关系。
进一步的,对于网关节点,网关节点将用自己的公钥做签名写在报文中,由网关节点替代Headend做每流的识别,Headend只需跟BRAS做一些交互,不用做每流的识别,提供了方案的可扩展性,因此解决了下述问题1:在中间节点不适合感知到每流的状态。
进一步的,由于UE收到了包含网络侧信息的反馈信息,使用对应的公钥进行签名的解析,确认签名正确,则信任这个或这些网络侧的信息,因此解决了下述问题2:APP需要能够相信中间节点提供的信息,识别假冒信息。
进一步的,由于Headend收到报文后,验证相关签名,确认流量可信即可转发,因此解决了下述问题3:中间节点需要信任APP,识别假冒的APP。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本发明的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1为本发明实施例中UE侧上的通信鉴权方法实施流程示意图;
图2为本发明实施例中Headend侧上的通信鉴权方法实施流程示意图;
图3为本发明实施例中网关节点侧的通信鉴权方法实施流程示意图;
图4为本发明实施例中实施例1中的基于BRAS代理的APN安全互信机制下的鉴权流程示意图;
图5为本发明实施例中实施例2中的基于BRAS代理的APN安全互信机制下的鉴权流程示意图;
图6为本发明实施例中实施例3中的基于BRAS代理的APN安全互信机制下的鉴权流程示意图;
图7为本发明实施例中实施例4中的基于BRAS代理的APN安全互信机制下的鉴权流程示意图;
图8为本发明实施例中sub TLV(Signing TLV)结构示意图1;
图9为本发明实施例中TLV结构示意图2;
图10为本发明实施例中UE结构示意图;
图11为本发明实施例中网络节点结构示意图;
图12为本发明实施例中网关节点结构示意图。
具体实施方式
发明人在发明过程中注意到:
下面对APN(应用感知网络,Application-aware Networking)机制与PANRG(路径感知网络研究小组,Path Aware Networking Research Group)的相关研究进行简要说明。
PANRG(Path Aware Networking)是IRTF(互联网研究专门工作组,InternetResearch Task Force)的一个研究组,在研究网络信息通告给APP(应用程序,Application),以及APP的相关的路径选择等机制。APN机制与PANRG思路存在如下区别:
区别1:APN希望在IP层来执行相关的信息交互,更为底层;PANRG目前的计划是在传输层做,实现上更加上层,但同时做了很多相关技术的调研,而这些相关技术不局限在传输层。
区别2:APN机制目前还比较初步,没做太多的安全隐私方面的考虑,直接提出了一种在IPv6头插入信息的解决方案,PANRG的思路是先考虑所有的问题,再稳步推进,目前并没有给出相关的解决方案。
原本的TCP/IP(传输控制协议/互联网协议,Transmission Control Protocol/Internet Protocol)四层架构中,APP不需要感知底层路径,知道Server(服务器)的IP即可。PANRG认为这种跨层设计的思路(让APP感知到底层路径信息)中存在的一些问题,其中的几个包括:
问题1:在中间节点不适合感知到每流的状态。
这是为了减轻中间节点的转发压力,让中间节点仅仅根据DA(目的地址,Destination Address)执行Packet(包)的转发即可,并不需要识别这些Packet属于那个流,即执行Per-packet(逐包)的操作,而不是Per-flow(逐流)的操作。
问题2:APP需要能够相信中间节点提供的信息,识别假冒信息。
避免APP收到了其他的假冒的网络信息,而是仅收到和认可可信的节点发来的网络信息,例如通过签名的方式。
问题3:中间节点需要信任APP,识别假冒的APP。
避免其他假冒的APP发送仿冒的流量。
目前的APN的机制涉及到的APN中的网元:Mapping(映射)节点,即网络的Headend(头端)。
映射节点需要按照APN packet的业务需求(携带在IPv6报文头中),给出网络侧的应对。
映射节点的安全需求:需要跟APP建立信任,1、APP相信Headend提供的信息(前述问题2),2、Headend能确定APP的可信(前述问题3)。
涉及到的APN中的另一个网元:APP,或Client(客户端)节点(终端用户/设备/应用),在实施例中其他地方也被称为UE(用户设备)。
APP需要支持APN报文的封装,向网络提出要求。
APP的安全需求:需要跟Headend建立信任,1、APP相信Headend提供的信息,2.Headend能确定APP的可信。
这种跨层设计带来的问题:Headend节点是一个转发节点,传统IP网络中作为L3(层3)中间节点,跟APP没有太大的关系。
目前的TCP/IP四层架构中(一层是物理层,二层是链路层,三层是IP层,四层是传输层),网络节点仅负责按照IP地址提供连通性/可达性,不感知上层APP的详细信息,一方面这是由于这样做有利于网络节点的简单性和可扩展性,即不需要在网络节点感知每个用户会话,另一方面是为了保障用户隐私,既不需要要网络节点感知到用户的相关信息。
现有TCP/IP架构中,APP不感知底层路径,仅仅通过四层,感知对端的Server,不感知底层中转节点,不需要对底层节点的信任关系,只需要整体上感知底层网络能够提供连通(因此这里认为APN的设计方式是一种跨层设计)。
Headend本身也不适合感知到APP层次的信息,感知每应用流的状态(见前述的问题1)。
基于此,本发明实施例中将提供一种通信鉴权方案,使得通过网关节点(例如固定网络的BRAS(宽带接入服务器)或者移动网络的UPF(用户面功能,User Plane Function)),APP与Headend更容易建立互信关系。
下面结合附图对本发明的具体实施方式进行说明。
在说明过程中,将分别从UE(用户设备,User Equipment)与Headend、网关节点侧的实施进行说明,然后还将给出它们配合实施的实例以更好地理解本发明实施例中给出的方案的实施。这样的说明方式并不意味着它们必须配合实施、或者必须单独实施,实际上,当它们分开实施时,其也各自解决自身一侧的问题,而它们结合使用时,会获得更好的技术效果。
图1为UE侧上的通信鉴权方法实施流程示意图,如图所示,可以包括:
步骤101、UE向Headend发出第一报文;
步骤102、UE接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;
步骤103、UE向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数。
实施中,所述第二报文中还可以包含有用以供网关节点判断报文可信性的使用与网关节点约定的密钥做的签名。
具体的,UE向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性的APN签名代理的SRv6的FUNCT(函数),可选的,所述第二报文中还可以包含有用以供网关节点判断报文可信性的使用与网关节点约定的密钥做的签名。
实施中,所述的第一报文是APN报文,和/或,第二报文是APN报文。
实施中,Headend ID及其对应的公钥是通过网关节点和/或AAA获得的,如携带在EAP Request/Notification消息中。
实施中,所述UE进行报文的可信性判断,包括:
UE接收网络侧发送的包含有Headend ID以及签名的信息;
UE使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,确定来自该网络侧的报文携带的信息是可信任的信息。
一种可行的方案中,可以由BRAS代理验证签名的方案(将在实施例2、实施例4中进行说明),该方案并不需要UE验证签名。
实施中,Headend ID及其对应的公钥是通过网关节点和/或AAA获得的。
具体的,UE上需要启动APN packet的通信,可以事先通过网关和/或AAA得到一个或多个Headend的ID和对应的公钥。
或者,通过其他方式得到Headend的ID和公钥。
实施中,所述SRv6的FUNCT从网关节点获取的,如携带在EAP Request/Notification消息中。
具体实施中,所述SRv6的FUNCT是END.APN_Signing_Proxy函数。
具体的,UE上需要启动安全的APN packet的通信,可以事先通过网关,得到网关的一个SRv6(SR:段路由,Segment Routing,v6是指IPv6)的FUNCT(函数),例如END.APN_Signing_Proxy(终点.APN_签名_代理)函数。
图2为Headend侧上的通信鉴权方法实施流程示意图,如图所示,可以包括:
步骤201、Headend接收UE发出的第一报文;
步骤202、Headend解析所述第一报文,获取其中携带的网关ID和网关的私钥签名,Headend使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的第一报文是可信任的信息;
具体的,Headend解析所述第一报文,得到其中携带的例如BRAS ID和BRAS的私钥签名,Headend使用与BRAS ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE发出的第一报文的信息是可信任的信息;
步骤203、Headend向网络转发第一报文;
步骤204、Headend接收UE发出的第二报文;
步骤205、Headend使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息;
具体的,Headend解析上述第二报文,得到其中携带的BRAS ID和BRAS的私钥签名,Headend使用与BRAS ID对应的公钥对信息中的签名进行验证,若签名正确,确定第二报文是可信任的信息;
步骤206、Headend向网络转发第二报文。
实施中,所述的第一报文是APN报文,和/或,第二报文是APN报文。
实施中,还可以进一步包括:
根据第一报文中的要求在第一报文中插入信息,并进行签名。
具体实施中,签名时,进一步包括:
加入Headend自己的ID。
具体的,可以在UE发出APN packet,Headend收到后,做对应的处理,例如,要求插入信息,则插入,并进行签名。
签名时,同时加入自己的ID,例如自己的一个全网唯一的名字。
图3为网关节点侧的通信鉴权方法实施流程示意图,如图所示,可以包括:
步骤301、网关节点接收UE发送的第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
步骤302、网关节点根据代理签名SRv6的FUNCT和/或密钥确认UE的信息是否是可信任的信息,在可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend。
实施中,所述第二报文中还可以包含有用以供网关节点判断报文可信性的使用UE与网关节点约定的密钥做的签名。
实施中,所述的第二报文是APN报文。
实施中,还可以进一步包括:
对报文进行监控,在判断包含Headend签名,且要求网关进行验证时,进行解析和验证签名。
具体的,对APN packet进行监控,在包含Headend签名时,进行解析。网关节点可以支持报文的监控,看到包含Headend签名的报文,主动进行解析,具体方式例如是:网络侧(例如Headend)反馈的报文中有要求网关验证网络侧签名的标识(例如报文中包含有一个新的APN服务参数Service Para.等)。
实施中,还可以进一步包括:
接收到网络侧发送信息后,使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,转发至UE。
具体的,网关节点收到了包含网络侧信息的反馈信息时,可以使用对应的公钥进行签名的解析,确认签名正确后,再转发报文给UE,UE会信任这个或这些网络侧的信息。
实施中,网关节点根据SRv6的代理签名FUNCT和/或密钥确认UE是否可信,在可信时,还可以进一步包括:
将报文转发到预定的IPSec。
具体实施中,将报文转发到预定的IPSec,是根据第二报文中的参数确定预定的IPSec的。
具体的,网关节点收到之后执行函数,确认UE可信,按照参数,例如Headend ID,将报文转发到特定IPSec。
网关节点根据报文的参数,决定转发到哪个IPsec,如果没有参数(例如参数部分为0),则正常转发,不将报文转发到IPSec。
下面主要以BRAS(宽带远程接入服务设备,Broadband Remote Access Server)的实例进行说明。
先对实施例进行简要说明。
在实施例1中,client发送的报文,没有Signing TLV,到BRAS,加入了Signing TLV(其中包含了BRAS ID,以及BRAS的签名,TLV的Flag的部分后两位为00,代表请求headend验证签名),Headend解析签名之后,可能会写入一些信息,此时Headend删掉原来的SigningTLV(00),写入新的Signing TLV(其中包含了Headend ID,以及Headend的签名,TLV的Flag的部分后两位为01,代表请求Client/UE验证签名),client收到之后,进行验证解析。
在实施例2中,client发送的报文,没有Signing TLV,到BRAS,加入了Signing TLV(00),Headend解析签名之后,可能会写入一些信息,此时headend删掉原来的Signing TLV(00),写入新的Signing TLV(其中包含了Headend ID,以及Headend的签名,TLV的Flag的部分后两位为11,代表请求网关验证签名),网关收到之后,进行验证解析,如果通过,可选删掉原来的Signing TLV(11),之后转给client。
在实施例3中,client发送的报文,有Signing TLV(其中不包含ID或者签名信息,或者包含ID信息,但是为空,TLV的Flag的部分后两位为10),其目的是向Headend请求HeadendID,BRAS也不插入签名,headend解析到了Signing TLV(10),会写入一些信息,此时headend删掉原来的Signing TLV(10),写入新的Signing TLV(01),client收到之后,进行验证解析,学习到HeadendID,后续的这个流的报文中,可以携带这个HeadendID,BRAS根据这个信息,进入特定的IPSec,执行签名操作,发给headend。
在实施例4中,client发送的报文,有Signing TLV(10),其目的是请求HeadendID,但是此时并不含有签名信息,BRAS也不插入签名,headend解析到了Signing TLV(10),会写入一些信息,此时headend删掉原来的Signing TLV(10),写入新的Signing TLV(11),网关收到之后,进行解析和验证,如果通过,不删掉原来的Signing TLV(11),之后转给client,client收到之后,进行解析,学习到HeadendID,后续的这个流的报文中,可以携带这个HeadendID,BRAS根据这个信息,进入特定的IPSec。
实施例1
图4为实施例1中的基于BRAS代理的APN安全互信机制下的鉴权流程示意图,如图所示,可以按如下方式实施。
前提1:网关与Headend之间建立有互信关系。
它们各自有用于签名的公钥私钥,并且有相关的公钥的交互机制。
前提2:由于UE上需要启动APN packet的通信,可以事先通过网关和/或AAA(验证、授权和计费服务器,Authentication,Authorization and Accounting)得到一个或多个headend的ID+公钥。
或者,通过其他方式得到headend的ID和公钥。
前提3:由于UE上需要启动安全的APN packet的通信,可以事先通过网关,得到网关的一个SRv6的FUNCT,例如END.APN_Signing_Proxy函数。
这个函数中,网关操作可以包括:
需要判断报文的可信性(可以替Headend做每流的识别,可选的,UE在APN packet中根据UE与BRAS的Session(会话)密钥做签名),之后,会继续转发报文,并且BRAS用自己的公钥做签名写在packet中(BRAS替代Headend做每流的识别,Headend只需跟BRAS做一些交互,不用做每流的识别,提供了方案的可扩展性,解决了问题1。
在上述前提下,实施流程可以如下:
1:UE发出APN packet,Headend收到后,做对应的处理,如果要求插入信息,则插入,并进行签名。
签名时,可以同时加入自己的ID,例如自己的一个全网唯一的名字。
2:UE收到了包含网络侧信息的反馈信息,使用对应的公钥进行签名的解析,确认签名正确,则信任这个或这些网络侧的信息,解决了问题2。
3:UE封装新的APN packet,并且封装END.APN_Signing_Proxy的SRv6 FUNCT,BRAS收到后,执行函数,确认UE可信,封装自己的签名。
4:Headend收到这个packet,验证相关签名,确认流量可信,转发。解决了问题3。
实施例2
图5为实施例2中的基于BRAS代理的APN安全互信机制下的鉴权流程示意图,如图所示,可以按如下方式实施。
本例中,将引入BRAS解封验证实施。
前提1:网关与Headend之间建立有互信关系。
它们各自有用于签名的公钥私钥,并且有相关的公钥的交互机制。
网关支持报文的监控,监控到包含Headend签名的报文时,主动进行解析,具体方式例如是:反馈的报文中有要求网关解封的标识(例如有一个新的APN service para.封装,即前述的Signing TLV(11),具体可以见下述)。
前提2:由于UE需要启动安全的APN packet的通信,所以可以事先通过网关,得到网关的一个SRv6的FUNCT,END.APN_Signing_Proxy函数。
这个函数中,网关操作可以包括:
需要判断报文的可信性(替Headend做每流的识别,可选的,UE在APN packet中根据UE与BRAS的session密钥做签名),之后,会继续转发报文,并且BRAS用自己的公钥做签名写在packet中。
可按如下流程实施:
1:UE发出APN packet,Headend收到后,做对应的处理,如果要求插入信息,则插入,并进行签名。
签名时,同时加入自己的ID,例如自己的一个全网唯一的名字。
2:BRAS收到了包含网络侧信息的反馈信息,使用对应的公钥进行签名的解析,确认签名正确,从而转发报文给UE,UE会信任这个或这些网络侧的信息
3:UE封装新的APN packet,并且封装END.APN_Signing_Proxy的SRv6 FUNCT,BRAS收到后,执行函数,确认UE可信,封装自己的签名。
4:Headend收到该APN packet,验证相关签名,确认流量可信,转发。
实施例3
图6为实施例3中的基于BRAS代理的APN安全互信机制下的鉴权流程示意图,如图所示,可以按如下方式实施。
本例中增加了IPSec+Args(参数)的实施。
前提1:网关与Headend之间建立有互信关系。
Headend有用于签名的公钥私钥,并且有相关的公钥的交互机制。
网关建立有到Headend的IPSec通道,支持报文的网关(BRAS)签名,IPSec也可以支持进行报文的加密。
前提2:由于UE上需要启动APN packet的通信,所以可以事先通过网关和/或AAA得到headend的ID+公钥。
或者,通过其他方式得到headend的ID和公钥。
前提3:由于UE上需要启动安全的APN packet的通信,所以可以事先通过网关,得到网关的一个SRv6的FUNCT,END.APN_Signing_Proxy2函数(这个函数与END.APN_Signing_Proxy的区别是携带一个headend ID的参数)。
这个函数中,网关可以判断报文的可信性(替Headend做每流的识别,可选的,UE可以在APN packet中根据UE与BRAS的session密钥做签名),之后,会继续转发报文,并且BRAS根据报文的参数,决定进入哪个IPsec,如果没有参数(例如,参数部分为0),则正常转发,不进入IPSec。
具体可以按如下流程实施:
1:UE发出APN packet,Headend收到后,做对应的处理,如果要求插入信息,则插入,并进行签名。
签名时,同时加入自己的ID,例如自己的一个全网唯一的名字。
一般至少会要求插入headend ID。
2:UE收到了包含网络侧信息的反馈信息,使用对应的公钥进行签名的解析,确认签名正确,从而信任这个或这些网络侧的信息。
3:UE封装新的APN packet,同时封装END.APN_Signing_Proxy2,BRAS收到之后执行函数,确认UE可信,按照参数,例如headend ID,进入特定IPSec。
4:Headend收到该packet,验证相关签名,确认流量可信,转发。
实施例4
图7为实施例4中的基于BRAS代理的APN安全互信机制下的鉴权流程示意图,如图所示,可以按如下方式实施。
本例中增加了BRAS解封的实施。
前提1:网关与Headend之间建立有互信关系。
Headend有用于签名的公钥私钥,并且有相关的公钥的交互。
网关建立有到Headend的IPSec通道,支持报文的BRAS签名。
网关支持报文的监控,看到包含Headend签名的报文,主动进行解析。
前提2:由于UE上需要启动安全的APN packet的通信,所以可以事先通过网关,得到网关的一个SRv6的FUNC,END.APN_Signing_Proxy2函数。
这个函数中,网关可以判断报文的可信性(替Headend做每流的识别,可选的,UE在APN packet中根据UE与BRAS的session密钥做签名),之后,会继续转发报文,并且BRAS根据报文的参数,决定进入哪个IPsec,如果没有参数,则正常转发,可以同时插入BRAS ID。
具体可以按如下流程实施:
1:UE发出APN packet,Headend收到后,做对应的处理,如果要求插入信息,则插入,并进行签名。
签名时,同时加入自己的ID,例如自己的一个全网唯一的名字。
2:BRAS收到了包含网络侧信息的反馈信息,使用对应的公钥进行签名的解析,确认签名正确,转发报文给UE,UE会信任这个或这些网络侧信息。
3:UE封装新的APN packet,并且封装END.APN_Signing_Proxy2的SRv6 FUNCT,BRAS收到之后,执行函数,确认UE可信,按照参数,例如headend ID,进入特定IPSec。
4:Headend收到该packet,验证相关签名,确认流量可信,转发。
下面对安全机制中的SRv6的END.APN_Signing_Proxy FUNCT以及END.APN_Signing_Proxy2 FUNCT的实施进行说明。
APN设计时,可以在IPv6包头中携带的相关的信息(IDs,SLAs(服务等级协议,Service Level Agreement)),有三个可选的位置Hop-by-Hop options header(Hop-by-Hop Options Header逐跳可选项头部;Hop-by-Hop指数据包经过的每跳路由器),DoH(Destination Options Header,目的地可选项头部),SRH(段路由头,Segment RoutingHeader),其中,在SRH中,APN的信息可以是在SID list(SID列表;SID:段标识符,SegmentIDentifier)中,可以是在option TLV(可选TLV;TLV:标签、长度、值,Tag、Length、Value)中,也可以是在一个SID的Args(Arguments,参数)中,在SRv6中,一个SID的格式可以是LOC:FUNCT的格式,其中,LOC代表Location地址,用于寻址,FUNCT代表Function函数,用于指明某种函数功能;另一种SID的格式是LOC:FUNCT:ARGS,这种格式中的ARGS从属于FUNCT,支持在执行函数时考虑特定的参数。
本发明实施例提供的技术方案中,通过现有的机制(例如EAP(可扩展的身份验证协议,Extensible Authentication Protocol)或DNS(域名系统,Domain Name System)或DHCP(动态主机配置协议,Dynamic Host Configuration Protocol)或SLAAC(无状态地址自动配置,Stateless address autoconfiguration)),用户网关向client(客户端)发送相关的SRv6 FUNCT,允许用户进行相关的代理签名功能调用。
SRv6 APN_Signing_Proxy FUNCT可以在网关被剥掉,例如作为一个单独的SRH头插入。
例如:终端访问Server的源目的地址是<E::,D::>,插入SRH头,则变为<E::,A1::00AC:0001><D::,A1::00AC:0001,SL=1>(第一个尖括号内是新的源目的地址,第二个尖括号是SRH中的SID list的内容,按照IPv6/SRv6的定义,这里的顺序是倒序的,并且有一个Segment Left的指针指向当前的SID);按照SRH的处理规则(即代理签名函数),到达网关后SL-1=0,替换DA后,这时可以剥掉SRH头,剩下的还是<E::,D::>。
SRv6 END.APN_Signing_Proxy FUNCT:
例如SRv6 END.APN_Signing_Proxy FUNCT是A1::00AC:0000,其中A1是网关的地址,00AC:0000是FUNCT,代表需要网关代理签名。
签名格式例如是在Option TLV中加入BRAS ID,以及256bits的签名。
例如SRv6 END.APN_Signing_Proxy2 FUNCT是A1::00AC:0001,其中A1是网关的地址,00AC:0001是FUNCT,其中0001是参数,代表需要网关代理签名,并且进入0001对应的headendID对应的IPSec。
下面以实例进行说明。
新建一个service-para option中的sub-tlv:Signing TLV
type=110
例如,设定最后一个bit为0,代表headend验证,为1,代表网关或者client验证。
适用于实施例1(后两位取值可能为01或00),实施例3(后两位取值可能为01或00)。
取值01,用于headend写入了自己的ID和签名之后,发给client,在实施例1中,是发给client,client进行解析签名和验证,在实施例3亦然。
取值00,代表网关写入了自己的ID和签名,发给了headend,headend会解析签名和验证。
例如设定倒数第二个bit为0,代表client验证,为1,代表要求网关验证。
上述例子至少适用于实施例2(后两位取值可能为11或00),实施例4(后两位取值可能为11或00)。
取值11,用于headend写入了自己的ID和签名之后,发给网关,网关进行签名的解析和验证。
图8为sub TLV(Signing TLV)结构示意图1。service-para option本身也可以被认为是一个TLV,该TLV除了使用sub TLV携带ID信息,也可以使用其他的sub TLV携带更多的信息,例如当前报文到达的时间戳,当前报文会进入的路径信息等。
同时,还有一个service-para option中的sub-tlv:Signing TLV的flag后两位的状态:10,适用于实施例3、4,如要求至少插入headendID。
图9为TLV结构示意图2,如图所示,如果状态是10,则可以没有ID信息,或者是ID信息为空,这时也不会包含signing info信息。
基于同一发明构思,本发明实施例中还提供了一种用户设备、网络节点、网关节点及计算机可读存储介质,由于这些设备解决问题的原理与通信鉴权方法相似,因此这些设备的实施可以参见方法的实施,重复之处不再赘述。
在实施本发明实施例提供的技术方案时,可以按如下方式实施。
图10为UE结构示意图,如图所示,用户设备包括:
处理器1000,用于读取存储器1020中的程序,执行下列过程:
向Headend发出第一报文;
接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;
向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
收发机1010,用于在处理器1000的控制下接收和发送数据。
实施中,所述第二报文中还可以包含有用以供网关节点判断报文可信性的使用与网关节点约定的密钥做的签名。
实施中,Headend ID及其对应的公钥是通过网关节点和/或AAA获得的。
实施中,所述的第一报文是APN报文,和/或,第二报文是APN报文。
实施中,所述UE进行报文的可信性判断,包括:
UE接收网络侧发送的包含有Headend ID以及签名的信息;
UE使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,确定来自该网络侧的报文携带的信息是可信任的信息。
实施中,Headend ID及其对应的公钥是通过网关节点和/或AAA获得的。
实施中,所述SRv6的FUNCT从网关获取的。
其中,在图10中,总线架构可以包括任意数量的互联的总线和桥,具体由处理器1000代表的一个或多个处理器和存储器1020代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。收发机1010可以是多个元件,即包括发送机和接收机,提供用于在传输介质上与各种其他装置通信的单元。针对不同的用户设备,用户接口1030还可以是能够外接内接需要设备的接口,连接的设备包括但不限于小键盘、显示器、扬声器、麦克风、操纵杆等。
处理器1000负责管理总线架构和通常的处理,存储器1020可以存储处理器1000在执行操作时所使用的数据。
本发明实施例中还提供了一种用户设备,包括:
UE发送模块,用于向Headend发出第一报文;
UE接收模块,用于接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;
UE发送模块,用于向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数。
实施中,所述第二报文中还可以包含有用以供网关节点判断报文可信性的使用与网关节点约定的密钥做的签名。
实施中,所述的第一报文是APN报文,和/或,第二报文是APN报文。
实施中,UE接收模块进一步用于在所述UE进行报文的可信性判断时,包括:
接收网络侧发送的包含有Headend ID以及签名的信息;
使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,确定来自该网络侧的报文携带的信息是可信任的信息。
实施中,进一步包括:
UE获取模块,用于通过网关节点和/或AAA获得Headend ID及其对应的公钥。
实施中,进一步包括:
UE获取模块,用于从网关获取所述SRv6的FUNCT。
为了描述的方便,以上所述装置的各部分以功能分为各种模块或单元分别描述。当然,在实施本发明时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。
图11为网络节点结构示意图,如图所示,网络节点中包括:
处理器1100,用于读取存储器1120中的程序,执行下列过程:
接收UE发出的第一报文;
解析所述第一报文,获取其中携带的网关ID和网关的私钥签名,使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的信息是可信任的信息;
向网络转发第一报文;
接收UE发出的第二报文;
使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息;
向网络转发第二报文;
收发机1110,用于在处理器1100的控制下接收和发送数据。
实施中,进一步包括:
根据第一报文中的要求在第一报文中插入信息,并进行签名。
实施中,签名时,进一步包括:
加入Headend自己的ID。
其中,在图11中,总线架构可以包括任意数量的互联的总线和桥,具体由处理器1100代表的一个或多个处理器和存储器1120代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。收发机1110可以是多个元件,即包括发送机和接收机,提供用于在传输介质上与各种其他装置通信的单元。处理器1100负责管理总线架构和通常的处理,存储器1120可以存储处理器1100在执行操作时所使用的数据。
本发明实施例中还提供了一种网络节点,包括:
Headend接收模块,用于接收UE发出的第一报文;
Headend解析模块,用于解析所述第一报文,获取其中携带的网关ID和网关的私钥签名,使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的信息是可信任的信息;
Headend发送模块,用于向网络转发第一报文;
Headend接收模块,用于接收UE发出的第二报文;
Headend解析模块,用于使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息;
Headend发送模块,用于向网络转发第二报文。
实施中,Headend解析模块进一步用于根据第一报文中的要求在第一报文中插入信息,并进行签名。
实施中,Headend解析模块进一步用于签名时,加入Headend自己的ID。
为了描述的方便,以上所述装置的各部分以功能分为各种模块或单元分别描述。当然,在实施本发明时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。
图12为网关节点结构示意图,如图所示,网关节点中包括:
处理器1200,用于读取存储器1220中的程序,执行下列过程:
接收UE发送的第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
根据SRv6的代理签名FUNCT和/或密钥确认UE的信息是否是可信任的信息,在可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend;
收发机1210,用于在处理器1200的控制下接收和发送数据。
实施中,所述第二报文中还可以包含有用以供网关节点判断报文可信性的使用UE与网关节点约定的密钥做的签名。
实施中,所述的第二报文是APN报文。
实施中,进一步包括:
对报文进行监控,在判断包含Headend签名,且要求网关进行验证时,进行解析和验证签名。
实施中,进一步包括:
接收到网络侧发送信息后,使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,转发至UE。
实施中,根据SRv6的代理签名FUNCT和/或密钥确认UE是否可信,在可信时,进一步包括:
将报文转发到预定的IPSec。
实施中,将报文转发到IPSec,是根据第二报文中的参数确定预定的IPSec的。
其中,在图12中,总线架构可以包括任意数量的互联的总线和桥,具体由处理器1200代表的一个或多个处理器和存储器1220代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。收发机1210可以是多个元件,即包括发送机和接收机,提供用于在传输介质上与各种其他装置通信的单元。处理器1200负责管理总线架构和通常的处理,存储器1220可以存储处理器1200在执行操作时所使用的数据。
本发明实施例中还提供了一种网关节点,包括:
网关节点接收模块,用于接收UE发送的第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
网关节点解析模块,用于根据SRv6的代理签名FUNCT和/或密钥确认UE的信息是否是可信任的信息,在可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend。
实施中,所述第二报文中还可以包含有用以供网关节点判断报文可信性的使用UE与网关节点约定的密钥做的签名。
实施中,所述的第二报文是APN报文。
实施中,网关节点解析模块进一步用于对报文进行监控,在判断包含Headend签名,且要求网关进行验证时,进行解析和验证签名。
实施中,网关节点解析模块进一步用于接收到网络侧发送信息后,使用与HeadendID对应的公钥对信息中的签名进行解析,若签名正确,转发至UE。
实施中,网关节点解析模块进一步用于根据SRv6的代理签名FUNCT和/或密钥确认UE是否可信,在可信时,将报文转发到预定的IPSec。
实施中,网关节点解析模块进一步用于根据第二报文中的参数将报文转发到IPSec的。
为了描述的方便,以上所述装置的各部分以功能分为各种模块或单元分别描述。当然,在实施本发明时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。
本发明实施例中还提供了一种计算机可读存储介质,所述计算机可读存储介质存储有执行上述通信鉴权方法的计算机程序。
具体实施中可以参见UE、网络节点或网关节点上的通信鉴权方法的实施。
综上所述,本发明实施例提供的技术方案中,在Headend上使能用于签名的公钥机制,在收到报文后,如果需要插入信息,则进行签名。这些需要插入信息的packet,可以是普通的业务报文,也可以是一些client发送的专门的探测packet,不需要携带具体的业务报文。
扩展SRv6网络编程,在BRAS上支持END.APN_Signing_Proxy(可选参数)的FUNCT,该函数支持client的可信性检查,代替Headend维护每流状态。
通过检查的报文,在BRAS进行签名后,再发送给Headend。
使用EAP协议来传递SRv6 FUNCT和headend ID&公钥。
例如作为EAP Request(请求)/Notification(通知)消息的TLV,发送本发明的SRv6 FUNCT,以及headend ID&公钥给client。
一方面,由于Headend不需要感知不同的终端,只要感知到了APN报文要求headend记录信息,就记录,并且签名,还是仅作packet级别的处理,不识别具体流,从而高效的完成了Headend的可信使能,保证了提供信息的正确来源。
另一方面,由于通过BRAS的代理签名,保证了终端的可信,保证了Headend能够相信这些终端。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
Claims (24)
1.一种通信鉴权方法,其特征在于,包括:
用户设备UE向头端Headend发出第一报文;
UE接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;
UE向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数。
2.如权利要求1所述的方法,其特征在于,所述第二报文中进一步包含有用以供网关节点判断报文可信性的使用与网关节点约定的密钥做的签名。
3.如权利要求1所述的方法,其特征在于,所述的第一报文是应用感知网络APN报文,和/或,第二报文是APN报文。
4.如权利要求1所述的方法,其特征在于,所述UE进行报文的可信性判断,包括:
UE接收网络侧发送的包含有头端标识Headend ID以及签名的信息;
UE使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,确定来自该网络侧的报文携带的信息是可信任的信息。
5.如权利要求1所述的方法,其特征在于,Headend ID及其对应的公钥是通过网关节点和/或验证、授权和计费服务器AAA获得的。
6.如权利要求1所述的方法,其特征在于,所述IPv6段路由SRv6的函数FUNCT从网关获取的。
7.一种通信鉴权方法,其特征在于,包括:
Headend接收UE发出的第一报文;
Headend解析所述第一报文,获取其中携带的网关ID和网关的私钥签名,Headend使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的第一报文是可信任的信息;
Headend向网络转发第一报文;
Headend接收UE发出的第二报文;
Headend使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息;
Headend向网络转发第二报文。
8.如权利要求7所述的方法,其特征在于,所述的第一报文是APN报文,和/或,第二报文是APN报文。
9.如权利要求7所述的方法,其特征在于,进一步包括:
根据第一报文中的要求在第一报文中插入信息,并进行签名。
10.如权利要求9所述的方法,其特征在于,签名时,进一步包括:
加入Headend自己的ID。
11.一种通信鉴权方法,其特征在于,包括:
网关节点接收UE发送的第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
网关节点根据SRv6的代理签名FUNCT和/或密钥确认UE的信息是否是可信任的信息,在可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend。
12.如权利要求11所述的方法,其特征在于,所述第二报文中进一步包含有用以供网关节点判断报文可信性的使用UE与网关节点约定的密钥做的签名。
13.如权利要求12所述的方法,其特征在于,所述的第二报文是APN报文。
14.如权利要求12所述的方法,其特征在于,进一步包括:
对报文进行监控,在判断包含Headend签名,且要求网关进行验证时,进行解析和验证签名。
15.如权利要求11或12所述的方法,其特征在于,进一步包括:
接收到网络侧发送信息后,使用与Headend ID对应的公钥对信息中的签名进行解析,若签名正确,转发至UE。
16.如权利要求11所述的方法,其特征在于,网关节点根据SRv6的代理签名FUNCT和/或密钥确认UE是否可信,在可信时,进一步包括:
将报文转发到预定的因特网协议安全IPSec。
17.如权利要求16所述的方法,其特征在于,将报文转发到预定的IPSec,是根据第二报文中的参数确定预定的IPSec的。
18.一种用户设备,其特征在于,包括:
处理器,用于读取存储器中的程序,执行下列过程:
向Headend发出第一报文;
接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;
向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
收发机,用于在处理器的控制下接收和发送数据。
19.一种用户设备,其特征在于,包括:
UE发送模块,用于向Headend发出第一报文;
UE接收模块,用于接收网络侧发送的包含网络侧信息的报文,进行报文的可信性判断;
UE发送模块,用于向网关节点发送第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数。
20.一种网络节点,其特征在于,包括:
处理器,用于读取存储器中的程序,执行下列过程:
接收UE发出的第一报文;
解析所述第一报文,获取其中携带的网关ID和网关的私钥签名,使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的信息是可信任的信息;
向网络转发第一报文;
接收UE发出的第二报文;
使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息;
向网络转发第二报文;
收发机,用于在处理器的控制下接收和发送数据。
21.一种网络节点,其特征在于,包括:
Headend接收模块,用于接收UE发出的第一报文;
Headend解析模块,用于解析所述第一报文,获取其中携带的网关ID和网关的私钥签名,使用与网关ID对应的公钥对信息中的签名进行验证,若签名正确,确定来自该UE的信息是可信任的信息;
Headend发送模块,用于向网络转发第一报文;
Headend接收模块,用于接收UE发出的第二报文;
Headend解析模块,用于使用与网关ID对应的公钥对信息中的签名进行解析,若签名正确,确定第二报文是可信任的信息;
Headend发送模块,用于向网络转发第二报文。
22.一种网关节点,其特征在于,包括:
处理器,用于读取存储器中的程序,执行下列过程:
接收UE发送的第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
根据SRv6的代理签名FUNCT和/或密钥确认UE的信息是否是可信任的信息,在可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend;
收发机,用于在处理器的控制下接收和发送数据。
23.一种网关节点,其特征在于,包括:
网关节点接收模块,用于接收UE发送的第二报文,所述第二报文中封装有用以供网关节点判断报文可信性以及执行代理签名功能的SRv6 FUNCT函数;
网关节点解析模块,用于根据SRv6的代理签名FUNCT和/或密钥确认UE的信息是否是可信任的信息,在可信时,在第二报文封装使用网关节点公钥做的签名,并发送至Headend。
24.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有执行权利要求1至17任一所述方法的计算机程序。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110163146.8A CN114884667A (zh) | 2021-02-05 | 2021-02-05 | 一种通信鉴权方法、设备及存储介质 |
PCT/CN2022/075234 WO2022166932A1 (zh) | 2021-02-05 | 2022-01-30 | 一种通信鉴权方法、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110163146.8A CN114884667A (zh) | 2021-02-05 | 2021-02-05 | 一种通信鉴权方法、设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114884667A true CN114884667A (zh) | 2022-08-09 |
Family
ID=82666964
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110163146.8A Pending CN114884667A (zh) | 2021-02-05 | 2021-02-05 | 一种通信鉴权方法、设备及存储介质 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN114884667A (zh) |
WO (1) | WO2022166932A1 (zh) |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101635714A (zh) * | 2009-05-31 | 2010-01-27 | 北京飞天诚信科技有限公司 | 提高网络应用安全性的方法和系统 |
CN103107977A (zh) * | 2011-11-10 | 2013-05-15 | 中兴通讯股份有限公司 | 信息安全传输方法、系统及接入服务节点 |
CN107409136A (zh) * | 2015-03-17 | 2017-11-28 | 高通股份有限公司 | 用于使用应用专用网络接入凭证到无线网络的受担保连通性的装置和方法 |
CN110120934A (zh) * | 2018-02-06 | 2019-08-13 | 丛林网络公司 | 应用防火墙策略的方法、软件定义网络控制器和介质 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120054497A1 (en) * | 2009-06-15 | 2012-03-01 | Nokia Siemens Networks Oy | Gateway certificate creation and validation |
CN102571729A (zh) * | 2010-12-27 | 2012-07-11 | 方正宽带网络服务股份有限公司 | Ipv6网络接入认证方法、装置及系统 |
WO2018076299A1 (zh) * | 2016-10-28 | 2018-05-03 | 华为技术有限公司 | 数据传输方法及装置 |
CN110035037B (zh) * | 2018-01-11 | 2021-09-17 | 华为技术有限公司 | 安全认证方法、相关设备及系统 |
-
2021
- 2021-02-05 CN CN202110163146.8A patent/CN114884667A/zh active Pending
-
2022
- 2022-01-30 WO PCT/CN2022/075234 patent/WO2022166932A1/zh unknown
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101635714A (zh) * | 2009-05-31 | 2010-01-27 | 北京飞天诚信科技有限公司 | 提高网络应用安全性的方法和系统 |
CN103107977A (zh) * | 2011-11-10 | 2013-05-15 | 中兴通讯股份有限公司 | 信息安全传输方法、系统及接入服务节点 |
CN107409136A (zh) * | 2015-03-17 | 2017-11-28 | 高通股份有限公司 | 用于使用应用专用网络接入凭证到无线网络的受担保连通性的装置和方法 |
CN110120934A (zh) * | 2018-02-06 | 2019-08-13 | 丛林网络公司 | 应用防火墙策略的方法、软件定义网络控制器和介质 |
Also Published As
Publication number | Publication date |
---|---|
WO2022166932A1 (zh) | 2022-08-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109548008B (zh) | 网络侧对远端用户设备的识别和控制方法以及设备 | |
CN107800602B (zh) | 一种报文处理方法、设备及系统 | |
RU2382506C2 (ru) | Способ и устройство для эффективного интерфейса сервера vpn, выделения адреса и передачи сигналов с локальным доменом адресации | |
EP2850776B1 (en) | Tls abbreviated session identifier protocol | |
EP2955874A2 (en) | Link discovery method and device | |
US20150381563A1 (en) | Relay system for transmitting ip address of client to server and method therefor | |
CN104993993B (zh) | 一种报文处理方法、设备和系统 | |
CN110622471B (zh) | 交换装置、通信控制方法和通信控制程序 | |
US10742768B2 (en) | Relaying system and method of transmitting IP address of client to server using encapsulation protocol | |
WO2017016473A1 (zh) | 用于进行隧道检测的方法、装置及系统 | |
CN107154917B (zh) | 数据传输方法及服务器 | |
US8819790B2 (en) | Cooperation method and system between send mechanism and IPSec protocol in IPV6 environment | |
EP4152716A1 (en) | Packet processing method, device and system | |
US20160248668A1 (en) | Network packet forwarding method and device | |
CN100353711C (zh) | 通信系统、通信装置、操作控制方法 | |
US20230370848A1 (en) | Methods for configuring a user apparatus, negotiating with a network entity, and managing a connection, and associated devices | |
CN114884667A (zh) | 一种通信鉴权方法、设备及存储介质 | |
CN111917650B (zh) | 确定通用路由封装gre隧道标识的方法、设备和系统 | |
CN108259292B (zh) | 建立隧道的方法及装置 | |
CN112737949A (zh) | 故障检测方法及装置、电子设备、计算机可读介质 | |
WO2024027419A1 (zh) | 报文发送方法、装置及系统 | |
US11863446B2 (en) | User group-based packet forwarding method, device, and system | |
CN112702263B (zh) | 转发报文的方法及装置 | |
WO2022063075A1 (zh) | 计费方法、装置、通信设备及可读存储介质 | |
CN116782275A (zh) | 一种终端设备接入核心网的控制方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |