WO2024037215A1 - 通信方法及装置 - Google Patents

通信方法及装置 Download PDF

Info

Publication number
WO2024037215A1
WO2024037215A1 PCT/CN2023/104041 CN2023104041W WO2024037215A1 WO 2024037215 A1 WO2024037215 A1 WO 2024037215A1 CN 2023104041 W CN2023104041 W CN 2023104041W WO 2024037215 A1 WO2024037215 A1 WO 2024037215A1
Authority
WO
WIPO (PCT)
Prior art keywords
network element
entity
verification
measurement
request
Prior art date
Application number
PCT/CN2023/104041
Other languages
English (en)
French (fr)
Inventor
李论
吴义壮
刘丹
胡力
胡华东
Original Assignee
华为技术有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2024037215A1 publication Critical patent/WO2024037215A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security

Abstract

本申请提供一种通信方法及装置,属于通信技术领域,用以避免跨域访问时的安全风险。该方法中,由于第二信任域内的第二网元跨域请求第一信任域内的第一网元提供相应的服务时,第一网元可以执行端对端的验证,也即触发验证该第二网元是否可信,以便在确定第二网元可信的情况下,第一网元才为第二网元提供服务,如此可以避免跨域访问时的安全风险。

Description

通信方法及装置
本申请要求于2022年08月18日提交国家知识产权局、申请号为202210994211.6、申请名称为“通信方法及装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域,尤其涉及一种通信方法及装置。
背景技术
目前,第三代合作伙伴计划(3rd generation partnership project,3GPP)定义不同的运营商网络可以相互访问。拜访公共陆地移动网(visited public land mobile network,VPLMN)中的网元,如v-网络功能(network function,NF)消费实体(consumer),与本地公共陆地移动网(home public land mobile network,HPLMN)中的网元,如hNF提供实体(producer)可以进行通信。例如,vNF消费实体与-安全边缘保护代理(security edge protection proxy,vSEPP)建立安全传输层协议(transport layer security,TLS)连接,vSEPP与hSEPP建立TLS连接,hSEPP与hNF提供实体建立TLS连接。这样,vNF消费实体与hNF提供实体便可以通过逐跳路由的方式进行通信,如hNF提供实体向vNF消费实体提供服务。
但是,hNF提供实体与hNF提供实体并非直接进行通信,而是由vSEPP和hSEPP进行中继,导致跨域访问存在安全风险。
发明内容
本申请实施例提供一种通信方法及装置,用以避免跨域访问时的安全风险。
为达到上述目的,本申请采用如下技术方案:
第一方面,提供一种通信方法。该方法包括:在第一信任域内的第一网元需要为第二信任域内的第二网元提供第一信任域的服务的情况下,第一网元通过触发对第二网元的可信度量,获得可信度量对应的结果信息。如此,在第一网元根据可信度量对应的结果信息,确定第二网元可信的情况下,第一网元为第二网元提供第一信任域的服务。
基于第一方面所述的方法可知,由于第一信任域内的第一网元跨域为第二信任域内的第二网元提供相应的服务之前,第一网元可以执行端对端的验证,也即触发验证该第二网元是否可信,以便在确定第二网元可信的情况下,第一网元才为第二网元提供服务,如此可以避免跨域访问时的安全风险。
一种可能的设计方案中,第一网元通过触发对第二网元的可信度量,获得可信度量对应的结果信息,包括:第一网元向第二网元发送度量请求,以接收来自第二网元的度量响应。其中,度量请求用于请求第二网元触发对第二网元的可信度量,度量响应用于指示可信度量对应的结果信息。也即,第一网元可以直接指示第二网元触发对第二网元的可信度量,以提高通信效率。此外,第二网元的可信度量对应的结果信息也可以是第二网元的度量凭证,或者说第二网元的度量令牌,不做限定。
可选地,第一信任域是第一运营商网络,第一网元是认证网元,第二信任域是第二运营商网络,第二网元是接入和移动性管理网元。第一网元向第二网元发送度量请求,包括:认证网元接收来自接入和移动性管理网元的认证请求,并根据认证请求,向接入和移动性管理网元发送度量请求。其中,认证请求用于请求认证网元为接入和移动性管理网元提供认证服务,度量请求用于请求接入和移动性管理网元触发对接入和移动性管理网元的可信度量。
可选地,第一网元为第二网元提供服务,包括:认证网元向接入和移动性管理网元发送认证响应。其中,认证响应用于指示认证服务,度量请求用于请求接入和移动性管理网元触发对接入和移动性管理网元的可信度量。
可以看出,在第一信任域是第一运营商网络,第二信任域是第二运营商网络的情况下,第一网元触发对第二网元的可信度量可以被复用到终端的注册场景,如认证网元可以触发对接入和移 动性管理网元的可信度量,以保障注册场景下的通信安全。
进一步的,终端归属于第一运营商网络,认证服务用于指示终端注册到第二运营商网络所需的信息,以确保终端能够注册到第二运营商网络。
进一步的,第一方面所述的方法还可以包括:认证网元向接入和移动性管理网元发送验证证明信息。其中,验证证明信息用于终端验证认证网元或认证网元关联的第一验证实体是否可信,第一验证实体位于第一运营商网络,认证网元或第一验证实体用于验证第二验证实体是否可信,第二验证实体用于对接入和移动性管理网元进行可信度量,第二验证实体位于第二运营商网络。可以看出,由于注册流程通常是由终端触发,如终端请求注册到第二运营商网络,因此也可以向终端提供验证证明信息,以实现双向验证,进一步保障通信安全。
可选地,第一信任域是业务域,第二信任域是虚拟化设施域,第二网元是虚拟网络功能。第一网元向第二网元发送度量请求,包括:第一网元接收来自虚拟网络功能的注册请求,并根据注册请求,向虚拟网络功能发送度量请求,其中,注册请求用于请求第一网元为虚拟网络功能提供注册服务,度量请求用于请求虚拟网络功能提触发对虚拟网络功能提的可信度量。
可选地,第一网元为第二网元提供服务,包括:第一网元向虚拟网络功能发送注册响应,其中,注册响应用于指示认证服务。
可以看出,在第一信任域是业务域,第二信任域是虚拟化设施域的情况下,第一网元触发对第二网元的可信度量可以被复用到虚拟网络功能的注册场景,如第一网元可以触发对虚拟网络功能的可信度量,以保障注册场景下的通信安全。
进一步的,注册服务用于指示第一网元允许虚拟网络功能注册到业务域,以确保虚拟网络功能能够成功注册到业务域。
一种可能的设计方案中,第一网元通过触发对第二网元的可信度量,获得可信度量对应的结果信息,包括:第一网元向第二信任域内的第三网元发送度量请求,以接收来自第三网元的度量响应。其中,第三网元是第二网元关联的网元,度量请求用于请求第三网元触发对第二网元的可信度量,度量响应用于指示可信度量对应的结果信息。也即,在第一网元与第二网元可能无法直接通信的情况下,第一网元仍可以通过指示第二信任域内的第三网元来触发对第二网元的可信度量,确保可信度量仍能够被有效执行。
可选地,第一信任域是第一运营商网络,第一网元是第一会话管理网元,第二信任域是第二运营商网络,第二网元是第二用户面网元,第三网元是第二会话管理网元。第一网元向第二网元发送度量请求,包括:第一会话管理网元接收来自第二会话管理网元的会话创建请求,并根据会话创建请求,向第二会话管理网元发送度量请求。其中,会话创建请求用于请求第一会话管理网元为第二用户面网元提供会话创建服务,度量请求用于请求第二会话管理网元触发对第二用户面网元的可信度量。
可选地,第一网元为第二网元提供服务,包括:第一会话管理网元向第二会话管理网元发送会话创建响应,其中,会话建立创建用于指示会话创建服务。
可以看出,在第一信任域是第一运营商网络,第二信任域是第二运营商网络的情况下,第一网元触发对第二网元的可信度量可以被复用到会话建立场景,如第一会话管理网元可以触发对第二会话管理网元的可信度量,以保障会话场景下的通信安全。
进一步的,第一用户面网元是第一运营商网络内的网元,会话创建服务用于指示第二用户面网元需要与第一用户面网元建立会话,以确保能够成功建立会话。
进一步的,第一方面所述的方法还可以包括:第一会话管理网元向第一用户面网元发送指示信息。其中,指示信息用于指示:第一用户面网元需要验证第一用户面网元接收的数据是否来自第二用户面网元,以确保第一用户面网元可以只处理来自可信的第二用户面网元的数据,保障用户面的通信安全。
一种可能的设计方案中,在第一网元根据可信度量对应的结果信息,确定第二网元可信之前,第一方面所述的方法还可以包括:第一网元接收来自第二网元的第二验证实体的信息,并根据第二验证实体的信息,确定第二验证实体可信。其中,第二验证实体是用于度量第二网元的验证实体,第二验证实体位于第二信任域内,第一网元与第二信任域内的验证实体之间不具有信任关系。 也就是说,在确定第二网元是否可信之前,第一网元还可以确定对第二网元执行可信度量的第二验证实体是否可信,以进一步保障通信安全。
可选地,第一网元根据第二验证实体的信息,确定第二验证实体可信,包括:第一网元向第一信任域内的第一验证实体发送验证请求,其中,验证请求用于请求第一验证实体根据第二验证实体的信息,验证第二验证实体是否可信。例如,验证请求用于请求订阅第一事件,第一事件可以为第一验证实体需要根据第二验证实体的信息,验证第二验证实体是否可信。如此,第一网元接收来自第一验证实体的验证响应。其中,验证响应用于指示第二验证实体可信。可以理解,如果第二验证实体无法被第一网元信任,则第一网元通常也没有配置第二验证实体相关的配置文件,因此也无法直接验证该第二验证实体是否可信。这种情况下,第一网元还可以触发第一网元信任的第一验证实体验证该第二验证实体是否可信,以保障通信安全。当然,在第一网元配置有第二验证实体相关的配置文件的情况下,第一网元也可以直接验证第二验证实体是否可信,不做限定。
进一步的,第二验证实体的信息包括如下至少一项:第二验证实体的身份信息、或第二验证实体的证明信息。其中,第二验证实体的身份信息可以包括如下至少一项:第二验证实体的标识、第二验证实体的签名,第二验证实体的证明信息可以包括如下至少一项:第二验证实体的部署证据、第二验证实体所属机构的凭据、第二验证实体的签约注册信息,以实现对第二验证实体进行较为全面的验证。
可以理解,由于第二验证实体的信息也可以携带在上述可信度量对应的结果信息,如第二网元的度量凭证中,因此,也可以理解为第一网元根据第二网元的度量凭证,确定第二验证实体可信。进一步的,还可以理解为第一验证实体根据第二网元的度量凭证,确定第二验证实体可信。
一种可能的设计方案中,在第一网元通过触发对第二网元的可信度量,获得可信度量对应的结果信息之前,第一方面所述的方法还可以包括:第一网元确定没有第二网元的可信度量记录;或者,第一网元确定有第二网元的可信度量记录,但可信度量记录失效。也就是说,在没有对第二网元进行过可信度量,或者虽然对第二网元进行过可信度量,但该可信度量已经失效的情况下,第一网元才触发对第二网元的可信度量,否则,第一网元可以不触发对第二网元的可信度量,而可以直接与第二网元通信,以节约开销。
可选地,第一网元确定没有第二网元的可信度量记录,包括:第一网元确定至少一个网元未保存第二网元的可信度量记录。或者,第一网元确定有第二网元的可信度量记录,但可信度量记录失效,包括:第一网元确定至少一个网元保存有第二网元的可信度量记录,但可信度量记录失效。其中,至少一个网元包括:第一网元、或代理功能,其中,代理功能是第一网元与第二网元通信的中继。也即,可信度量记录可以被灵活保存在第一网元或代理功能,不做限定。
一种可能的设计方案中,第一网元通过触发对第二网元的可信度量,获得可信度量对应的结果信息,包括:第一网元向第一信任域内的第一验证实体发送度量请求,以接收来自第一验证实体的度量响应,其中,度量请求用于请求第一验证实体触发对第二网元的可信度量,度量响应用于指示可信度量对应的结果信息。也即,在第二网元当前可能无法被第一网元信任的情况下,第一网元可通过第一网元信任的第一验证实体触发对第二网元的可信度量,以避免与第二网元直接通信,进一步保障通信安全。
可选地,在第一信任域内的第一网元还需要为第三信任域内的网元提供所述第一信任域的服务的情况下,度量请求用于请求第一验证实体触发对第二网元和第三信任域内的网元的可信度量,度量响应用于指示该第二网元和第三信任域内的网元的可信度量对应的结果信息。以及,第一网元为第二网元提供所述服务,包括:第一网元根据该可信度量对应的结果信息,确定第二网元和第三信任域内的网元可信,从而为第二网元和第三信任域内的网元提供服务。
一种可能的设计方案中,第一网元根据可信度量对应的结果信息,确定第二网元可信,包括:第一网元根据可信度量对应的结果信息中的至少一项满足预设条件,确定第二网元可信,其中,结果信息中的至少一项满足预设条件包括:用于表征度量凭证的标识与预配置的标识匹配、被度量网元的标识与第二网元的标识匹配、或结果信息指示第二网元可信,以实现对第二网元进行较为全面的验证。
第二方面,提供一种通信方法。该方法包括:第一信任域内的第一验证实体接收来自第一信 任域内的第一网元的验证请求。其中,验证请求用于请求第一验证实体根据第二验证实体的信息,验证第二验证实体是否可信,第二验证实体位于第二信任域,第一网元与第二信任域内的验证实体之间不具有信任关系。如此,第一验证实体根据验证请求,向第一网元发送验证响应。其中,验证响应用于指示第二验证实体可信,或者,验证响应用于指示第二验证实体不可信。
一种可能的设计方案中,验证请求用于请求订阅第一事件,第一事件为第一验证实体需要根据第二验证实体的信息,验证第二验证实体是否可信。
可选地,第二验证实体的信息包括如下至少一项:第二验证实体的身份信息、或第二验证实体的证明信息。其中,第二验证实体的身份信息可以包括如下至少一项:第二验证实体的标识、第二验证实体的签名。第二验证实体的证明信息可以包括如下至少一项:第二验证实体的部署证据、第二验证实体所属机构的凭据、第二验证实体的签约注册信息。
此外,第二方面所述的通信方法的技术效果可以参考第一方面所述的通信方法的技术效果,此处不再赘述。
第三方面,提供一种通信方法。该方法包括:在第一信任域内的第一网元需要为第二信任域内的第二网元提供第一信任域的服务的情况下,第二信任域内的第四网元接收来自第一网元的度量请求,并根据度量请求向第一网元发送度量响应。其中,第四网元与第二网元关联,度量请求用于指示第四网元触发对第二网元的可信度量,度量响应用于指示第二网元是否可信。如此,在第二网元可信的情况下,第四网元获取第一网元为第二网元提供的服务。
一种可能的设计方案中,第四网元与第二网元是同一个网元。
可选地,第一信任域是第一运营商网络,第一网元是认证网元,第二信任域是第二运营商网络,第二网元是接入和移动性管理网元。第三方面所述的方法还包括:接入和移动性管理网元向认证网元发送认证请求,其中,认证请求用于请求认证网元触发为接入和移动性管理网元提供认证服务。第四网元接收来自第一网元的度量请求,包括:接入和移动性管理网元接收认证网元针对认证请求返回的度量请求。
可选地,第四网元获取第一网元为第二网元提供的服务,包括:接入和移动性管理网元接收来自认证网元的认证响应,其中,认证响应用于指示认证服务。
可选地,接入和移动性管理网元向认证网元发送认证请求,包括:接入和移动性管理网元接收来自终端的注册请求,其中,终端归属于第一运营商网络,注册请求用于终端请求注册到第二运营商网络。如此,接入和移动性管理网元根据注册请求,向认证网元发送认证请求。
进一步的,认证服务用于指示终端注册到第二运营商网络所需的信息。
进一步的,第三方面所述的方法还可以包括:接入和移动性管理网元接收来自认证网元的验证证明信息,并向终端发送验证证明信息。其中,验证证明信息用于终端验证认证网元或认证网元关联的第一验证实体是否可信,第一验证实体位于第一运营商网络,认证网元或第一验证实体用于验证第二验证实体是否可信,第二验证实体用于对接入和移动性管理网元进行可信度量,第二验证实体位于第二运营商网络。
可选地,第一信任域是业务域,第二信任域是虚拟化设施域,第二网元是虚拟网络功能。第三方面所述的方法还包括:虚拟网络功能向第一网元发送注册请求,其中,注册请求用于请求第一网元为虚拟网络功能提供注册服务。第四网元接收来自第一网元的度量请求,包括:虚拟网络功能接收第一网元针对注册请求返回的度量请求。
可选地,第四网元获取第一网元为第二网元提供的服务,包括:虚拟网络功能接收来自第一网元的注册响应,其中,认证响应用于指示注册服务。
进一步的,注册服务用于指示第一网元允许虚拟网络功能注册到业务域。
一种可能的设计方案中,第四网元与第二网元是不同的网元。
可选地,第一信任域是第一运营商网络,第一网元是第一会话管理网元,第二信任域是第二运营商网络,第二网元是第二用户面网元,第四网元是第二会话管理网元。第三方面所述的方法还包括:第二会话管理网元向第一会话管理网元发送会话创建请求,其中,会话创建请求用于请求第一会话管理网元为第二用户面网元提供会话创建服务。第四网元接收来自第一网元的度量请求,包括:第二会话管理网元接收第一会话管理网元针对会话创建请求返回的度量请求。
可选地,第四网元获取第一网元为第二网元提供的服务,包括:第二会话管理网元接收来自第一会话管理网元的会话创建响应,其中,会话创建响应用于指示会话创建服务。
进一步的,会话创建服务用于指示第二用户面网元需要与第一用户面网元建立服务会话,第一用户面网元是第一运营商网络内的网元。
进一步的,第三方面所述的方法还可以包括:第二会话管理网元向第二用户面网元发送指示信息,其中,指示信息用于指示:第二用户面网元需要对数据进行标识,对数据进行标识用于表征数据是由第二用户面网元发送的数据。
进一步的,第三方面所述的方法还可以包括:第二会话管理网元接收来自终端的会话建立请求,并根据会话建立请求,确定第二用户面网元。其中,终端归属于第一运营商网络,会话建立请求用于终端请求建立会话。这种情况下,第二会话管理网元可以优先选择有可信度量记录的用户面网元,以便本次可以不再执行可信度量,节约开销。
第四方面,提供一种通信装置。该通信装置包括:用于执行第一方面所述的通信方法的模块,例如,收发模块和处理模块,收发模块可以用于执行该通信装置的收发功能,处理模块可以用于执行该通信装置除收发功能以外的其他功能。一种可能的场景中,在第一信任域内的第一网元需要为第二信任域内的第二网元提供第一信任域的服务的情况下,处理模块,用于通过触发对第二网元的可信度量,获得可信度量对应的结果信息。处理模块,还用于在第一网元根据可信度量对应的结果信息,确定第二网元可信的情况下,控制收发模块为第二网元提供第一信任域的服务。
可选地,收发模块可以包括发送模块和接收模块。其中,发送模块用于实现第四方面所述的通信装置的发送功能,接收模块用于实现第四方面所述的通信装置的接收功能。
可选地,第四方面所述的通信装置还可以包括存储模块,该存储模块存储有程序或指令。当该处理模块执行该程序或指令时,使得该通信装置可以执行第一方面所述的通信方法。
需要说明的是,第四方面所述的通信装置可以是网络设备,也可以是可设置于网络设备中的芯片(系统)或其他部件或组件,还可以是包含网络设备的装置,本申请对此不做限定。
此外,第四方面所述的通信装置的技术效果可以参考第一方面所述的通信方法的技术效果,此处不再赘述。
第五方面,提供一种通信装置。该通信装置包括:用于执行第二方面的通信方法的模块,例如,收发模块和处理模块,收发模块可以用于执行该通信装置的收发功能,处理模块可以用于执行该通信装置除收发功能以外的其他功能。一种可能的场景中,收发模块,用于接收来自第一信任域内的第一网元的验证请求。其中,验证请求用于请求第一信任域内的该通信装置根据第二验证实体的信息,验证第二验证实体是否可信,第二验证实体位于第二信任域,第一网元与第二信任域内的验证实体之间不具有信任关系。如此,处理模块,用于根据验证请求,控制收发模块向第一网元发送验证响应。其中,验证响应用于指示第二验证实体可信,或者,验证响应用于指示第二验证实体不可信。
可选地,收发模块可以包括发送模块和接收模块。其中,发送模块用于实现第五方面所述的通信装置的发送功能,接收模块用于实现第五方面所述的通信装置的接收功能。
可选地,第五方面所述的通信装置还可以包括存储模块,该存储模块存储有程序或指令。当该处理模块执行该程序或指令时,使得该通信装置可以执行第二方面所述的通信方法。
需要说明的是,第五方面所述的通信装置可以是网络设备,也可以是可设置于网络设备中的芯片(系统)或其他部件或组件,还可以是包含网络设备的装置,本申请对此不做限定。
此外,第五方面所述的通信装置的技术效果可以参考第二方面所述的通信方法的技术效果,此处不再赘述。
第六方面,提供一种通信装置。该通信装置包括:用于执行第三方面所述的通信方法的模块,例如,收发模块和处理模块,收发模块可以用于执行该通信装置的收发功能,处理模块可以用于执行该通信装置除收发功能以外的其他功能。一种可能的场景中,通信装置是第二信任域内的网元,在第一信任域内的第一网元需要为第二信任域内的第二网元提供第一信任域的服务的情况下,收发模块,用于接收来自第一网元的度量请求,处理模块,用于根据度量请求,控制收发模块向第一网元发送度量响应。其中,第四网元与第二网元关联,度量请求用于指示通信装置触发对第 二网元的可信度量,度量响应用于指示第二网元是否可信。如此,在第二网元可信的情况下,处理模块,用于获取第一网元为第二网元提供的服务。
可选地,收发模块可以包括发送模块和接收模块。其中,发送模块用于实现第六方面所述的通信装置的发送功能,接收模块用于实现第六方面所述的通信装置的接收功能。
可选地,第六方面所述的通信装置还可以包括存储模块,该存储模块存储有程序或指令。当该处理模块执行该程序或指令时,使得该通信装置可以执行第三方面所述的通信方法。
需要说明的是,第六方面所述的通信装置可以是网络设备,也可以是可设置于网络设备中的芯片(系统)或其他部件或组件,还可以是包含网络设备的装置,本申请对此不做限定。
此外,第六方面所述的通信装置的技术效果可以参考第三方面所述的通信方法的技术效果,此处不再赘述。
第七方面,提供一种通信装置。该通信装置包括:处理器,该处理器用于执行第一方面至第三方面中任意一种可能的实现方式所述的通信方法。
在一种可能的设计方案中,第七方面所述的通信装置还可以包括收发器。该收发器可以为收发电路或接口电路。该收发器可以用于第七方面所述的通信装置与其他通信装置通信。
在一种可能的设计方案中,第七方面所述的通信装置还可以包括存储器。该存储器可以与处理器集成在一起,也可以分开设置。该存储器可以用于存储第一方面至第三方面中任一方面所述的通信方法所涉及的计算机程序和/或数据。
在本申请中,第七方面所述的通信装置可以为第一方面至第三方面中任一方面所述的终端,或者可设置于该终端中的芯片(系统)或其他部件或组件,或者包含该终端的装置。
此外,第七方面所述的通信装置的技术效果可以参考第一方面至第三方面中任意一种实现方式所述的通信方法的技术效果,此处不再赘述。
第八方面,提供一种通信装置。该通信装置包括:处理器,该处理器与存储器耦合,该处理器用于执行存储器中存储的计算机程序,以使得该通信装置执行第一方面至第三方面中任意一种可能的实现方式所述的通信方法。
在一种可能的设计方案中,第八方面所述的通信装置还可以包括收发器。该收发器可以为收发电路或接口电路。该收发器可以用于第八方面所述的通信装置与其他通信装置通信。
在本申请中,第八方面所述的通信装置可以为第一方面至第三方面中任一方面所述的终端,或者可设置于该终端中的芯片(系统)或其他部件或组件,或者包含该终端的装置。
此外,第八方面所述的通信装置的技术效果可以参考第一方面至第三方面中任意一种实现方式所述的通信方法的技术效果,此处不再赘述。
第九方面,提供了一种通信装置,包括:处理器和存储器;该存储器用于存储计算机程序,当该处理器执行该计算机程序时,以使该通信装置执行第一方面至第三方面中的任意一种实现方式所述的通信方法。
在一种可能的设计方案中,第九方面所述的通信装置还可以包括收发器。该收发器可以为收发电路或接口电路。该收发器可以用于第九方面所述的通信装置与其他通信装置通信。
在本申请中,第九方面所述的通信装置可以为第一方面至第三方面中任一方面所述的终端,或者可设置于该终端中的芯片(系统)或其他部件或组件,或者包含该终端的装置。
此外,第九方面所述的通信装置的技术效果可以参考第一方面至第三方面中任意一种实现方式所述的通信方法的技术效果,此处不再赘述。
第十方面,提供了一种通信装置,包括:处理器;该处理器用于与存储器耦合,并读取存储器中的计算机程序之后,根据该计算机程序执行如第一方面至第三方面中的任意一种实现方式所述的通信方法。
在一种可能的设计方案中,第十方面所述的通信装置还可以包括收发器。该收发器可以为收发电路或接口电路。该收发器可以用于第十方面所述的通信装置与其他通信装置通信。
在本申请中,第十方面所述的通信装置可以为第一方面至第三方面中任一方面所述的终端,或者可设置于该终端中的芯片(系统)或其他部件或组件,或者包含该终端的装置。
此外,第十方面所述的通信装置的技术效果可以参考第一方面至第三方面中任意一种实现方 式所述的通信方法的技术效果,此处不再赘述。
第十一方面,提供一种通信系统。该通信系统包括:第一方面至第三方面中任一方面所述的一个或多个终端。
第十二方面,提供一种计算机可读存储介质,包括:计算机程序或指令;当该计算机程序或指令在计算机上运行时,使得该计算机执行第一方面至第三方面中任意一种可能的实现方式所述的通信方法。
第十三方面,提供一种计算机程序产品,包括计算机程序或指令,当该计算机程序或指令在计算机上运行时,使得该计算机执行第一方面至第三方面中任意一种可能的实现方式所述的通信方法。
附图说明
图1为5G系统的非漫游架构示意图;
图2为5G系统的漫游架构示意图;
图3为在漫游架构下VPLMN中的网元与HPLMN中的网元通信的流程示意图;
图4为远程证明的流程示意图;
图5为NFV的架构示意图;
图6为基于远程证明的NFV的架构示意图;
图7为基于远程证明的NFV的流程示意图;
图8为本申请实施例提供的通信系统的架构示意图;
图9为本申请实施例提供的通信方法的流程示意图一;
图10为本申请实施例提供的通信方法的流程示意图二;
图11为本申请实施例提供的通信方法的流程示意图三;
图12为本申请实施例提供的通信方法的流程示意图四;
图13为本申请实施例提供的通信方法的流程示意图五;
图14为本申请实施例提供的通信方法的流程示意图六;
图15为本申请实施例提供的通信装置的结构示意图一;
图16为本申请实施例提供的通信装置的结构示意图二。
具体实施方式
方便理解,下面先介绍本申请实施例所涉及的技术术语。
1、第五代(5th generation,5G)移动通信系统(简称5G系统(5G system,5GS)):
图1为5GS的非漫游架构示意图。如图1所示,5GS包括:接入网(access network,AN)和核心网(core network,CN),还可以包括:终端。
上述终端可以为具有收发功能的终端,或为可设置于该终端的芯片或芯片系统。该终端也可以称为用户装置(uesr equipment,UE)、接入终端、用户单元(subscriber unit)、用户站、移动站(mobile station,MS)、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。本申请的实施例中的终端可以是手机(mobile phone)、蜂窝电话(cellular phone)、智能电话(smart phone)、平板电脑(Pad)、无线数据卡、个人数字助理电脑(personal digital assistant,PDA)、无线调制解调器(modem)、手持设备(handset)、膝上型电脑(laptop computer)、机器类型通信(machine type communication,MTC)终端、带无线收发功能的电脑、虚拟现实(virtual reality,VR)终端、增强现实(augmented reality,AR)终端、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、车载终端、具有终端功能的路边单元(road side unit,RSU)等。本申请的终端还可以是作为一个或多个部件或者单元而内置于车辆的车载模块、车载模组、车载部件、车载芯片或者车载单元。
上述AN用于实现接入有关的功能,可以为特定区域的授权用户提供入网功能,并能够根据 用户的级别,业务的需求等确定不同质量的传输链路以传输用户数据。AN在终端与CN之间转发控制信号和用户数据。AN可以包括:接入网设备,也可以称为无线接入网设备(radio access network,RAN)设备。CN主要负责维护移动网络的签约数据,为终端提供会话管理、移动性管理、策略管理以及安全认证等功能。CN主要包括如下:用户面功能(user plane function,UPF)、鉴权服务器功能(authentication server function,AUSF)、接入和移动性管理功能(access and mobility management function,AMF)、会话管理功能(session management function,SMF)、网络切片选择功能(network slice selection function,NSSF)、网络开放功能(network exposure function,NEF)、网络存储功能(network repository function,NRF)、策略控制功能(policy control function,PCF)、统一数据管理(unified data management,UDM)、统一数据存储(unified data repository,UDR)、以及应用功能(application function,AF)。
如图1所示,UE通过RAN设备接入5G网络,UE通过N1接口(简称N1)与AMF通信;RAN通过N2接口(简称N2)与AMF通信;RAN通过N3接口简称N3与UPF通信;SMF通过N4接口(简称N4)与UPF通信,UPF通过N6接口(简称N6)接入数据网络(data network,DN)。此外,图1所示的AUSF、AMF、SMF、NSSF、NEF、NRF、PCF、UDM、UDR或者AF等控制面功能采用服务化接口进行交互。比如,AUSF对外提供的服务化接口为Nausf;AMF对外提供的服务化接口为Namf;SMF对外提供的服务化接口为Nsmf;NSSF对外提供的服务化接口为Nnssf;NEF对外提供的服务化接口为Nnef;NRF对外提供的服务化接口为Nnrf;PCF对外提供的服务化接口为Npcf;UDM对外提供的服务化接口为Nudm;UDR对外提供的服务化接口为Nudr;AF对外提供的服务化接口为Naf。
RAN设备可以是为终端提供接入的设备。例如,RAN设备可以包括:下一代移动通信系统,例如6G的接入网设备,例如6G基站,或者在下一代移动通信系统中,该网络设备也可以有其他命名方式,其均涵盖在本申请实施例的保护范围以内,本申请对此不做任何限定。或者,RAN设备也可以包括5G,如新空口(new radio,NR)系统中的gNB,或,5G中的基站的一个或一组(包括多个天线面板)天线面板,或者,还可以为构成gNB、传输点(transmission and reception point,TRP或者transmission point,TP)或传输测量功能(transmission measurement function,TMF)的网络节点,如基带单元(building base band unit,BBU),或,集中单元(centralized unit,CU)或分布单元(distributed unit,DU)、具有基站功能的RSU,或者有线接入网关,或者5G的核心网。或者,RAN设备还可以包括无线保真(wireless fidelity,WiFi)系统中的接入点(access point,AP),无线中继节点、无线回传节点、各种形式的宏基站、微基站(也称为小站)、中继站、接入点、可穿戴设备、车载设备等等。
UPF主要负责用户数据处理(转发、接收、计费等)。例如,UPF可以接收来自数据网络(data network,DN)的用户数据,通过接入网设备向终端转发该用户数据。UPF也可以通过接入网设备接收来自终端的用户数据,并向DN转发该用户数据。DN指的是为用户提供数据传输服务的运营商网络。例如网际互连协议(internet protocol,IP)多媒体业务(IP multi-media srvice,IMS)、互联网(internet)等。DN可以为运营商外部网络,也可以为运营商控制的网络,用于向终端设备提供业务服务。在协议数据单元(protocol data unit,PDU)会话中,通过N6与DN直接相连的UPF,也称为协议数据单元会话锚点(protocol data unit Session Anchor,PSA)。
AUSF主要用于执行终端的安全认证。
AMF主要用于移动网络中的移动性管理。例如用户位置更新、用户注册网络、用户切换等。
SMF主要用于移动网络中的会话管理。例如会话建立、修改、释放。具体功能例如为用户分配互联网协议(internet protocol,IP)地址,选择提供数据包转发功能的UPF等。
PCF主要支持提供统一的策略框架来控制网络行为,提供策略规则给控制层网络功能,同时负责获取与策略决策相关的用户签约信息。PCF可以向AMF、SMF提供策略,例如服务质量(quality of service,QoS)策略、切片选择策略等。
NSSF主要用于为终端选择网络切片。
NEF主要用于支持能力和事件的开放。
UDM主要用于存储用户数据,例如签约数据、鉴权/授权数据等。
UDR主要用于存储结构化数据,存储的内容包括签约数据和策略数据、对外暴露的结构化数据和应用相关的数据。
AF主要支持与CN交互来提供服务,例如影响数据路由决策、策略控制功能或者向网络侧提供第三方的一些服务。
图2为5GS的漫游架构示意图,该5G网络包括HPLMN和VPLMN,HPLMN为UE的归属地网络,VPLMN为UE的漫游地网络,VPLMN和HPLMN通过vSEPP和hSEPP通信。在图2所示的场景下,业务可以部署在HPLMN,即,DN在HPLMN(未在图中显示),终端通过建立归属路由的会话与DN通信。可选的,业务也可以位于V-PLMN,即DN在V-PLMN,终端建立本地会话与V-PLMN的DN通信。可选地,对于归属路由的会话场景,可以在会话中插入中间UPF,使得终端可以访问位于V-PLMN中的数据网络中的业务。具体的架构可以参考TS(technical specification,技术标准)23.548。
如图2所示,在VPLMN中,UE通过RAN设备接入5G网络,UE通过N1接口(简称N1)与AMF通信;RAN设备通过N2接口(简称N2)与AMF通信;RAN设备通过N3接口(简称N3)与UPF通信;SMF通过N4接口(简称N4)与UPF通信。在HPLMN,UPF通过N6接口(简称N6)接入DN;UPF通过N4接口(简称N4)与SMF通信。且VPLMN内的UPF与HPLMN内的UPF通过N9接口(简称N9)通信。此外,图2所示的VPLMN的NSSF、NEF、AMF、SMF、NRF、或者PCF等控制面功能采用服务化接口进行交互。比如,AMF对外提供的服务化接口为Namf;SMF对外提供的服务化接口为Nsmf;NSSF对外提供的服务化接口为Nnssf;NEF对外提供的服务化接口为Nnef;NRF对外提供的服务化接口为Nnrf;PCF对外提供的服务化接口为Npcf。图2所示的HPLMN的UDM、AUSF、PCF、NRF、NSSF、AF、或者NEF等控制面功能也采用服务化接口进行交互。比如,AUSF对外提供的服务化接口为Nausf;UDM对外提供的服务化接口为Nudm;AF对外提供的服务化接口为Naf。图2所示的两个之间的“Nxx”表示这两个之间的接口,具体不再一一例举。
如图3所示,在漫游架构下,VPLMN中的网元与HPLMN中的网元进行通信,具体流程如下:
S301,vNF消费实体(consumer)与v-安全边缘保护代理(security edge protection proxy,SEPP)建立安全传输层协议(transport layer security,TLS)连接。
vNF消费实体为VPLMN中的功能网元,如V-UPF、V-AMF、V-SMF等。vSEPP是指VPLMN对应的SEPP。vNF消费实体与vSEPP可以互相验证对方的可信凭据(也即证书),并在彼此都验证通过的情况下,建立vNF消费实体与vSEPP之间的TLS连接。
S302,vSEPP与hSEPP建立TLS连接。
hSEPP是指HPLMN对应的SEPP。vSEPP与hSEPP可以互相验证对方的可信凭据,并在彼此都验证通过的情况下,建立vSEPP与hSEPP之间的TLS连接。
S303,hSEPP与hNF提供实体(producer)建立TLS连接。
hNF提供实体为HPLMN中的功能网元,如H-UPF、H-AMF、H-SMF等。hNF提供实体与hSEPP可以互相验证对方的可信凭据,并在彼此都验证通过的情况下,建立hNF提供实体与hSEPP之间的TLS连接。
S304,vNF消费实体与hNF提供实体交互业务数据。
通过上述S301-S304逐跳建立TLS连接的方式,vNF消费实体与hNF提供实体之间的路由路径被打通,用以通过路由方式交互彼此的业务数据。
可以看出,上述逐跳建立TLS连接的方式可能存在如下技术问题:
vNF消费实体与hNF提供实体之间的连接并不是端到端的直接通信,如vNF消费实体和hNF提供实体并没有直接对对端进行校验,而是通过验证凭据的方式,配合vSEPP和hSEPP逐跳建立TLS连接,这就导致任何一个恶意的网元都可以通过窃取等手段持有一个合法的凭据进行通信,存在安全风险。
2、远程证明(remote attestation)技术
近年来,随着嵌入式系统、网络物理系统和物联网设备的数量大幅增加,这些系统或设备的 已经涉及到了日常生活的许多场景,如家庭、办公室和工厂等。这些系统或设备可以接入到互联网,用以为用户提供相应的网络服务,但同时也扩大了攻击者的攻击面。例如,攻击者的恶意软件可以在这些系统或设备的驱动升级时,影响其安全性或者窃取隐私数据。或者,攻击者的恶意软件还可能将这些系统或设备转变为“僵尸”设备,即被恶意操控成为分布式拒绝服务(
distributed denial of service,DDoS)攻击的来源。但是,受限于成本、尺寸和功率等因素,安全性通常不是这些系统或设备的优先考虑事项,使得其难以实现自行防止攻击。
这种情况下,我们可以通过远程证明技术来验证这些系统或设备的安全性,以确定其是否受到攻击。远程证明包括度量实体(attester)和验证实体(verifier)。度量实体和验证实体可以分离,例如度量实体可以部署在这些系统或设备侧,验证实体可以部署在远程。验证实体可以请求度量实体对这些系统或设备进行度量,以获得证据(evidence)。验证实体可以根据这些证据,验证这些系统或设备的安全性。下面具体介绍。
图4为远程证明的流程示意图,如图4所示,远程证明的流程包括:
S401,验证实体向度量实体发送挑战消息。相应的,度量实体接受来自挑战方的挑战消息。
挑战消息可以携带有请求信息。该请求信息用以请求度量实体进行度量,如请求度量实体对上述系统或设备进行度量。挑战消息还可以携带本次度量唯一对应的随机数。该随机数用于度量实体度量使用。
S402,度量实体执行度量。
度量实体可以根据挑战消息,从上述系统或设备进行度量获取度量所需的证据,如获取这些系统或设备内部的程序或文件等,并根据随机数计算这些程序或文件对应的散列值。
S403,度量实体向验证实体发送响应消息。相应的,验证实体接收度量实体的响应消息。
响应消息用可以用于指示度量完成。响应消息可以携带上述散列值。
S404,验证实体执行验证。
验证实体可以将响应消息中的散列值与上述系统或设备的预设散列值比较。如果响应消息中的散列值与系统或设备的预设散列值相同,则表示这些系统或设备的程序或软件未被篡改,因此验证实体可以确定这些系统或设备是可信设备,也即确定验证通过。如果响应消息中的散列值与系统或设备的预设散列值不同,则表示这些系统或设备的程序或软件可能被篡改,因此验证实体可以确定这些系统或设备是不可信设备,也即确定验证失败。
3、网络功能虚拟化(network functions virtualization,NFV)
NFV是指将传统类型的通信设备的网络功能与其物理设备剥离,然后以软件的形式运行在商业现成主机(commercial off-the-shelf,COTS)上。也可以说,NFV是通过借用互联网技术(internet technology,IT)中虚拟化技术实现的虚拟实体(Virtual Instance),将传统的通信设备的通信技术(conmmunication technology,CT)业务部署到虚拟实体上。虚拟实体可以是虚拟机(virtual machine,VM)或容器(container),或者其他任何可能的虚拟化功能实体,对此不做具体限定。
图5为NFV的架构示意图,如图5所示,NFV包括:网络功能虚拟化基础架构(network functions virtualization infrastructure,NFVI)、虚拟网络功能(virtual network function,VNF)、网元管理系统(element management system,EMS)、管理、自动化和网络编排(management and orchestration,MANO)。
其中,NFVI可以用于为VNF提供虚拟资源。NFVI包括硬件资源,例如硬件的网络、计算、存储等设备。以及,NFVI还包括软件资源,例如虚拟化层(virtualization layer),虚拟化层中可以包括虚拟机管理程序(hypervisor)或容器管理系统。虚拟化层可以将硬件资源虚拟化为虚拟资源,例如虚拟的网络、计算、存储等功能,以供VNF使用。
EMS与VNF通常是一一对应的关系,用以对VNF的功能进行配置和管理。
VNF是虚拟化的NF。VNF可以用于提供网络服务,例如数据转发、文件共享、目录服务和IP配置等等。VNF的形态可以是应用软件,也即可以是一个提供网络服务的应用软件。VNF可以部署在VM或者容器中。以VM为例,一个VNF可以部署到一个或多个VM上,也即这一个或多个VM可以共同提供这一个VNF。由于运营商网络可能不感知VNF,VNF也可以理解为运营商网络中的NF。这种情况下,如果VNF提供网络服务不同,则NF的形态也可能不同。例如, 如果VNF提供数据传输服务,则NF可以是UPF网元;如果VNF提供移动性管理服务,则NF可以是AMF网元;如果VNF提供会话管理服务,则NF可以是SMF网元;如果VNF提供策略管理服务,则NF可以是PCF网元,然后以此类推。本申请实施例中,VNF可以具有独立的标识(identifier,ID),如VNF的标识,用以直接标识VNF。或者,VNF也可以不具有独立的标识,该VNF可以由与该VNF相关的其他标识间接标识。例如,一个或多个VM的标识可以用于间接标识这一个或多个VM提供的VNF,或者NF的标识也可以用于间接标识对应的VNF。可以理解,由于业务可能无法感知VNF,因此对于业务而言,VNF即为NF,或者说VNF也可以理解为NF。
MANO可以提供用于管理NFVI和VNF的框架,例如,MANO可以包括:网络功能虚拟化编排器(network functions virtualization orchestrator,NFVO)、虚拟化基础架构管理(virtualized infrastructure management,VIM)、以及虚拟网络功能管理者(network functions virtualization manager,VNFM)。
NFVO用于网络业务(network service)的部署和管理,并根据网络业务协调VNF的部署和管理。NFVO可以对接运营支撑系统(operations support system,OSS)或业务支撑系统(business support system,BSS),以获得网络业务的业务描述。NFVO可以根据业务描述,部署和管理对应的网络业务。例如,创建网络业务、管理网络业务的生命周期等等。NFVO可以根据网络业务,协调VIM和VNFM部署或管理对应的VNF。
VNFM用于部署或管理对应的VNF。例如,VNFM可以从NFVO获得虚拟网络功能描述符(virtualized network function descriptor,VNFD),以根据VNFD增加VNF、删除VNF、查找VNF、或者管理VNF,如对VNF的状态监控和调整。
VIM用于控制NFVI为VNF提供对应的虚拟资源。例如,VIM可以根据NFVO调度,控制NFVI为VNF的部署或管理提供对应的虚拟资源。VIM可以是一个云平台,例如开源的云平台,如OpenStack,或者商业的云平台,如VMWare。
4、基于远程证明的VNF安全方案
图6为基于远程证明的NFV的架构示意图,如图6所示,VNFs在3GPP定义的网络中的实例是各种NF,这些NF也可以认为是部署在3GPP定义的网络,也即业务域。但是,在NFV架构层面,VNFs可认为部署在NFV域。验证实体可以部署在NFV域,如MANO。度量实体也可以部署在NFV域,如NFVI的虚拟化层。此外,由于NFV通常属于基于服务的架构(service based architecture,SBA)架构,例如NFV内的网元或功能之间可以基于第三代合作伙伴计划(3rd generation partnership project,3GPP)协议通信,而度量实体和验证实体通常不属于SBA架构,例如度量实体和验证实体之间通常基于欧洲电信标准协会(european telecommunications standards institute,ETSI)协议通信,因此还可以在VNF与验证实体之间部署配置文件和证明检查功能(profile and attestation check function,PACF),用于通过协议转换实现VNF与验证实体之间的通信。
在此基础上,3GPP-服务架构组3(service and archtacture aspects 3)#105e-213897大致定义了基于远程证明的VNF安全方案的跨域(业务域-NFV域)实现流程,具体如图7所示:
S701,NF消费实体向网络存储功能(network repository function,NRF)发送管理NF注册请求(Nnrf_NFManagement_NFRegister Request)消息。相应的,NRF接收来自NF消费实体的管理NF注册请求。
NF消费实体也可以理解为VNF,如某个不受信任的(untrusted)VNF。管理NF注册请求可携带NF配置文件(NF profile),用于NF的注册管理使用,如包括NF消费实体的标识。
S702,NRF向PACF发送度量请求(Attestation_request)消息。相应的,PACF接收NRF的度量请求。
度量请求用于请求对NF消费实体进行度量,可包括NRF签名后的NF配置文件。
S703,PACF触发对NF消费实体的度量流程。
PACF验证NF配置文件的签名。在验证通过的情况下,PACF使用NF消费实体的标识,触发度量流程。例如,PACF可以向验证实体发送度量策略,以及被度量的网元,如NF消费实体的描述。验证实体可以根据度量策略以及NF消费实体的描述,请求度量实体对该NF消费实体的各 种数据进行度量,以获得相应的证据。验证实体可以验证该证据,从而得到度量结果(attestation results),并向PACF发送该度量结果。
S704,PACF向NRF发送度量响应(Attestation_response)消息。相应的,NRF接收PACF的度量响应。
度量响应可用于响应上述度量请求,如包括NF消费实体的度量结果。可以理解,PACF从验证实体获得的度量结果为ETSI协议支持的度量结果,PACF可以将ETSI协议的度量结果转为3GPP协议支持的度量结果,然后将3GPP协议支持的度量结果携带到度量响应中。
S705,NRF存储NF的配置文件。
如果度量结果指示认证通过,则NRF确定NF消费实体可信,标记NF消费实体可用,并存储NF消费实体的NF的配置文件。但是,如果度量结果指示认证失败,则NRF确定NF消费实体不可信,触发恢复过程,以处理不可信的NF消费实体。
S706,NRF向NF消费实体发送管理NF注册响应(Nnrf_NFManagement_NFRegister Response)消息。相应的,NF消费实体接收来自NRF的管理NF注册响应。
在NRF确定NF消费实体可信的情况下,NRF可以向NF消费实体发送管理NF注册响应,用以指示NRF已确认NF消费实体的注册。此外,S706为可选步骤,例如,在NF消费实体不可信的情况下,S706可能不执行。
可以看出,基于远程证明的VNF安全方案的跨域实现流程可能存在如下问题:
1)上述跨域实现流程主要应用到NRF注册流程,也即,只在网元注册时对网元进行远程证明,以确定网元在注册时是否可信,而无法确定网元在其他情况下(如发起业务、切换业务时)是否仍可信,存在安全风险。
2)上述跨域实现流程的实现是基于业务域内的网元对NFV域中的验证实体默认信任,但业务域内的网元无法得知该验证实体实际是否可信,导致流程存在安全风险。
3)由于NF消费实体无法直接对验证实体的度量结果进行验证,导致每次验证都需要通过PACF完成。在此基础上,如果将通过PACF完成校验的方式增强,如扩展到多种业务流程中动态触发,可能会导致PACF负载过大,在实现中容易出现PACF单点故障问题。
综上,针对上述技术问题,本申请实施例提出了如下技术方案,用以避免跨域通信出现安全风险。
下面将结合附图,对本申请中的技术方案进行描述。
本申请实施例的技术方案可以应用于各种通信系统,例如无线保真(wireless fidelity,WiFi)系统,车到任意物体(vehicle to everything,V2X)通信系统、设备间(device-todevie,D2D)通信系统、车联网通信系统、第四代(4th generation,4G)移动通信系统,如长期演进(long term evolution,LTE)系统、全球互联微波接入(worldwide interoperability for microwave access,WiMAX)通信系统、5G,如新空口(new radio,NR)系统,以及未来的通信系统等。
本申请将围绕可包括多个设备、组件、模块等的系统来呈现各个方面、实施例或特征。应当理解和明白的是,各个系统可以包括另外的设备、组件、模块等,并且/或者可以并不包括结合附图讨论的所有设备、组件、模块等。此外,还可以使用这些方案的组合。
另外,在本申请实施例中,“示例的”、“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用示例的一词旨在以具体方式呈现概念。
本申请实施例中,“信息(information)”,“信号(signal)”,“消息(message)”,“信道(channel)”、“信令(singaling)”有时可以混用,应当指出的是,在不强调其区别时,其所要表达的含义是匹配的。“的(of)”,“相应的(corresponding,relevant)”和“对应的(corresponding)”有时可以混用,应当指出的是,在不强调其区别时,其所要表达的含义是匹配的。此外,本申请提到的“/”可以用于表示“或”的关系。
本申请实施例描述的网络架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案,并不构成对于本申请实施例提供的技术方案的限定,本领域普通技术人员可知,随着网络架构的演变和新业务场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。
为便于理解本申请实施例,首先以图8中示出的通信系统为例详细说明适用于本申请实施例的通信系统。示例性的,图8为本申请实施例提供的通信方法所适用的一种通信系统的架构示意图。
如图8所示,该通信系统主要包括:不同的信任域内的网元,具体可以是信任域1内的网元和信任域2内的网元、验证实体1,以及验证实体2。
其中,信任域可以有多种划分方式。一种可能的方式,信任域可以按运营商划分,不同运营商网络,也即不同的PLMN可以被划分为不同的信任域。例如,信任域1是PLMN1,信任域2是PLMN2。另一种可能的方式,信任域可以按网络功能划分。例如,核心网虚拟化设施中的业务域和NFV域,信任域1是NFV域,信任域2是业务域。同一个信任域内的网元有统一的管理和认证技术,用以实现该信任域内的不同网元可以默认对方可信,从而建立业务连接。但是,对于来自不同信任域的网元(跨信任域的网元),这些网元通常无法直接确认对方是否可信,需要额外步骤来建立彼此之间的信任关系,以获得对方提供的服务,具体可参考下文,不再赘述。
信任域1内的网元可以包括NF消费实体。例如,信任域1是PLMN1,NF消费实体可以包括如下任一项:AMF1、UPF1、或SMF1等。信任域1是NFV域,NF消费实体可以是VNF。信任域1内的还可以包括其他网元/设备,如UE、代理功能(proxy function),也可以理解为上述的SEPP,不做限定。
信任域2内的网元可以包括NF提供实体。例如,信任域1是PLMN2,NF消费实体可以包括如下任一项:AUSF2、SMF2、或UPF2等。信任域2是业务域,NF消费实体可以是NF。信任域2内的还可以包括其他网元/设备,如代理功能,也可以理解为上述的SEPP,不做限定。
验证实体1可以部署在信任域1中,可以是NFVI中的网元(如云管/网管)、NFVI中的网元的验证功能(如云管/网管的验证功能)、运营商网络(如PLMN1)中用于提供验证功能的网元、或者运营商网络(如PLMN1)中的网元的验证功能。
验证实体2可以部署在信任域2中,可以是NFVI中的网元(如云管/网管)、NFVI中的网元的验证功能(如云管/网管的验证功能)、OSS/BSS、OSS/BSS中的验证功能、运营商网络(如PLMN2)中用于提供验证功能的网元、或者运营商网络(如PLMN2)中的网元的验证功能。
需要说明的是,验证实体1是NFVI中的网元、NFVI中的网元的验证功能,以及验证实体2也是NFVI中的网元、NFVI中的网元的验证功能,此时,验证实体1和验证实体2是不同的网元或功能。或者,验证实体1是NFVI中的网元、NFVI中的网元的验证功能,验证实体2是OSS/BSS、OSS/BSS中的验证功能,此时,验证实体1和验证实体2可认为存在上下级关系,如验证实体2可用于管理验证实体1,验证实体2可以验证该验证实体1是否可信,但是验证实体1可能无法确定验证实体2是否可信。
验证实体1和验证实体2都可以属于可信第三方,也即可以由可信第三方部署。在此基础上,一种情况是:验证实体1是所有信任域(包括信任域1和信任域2)内的网元都信任的验证实体。例如,可信第三方针对所有信任域配置验证实体1,如验证实体1的证书被预配置在所有信任域内的网元的操作系统中。此时,验证实体1的度量结果可以被所有信任域内的网元直接验证,无需验证实体2执行进一步验证。另一种情况是:验证实体1是信任域1内的网元信任的验证实体,但验证实体1不被其它信任域,如信任域2内的网元直接信任。例如,可信第三方针对信任域1配置验证实体1,如验证实体1的证书被预配置在信任域1内的网元的操作系统中,而信任域2内的网元的操作系统未配置验证实体1的证书。此时,验证实体1的度量结果便不能被信任域2内的网元直接验证。这种情况下,信任域2内的网元可以请求自身能够信任的验证实体2,对验证实体1进行验证,以确定验证实体1是否可信,以及验证实体1的度量结果是否可信。
还需要说明的是,信任域可以是针对网元定义的概念,例如,如果两个网元之间默认具有信任关系,则可以认为这两个网元属于同一个信任域。但是,网元可以是业务层面的概念,验证实体1和验证实体2是安全层面的概念,因此验证实体1和验证实体2可能无法被理解为常规意义上的网元,信任域的概念也可能不适用于验证实体1和验证实体2,也即,虽然验证实体1和验证实体2可以具有信任关系,如上下级的管理关系,但验证实体1和验证实体2仍可以属于不同的信任域。
本申请实施例中,信任域1内的网元(如NF消费实体,或者除NF消费实体以外的网元)可以跨域请求信任域2内的网元(如NF提供实体,或者除NF提供实体以外的网元),触发NF提供实体提供NF消费实体所需的服务。信任域2内的网元可以响应信任域1内的网元的请求,触发验证NF消费实体是否可信。或者,信任域2内的网元也可以自行触发NF提供实体提供NF消费实体所需的服务,从而触发验证NF消费实体是否可信。例如,信任域2内的网元请求信任域1内的网元提供用于表征NF消费实体是否可信的度量结果。这样,信任域1内的网元可以根据信任域2内的网元的请求,触发验证实体1对NF消费实体进行可信度量,以向信任域1内的网元反馈NF消费实体的度量令牌(token)。此时,如果验证实体1是所有信任域内的网元都信任的验证实体,则信任域1内的网元可以验证NF消费实体的度量令牌,以确定NF消费实体是否可信。如果验证实体1是信任域1内的网元信任的验证实体,且验证实体1不被其它信任域内的网元信任,则信任域2内的网元可以请求自身信任的验证实体2对验证实体1进行验证,以便在确定验证实体1可信的情况下,再根据NF消费实体的度量令牌,确定NF消费实体是否可信。如果信任域2内的网元确定NF消费实体可信,则信任域2内的网元响应信任域1内的网元的请求,触发NF消费实体提供NF提供实体所需的服务;否则,如果信任域2内的网元确定NF消费实体不可信,则信任域2内的网元可能拒绝触发NF消费实体提供NF提供实体所需的服务。
可以理解,本申请实施例中,不同的PLMN可以通过标号,如“1”、“2”、“3”进行区分,例如,PLMN1、PLMN2等,以此类推。对于归属于PLMN1的某个UE,如UE1,PLMN1是UE1的归属网络,也可以称为UE1的HPLMN,如果UE1移动到PLMN2,则PLMN2是UE的拜访网络,也可以称为UE1的VPLMN。类似的,对于归属于PLMN2内的某个UE,如UE2,PLMN2是UE2的归属网络,也可以称为UE2的HPLMN,如果UE2移动到PLMN1,则PLMN1是UE的拜访网络,也可以称为UE2的VPLMN。本申请实施例中,不同PLMN内的网元可以通过标号,如“1”、“2”、“3”进行区分。例如,PLMN1内的网元可以为AMF1、UPF1、SMF1、AUSF1等,PLMN2内的网元可以为AMF2、UPF2、SMF2、AUSF2等,以此类推。
为方便理解,下面将结合图9-图14,通过方法实施例具体介绍上述通信系统中各网元/设备之间的交互流程。本申请实施例提供的通信方法可以适用于上述通信系统,并具体应用到上述通信系统中提到的各种场景,下面具体介绍。
实施例1:
示例性的,图9为本申请实施例提供的通信方法的流程示意图一。在实施例1中,信任域1内的网元1可以请求信任域2内的网元2,触发NF提供实体提供信任域2的服务,如NF消费实体所需的服务。此时,网元2可触发网元1对NF消费实体的可信度量,以便在确定NF消费实体可信的情况下,提供相应的服务,避免出现安全风险。
具体的,如图9所示,该通信方法的流程如下:
S901,网元1向网元2发送服务建立请求。相应的,网元2接收来自网元1的服务建立请求。
网元1可以是NF消费实体,或者NF消费实体关联的网元,如用于管理NF消费实体的网元。类似的,网元2可以是NF提供实体,或者NF提供实体关联的网元,如用于管理NF提供实体的网元。
服务建立请求可以用于请求NF提供实体提供NF消费实体所需的服务,如可以是认证请求(authentication request)、注册请求(register request)、会话创建请求(PDU session create request)消息、或者其他任何可能的消息,不做限定。
其中,服务建立请求可包括:NF消费实体的标识,以及服务的描述(可选)。
NF消费实体的标识可用于表征NF消费实体在信任域1内的身份。服务的描述可用于表征服务触发实体触发服务的如下至少一项:服务目的、服务原因、或服务限制条件。服务目的可用于表征该服务最终需要实现的目标,如认证、注册、创建会话等等。服务原因可用于表征服务触发实体因为什么原因触发该服务,如UE需要注册,UE需要建立会话等。服务限制条件可以用于表征实现该服务需要满足的条件,如时效性,即该服务在什么时间段内有效、指定网元,即该服务需要哪些指定的网元参与、或者其他任何的条件,不做限定。
服务触发实体可以是网元1,也即网元1可根据自身的需求,发送服务建立请求。或者,服务 触发实体也可以是其他设备,如信任域1内的UE,也即网元1可根据该UE的需求,发送服务建立请求。此时,服务建立请求还可以包括该UE的标识,如UE的用户永久标识符(subscription permanent identifier,SUPI)、或通用公共用户标识(generic public subscription identifier,GPSI),不做限定。
网元1可直接向网元2发送服务建立请求。或者,网元1也可以通过代理功能,向网元2发送服务建立请求。例如,代理功能可以先接收到来自网元1的服务建立请求,再向网元2转发该服务建立请求。代理功能可以是信任域2内的网元(如图9所示),或者代理功能也可以是信任域1内的网元,不做限定。
可以理解,S901为可选步骤,例如,网元2也可以自行触发NF提供实体提供NF消费实体所需的服务。
S902,网元2确定是否有NF消费实体的可信度量记录。
由于验证实体1对NF消费实体的可信度量可用于网元2确定NF消费实体是否可信,因此在网元2不确定NF消费实体是否可信的情况下,网元2可确定是否有NF消费实体的可信度量记录。
一种可能的实现方式中,网元2可以通过NF消费实体的度量凭证,确定是否有NF消费实体的可信度量记录。
其中,验证实体1对NF消费实体的每一次可信度量,都可生成该NF消费实体的度量凭证(token),具体可参考下述S904的相关介绍,不再赘述。NF消费实体的度量凭证可以包括:NF消费实体的标识、度量结果。度量结果可用于表征这次对NF消费实体的可信度量是通过还是失败,即表征NF消费实体是可信还是不可信。度量凭证还可以包括当前步骤可能不涉及的其他信元,具体也可参考下述S904的相关介绍,不再赘述。网元1可以向网元2提供NF消费实体的度量凭证。此时,如果网元1直接向网元2提供NF消费实体的度量凭证,则该度量凭证可以被网元2保存。或者,如果网元1通过代理功能,向网元2提供NF消费实体的度量凭证,则该度量凭证可以被代理功能,或者仍可以被网元2保存,不做限定。
方式1:网元2保存NF消费实体的度量凭证:
网元2可以默认保存NF消费实体的度量凭证,如不论该度量凭证中的度量结果表征NF消费实体是可信还是不可信,网元2都可以保存该度量凭证。当网元2接收到服务建立请求后,网元2可以从服务建立请求中获取NF消费实体的标识,以据此确定是否有NF消费实体的度量凭证,包括如下几种情况:
1)如果没有NF消费实体的度量凭证,则网元2当前无法确定NF消费实体是否可信,需要触发对NF消费实体的可信度量,触发执行S903。
2)如果有NF消费实体的度量凭证,则网元2可根据该度量凭证中的度量结果,确定NF消费实体是否可信。如果NF消费实体可信,则网元2无需再次触发对NF消费实体的可信度量,触发执行S909。如果NF消费实体不可信,则网元2可能拒绝触发N提供实体提供NF消费实体所需的服务。
3)如果有NF消费实体的度量凭证,则网元2可确定NF消费实体的度量凭证是否有效。例如,网元2可以确定当前时间是否在网元2预先为NF消费实体的度量凭证配置的时间段以内。如果当前时间在该时间段以外,则表示NF消费实体的度量凭证已失效,网元2当前无法确定该NF消费实体是否可信,触发执行S903。如果当前时间在该时间段以内,则表示NF消费实体的度量凭证有效,网元2可根据该度量凭证中的度量结果,确定NF消费实体是否可信。如果NF消费实体可信,则网元2触发执行S909。如果NF消费实体不可信,则网元2可能拒绝触发NF提供实体提供NF消费实体所需的服务。
或者,网元2可保存NF消费实体在可信情况下的度量凭证,如在该度量凭证中的度量结果表征NF消费实体是可信的情况下,网元2保存该度量凭证,否则,不保存该度量凭证。当网元2接收到服务建立请求后,网元2也可以从服务建立请求中获取NF消费实体的标识,以据此确定是否有NF消费实体的度量凭证,也包括如下几种情况:
1)如果没有NF消费实体的度量凭证,则网元2当前无法确定NF消费实体是否可信,触发 执行S903。
2)如果有NF消费实体的度量凭证,则网元2确定NF消费实体可信,触发执行S903。
3)如果有NF消费实体的度量凭证,则网元2可以确定该度量凭证是否有效,具体可参考上述,不再赘述。如果NF消费实体的度量凭证已失效,则网元2当前无法确定NF消费实体是否可信,触发执行S903。如果NF消费实体的度量凭证有效,则网元2确定NF消费实体可信,触发执行S909。
方式2:代理功能保存NF消费实体的度量凭证:
代理功能可主动向网元2提供自身保存NF消费实体的度量凭证。
具体的,当代理功能接收到服务建立请求后,可以从服务建立请求中获取NF消费实体的标识,以据此确定是否有NF消费实体的度量凭证。如果有NF消费实体的度量凭证,则代理功能可以向网元2发送该度量凭证,如将度量凭证携带到服务建立请求中,再向网元2发送该服务建立请求。如果没有NF消费实体的度量凭证,则代理功能可以将这一情况告知网元2。例如,代理功能可以直接向网元2转发服务建立请求,也即该服务建立请求没有携带NF消费实体的度量凭证,用以隐式指示代理功能未保存NF消费实体的度量凭证。或者,代理功能也可以向网元2发送额外的消息,用以显示指示代理功能未保存NF消费实体的度量凭证。
或者,代理功能可根据网元2的请求,向网元2提供自身保存NF消费实体的度量凭证。
具体的,当网元2接收到服务建立请求后,网元2可根据该服务建立请求,向代理功能发送度量凭证请求,用以请求代理功能提供NF消费实体的度量凭证。例如,度量凭证请求可以是任何可能的消息,不做限定。度量凭证请求可以包括:NF消费实体的标识,以及度量凭证描述(可选)。度量凭证描述可用于表征度量凭证请求的目的是用于请求代理功能提供自身保存的度量凭证。度量凭证描述为可选信元,例如,在没有度量凭证描述的情况下,也可以通过度量凭证请求的消息类型,隐式指示度量凭证请求的目的。
可以理解,度量凭证描述为一种示例性的命名,如也可以替换为可信度量目的、可信度量描述等,不做限定。
当代理功能接收到度量凭证请求后,可以从度量凭证请求中获取NF消费实体的标识,以据此确定是否有NF消费实体的度量凭证。如果有NF消费实体的度量凭证,则代理功能可以向网元2发送该度量凭证,如发送携带该度量凭证的度量凭证响应。如果没有NF消费实体的度量凭证,则代理功能可以将这一情况告知网元2。例如,代理功能可以向网元2发送未携带该NF消费实体的度量凭证的度量凭证响应,用以隐式指示代理功能未保存NF消费实体的度量凭证。或者,代理功能也可以不向网元2发送任何可能消息,以通过超时未发送消息来隐式指示代理功能未保存NF消费实体的度量凭证。
如果网元2从代理功能获得NF消费实体的度量凭证,则网元2可以根据该度量凭证,确定该NF消费实体是否可信,具体实现可参考上述方式1的相关介绍,不再赘述。如果网元2未从代理功能获得NF消费实体的度量凭证,则网元2当前无法确定NF消费实体是否可信,触发执行S903。
可以理解,上述方式1和方式2也可以结合实施,如网元2在确定自身没有保存NF消费实体的度量凭证的情况下,再请求代理功能提供NF消费实体的度量凭证。
另一种可能的实现方式中,NF提供实体可以直接确定是否有NF消费实体的可信度量记录。
其中,网元1可以向网元2提供NF消费实体的度量凭证,具体可参考上述相关介绍,不再赘述。此时,如果网元1直接向网元2提供NF消费实体的度量凭证,则网元2可以根据该度量凭证,生成并保存NF消费实体的可信度量记录,如该可信度量记录可以包括:NF消费实体的标识,以及记录时间。记录时间可用于表征该可信度量记录的生成时间点。或者,如果网元1通过代理功能,向网元2提供NF消费实体的度量凭证,则代理功能可以根据该度量凭证,生成并保存NF消费实体的可信度量记录,或者仍由网元2根据该度量凭证,生成并保存NF消费实体的可信度量记录,不做限定。
方式3:网元2保存NF消费实体的可信度量记录:
当网元2接收到服务建立请求后,网元2可以获取NF消费实体的标识,以据此确定是否有 NF消费实体的可信度量记录,包括如下几种情况:
1)如果没有NF消费实体的可信度量记录,则网元2当前无法确定NF消费实体是否可信,需要触发对NF消费实体的可信度量,触发执行S903。
2)如果有NF消费实体的可信度量记录,则网元2确定NF消费实体可信,触发执行S909。或者,如果有NF消费实体的可信度量记录,则网元2可确定该度量凭证是否有效。例如,网元2可确定当前时间与记录时间的间隔时长,是否小于网元2为NF消费实体的可信度量记录配置的预设时长。如果间隔时长大于或等于预设时长,则表示NF消费实体的可信度量记录失效,网元2当前无法确定该NF消费实体是否可信,触发执行S903。如果间隔时长小于预设时长,则表示NF消费实体的可信度量记录有效,网元2确定NF消费实体可信,触发执行S909。
方式4:代理功能保存NF消费实体的可信度量记录:
代理功能可主动向网元2提供自身保存NF消费实体的可信度量记录,具体实现与上述方式2类似,可参考理解,不再赘述。或者,代理功能可根据网元2的请求,向网元2提供自身保存NF消费实体的可信度量记录,具体实现也与上述方式2类似,可参考理解,不再赘述。相应的,如果网元2从代理功能获得NF消费实体的可信度量记录,则网元2可以根据该可信度量记录,确定该NF消费实体是否可信,具体实现可参考上述方式3的相关介绍,不再赘述。如果网元2未从代理功能获得NF消费实体的可信度量记录,则网元2当前无法确定NF消费实体是否可信,触发执行S903。
可以理解,上述方式3和方式4也可以结合实施,如网元2在确定自身没有保存NF消费实体的可信度量记录的情况下,再请求代理功能提供NF消费实体的可信度量记录。
还可以理解,S902为可选步骤,例如,如果网元2或者代理功能不保存NF消费实体的可信度量记录,则S902不执行。
S903,网元2向网元1发送度量触发请求。相应的,网元1接收来自网元2的度量触发请求。
度量触发请求可以用于请求网元1触发对NF消费实体的可信度量,或者说请求网元1提供NF消费实体的度量凭证。度量触发请求可以是任何可能的消息,不做限定。网元2直接向网元1发送度量触发请求,或者也可以通过代理功能向网元1发送度量触发请求,不做限定。度量触发请求可以包括:新鲜值、NF消费实体的标识(可选),以及可信度量策略(可选)。
其中,新鲜值可用于验证实体1可信度量使用,如标识本次可信度量生成的度量凭证,以确保该度量凭证是该度量触发请求对应的度量凭证,或者说针对该度量触发请求生成的度量凭证,从而确保本次可信度量的唯一性。新鲜值可以是随机数、时间戳,如时间、日期等,不做限定。
NF消费实体的标识可以用于表征本次被可信度量的对象为NF消费实体。NF消费实体的标识是可选信元,例如,如果网元2不指示NF消费实体的标识,则网元1也可以默认触发验证实体1对NF消费实体进行可信度量。
可信度量策略可用于指示验证实体1需要按照可信度量策略指定的方式执行可信度量。例如,可信度量策略可以指示验证实体1对NF消费实体是否可信启动进行可信度量、或者指示验证实体1对NF消费实体是否有指定的软件版本进行可信度量等,不做限定。可信度量策略是可选信元,例如,如果网元2不指示可信度量策略,则验证实体1可以按照自身默认的可信度量策略执行可信度量。
S904,网元1触发验证实体1对NF消费实体进行可信度量。
其中,网元1可以向验证实体1发送度量请求,度量请求可以用于触发验证实体1对NF消费实体进行可信度量,可以是任何可能的消息,不做限定。度量请求可以包括:NF消费实体的标识、新鲜值,以及可信度量策略(可选)。其中,可信度量策略为可选信元,例如,如果网元1在S903中获得可信度量策略,则网元1可以将该可信度量策略携带到度量请求中,否则,度量请求可以不包含可信度量策略。
验证实体1接收到度量请求后,可以指示验证实体1对应的度量实体(图9未示出)对NF消费实体进行可信度量。例如,验证实体1可以向度量实体发送NF消费实体的标识/VNF的标识,以及可信度量策略(可选)。
其中,NF消费实体是VNF实例化的表现。对于度量实体而言,NF消费实体是VNF,也即, 度量实体可以感知到VNF,而可能无法感知到NF消费实体。因此,如果度量实体可以感知到NF消费实体,则验证实体1发送NF消费实体的标识。如果度量实体无法感知到NF消费实体,则验证实体1可以将NF消费实体的标识转换为度量实体能够识别的VNF的标识,如包括如下至少一项:VNF的标识本身、VNF的机房号、VNF的主机号、或VNF的主机上的操作系统号等等,也可以称为VNF的描述。例如,验证实体1可以根据NF消费实体的标识,遍历NF消费实体的标识与VNF的标识的映射关系表,以确定NF消费实体的标识对应的VNF的标识,从而向度量实体发送该VNF的标识。其中,该映射关系表可以配置在验证实体1本地,或者配置在其他设备/网元,不做限定。例如,验证实体1是NFVO中的功能,其他设备/网元可以是VNFM,这种情况下,NFVO可以访问VNFM,以获得VNF的标识。
其中,可信度量策略为可选信元。例如,如果验证实体1获得来自网元1的可信度量策略,则验证实体1可以向度量实体提供该可信度量策略,否则,不提供可信度量策略,或者提供验证实体1默认的可信度量策略。
度量实体可以根据NF消费实体的标识/VNF的标识,以及可信度量策略(可选),对NF消费实体进行可信度量,以向验证实体1反馈度量证据。例如,度量实体可以根据VNF的标识,对VNF进行寻址,从而找到VNF对应的至少一个VM。度量实体可以对这至少一个VM进行可信度量,以获得度量证据,并向验证实体1反馈携带该度量证据的度量响应。其中,度量响应可以是任何可能的消息,不做限定。度量证据可以包括如下至少一项:NF消费实体的运行数据、或NF消费实体的通信数据。NF消费实体的运行数据可以包括如下至少一项:可信启动数据、软件版本、密钥的推演、存储与更新记录、关键文件的签名、关键代码的签名、内存和/或CPU占用率、或者其他任何可能的数据等,不做限定。NF消费实体的通信数据可以包括如下至少一项:通信数据量、通信时的异常情况次数、业务告警次数、或者其他任何可能的数据等,不做限定。
验证实体1在接收到度量实体反馈的度量证据后,可以根据该度量证据,确定NF消费实体是否可信。例如,验证实体1可以确定如下至少一项是否匹配:可信启动数据是否与预设可信启动数据匹配、软件版本是否与预设软件版本匹配、关键文件的签名是否与预设文件签名匹配、关键代码的签名是否与预设代码签名匹配、网络流量数据是否与预设流量数据匹配、内存和/或CPU占用率是否与预设占用率匹配、密钥的推演、存储与更新记录是否与预设记录匹配、传输时的异常情况次数是否与预设次数匹配、或者业务告警次数是否与预设次数匹配等等。如果上述不匹配的数据数目大于或等于预设数目,则验证实体1可确定NF消费实体不可信。如果上述不匹配的数据数目小于预设数目,则验证实体1可确定NF消费实体可信。预设数目可以根据实际需求设置,对此不限定。验证实体1可以根据生成针对本次可信度量的NF消费实体的度量凭证,并向网元1发送NF消费实体的度量凭证。其中,NF消费实体的度量凭证可以包括如下至少一项:新鲜值、NF消费实体的标识、验证实体1的标识、验证实体1的签名、可信度量策略、度量结果、可信度量时间等。其中,验证实体1的标识可以用于表征验证实体1在信任域1内的身份,可信度量时间可以用于表征验证实体1触发可信度量的时间,此外,NF消费实体的度量凭证中的其他参数可以参考上述相关介绍,不再赘述。
S905,网元1向网元2发送度量触发响应。相应的,网元2接收来自网元1的度量触发响应。
度量触发响应可以用于响应上述度量触发请求,用于表征量已完成对NF消费实体的可信度。度量触发响应可以是任何可能的消息,不做限定。网元1可以直接向网元2发送度量触发响应,或者也可以通过代理功能向网元2发送度量触发响应,不做限定。度量触发响应可以包括:NF消费实体的度量凭证,以及验证实体1的证明信息(可选)。
其中,验证实体1的证明信息包括如下至少一项:验证实体1的部署证据、验证实体1所属机构的凭据、验证实体1的签约注册信息、或者其他任何可能的信息,用以辅助验证该验证实体1是否可信。验证实体1的证明信息是可选信元,例如,也可仅通过NF消费实体的度量凭证验证该验证实体1是否可信,此时,度量触发响应可以不包含验证实体1的证明信息。或者,如果验证实体1默认能够被网元2直接信任,则度量触发响应也可以不包含验证实体1的证明信息。
可以理解,验证实体1的证明信息可以预配置在网元1,或者网元1预先从验证实体1获取,不做限定。验证实体1的证明信息为一种示例性的命名,不做限定,如也可以替换为验证实体1 的辅助证明信息、验证实体1的辅助信息等。
S906,网元2触发验证实体2确定验证实体1是否可信。
其中,如果验证实体1无法直接被网元2信任,则网元2通常也没有配置验证实体1相关的配置文件,也无法验证该验证实体1是否可信。或者,由于网元2可以是常规的核心网网元,其可能不具备验证验证实体的功能。这种情况下,网元2可以触发验证实体2确定该验证实体1是否可信。
例如,网元2接收到度量触发响应后,可以通过PACF(图9未示出)向验证实体2发送验证请求。验证请求可以用于触发验证实体2确定验证实体1是否可信。验证请求可以是任何可能的消息,如订阅请求消息,不做限定。其中,如果网元2未获得验证实体1的证明信息,则验证请求可以包括NF消费实体的度量凭证,也即网元2可以仅将NF消费实体的度量凭证携带到验证请求中。如果网元2获得验证实体1的证明信息,则验证请求可以包括如下至少一项:NF消费实体的度量凭证、或验证实体1的证明信息,也即网元2可以选择将NF消费实体的度量凭证和验证实体1的证明信息中的至少一项携带到验证请求中。验证实体2接收到验证请求后,可根据验证请求,确定验证实体1是否可信。下面具体介绍。
情况1:验证请求包括NF消费实体的度量凭证,验证实体2可以根据NF消费实体的度量凭证,确定验证实体1是否可信。例如,验证实体2可以根据NF消费实体的度量凭证中验证实体1的身份信息,确定验证实体1是否可信。验证实体1的身份信息可以包括如下至少一项:验证实体1的标识、或验证实体1的签名。
一种可能的验证方式中,验证实体2可以确定验证实体1的标识,是否在验证实体2预配置的可信名单或者黑名单中。如果验证实体1的标识在可信名单中,或者验证实体1的标识不在黑名单中,则验证实体2确定验证通过,也即验证实体1可信。否则,如果验证实体1的标识不在可信名单中,或者验证实体1的标识在黑名单中,则验证实体2确定验证失败,也即验证实体1不可信。
另一种可能的验证方式中,验证实体2可以确定验证实体1的签名,是否与验证实体2预配置的签名匹配。如果验证实体1的签名与预配置的签名不匹配,则验证实体2确定验证实体1不可信。如果验证实体1的签名与预配置的签名匹配,则验证实体2对验证实体1的签名进行验签。如果验证失败,则验证实体2确定验证实体1不可信。如果验证成功,则验证实体2确定验证实体1可信。
可以理解,上述各种验证方式也可以结合实施,例如,如果验证实体1的标识在验证实体2预配置的可信名单,且验证实体1对验证实体1的签名验签成功,则验证实体2确定验证实体1可信,否则,验证实体2确定验证实体1不可信。此外,上述验证方式仅为一些示例,还可能有其他的验证方式,本申请实施例不做限定。
情况2:验证请求包括验证实体1的证明信息,验证实体2可以根据NF验证实体1的证明信息,确定验证实体1是否可信。
一种可能的验证方式中,验证实体2可以根据验证实体1的部署证据,确定验证实体1是否部署在验证实体2预配置的可信区域内,如确定验证实体1的部署证据指示的部署位置是否位于验证实体2预配置的可信区域内。如果验证实体1部署在验证实体2预配置的可信区域内,则验证实体2确定验证通过,也即验证实体1可信。否则,如果验证实体1未部署在验证实体2预配置的可信区域内,则验证实体2确定验证失败,也即验证实体1不可信。
另一种可能的验证方式中,验证实体2可以根据验证实体1所属机构的凭据,确定验证实体1是否由验证实体2认可的结构部署,如确定验证实体1所属机构的凭据是否与验证实体2预配置的机构的凭据匹配。如果验证实体1由验证实体2认可的结构部署,则验证实体2确定验证通过,也即验证实体1可信。否则,如果验证实体1不由验证实体2认可的结构部署,则验证实体2确定验证失败,也即验证实体1不可信。
再一种可能的验证方式中,验证实体2可以确定验证实体1的签约注册信息,是否与验证实体2预配置的签约注册信息匹配。如果验证实体1的签约注册信息与验证实体2预配置的签约注册信息匹配,则验证实体2确定验证通过,也即验证实体1可信。否则,如果验证实体1的签约 注册信息与验证实体2预配置的签约注册信息不匹配,则验证实体2确定验证失败,也即验证实体1不可信。
可以理解,上述各种验证方式也可以任意结合实施,例如,如果验证实体1部署在验证实体2预配置的可信区域内、验证实体1由验证实体2认可的结构部署,且验证实体1的签约注册信息与验证实体2预配置的签约注册信息匹配,则验证实体2确定验证实体1可信,否则,验证实体2确定验证实体1不可信。此外,上述验证方式仅为一些示例,还可能有其他的验证方式,本申请实施例不做限定。
情况3:验证请求包括NF消费实体的度量凭证和验证实体1的证明信息,验证实体2可以根据NF消费实体的度量凭证和验证实体1的证明信息,确定验证实体1是否可信,具体实现可结合参考上述情况1和情况2的相关介绍,不再赘述。
验证实体2可以通过PACF(图9未示出),向网元2发送验证响应,验证响应可以用于指示验证实体1是否可信。例如,验证响应可以包括:验证实体1的标识,以及验证结果(可选),该验证结果可以用于指示验证是通过还是失败。验证响应可以是任何可能的消息,如订阅响应消息,不做限定。此时,网元2接收到验证响应后,可根据验证响应中验证实体1的标识以及验证结果,确定验证实体1是否可信。例如,网元2可以根据验证实体1的标识以及验证结果指示验证通过,确定是针对验证实体1的验证通过,从而确定验证实体1可信,执行S907。或者,网元2可以根据验证实体1的标识,以及验证结果指示验证失败,确定是针对验证实体1的验证失败,从而确定验证实体1不可信,网元2可能拒绝触发NF提供实体提供NF消费实体所需的服务。
可以理解,验证结果为可选信元,在没有验证结果的情况下,也可以通过其他方式隐式指示验证是通过还是失败。例如,验证响应可以通过消息类型隐式指示验证是通过还是失败。
需要指出的是,如果网元2请求验证实体2对验证实体1进行验证是通过订阅的方式实现,如验证请求是订阅请求消息,用于验证响应是订阅响应消息。这种情况下,对验证实体1进行验证可认为是一个订阅事件,因此订阅请求消息还可以包括订阅事件的标识,用以指示网元2需要获得该订阅事件对应结果。相应的,订阅响应消息也可以包括该订阅事件的标识,用以指示验证实体2反馈的是针对该订阅事件的结果。
S907,网元2确定NF消费实体是否可信。
其中,网元2可以验证NF消费实体的度量凭证,如确定度量凭证中的一项或多项参数是否满足预设条件,以便在满足预设条件的情况下,确定NF消费实体是否可信。
一种可能的验证方式中,网元2可以根据NF消费实体的度量凭证中的度量结果,确定NF消费实体是否可信。例如,如果该度量凭证中的度量结果指示可信度量通过,则网元2确定NF消费实体可信,执行S909。如果该度量凭证中的度量结果指示可信度量失败,则网元2确定NF消费实体不可信,因此可能拒绝触发NF提供实体提供NF消费实体所需的服务。
另一种可能的验证方式中,网元2可以根据NF消费实体的度量凭证中的新鲜值,确定NF消费实体是否可信。例如,网元2可以确定NF消费实体的度量凭证中的新鲜值,是否与网元2针对该NF消费实体配置的新鲜值(S903)匹配。如果该度量凭证中的新鲜值与网元2针对该NF消费实体配置的新鲜值匹配,则网元2确定NF消费实体可信。如果该度量凭证中的新鲜值与网元2针对该NF消费实体配置的新鲜值不匹配,则网元2确定NF消费实体不可信。
再一种可能的验证方式中,网元2可以根据NF消费实体的度量凭证中的可信度量时间,确定NF消费实体是否可信。例如,网元2可以确定该度量凭证中的可信度量时间,是否在网元2针对该NF消费实体配置的可信度量时间以内。如果该度量凭证中的可信度量时间在网元2针对该NF消费实体配置的可信度量时间以内,则网元2确定NF消费实体可信。如果该度量凭证中的可信度量时间在网元2针对该NF消费实体配置的可信度量时间以外,则网元2确定NF消费实体不可信。
可以理解,上述各种验证方式也可以任意结合实施,例如,如果NF消费实体的度量凭证中的度量结果指示可信度量通过、该度量凭证中的新鲜值与网元2针对该NF消费实体配置的新鲜值匹配,且该度量凭证中的可信度量时间在网元2针对该NF消费实体配置的可信度量时间以内,则网元2确定NF消费实体可信,否则,网元2确定NF消费实体不可信。此外,上述验证方式仅 为一些示例,还可能有其他的验证方式,本申请实施例不做限定。
S908,网元2确定验证实体1是否可信,以及确定NF消费实体是否可信。
网元2确定验证实体1是否可信的具体实现与上述S906类似,可参考理解,不再赘述。此外,网元2确定NF消费实体的具体实现与上述S907类似,可参考理解,不再赘述。
需要指出的是,S906-S907与S908为可选步骤,例如,如果验证实体1无法被网元2直接信任,则在S905后,网元2执行S906-S907,或者,如果验证实体1能够被网元2直接信任,则在S905后,网元2执行S908。
S909,网元2向网元1发送服务建立响应。相应的,网元1接收来自网元2的服务建立响应。
服务建立响应可以用于指示网元2允许触发NF提供实体提供NF消费实体所需的服务,如可以是PDU会话创建响应(session establishment response)消息、注册响应(register response)消息、或者其他任何可能的消息,不做限定。在此基础上,NF提供实体可以为NF消费实体提供NF消费实体所需的服务。
场景1
示例性的,图10为本申请实施例提供的通信方法的流程示意图二。场景1是上述实施例1的一种具体场景,在场景1中,信任域1是PLMN1,网元1和NF消费实体都是AMF1,信任域2是PLMN2,网元2和NF提供实体都是AUSF2。AMF1可以请求AUSF2对UE进行认证,此时,AUSF2可触发对AMF1的可信度量,以便在确定AMF1可信的情况下,完成对UE的认证,避免出现安全风险。
具体的,如图10所示,该通信方法的流程如下:
S1001,UE向AMF1发送注册请求。相应的,AMF1接收来自UE的注册请求。
其中,注册请求可以包括UE的标识,以及PLMN1的标识,用以请求AMF1将UE注册到PLMN1。可以理解,对于UE而言,PLMN1可以是UE的VPLMN,或者也可以是HPLMN,不做限定。
S1002,AMF1向AUSF2发送认证请求。相应的,AUSF2接收来自AMF1的认证请求。
AMF1可以根据认证请求获知UE想要注册到PLMN1,因此AMF1可以向AUSF2发送认证请求(也即,服务建立请求),用以获取UE注册到PLMN1所需的信息。认证请求可以包括:UE的标识、AMF1的标识,以及服务的描述(可选),用以请求AUSF2提供认证服务(也即,NF消费实体所需的服务)。
此外,S1002的具体实现也可以参考上述S901中的相关介绍,不再赘述。
S1003,AUSF2确定是否有AMF1的可信度量记录。
S1004,AUSF2向AMF1发送度量触发请求。相应的,AMF1接收来自AUSF2的度量触发请求。
S1005,AMF1触发验证实体1对AMF1进行可信度量。
S1006,AMF1向AUSF2发送度量触发响应。相应的,AUSF2接收来自AMF1的度量触发响应。
S1007,AUSF2触发验证实体2确定验证实体1是否可信。
S1008,AUSF2确定AMF1是否可信。
S1009,AUSF2确定验证实体1是否可信,以及确定AMF1是否可信。
其中,S1003-S1009的具体实现可以参考S902-S908中的相关介绍,不再赘述。
S1010,AUSF2向AMF1发送认证响应。相应的,AMF1接收来自AUSF2的认证响应。
其中,认证响应(也即,服务建立响应)可以用于指示AUSF2提供的认证服务,如认证服务可以包括UE注册到PLMN1所需的信息,用以UE注册到PLMN1使用。
可选地,认证响应还可以包括验证证明信息。其中,验证证明信息可以用于描述AUSF2或验证实体1已完成验证。例如,验证证明信息可以是AUSF2生成并签名的信息,用于描述AUSF2已完成验证,以便UE可以据此确定AUSF2是否可信。或者,验证证明信息可以是验证实体1生成并签名的信息,用于描述验证实体1已完成验证,以便UE可以据此确定验证实体1是否可信。
S1011,AMF1向UE发送注册响应(register response)。相应的,UE接收来自AMF1的注册响应。
其中,注册响应可以用于指示AMF1已将UE注册到PLMN1,如AMF1根据UE的认证结果,确定UE可信,将UE注册到PLMN1。或者,注册响应也可以用于指示AMF1拒绝将UE注册到PLMN1,如AMF1根据UE的认证结果,确定UE不可信,从而拒绝将UE注册到PLMN1。
可选地,在注册响应指示AMF1已将UE注册到PLMN1的情况下,注册响应还可以包括上述验证证明信息。如此,UE可以根据该验证证明信息,确定AUSF2或验证实体1是否可信,如确定是否能够对AUSF2或验证实体1的签名验签成功。如果UE对AUSF2或验证实体1的签名验签成功,也即AUSF2或验证实体1可信,则UE可以继续进行通信。如果UE对AUSF2或验证实体1的签名验签失败,也即AUSF2或验证实体1不可信,则UE可能认为存在安全风险,停止通信。
场景2
示例性的,图11为本申请实施例提供的通信方法的流程示意图三。场景2是上述实施例1的另一种具体场景,在场景2中,信任域1是NFV域,信任域2是业务域。NF消费实体可以是VNF,或者说VNF实例(virtual network function instance,VNFI),或者VNF组件实例(virtual network function component instance,VNFCI),NF提供实体可以是业务域内的网元。VNF可以请求注册到业务域,此时,业务域内的网元可触发对VNF的可信度量,以便在确定VNF可信的情况下,允许VNF注册到业务域内,避免出现安全风险。
具体的,如图11所示,该通信方法的流程如下:
S1101,VNF向业务域内的网元发送服务建立请求。相应的,业务域内的网元接收来自VNF的服务建立请求。
服务建立请求可以用于请求业务域内的网元提供VNF所需的服务。服务建立请求可以是任何可能的消息,不做限定。服务建立请求可包括:VNF的标识,以及服务的描述(可选)。
VNF的标识可用于表征VNF在NFV域内的身份。服务的描述可用于表征服务触发实体触发服务的如下至少一项:服务目的、服务原因、或服务限制条件。服务目的可用于表征该服务最终需要实现的目标,如访问业务域等等。服务原因可用于表征因为什么原因触发该服务,如VNF应用程序需想要访问业务域等。服务限制条件可以用于表征实现该服务需要满足的条件,如时效性,即该服务在什么时间段内有效、指定网元,即该服务需要哪些指定的网元参与、或者其他任何的条件,不做限定。
VNF可以基于VNF应用程序的需求,如VNF应用程序需想要访问业务域,触发向业务域内的网元发送服务建立请求,或者也可以是通过其他方式触发发送服务建立请求,不做限定。
可以理解,S1101为可选步骤,例如,业务域内的网元可以自行触发为VNF提供服务。
S1102,业务域内的网元确定是否有VNF的可信度量记录。
其中,S1102的具体实现可以参考上述S902中的相关介绍,不再赘述。
S1103,业务域内的网元向VNF发送度量触发请求。相应的,VNF接收来自业务域内的网元的度量触发请求。
S1104,VNF触发验证实体1对VNF进行可信度量。
S1105,VNF向业务域内的网元发送度量触发响应。相应的,业务域内的网元接收来自VNF的度量触发响应。
S1106,业务域内的网元触发验证实体2确定验证实体1是否可信。
S1107,业务域内的网元确定NF消费实体是否可信。
S1108,业务域内的网元确定验证实体1是否可信,以及确定NF消费实体是否可信。
S1109,业务域内的网元向VNF发送服务建立响应。相应的,VNF接收来自业务域内的网元的服务建立响应。
其中,S1103-S1109的具体实现与上述S903-S909类似,可参考理解,不再赘述。
需要指出的是,在实施例3中,业务域内的网元也可以直接通过验证实体2,触发验证实体1 对VNF进行可信度量,具体实现原理与上述实施例2类似,可以参考理解,不再赘述。
场景3
示例性的,图12为本申请实施例提供的通信方法的流程示意图四。场景3是上述实施例1的另一种具体场景,在场景3中,信任域1是PLMN1,信任域2是PLMN2,网元1是SMF1,NF消费实体是UPF1,网元2是SMF2,NF提供实体是UPF2。SMF1可以请求SMF2建立UPF1对应的会话,此时,SMF2可触发对UPF1的可信度量,以便在确定UPF1可信的情况下,触发建立UPF1对应的会话,避免出现安全风险。
具体的,如图12所示,该通信方法的流程如下:
S1201,UE向SMF1发送会话建立请求(PDU session establishment request)。相应的,SMF1接收来自UE的会话建立请求。
其中,会话建立请求可以包括UE的标识,PLMN1的标识,用以请求SMF1为该UE建立PDU会话,以便该UE收发业务数据。对于UE而言,PLMN1可以是UE的VPLMN,或者也可以是HPLMN,不做限定。
S1202,SMF1选择UPF1。
其中,SMF1可以优先选择保存有该UPF的度量凭证的UPF,如UPF1。例如,SMF1预先配置有PLMN1的标识与该PLMN1内的UPF的标识的映射关系表。其中,映射关系表中UPF都可以是保存有该UPF的度量凭证的UPF。SMF1可以根据PLMN1的标识,遍历映射关系表,以选择适合UE的UPF,如UPF1。
此外,SMF1选择UPF1也可以参考TS 23.501中的相关介绍,不再赘述。
S1203,SMF1向SMF2发送会话创建请求。相应的,SMF2接收来自SMF1的会话创建请求。
会话创建请求(也即,服务建立请求)可以包括:UE的标识、UPF1的标识,以及服务的描述(可选),用以请求SMF2建立UPF1对应的PDU会话(也即,NF消费实体所需的服务)。
此外,S1203的具体实现也可以参考上述S901中的相关介绍,不再赘述。
S1204,SMF2确定是否有UPF1的可信度量记录。
S1205,SMF2向SMF1发送度量触发请求。相应的,SMF1接收来自SMF2的度量触发请求。
S1206,SMF1触发验证实体1对UPF1进行可信度量。
S1207,SMF1向SMF2发送度量触发响应。相应的,SMF2接收来自SMF1的度量触发响应。
S1208,SMF2触发验证实体2确定验证实体1是否可信。
S1209,SMF2确定UPF1是否可信。
S1210,SMF2确定验证实体1是否可信,以及确定UPF1是否可信。
其中,S1204-S1210的具体实现可以参考S902-S908中的相关介绍,不再赘述。
S1211,SMF2选择UPF2。
其中,SMF2可以选择适合UE的UPF2,具体实现可参考TS 23.501中的相关介绍,不再赘述。
S1212,SMF2向UPF2发送指示信息。相应的,UPF2接收来自SMF2的指示信息。
指示信息可以包括:UPF的度量凭证或UPF的度量凭证的描述信息(简称为描述信息)、UPF1的标识,以及PDU会话的标识(可选)。
其中,描述信息可以是该UPF的度量凭证的标识或散列值,不做限定。UPF1的标识用于表征:UPF的度量凭证或描述信息属于UPF1。PDU会话的标识可以用于指示该PDU会话关联到UPF1的度量凭证或描述信息,也即,表征该PDU会话的数据需要使用UPF1的度量凭证或描述信息进行验证,以确定该PDU会话的数据是否来自UPF1。可以理解,PDU会话的标识为可选信元,如果没有PDU会话的标识,则表示UPF1的度量凭证或描述信息可以默认关联到该UPF1对应的所有PDU会话。
S1213,SMF2向SMF1发送会话创建响应(PDU session create response)。相应的,SMF1接收来自SMF2的会话创建响应。
其中,会话创建响应(也即,服务建立响应)可以用于指示SMF2已创建UPF1对应的PDU 会话,如包括该PDU会话对应的UPF2的标识。
S1214,SMF1向UPF1发送指示信息。相应的,UPF1接收来自SMF1的指示信息。
其中,指示信息的具体实现可以参考上述S1212的相关介绍,不再赘述。至此,PDU会话建立完成,PLMN1与PLMN2之间的用户面路径被打通。
S1215,传输用户面数据。
UE可以通过PDU会话,向UPF1发送用户面数据。UPF1可以使用UPF1的度量凭证或描述信息,对该PDU会话的用户面数据进行签名,并通过该PDU会话,向UPF2发送签名后的用户面数据。UPF2可以使用UPF1的度量凭证或描述信息,验证该签名后的用户面数据,以确定该数据是否来自可信的UPF1。如果来自可信的UPF1,则UPF2继续处理该数据,否则,UPF2可以丢弃该数据,以保障用户面的通信安全。
实施例2:
示例性的,图13为本申请实施例提供的通信方法的流程示意图五。在实施例2中,信任域1内的网元1可以请求信任域2内的网元2,触发NF提供实体提供NF消费实体所需的服务。此时,网元2可直接触发验证实体1对NF消费实体进行可信度量,以便在确定NF消费实体可信的情况下,提供相应的服务,避免出现安全风险。
具体的,如图13所示,该通信方法的流程如下:
S1301,网元1向网元2发送服务建立请求。相应的,网元2接收来自网元1的服务建立请求。
其中,S1301的具体实现可以参考上述S901中的相关介绍,不再赘述。
S1302,网元2向验证实体2发送度量触发请求。相应的,验证实体2接收来自网元2的度量触发请求。
度量触发请求可以用于请求验证实体2触发对NF消费实体的可信度量。度量触发请求可以是任何可能的消息,不做限定。网元2(如PACF或者其他任何可能的网元)可以直接向验证实体2发送度量触发请求,或者也可以通过PACF(图12未示出)向验证实体2发送度量触发请求,不做限定。度量触发请求可以包括:新鲜值(可选)、事件的标识(可选)、NF消费实体的标识(可选)、可信度量策略(可选),以及验证实体1的标识(可选)。
其中,验证实体1的标识可以用于验证实体2对验证实体1进行寻址。例如,验证实体2是网管,验证实体1是云管,验证实体1的标识可以用于指示验证实体1具体是哪个区域的云管,以便验证实体2能够寻址到验证实体1。新鲜值是可选信元,例如,由于验证实体2是网元2信任的验证实体,因此网元2也可以不提供新鲜值。此外,新鲜值、事件的标识、NF消费实体的标识,以及可信度量策略可以参考上述实施例1中的相关介绍,不再赘述。
S1303,验证实体2向网元2发送度量触发响应。相应的,网元2接收来自验证实体2的度量触发响应。
度量触发响应可以用于指示NF消费实体是否可信。例如,度量触发响应可以包括:NF消费实体的标识、度量结果的描述(可选)、事件的标识(可选),以及验证实体1的标识(可选)。
其中,度量结果的描述可以用于指示可信度量通过或者可信度量失败。度量结果的描述,在没有度量结果的描述的情况下,度量触发响应也可以通过其他方式隐式指示可信度量通过或者可信度量失败。例如,度量触发响应可以通过消息类型隐式指示可信度量通过或者可信度量失败。验证实体1的标识是可选信元。例如,网元2发送的可信度量策略中指示验证实体2需要提供用于可信度量的验证实体的标识,则验证实体2可以提供验证实体1的标识,否则,验证实体2可以不提供验证实体1的标识。此外,NF消费实体的标识、事件的标识,以及验证实体1的标识也可以参考上述场景1中的相关介绍。
验证实体2可能预先保存有NF消费实体的度量凭证。这样,验证实体2可以根据NF消费实体的度量凭证,直接向网元2反馈度量触发响应,无需再次执行可信度量,以节约开销。网元2接收到度量触发响应后,可根据该度量触发响应中NF消费实体的标识以及度量结果的描述,确定NF消费实体是否可信。例如,网元2可以根据NF消费实体的标识以及度量结果指示可信度量 通过,确定是针对NF消费实体的可信度量通过,从而确定NF消费实体可信,执行S1309。或者,网元2可以根据NF消费实体的标识以及度量结果指示可信度量失败,确定是针对NF消费实体的可信度量失败,从而确定NF消费实体失败,此时,网元2可能拒绝触发NF提供实体提供NF消费实体所需的服务。
可以理解,S1303为可选步骤,如果验证实体2没有预先保存有NF消费实体的度量结果,则验证实体2不执行S1303,执行S1304。
S1304,验证实体2向验证实体1发送度量请求。相应的,验证实体1接收来自验证实体2的度量请求。
度量请求可以用于请求验证实体1触发对NF消费实体的可信度量,或者说请求验证实体1提供NF消费实体的度量凭证。度量请求可以是任何可能的消息,不做限定。度量请求可以包括:验证实体1的标识、NF消费实体的标识/VNF的标识、新鲜值(可选),以及可信度量策略。
其中,验证实体1的标识可以用于指示需要由验证实体1执行可信度量。验证实体2可以从度量触发请求中获取验证实体1的标识,或者验证实体2也可以从本地获取验证实体1的标识,不做限定。
NF消费实体的标识/VNF的标识主要用于标识转换,如验证实体2可以将NF消费实体的标识转换为VNF的标识,具体可以参考上述S904中的相关介绍。
S1305,验证实体1对NF消费实体进行可信度量。
其中,S1305的具体实现可以参考上述S904中的相关介绍,不再赘述。
S1306,验证实体1向验证实体2发送度量响应。相应的,验证实体2接收来自验证实体1的度量响应。
度量响应可以用于响应度量请求,用于表征已完成对NF消费实体的可信度量。度量响应可以是任何可能的消息,不做限定。度量响应可以包括:NF消费实体的度量凭证,以及验证实体1的证明信息(可选),具体也可以参考S905中的相关介绍,不再赘述。
可以理解,如果验证实体1预先保存有NF消费实体的度量凭证,则验证实体1可以不S1305,执行S1306。
S1307,验证实体2确定验证实体1是否可信。
其中,S1307的具体实现可以参考上述S906中的相关介绍,不再赘述。
S1308,验证实体2向网元2发送度量触发响应。相应的,网元2接收来自验证实体2的度量触发响应。
其中,度量触发响应的具体可以参考上述S1303中的相关介绍,不再赘述。
可以理解,上述S1304-S1307为一种可能的实现方式,不作为限定。验证实体1也可以是多个,这多个验证实体1可以部署在同一信任域或者不同的信任域,不做限定。验证实体2可以向每个验证实体1发送度量请求。此时,每个验证实体1都可以向验证实体2反馈该验证实体1针对NF消费实体执行度量而获得的度量凭证,以及每个验证实体1的证明信息(可选)。可选地,验证实体2可以根据每个验证实体1反馈的度量凭证,以及该验证实体1的证明信息(可选),确定该验证实体1是否可信。在多个验证实体1都可信,或者多个验证实体1中超过预设数量的验证实体1可信的情况下,验证实体2可以根据多个验证实体1各自反馈的度量凭证,也即多个度量凭证,向网元2反馈度量触发响应。
例如,验证实体2可以是OSS/BSS中的验证功能,网元2可以是OSS/BSS的管理员界面。此时,网元2需要确定NFV系统是否可信,NFV系统包含位于业务域的NF,以及位于NFV域的VNF。因此,验证实体2可以触发位于业务域的验证实体1a对NF进行可信度量,以及触发位于NFV域的验证实体1b对VNF。在NF和VNF都可信的情况下,验证实体2确定NFV系统可信,向网元2反馈NFV系统的度量凭证。
S1309,网元2向网元1发送服务建立响应。相应的,网元1接收来自网元2的服务建立响应。
其中,S1309的具体实现可以参考上述S909中的相关介绍,不再赘述。
需要指出的是,实施例2也可以应用具体的场景,如注册或者会话建立的场景,具体实现原 理可以参考上述场景1-3中的相关介绍,不再赘述。
综上,上述实施例具有如下技术效果:
1)由于NF消费实体请求NF提供实体提供相应的服务时,NF提供实体可以执行端对端的验证,也即触发验证该NF消费实体是否可信,如此可以防止恶意的网元恶意伪造合法凭证,避免出现安全风险。
2)NF提供实体对NF消费实体的验证可以适用于任何业务流程,如注册流程,会话建立流程等等,以降低这些流程的安全风险。
3)在跨域的情况下,信任域2内的业务域内的网元/验证实体2可以对信任域1内的验证实体1验证,如此可以确保在验证实体1可信的情况下,才继续后续流程,以降低安全风险。
4)如果通过PACF对验证实体1进行了可信度量,则业务域内的网元/代理功能可以保存对应的度量凭证,以便后续可以不用再通过PACF对验证实体1进行可信度量;或者,NF提供实体也可以不通过PACF,由NF提供实体自行验证NF消费实体是否可信,如此可以降低PACF被触发次数,从而可以降低PACF的负载,避免出现PACF单点故障的问题。
以上结合图9-图13详细说明了本申请实施例提供的通信方法在上述实施例的具体流程。以下结合图14介绍该通信方法的整体流程。
示例性的,图14为该通信方法的流程示意图六。该通信方法主要涉及第一信任域内的第一网元与第二信任域内的第四网元之间的通信。其中,第一信任域可以是上述的信任域2,第一网元可以是上述的网元2,第二信任域可以是上述的信任域1,第四网元可以是上述的网元1,如图14所示,该通信方法的流程如下:
S1401,在第一信任域内的第一网元需要为第二信任域内的第二网元提供第一信任域的服务的情况下,第一网元通过触发对第二网元的可信度量,获得可信度量对应的结果信息。
其中,第一网元可以自行确定需要为第二网元提供第一信任域的服务,例如,第一网元可以根据自身的服务的需求,确定需要为第二网元提供该服务;或者,第一网元也可以根据接收到的消息,如服务建立请求,确定需要为第二网元提供第一信任域的服务。在此基础上,第一网元可以向第四网元发送度量请求。第四网元接收第一网元针对服务请求返回的度量请求,从而向第一网元发送度量响应。
一种可能的方式中,第四网元与第二网元是同一个网元。在第一网元需要为第二网元提供第一信任域的服务的情况下,第一网元可以向第二网元发送度量请求。其中,度量请求用于请求第二网元触发对第二网元的可信度量。第二网元可以根据度量请求,触发第二信任域内的第二验证实体对第二网元进行可信度量,以获得第二网元的可信度量对应的结果信息。第二网元的可信度量对应的结果信息也可以是第二网元的度量凭证,或者说第二网元的度量令牌,不做限定。第二网元可以向第一网元发送度量响应,第一网元可以接收来自第二网元的度量响应。其中,度量响应可以用于指示该第二网元的可信度量对应的结果信息。
可以看出,在第四网元与第二网元是同一个网元的情况下,第一网元可以直接指示第二网元触发对第二网元的可信度量,以提高通信效率,具体也可以参考上述S901-S905中的相关介绍。
或者,另一种可能的方式中,第四网元与第二网元可以是不同的网元,此时,第四网元也可以理解为下述的第三网元。在第一网元需要为第二网元提供第一信任域的服务的情况下,第一网元可以向第二信任域内的第三网元发送度量请求。其中,第三网元可以是第二网元关联的网元,度量请求可以用于请求第三网元触发对第二网元的可信度量。第三网元可以根据度量请求,触发第二验证实体对第二网元进行可信度量,以获得第二网元的可信度量对应的结果信息。第三网元可以向第一网元发送度量响应,第一网元可以接收来自第三网元的度量响应。其中,度量响应可以用于指示该第二网元的可信度量对应的结果信息。
可以看出,在第一网元与第二网元可能无法直接通信的情况下,第一网元仍可以通过指示第二信任域内的第三网元来触发对第二网元的可信度量,确保可信度量仍能够被有效执行,具体也可以参考上述S901-S905中的相关介绍。
下面结合场景介绍。
场景A:第一信任域可以是第一运营商网络(如上述PLMN2),第一网元可以是认证网元(如 上述ASUF2),第二信任域可以是第二运营商网络(如上述PLMN1),第二网元可以是接入和移动性管理网元(上述AMF1)。这种情况下,接入和移动性管理网元可以向认证网元发送服务建立请求,如认证请求。认证网元可以接收来自接入和移动性管理网元的认证请求,并根据认证请求,向接入和移动性管理网元发送度量请求。接入和移动性管理网元接收认证网元针对认证请求返回的度量请求。其中,认证请求可以用于请求认证网元为接入和移动性管理网元提供认证服务,度量请求可以用于请求接入和移动性管理网元触发对接入和移动性管理网元的可信度量。接入和移动性管理网元可以根据认证度量请求,触发第二验证实体(如上述验证实体1)对接入和移动性管理网元进行可信度量,以获得接入和移动性管理网元的可信度量对应的结果信息。接入和移动性管理网元可以向认证网元发送度量响应,用以指示该接入和移动性管理网元的可信度量对应的结果信息。
可以看出,在第一信任域是第一运营商网络,第二信任域是第二运营商网络的情况下,第一网元触发对第二网元的可信度量可以被复用到终端的注册场景,如认证网元可以触发对接入和移动性管理网元的可信度量,以保障注册场景下的通信安全。
此外,场景A的具体实现也可以参考上述S1002-S1006中的相关介绍,不再赘述。
场景B:第一信任域可以是业务域,或者说服务域,第二信任域可以是虚拟化设施域(如上述NFV域),第二网元可以是虚拟网络功能(如上述VNF)。虚拟网络功能可以向第一网元(如上述业务域内的网元)发送服务建立请求,如注册请求。第一网元可以接收来自虚拟网络功能的注册请求,并根据注册请求,向虚拟网络功能发送度量请求。虚拟网络功能可以接收第一网元针对注册请求返回的度量请求。其中,注册请求可以用于请求第一网元为虚拟网络功能提供注册服务,度量请求可以用于请求虚拟网络功能提触发对虚拟网络功能提的可信度量。虚拟网络功能可以根据度量请求,触发第二验证实体对虚拟网络功能进行可信度量,以获得虚拟网络功能的可信度量对应的结果信息。虚拟网络功能可以向认证网元发送度量响应,用以指示该虚拟网络功能的可信度量对应的结果信息。
可以看出,在第一信任域是业务域,第二信任域是虚拟化设施域的情况下,第一网元触发对第二网元的可信度量可以被复用到虚拟网络功能的注册场景,如第一网元可以触发对虚拟网络功能的可信度量,以保障注册场景下的通信安全。
此外,场景B的具体实现也可以参考上述S1101-S1105中的相关介绍,不再赘述。
场景C:第一信任域可以是第一运营商网络,第一网元可以是第一会话管理网元(上述SMF2),第二信任域可以是第二运营商网络,第二网元可以是第二用户面网元(上述UPF1),第三网元可以是第二会话管理网元(上述SMF1)。第二会话管理网元可以向第一会话管理网元发送服务建立请求,如会话创建请求。第一会话管理网元可以接收来自第二会话管理网元的服务建立请求,并根据会话创建请求,向第二会话管理网元发送度量请求。第二会话管理网元可以接收第一会话管理网元针对会话创建请求返回的度量请求。其中,会话创建请求可以用于请求第一会话管理网元为第二用户面网元提供会话创建服务,度量请求可以用于请求第二会话管理网元触发对第二用户面网元的可信度量。第二会话管理网元可以根据度量请求,触发第二验证实体对第二用户面网元进行可信度量,以获得第二用户面网元的可信度量对应的结果信息。第二会话管理网元可以向第一会话管理网元发送度量响应,用以指示该第二用户面网元的可信度量对应的结果信息。
可以看出,在第一信任域是第一运营商网络,第二信任域是第二运营商网络的情况下,第一网元触发对第二网元的可信度量可以被复用到会话建立场景,如第一会话管理网元可以触发对第二会话管理网元的可信度量,以保障会话场景下的通信安全。
此外,场景C的具体实现也可以参考上述S1203-S1206中的相关介绍,不再赘述。
S1402,在第一网元根据第二网元的可信度量对应的结果信息,确定第二网元可信的情况下,第一网元为第二网元提供服务。相应的,在第二网元可信的情况下,第四网元获取第一网元为第二网元提供的服务。
其中,第一网元可以根据第二网元的可信度量对应的结果信息中的至少一项满足预设条件,确定第二网元可信。结果信息中的至少一项满足预设条件可以包括:用于表征度量凭证的标识与预配置的标识匹配、被度量网元的标识与第二网元的标识匹配、或第二网元的可信度量对应的结 果信息指示第二网元可信,以实现对第二网元进行较为全面的验证,具体实现也可以参考上述S906-S909中的相关介绍。
下面结合上述场景A-场景C进行介绍。
场景A,认证网元可以向接入和移动性管理网元发送认证响应。其中,认证响应用于指示认证服务,度量请求用于请求接入和移动性管理网元触发对接入和移动性管理网元的可信度量。例如,终端归属于第一运营商网络,认证服务可以用于指示终端注册到第二运营商网络所需的信息,以确保终端能够注册到第二运营商网络。此外,场景A的具体实现也可以参考上述S1007-S1010中的相关介绍,不再赘述。
场景B,第一网元可以向虚拟网络功能发送认证响应。其中,认证响应用于指示注册服务。注册服务用于指示第一网元允许虚拟网络功能注册到业务域,以确保虚拟网络功能能够成功注册到业务域。此外,场景B的具体实现也可以参考上述S1106-S1109中的相关介绍,不再赘述。
场景C,第一会话管理网元向第二会话管理网元发送会话创建响应。相应的,第二会话管理网接收来自第一会话管理网元的会话创建响应。其中,会话建立创建响应用于指示会话创建服务。例如,第一用户面网元(如上述UPF2)是第一运营商网络内的网元,会话创建服务用于指示第二用户面网元需要与第一用户面网元建立会话,以确保能够成功建立会话。
可选地,第二会话管理网元可以向第二用户面网元发送指示信息。其中,指示信息可以用于指示第二用户面网元需要对数据进行标识,用以表征该数据是由第二用户面网元发送的数据。以及,第一会话管理网元还可以向第一用户面网元发送指示信息。相应的,接入和移动性管理网元接收来自认证网元的认证响应。其中,指示信息用于指示第一用户面网元需要验证第一用户面网元接收的数据是否来自第二用户面网元,以确保第一用户面网元可以只处理来自可信的第二用户面网元的数据,保障用户面的通信安全。
此外,场景C的具体实现也可以参考上述S1208-S1212中的相关介绍,不再赘述。
综上,由于第二信任域内的第二网元跨域请求第一信任域内的第一网元提供相应的服务时,第一网元可以执行端对端的验证,也即触发验证该第二网元是否可信,以便在确定第二网元可信的情况下,第一网元才为第二网元提供服务,如此可以避免跨域访问时的安全风险。
一种可能的设计方案中,对于场景A而言,在S1401之前,接入和移动性管理网元可以接收来自终端的注册请求。如此,接入和移动性管理网元根据注册请求,向认证网发送认证请求。此外,认证网元也可以向接入和移动性管理网元发送验证证明信息。相应的,接入和移动性管理网元接收来自认证网元的验证证明信息,并向终端发送验证证明信息。其中,验证证明信息用于终端验证认证网元或认证网元关联的第一验证实体是否可信。可以看出,由于注册流程通常是由终端触发,如终端请求注册到第二运营商网络,因此也可以向终端提供验证证明信息,以实现双向验证,进一步保障通信安全。
或者,对于场景C而言,在S1401之前,第二会话管理网元可以接收来自终端的会话建立请求。其中,会话建立请求用于终端请求建立会话。如此,第二会话管理网元根据会话建立请求,确定第二用户面网元。可以理解,第二会话管理网元可以优先选择有可信度量记录的用户面网元,以便本次可以不再执行可信度量,节约开销。
此外,该设计方案的具体实现也可以参考上述S1010以及S1201-S1203中的相关介绍,不再赘述。
一种可能的设计方案中,由于第一网元与第二信任域内的验证实体之间可能不具有信任关系,因此在S1402之前,第一网元还可以接收来自第二网元的第二验证实体的信息,并根据第二验证实体的信息,确定第二验证实体可信。其中,第二验证实体的信息可以包括如下至少一项:第二验证实体的身份信息、或第二验证实体的证明信息。其中,第二验证实体的身份信息可以包括如下至少一项:第二验证实体的标识、第二验证实体的签名,第二验证实体的证明信息可以包括如下至少一项:第二验证实体的部署证据、第二验证实体所属机构的凭据、第二验证实体的签约注册信息。也就是说,在确定第二网元是否可信之前,第一网元还可以确定对第二网元执行可信度量的第二验证实体是否可信,以进一步保障通信安全。
具体的,第一网元可以向第一信任域内的第一验证实体(如上述验证实体2)发送验证请求。 第一信任域内的第一验证实体接收来自第一信任域内的第一网元的验证请求。其中,验证请求可以用于请求第一验证实体根据第二验证实体的信息,验证第二验证实体是否可信。例如,验证请求用于请求订阅第一事件,第一事件可以为第一验证实体需要根据第二验证实体的信息,验证第二验证实体是否可信。如此,第一验证实体根据验证请求,向第一网元发送验证响应,第一网元接收来自第一验证实体的验证响应。其中,验证响应用于指示第二验证实体可信,或者,验证响应用于指示第二验证实体不可信。
可以理解,如果第二验证实体无法被第一网元信任,则第一网元通常也没有配置第二验证实体相关的配置文件,因此也无法直接验证该第二验证实体是否可信。这种情况下,第一网元还可以触发第一网元信任的第一验证实体验证该第二验证实体是否可信,以保障通信安全。当然,在第一网元配置有第二验证实体相关的配置文件的情况下,第一网元也可以直接验证第二验证实体是否可信,不做限定。
还可以理解,由于第二验证实体的信息也可以携带在上述结果信息,如第二网元的度量凭证中,因此,也可以理解为第一网元根据第二网元的度量凭证,确定第二验证实体可信。进一步的,还可以理解为第一验证实体根据第二网元的度量凭证,确定第二验证实体可信。
此外,该设计方案的具体实现也可以参考上述S906-S908、S1007-S1009、S1106-S1108以及中的相关介绍,不再赘述。
一种可能的设计方案中,在第一网元需要为第二网元提供第一信任域的服务的情况下,第一网元可以确定没有第二网元的可信度量记录。或者,在第一网元需要为第二网元提供第一信任域的服务的情况下,第一网元可以确定有第二网元的可信度量记录,但可信度量记录失效。也就是说,在没有对第二网元进行过可信度量,或者虽然对第二网元进行过可信度量,但该可信度量已经失效的情况下,第一网元才触发对第二网元的可信度量,否则,第一网元可以不触发对第二网元的可信度量,而可以直接与第二网元通信,以节约开销。
此外,该设计方案的具体实现也可以参考上述S902、S1003,以及S1102中的相关介绍,不再赘述。
需要说明的是,该通信方法的上述实现仅为一些示例,该通信方法也可以适用于第一网元请求第一验证实体,触发对第二网元的可信度量。例如,在第一网元需要为第二网元提供第一信任域的服务的情况下,第一网元可以向第一信任域内的第一验证实体发送度量请求,以接收来自第一验证实体的度量响应。其中,度量请求用于请求第一验证实体触发对第二网元的可信度量,度量响应用于指示第二网元的可信度量对应的结果信息。也即,在第二网元当前可能无法被第一网元信任的情况下,第一网元可通过第一网元信任的第一验证实体触发对第二网元的可信度量,以避免与第二网元直接通信,进一步保障通信安全,具体可参考上述实施例2中的相关介绍,不再赘述。
以上结合图9-图14详细说明了本申请实施例提供的通信方法。以下结合图15-图16详细说明用于执行本申请实施例提供的通信方法的通信装置。
示例性的,图15是本申请实施例提供的通信装置的结构示意图一。如图15所示,通信装置1500包括:收发模块1501和处理模块1502。为了便于说明,图15仅示出了该通信装置的主要部件。
一些实施例中,通信装置1500可适用于图8中所示出的通信系统中,执行上述第一网元/网元2的功能。其中,收发模块1501可以用于执行第一网元/网元2收发消息的功能,如上述S901等步骤中的功能,处理模块1502可以执行该第一网元/网元2除收发消息以外的功能,如上述S902等步骤中的功能。
例如,在第一信任域内的第一网元需要为第二信任域内的第二网元提供第一信任域的服务的情况下,处理模块1502,用于通过触发对第二网元的可信度量,获得可信度量对应的结果信息。处理模块1502,还用于在第一网元根据可信度量对应的结果信息,确定第二网元可信的情况下,控制收发模块1501为第二网元提供第一信任域的服务。
可选地,收发模块1501可以包括发送模块和接收模块。其中,发送模块用于实现通信装置 1500的发送功能,接收模块用于实现通信装置1500的接收功能。
可选地,通信装置1500还可以包括存储模块,该存储模块存储有程序或指令。当该处理模块1502执行该程序或指令时,使得通信装置1500可以执行上述通信方法。
需要说明的是,通信装置1500可以是网络设备,也可以是可设置于网络设备中的芯片(系统)或其他部件或组件,还可以是包含网络设备的装置,本申请对此不做限定。
此外,通信装置1500的技术效果可以参考上述通信方法的技术效果,此处不再赘述。
另一些实施例中,通信装置1500可适用于图8中所示出的通信系统中,执行上述第一验证实体/验证实体2的功能。其中,收发模块1501可以用于执行第一验证实体/验证实体2收发消息的功能,如上述S906等步骤中的功能。处理模块1502可以执行该第一验证实体/验证实体2除收发消息以外的功能,如上述S906等步骤中的功能。
例如,收发模块1501,用于接收来自第一信任域内的第一网元的验证请求。其中,验证请求用于请求第一信任域内的该通信装置1500根据第二验证实体的信息,验证第二验证实体是否可信,第二验证实体位于第二信任域,第一网元与第二信任域内的验证实体之间不具有信任关系。如此,处理模块1502,用于根据验证请求,控制收发模块1501向第一网元发送验证响应。其中,验证响应用于指示第二验证实体可信,或者,验证响应用于指示第二验证实体不可信。
可选地,收发模块1501可以包括发送模块和接收模块。其中,发送模块用于实现通信装置1500的发送功能,接收模块用于实现通信装置1500的接收功能。
可选地,通信装置1500还可以包括存储模块,该存储模块存储有程序或指令。当该处理模块1502执行该程序或指令时,使得通信装置1500可以执行上述通信方法。
需要说明的是,通信装置1500可以是网络设备,也可以是可设置于网络设备中的芯片(系统)或其他部件或组件,还可以是包含网络设备的装置,本申请对此不做限定。
此外,通信装置1500的技术效果可以参考上述通信方法的技术效果,此处不再赘述。
再一些实施例中,通信装置1500可适用于图8中所示出的通信系统中,执行上述第二网元/网元1的功能。其中,收发模块1501可以用于执行第二网元/网元1收发消息的功能,如上述S901等步骤中的功能。处理模块1502可以执行该第二网元/网元1除收发消息以外的功能,如上述S904等步骤中的功能。
例如,通信装置1500是第二信任域内的网元,在第一信任域内的第一网元需要为第二信任域内的第二网元提供第一信任域的服务的情况下,收发模块1501,用于接收来自第一网元的度量请求,处理模块1502,用于根据度量请求,控制收发模块1501向第一网元发送度量响应。其中,第四网元与第二网元关联,度量请求用于指示通信装置1500触发对第二网元的可信度量,度量响应用于指示第二网元是否可信。如此,在第二网元可信的情况下,处理模块1502,用于获取第一网元为第二网元提供的服务。
可选地,收发模块1501可以包括发送模块和接收模块。其中,发送模块用于实现通信装置1500的发送功能,接收模块用于实现通信装置1500的接收功能。
可选地,通信装置1500还可以包括存储模块,该存储模块存储有程序或指令。当该处理模块1502执行该程序或指令时,使得通信装置1500可以执行上述通信方法。
需要说明的是,通信装置1500可以是网络设备,也可以是可设置于网络设备中的芯片(系统)或其他部件或组件,还可以是包含网络设备的装置,本申请对此不做限定。
此外,通信装置1500的技术效果可以参考上述通信方法的技术效果,此处不再赘述。
示例性地,图16为本申请实施例提供的通信装置的结构示意图二。该通信装置可以是终端,也可以是可设置于终端的芯片(系统)或其他部件或组件。如图16所示,通信装置1600可以包括处理器1601。可选地,通信装置1600还可以包括存储器1602和/或收发器1603。其中,处理器1601与存储器1602和收发器1603耦合,如可以通过通信总线连接。
下面结合图16对通信装置1600的各个构成部件进行具体的介绍:
其中,处理器1601是通信装置1600的控制中心,可以是一个处理器,也可以是多个处理元件的统称。例如,处理器1601是一个或多个中央处理器(central processing unit,CPU),也可以是特定集成电路(application specific integrated circuit,ASIC),或者是被配置成实施本申请实施 例的一个或多个集成电路,例如:一个或多个微处理器(digital signal processor,DSP),或,一个或者多个现场可编程门阵列(field programmable gate array,FPGA)。
可选地,处理器1601可以通过运行或执行存储在存储器1602内的软件程序,以及调用存储在存储器1602内的数据,执行通信装置1600的各种功能,例如执行上述图9-图14所示的通信方法。
在具体的实现中,作为一种实施例,处理器1601可以包括一个或多个CPU,例如图16中所示出的CPU0和CPU1。
在具体实现中,作为一种实施例,通信装置1600也可以包括多个处理器,例如图16中所示的处理器1601和处理器1604。这些处理器中的每一个可以是一个单核处理器(single-CPU),也可以是一个多核处理器(multi-CPU)。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
其中,所述存储器1602用于存储执行本申请方案的软件程序,并由处理器1601来控制执行,具体实现方式可以参考上述方法实施例,此处不再赘述。
可选地,存储器1602可以是只读存储器(read-only memory,ROM)或可存储静态信息和指令的其他类型的静态存储设备,随机存取存储器(random access memory,RAM)或者可存储信息和指令的其他类型的动态存储设备,也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory,EEPROM)、只读光盘(compact disc read-only memory,CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。存储器1602可以和处理器1601集成在一起,也可以独立存在,并通过通信装置1600的接口电路(图16中未示出)与处理器1601耦合,本申请实施例对此不作具体限定。
收发器1603,用于与其他通信装置之间的通信。例如,通信装置1600为终端,收发器1603可以用于与网络设备通信,或者与另一个终端设备通信。又例如,通信装置1600为网络设备,收发器1603可以用于与终端通信,或者与另一个网络设备通信。
可选地,收发器1603可以包括接收器和发送器(图16中未单独示出)。其中,接收器用于实现接收功能,发送器用于实现发送功能。
可选地,收发器1603可以和处理器1601集成在一起,也可以独立存在,并通过通信装置1600的接口电路(图16中未示出)与处理器1601耦合,本申请实施例对此不作具体限定。
需要说明的是,图16中示出的通信装置1600的结构并不构成对该通信装置的限定,实际的通信装置可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
此外,通信装置1600的技术效果可以参考上述方法实施例所述的通信方法的技术效果,此处不再赘述。
应理解,在本申请实施例中的处理器可以是中央处理单元(central processing unit,CPU),该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor,DSP)、专用集成电路(application specific integrated circuit,ASIC)、现成可编程门阵列(field programmable gate array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解,本申请实施例中的存储器可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(read-only memory,ROM)、可编程只读存储器(programmable ROM,PROM)、可擦除可编程只读存储器(erasable PROM,EPROM)、电可擦除可编程只读存储器(electrically EPROM,EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory,RAM),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的随机存取存储器(random access memory,RAM)可用,例如静态随机存取存储器(static RAM,SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM,ESDRAM)、同步连接动 态随机存取存储器(synchlink DRAM,SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM,DR RAM)。
上述实施例,可以全部或部分地通过软件、硬件(如电路)、固件或其他任意组合来实现。当使用软件实现时,上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令或计算机程序。在计算机上加载或执行所述计算机指令或计算机程序时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质。半导体介质可以是固态硬盘。
应理解,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况,其中A,B可以是单数或者复数。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系,但也可能表示的是一种“和/或”的关系,具体可参考前后文进行理解。
本申请中,“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a-b,a-c,b-c,或a-b-c,其中a,b,c可以是单个,也可以是多个。
应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。

Claims (28)

  1. 一种通信方法,其特征在于,所述方法包括:
    在第一信任域内的第一网元需要为第二信任域内的第二网元提供所述第一信任域的服务的情况下,所述第一网元通过触发对所述第二网元的可信度量,获得所述可信度量对应的结果信息;
    在所述第一网元根据所述结果信息,确定所述第二网元可信的情况下,所述第一网元为所述第二网元提供所述服务。
  2. 根据权利要求1所述的方法,其特征在于,所述第一网元通过触发对所述第二网元的可信度量,获得所述可信度量对应的结果信息,包括:
    所述第一网元向所述第二网元发送度量请求,其中,所述度量请求用于请求所述第二网元触发对所述第二网元的可信度量;
    所述第一网元接收来自所述第二网元的度量响应,其中,所述度量响应用于指示所述可信度量对应的结果信息。
  3. 根据权利要求2所述的方法,其特征在于,所述第一信任域是第一运营商网络,所述第一网元是认证网元,所述第二信任域是第二运营商网络,所述第二网元是接入和移动性管理网元,所述第一网元向所述第二网元发送度量请求,包括:
    所述认证网元接收来自所述接入和移动性管理网元的认证请求;其中,所述认证请求用于请求所述认证网元为所述接入和移动性管理网元提供认证服务;
    所述认证网元根据所述认证请求,向所述接入和移动性管理网元发送所述度量请求,其中,所述度量请求用于请求所述接入和移动性管理网元触发对所述接入和移动性管理网元的可信度量。
  4. 根据权利要求3所述的方法,其特征在于,所述第一网元为所述第二网元提供所述服务,包括:
    所述认证网元向所述接入和移动性管理网元发送认证响应,其中,所述认证响应用于指示所述认证服务。
  5. 根据权利要求4所述的方法,其特征在于,所述认证服务用于指示终端注册到所述第二运营商网络所需的信息,所述终端归属于所述第一运营商网络。
  6. 根据权利要求5所述的方法,其特征在于,所述方法还包括:
    所述认证网元向所述接入和移动性管理网元发送验证证明信息,其中,所述验证证明信息用于所述终端验证所述认证网元或所述认证网元关联的第一验证实体是否可信,所述第一验证实体位于所述第一运营商网络,所述认证网元或所述第一验证实体用于验证第二验证实体是否可信,所述第二验证实体用于对所述接入和移动性管理网元进行可信度量,所述第二验证实体位于所述第二运营商网络。
  7. 根据权利要求2所述的方法,其特征在于,所述第一信任域是业务域,所述第二信任域是虚拟化设施域,所述第二网元是虚拟网络功能,所述第一网元向所述第二网元发送度量请求,包括:
    所述第一网元接收来自所述虚拟网络功能的注册请求,其中,所述注册请求用于请求所述第一网元为所述虚拟网络功能提供注册服务;
    所述第一网元根据所述注册请求,向所述虚拟网络功能发送所述度量请求,其中,所述度量请求用于请求所述虚拟网络功能提触发对所述虚拟网络功能提的可信度量。
  8. 根据权利要求7所述的方法,其特征在于,所述第一网元为所述第二网元提供所述服务,包括:
    所述第一网元向所述虚拟网络功能发送注册响应,其中,所述注册响应用于指示所述注册服务。
  9. 根据权利要求8所述的方法,其特征在于,所述注册服务用于指示所述第一网元允许所述虚拟网络功能注册到所述业务域。
  10. 根据权利要求1所述的方法,其特征在于,所述第一网元通过触发对所述第二网元的可信度量,获得所述可信度量对应的结果信息,包括:
    所述第一网元向所述第二信任域内的第三网元发送度量请求,其中,所述第三网元是所述第 二网元关联的网元,所述度量请求用于请求所述第三网元触发对所述第二网元的可信度量;
    所述第一网元接收来自所述第三网元的度量响应,其中,所述度量响应用于指示所述可信度量对应的结果信息。
  11. 根据权利要求10所述的方法,其特征在于,所述第一信任域是第一运营商网络,所述第一网元是第一会话管理网元,所述第二信任域是第二运营商网络,所述第二网元是第二用户面网元,所述第三网元是第二会话管理网元,所述第一网元向所述第二信任域内的第三网元发送度量请求,包括:
    所述第一会话管理网元接收来自所述第二会话管理网元的会话创建请求,其中,所述会话创建请求用于请求所述第一会话管理网元为所述第二用户面网元提供会话创建服务;
    所述第一会话管理网元根据所述会话创建请求,向所述第二会话管理网元发送所述度量请求,其中,所述度量请求用于请求所述第二会话管理网元触发对所述第二用户面网元的可信度量。
  12. 根据权利要求11所述的方法,其特征在于,所述第一网元为所述第二网元提供所述服务,包括:
    所述第一会话管理网元向所述第二会话管理网元发送会话创建响应,其中,所述会话建立创建用于指示所述会话创建服务。
  13. 根据权利要求12所述的方法,其特征在于,所述会话创建服务用于指示所述第二用户面网元需要与第一用户面网元建立会话,所述第一用户面网元是所述第一运营商网络内的网元。
  14. 根据权利要求13所述的方法,其特征在于,所述方法还包括:
    所述第一会话管理网元向所述第一用户面网元发送指示信息,其中,所述指示信息用于指示:所述第一用户面网元需要验证所述第一用户面网元接收的数据是否来自所述第二用户面网元。
  15. 根据权利要求1-14中任一项所述的方法,其特征在于,在所述第一网元根据所述结果信息,确定所述第二网元可信之前,所述方法还包括:
    所述第一网元接收来自所述第二网元的第二验证实体的信息,其中,所述第二验证实体是用于度量所述第二网元的验证实体,所述第二验证实体位于所述第二信任域内,所述第一网元与所述第二信任域内的验证实体之间不具有信任关系;
    所述第一网元根据所述第二验证实体的信息,确定所述第二验证实体可信。
  16. 根据权利要求15所述的方法,其特征在于,所述第一网元根据所述第二验证实体的信息,确定所述第二验证实体可信,包括:
    所述第一网元向所述第一信任域内的第一验证实体发送验证请求,其中,所述验证请求用于请求所述第一验证实体根据所述第二验证实体的信息,验证所述第二验证实体是否可信;
    所述第一网元接收来自所述第一验证实体的验证响应,其中,所述验证响应用于指示所述第二验证实体可信。
  17. 根据权利要求16所述的方法,其特征在于,所述验证请求用于请求订阅第一事件,所述第一事件为所述第一验证实体需要根据所述第二验证实体的信息,验证所述第二验证实体是否可信。
  18. 根据权利要求15-17中任一项所述的方法,其特征在于,所述第二验证实体的信息包括如下至少一项:所述第二验证实体的身份信息、或所述第二验证实体的证明信息。
  19. 根据权利要求18所述的方法,其特征在于,所述第二验证实体的身份信息包括如下至少一项:所述第二验证实体的标识、所述第二验证实体的签名。
  20. 根据权利要求18所述的方法,其特征在于,所述第二验证实体的证明信息包括如下至少一项:所述第二验证实体的部署证据、所述第二验证实体所属机构的凭据、所述第二验证实体的签约注册信息。
  21. 根据权利要求1-20中任一项所述的方法,其特征在于,在所述第一网元通过触发对所述第二网元的可信度量,获得所述可信度量对应的结果信息之前,所述方法还包括:
    所述第一网元确定没有所述第二网元的可信度量记录;或者,
    所述第一网元确定有所述第二网元的可信度量记录,但所述可信度量记录失效。
  22. 根据权利要求21所述的方法,其特征在于,所述第一网元确定没有所述第二网元的可信 度量记录,包括:
    所述第一网元确定至少一个网元未保存所述第二网元的可信度量记录;
    或者,
    所述第一网元确定有所述第二网元的可信度量记录,但所述可信度量记录失效,包括:
    所述第一网元确定至少一个网元保存有所述第二网元的可信度量记录,但所述可信度量记录失效;
    其中,所述至少一个网元包括:所述第一网元、或代理功能,其中,所述代理功能是所述第一网元与所述第二网元通信的中继。
  23. 根据权利要求1所述的方法,其特征在于,所述第一网元通过触发对所述第二网元的可信度量,获得所述可信度量对应的结果信息,包括:
    所述第一网元向所述第一信任域内的第一验证实体发送度量请求,其中,所述度量请求用于请求所述第一验证实体触发对所述第二网元的可信度量;
    所述第一网元接收来自所述第一验证实体的度量响应,其中,所述度量响应用于指示所述可信度量对应的结果信息。
  24. 根据权利要求1-23中任一项所述的方法,其特征在于,所述第一网元根据所述结果信息,确定所述第二网元可信,包括:
    所述第一网元根据所述结果信息中的至少一项满足预设条件,确定所述第二网元可信,其中,所述结果信息中的至少一项满足预设条件包括:用于表征所述度量凭证的标识与预配置的标识匹配、被度量网元的标识与所述第二网元的标识匹配、或所述结果信息指示所述第二网元可信。
  25. 一种通信装置,其特征在于,所述装置包括:用于执行如权利要求1-24中任一项所述的方法的模块。
  26. 一种通信装置,其特征在于,所述通信装置包括:处理器和存储器;所述存储器用于存储计算机指令,当所述处理器执行所述指令时,以使所述通信装置执行如权利要求1-24中任一项所述的通信方法。
  27. 一种计算机可读存储介质,其特征在于,所述计算机可读存储介质包括计算机程序或指令,当所述计算机程序或指令在计算机上运行时,使得所述计算机执行如权利要求1-24中任一项所述的通信方法。
  28. 一种计算机程序产品,其特征在于,所述计算机程序产品包括计算机程序或指令,当所述计算机程序或指令在计算机上运行时,使得所述计算机执行如权利要求1-24中任一项所述的通信方法。
PCT/CN2023/104041 2022-08-18 2023-06-29 通信方法及装置 WO2024037215A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210994211.6 2022-08-18
CN202210994211.6A CN117641342A (zh) 2022-08-18 2022-08-18 通信方法及装置

Publications (1)

Publication Number Publication Date
WO2024037215A1 true WO2024037215A1 (zh) 2024-02-22

Family

ID=89940614

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/104041 WO2024037215A1 (zh) 2022-08-18 2023-06-29 通信方法及装置

Country Status (2)

Country Link
CN (1) CN117641342A (zh)
WO (1) WO2024037215A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101453476A (zh) * 2009-01-06 2009-06-10 中国人民解放军信息工程大学 一种跨域认证方法和系统
US20190141536A1 (en) * 2018-12-28 2019-05-09 Alexander Bachmutsky Multi-domain trust establishment in edge cloud architectures
WO2020053481A1 (en) * 2018-09-13 2020-03-19 Nokia Technologies Oy Network function authentication using a digitally signed service request in a communication system
WO2022033676A1 (en) * 2020-08-12 2022-02-17 Telefonaktiebolaget Lm Ericsson (Publ) Establishment of secure communication
CN114503632A (zh) * 2019-10-07 2022-05-13 上海诺基亚贝尔股份有限公司 用于动态和多样性多域网络的自适应互信模型

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101453476A (zh) * 2009-01-06 2009-06-10 中国人民解放军信息工程大学 一种跨域认证方法和系统
WO2020053481A1 (en) * 2018-09-13 2020-03-19 Nokia Technologies Oy Network function authentication using a digitally signed service request in a communication system
US20190141536A1 (en) * 2018-12-28 2019-05-09 Alexander Bachmutsky Multi-domain trust establishment in edge cloud architectures
CN114503632A (zh) * 2019-10-07 2022-05-13 上海诺基亚贝尔股份有限公司 用于动态和多样性多域网络的自适应互信模型
WO2022033676A1 (en) * 2020-08-12 2022-02-17 Telefonaktiebolaget Lm Ericsson (Publ) Establishment of secure communication

Also Published As

Publication number Publication date
CN117641342A (zh) 2024-03-01

Similar Documents

Publication Publication Date Title
WO2020220865A1 (zh) 网络功能服务的身份校验方法及相关装置
TWI558253B (zh) 進行用戶認證的計算機執行方法及使用用戶識別碼得到存取目標域處服務的方法
WO2020057163A1 (zh) Mec平台部署方法及装置
WO2019236454A1 (en) Native blockchain platform for improving workload mobility in telecommunication networks
WO2019237058A1 (en) Systems, devices, and techniques for registering user equipment (ue) in wireless networks using a native blockchain platform
US20210377054A1 (en) Systems and methods for managing public key infrastructure certificates for components of a network
US11855977B2 (en) Systems and methods for configuring a network function proxy for secure communication
WO2009092315A1 (zh) 一种无线个域网接入方法
WO2022247812A1 (zh) 一种鉴权方法、通信装置和系统
CN116113936A (zh) 针对启用区块链的无线系统中的交易管理的方法、架构、装置和系统
US20230396602A1 (en) Service authorization method and system, and communication apparatus
WO2021099675A1 (en) Mobile network service security management
CN116134857A (zh) 基于服务的管理框架的接入控制
WO2023011630A1 (zh) 授权验证的方法及装置
WO2023066210A1 (zh) 鉴权方法及装置
WO2022222745A1 (zh) 一种通信方法及装置
WO2024037215A1 (zh) 通信方法及装置
WO2022067831A1 (zh) 一种建立安全通信方法及装置
WO2023216913A1 (zh) 通信方法及装置
WO2023169122A1 (zh) 通信方法和装置
WO2023216934A1 (zh) 通信方法及装置
WO2023169127A1 (zh) 通信方法、终端设备和通信装置
WO2024093923A1 (zh) 通信方法和通信装置
WO2024032226A1 (zh) 通信方法和通信装置
WO2023202412A1 (zh) 一种通信方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23854120

Country of ref document: EP

Kind code of ref document: A1