WO2011066779A1 - 业务流加密处理方法及系统 - Google Patents

业务流加密处理方法及系统 Download PDF

Info

Publication number
WO2011066779A1
WO2011066779A1 PCT/CN2010/079093 CN2010079093W WO2011066779A1 WO 2011066779 A1 WO2011066779 A1 WO 2011066779A1 CN 2010079093 W CN2010079093 W CN 2010079093W WO 2011066779 A1 WO2011066779 A1 WO 2011066779A1
Authority
WO
WIPO (PCT)
Prior art keywords
service flow
indication information
base station
aaa
sends
Prior art date
Application number
PCT/CN2010/079093
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 中兴通讯股份有限公司
Priority to JP2012541306A priority Critical patent/JP5795591B2/ja
Priority to KR1020127010617A priority patent/KR101695050B1/ko
Publication of WO2011066779A1 publication Critical patent/WO2011066779A1/zh

Links

Classifications

    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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

Definitions

  • the present invention relates to the field of communications, and in particular to a service stream encryption processing method and system.
  • BACKGROUND OF THE INVENTION Worldwide Interoperability for Microwave Access (WIMAX), as a new generation of broadband wireless access technology, provides a complete security mechanism to ensure the interests of operators and users.
  • WIMAX Worldwide Interoperability for Microwave Access
  • the 802.16e protocol provides an air interface data encryption transmission mechanism to ensure the confidentiality of data transmission in an open wireless environment, which can effectively prevent sensitive information from being illegally stolen.
  • the transmission of data in the air interface is based on connection, and each connection has a specific Quality of Service (QoS) attribute.
  • QoS Quality of Service
  • Each activated service flow corresponds to a service transport connection.
  • the Qos attribute of the service flow is authenticated upon access.
  • AAA Authentication Authorization Accounting
  • the server is allocated and sent to the base station (Base Station, BS for short), and the BS is used when establishing the service flow. If a certain service flow of a user has high security requirements, the data needs to be encrypted and transmitted. For example, user A and two pre-configured two active grant services are pre-configured with two best-effort (Best Effort, BE for short) service flows.
  • UGS Unsolicited Grant Service
  • User A has higher security requirements for data transmission on the air interface, but user B does not require it; or user C (including BE and pre-configured with multiple service flows) UGS) has high security requirements for the data transmitted by its UGS service, and there is no security requirement for the data transmitted on the BE traffic.
  • the R3 and R6 message interfaces in the existing NWG network protocol do not describe the security requirements of the service flow, and it is not convenient to implement the connection-based encrypted data transmission requirement. If the security requirements of the service flow (connection) are described or configured in the BS, the BS acts as a distributed access point and does not know the user information and the QoS attribute of its connection in advance, so the base station cannot be based on the user's information and QoS.
  • the present invention has been made in view of the problem that a base station cannot configure a service security requirement according to user information and QoS attributes in the related art.
  • the main object of the present invention is to provide a service flow. A confidential solution to solve the above problems.
  • a traffic stream encryption processing method is provided.
  • the service flow encryption processing method includes: the authentication and authorization charging server AAA Server sends indication information indicating whether the service flow needs to be encrypted to the authentication and authorization charging client AAA Client; AAA Client to the service flow ⁇ ⁇ authorized anchor point
  • the Anchor SFA sends the indication information; the Anchor SFA sends the indication information to the base station; the base station encrypts or does not encrypt the service flow according to the indication information.
  • the AAA Server sends the indication information to the AAA client, where the AAA Server carries the indication information in the Access Accept Access Accept message, and the AAA Server Access Accept message is sent to the AAA Client.
  • the AAA Server carries the indication information in the Access Accept message, including: adding a TLV in the subtype/length/value format TLV of the QoS-Descriptor of the Access Accept message, where the added TLV is used to indicate whether the service flow needs encryption.
  • the AAA client sends the indication information to the Anchor SFA, where the AAA client carries the indication information in the service flow parameter of the resource reservation request RR-Req message; the AAA Client sends the RR-Req message to the Anchor SFA.
  • the Anchor SFA sends the indication information to the base station, including: the Anchor SFA carries the indication information in the service flow parameter of the Data Channel Registration Request Path_Reg_Req message sent to the base station.
  • the base station performs encryption processing on the service flow according to the indication information, including: the base station determines a security association SA; the base station associates the identifier ID of the SA with the service flow, and sends the ID of the SA associated with the service flow to the mobile station; / or the mobile station encrypts and/or decrypts the data stream of the service flow using the SA corresponding to the ID.
  • a traffic stream encryption processing system is also provided.
  • the traffic flow confidentiality processing system includes: AAA Server, AAA Client, Anchor SFA, and a base station; the AAA Server sends an indication to the AAA Client indicating whether the service flow needs to be encrypted; AAA Client to Anchor SFA Send instructions; Anchor SFA The indication information is sent to the base station; the base station encrypts or does not encrypt the service flow according to the indication information.
  • the AAA server includes: a first setting module, configured to set indication information in an Access Accept message; and a first sending module, configured to send an Access Accept message to the AAA Client.
  • the first setting module is used for the QoS-Descriptor of the Access Accept message
  • the TLV is added to the TLV, and the added TLV is used to indicate whether the service flow needs to be encrypted.
  • the AAA client includes: a second setting module, configured to carry the indication information in the service flow parameter of the RR-Req message; and a second sending module, configured to send the RR-Req message to the Anchor SFA.
  • FIG. 1 is a flowchart of a service flow encryption processing method according to an embodiment of the present invention
  • FIG. 2 is a flowchart of establishing an encrypted service flow according to an embodiment of the present invention
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict.
  • the invention will be described in detail below with reference to the drawings in conjunction with the embodiments.
  • the steps shown in the flowchart of the accompanying drawings may be performed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some In this case, the steps shown or described may be performed in a different order than the ones described herein.
  • FIG. 1 is a flowchart of a service flow encryption method according to an embodiment of the present invention.
  • the method includes the following steps: step S 102 to step S.
  • the AAA Server sends, to the AAA Client, indication information indicating whether the service flow needs to be encrypted.
  • the AAA Server itself is a centralized point for recording user QoS information. Here, you can set whether the service needs to be encrypted according to the information recorded on the AAA Server.
  • the AAA client as a module that interacts with the AAA server, can be set inside the Anchor Service Flow Authorization (Anchor SFA) or other network elements.
  • Anchor SFA Anchor Service Flow Authorization
  • Step S104 the AAA Client sends an indication message to the Anchor SFA (or the anchor data channel function entity Anchor DPF).
  • the Anchor SFA sends the indication information to the base station.
  • Step S108 The base station uses the indication information to encrypt or not encrypt the service flow.
  • Step 4 S201, in an Extensible Authentication Protocol (abbreviation)
  • the AAA server sends an R3 Access Accept message to the AAA client.
  • the message carries the indication information indicating whether the service flow needs to be encrypted.
  • the AAA Client can also be called. Is the Authenticator.
  • the AAA Server may send an indication to the AAA Client to indicate whether the service flow needs to be encrypted through an Access Accept message, and the indication information may be sent through other messages, for example, through a newly defined message, where the Access Accept message is only
  • the Access Accept message is only
  • An example of a message capable of carrying the indication information, but is not limited thereto, can play the same role as long as it is a message capable of carrying indication information indicating whether the service flow needs to be encrypted.
  • a new TLV security level (Security Level) may be added in the sub-TLV of the QoS-Descriptor of the Access Accept message.
  • the data is organized in the format of "data type, data length, data value", which is expressed in English as “Type type, Length length, Value value”, referred to as TLV format), and the size is 1 byte.
  • TLV format The meaning of Security Level is shown in Table 1. 0 indicates that the user has no security requirements for the data transmitted on this service flow; 1 indicates that the user has security requirements for the data transmitted on this service flow. It should be noted that the other bytes in the message can be used to indicate whether the service flow needs to be encrypted. The following uses the TLV Security Level as an example. Table 1
  • TEK Traffic Encryption Key
  • MS Mobile Station, MS for short
  • BS ten carrier
  • the MS uses the Key-Request and Key-Reply messages to complete the TEK interaction of the SA.
  • TEK is a key used to encrypt and decrypt traffic data.
  • Step S202 During the service flow establishment phase, the Authenticator sends an RR_Req message to the SFA.
  • Each service flow parameter in RR Req carries a new TLV Security Level.
  • the Authenticator may carry the indication information indicating whether each service flow needs to be encrypted in the RR_Req message (the TLV Security Level is an example of the indication information).
  • the above indication information may also be carried in other messages.
  • Step S203 The SFA sends a data channel registration request Path_Reg_Req message to the BS, and a new TLV Security Level is added to each service flow parameter in the Path_Reg_Req.
  • the SFA may carry the foregoing indication information in the Path_Reg_Req message.
  • the indication information may be carried in other messages.
  • the Path_Reg_Req message is only an explanation for this.
  • Step S204 For the Security Level value in each service flow, if the Security Level is 0, it indicates that the data transmitted on the service flow is not necessarily encrypted, so it is not necessary to associate the security association SA with the encryption attribute for the service flow. Then the SAID in DSA_Req can be OxFFFF (indicating that it is not associated with the encrypted SA); if the Secureity Level is 1, it indicates that the data transmitted on this traffic flow has security requirements and needs to be encrypted.
  • the BS selects an SA with a data encryption type (Date Crypt Type) other than 0 from the SA generated by the three-step handshake phase negotiation, associates its SAID with the service flow, and carries the message to the MS through the DSA_Req message.
  • Date Crypt Type data encryption type
  • the BS receives the data flow with the security requirement (that is, needs to be encrypted), and finds the SA (including the corresponding TEK) to which the service flow is associated, and then specifies the data crypt type in the SA.
  • the encryption algorithm uses TEK to encrypt the media data and assembles the MAC PDU.
  • the EC bit in the PDU header is set to 1, indicating that the MAC PDU is hard-passed and sent to the MS through the air interface.
  • the MS receives the MAC PDU, identifies the EC bit as 1, and determines that it is an encrypted packet.
  • the corresponding SA is found according to the connection information in the PDU header, and the decryption algorithm specified by the data crypt type in the SA is used to decrypt the media data by using TEK.
  • the MS uses similar processing when receiving the data stream of the service flow with security requirements, and will not be mentioned here.
  • the security level configured by each service flow parameter determines whether the data transmitted in the air interface needs to be transmitted in an encrypted manner.
  • the operator can configure specific QoS attributes based on the user, and then the specific security attributes can be configured based on the user's connection.
  • a service flow encryption processing system is also provided.
  • the system includes: AAA Server, AAA Client, Anchor SFA, base station, in the system.
  • the AAA server sends an indication to the AAA client to indicate whether the service flow needs to be encrypted;
  • the AAA Client sends the indication information to the Anchor SFA;
  • the SFA sends the indication information to the base station; the base station encrypts or does not encrypt the service flow according to the indication information.
  • deal with. 3 is a structural block diagram of a service flow encryption processing system according to an embodiment of the present invention.
  • the AAA Server includes: a first setting module 32, where the module is configured to set indication information in an Access Accept message; A sending module 34, configured to send an Access Accept message to the AAA Client.
  • the first setting module 32 is configured to add a TLV in the sub-TLV of the QoS-Descriptor of the Access Accept message, where the added TLV is used to indicate whether the service flow needs to be encrypted.
  • FIG. 3 is a structural block diagram of a service flow encryption processing system according to an embodiment of the present invention.
  • the AAA Server includes: a first setting module 32, where the module is configured to set indication information in an Access Accept message; A sending module 34, configured to send an Access Accept message to the AAA Client.
  • the first setting module 32 is configured to add a TLV in
  • the AAA client includes: a second setting module 36, configured to carry indication information in a service flow parameter of a resource reservation request RR-Req message; a second sending module 38, where the module is used to The -Req message is sent to the Anchor SFA.
  • the processing between the AAA Server, the AAA Client, the Anchor SFA, and the base station has been described in detail in the above-mentioned embodiment, and will not be described again in jt.
  • the QoS profile of the Access Accept message sent by the AAA server carries the Security Level parameter.
  • each service flow of the user has a Security Level value.
  • the base station can determine, according to the Security Level value, whether the data needs to be transmitted in an encrypted manner on the corresponding service transmission connection. Since the Qos Profile is typically configurable based on users and connections on the AAA Server, it is also convenient to implement traffic-based transmissions based on users and connections. In summary, the foregoing embodiment solves the problem that the base station cannot configure the service flow security requirement according to the user information and the QoS attribute in the related art, and further implements the security requirement of configuring the service flow according to the user information and the QoS attribute.
  • modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device, or they may be separately fabricated into individual integrated circuit modules, or they may be Multiple modules or steps are made into a single integrated circuit module. Thus, the invention is not limited to any particular combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

业务流加密处理方法及系统 技术领域 本发明涉及通信领域，具体而言， 涉及一种业务流加密处理方法及系统。 背景技术 微波接入全球互通 ( Worldwide Interoperability for Microwave Access, 简 称为 WiMAX ) 作为新一代的宽带无线接入技术， 提供了完善的安全机制来 保证运营商和用户的利益。 例如， 802.16e协议提供空口数据加密传输机制， 保证在开放的无线环境下数据传输的机密性， 可以有效防止敏感信息被非法 窃取。 WiMAX 系统中数据在空口的传输是基于连接的， 每个连接都具有特定 的服务质量（Quality of Service, 简称为 QoS )属性。 每条激活的业务流和业 务传输连接 对应。 业务流的 Qos 属性在接入时由认证 ·ί受权计费
( Authentication Authorization Accounting , 简称为 AAA ) 月艮务器 ( Server ) 分配下来并发送给基站（ Base Station, 简称为 BS ), BS在建立业务流时使用。 如果某个用户的某条业务流具有高的安全需求， 需要加密传输数据， 例如， 预配置两条尽力而为 （Best Effort, 简称为 BE )业务流的用户 A和预配置两 条主动授予服务（Unsolicited Grant Service, 简称为 UGS ) 业务流的用户 B, 用户 A对数据在空口传输的安全性要求较高， 而用户 B没有要求； 或者预配 置了多条业务流的用户 C (包含 BE和 UGS), 对其 UGS业务传输的数据具有 较高的安全需求， 而对 BE业务流上传输的数据没有安全性要求。 现有的 NWG网络协议中 R3和 R6消息接口中没有对业务流的安全需求 进行描述， 不便于实现基于连接的加密数据传输需求。 如果业务流 (连接)的 安全需求在 BS描述或者配置， BS作为一个分布式的接入点， 事先并不知晓 用户信息和及其连接的 Qos属性， 所以在基站并不能根据用户的信息和 QoS 属性来配置特定用户的特定业务流的安全需求。 发明内容 针对相关技术中基站不能根据用户的信息和 QoS 属性来配置业务安全 需求的问题而提出本发明， 为此， 本发明的主要目的在于提供一种业务流加 密处理方案， 以解决上述问题。 为了实现上述目的， 才艮据本发明的一个方面， 提供了一种业务流加密处 理方法。 根据本发明的业务流加密处理方法包括： 认证授权计费服务器 AAA Server向认证授权计费客户端 AAA Client发送用于指示业务流是否需要加密 的指示信息； AAA Client 向业务流 ·ί受权锚点 Anchor SFA 发送指示信息； Anchor SFA将指示信息发送给基站；基站根据指示信息对业务流进行加密或 不加密处理。 优选地， AAA Server向 AAA Client发送指示信息包括： AAA Server在 接入接受 Access Accept消息中携带指示信息； AAA Server Access Accept 消息发送给 AAA Client。 优选地， AAA Server 在 Access Accept 消息中携带指示信息包括： 在 Access Accept消息的服务质量描述符 QoS -Descriptor的子类型 /长度 /数值格 式 TLV中增加 TLV, 增加的 TLV用于指示业务流是否需要加密。 优选地， AAA Client向 Anchor SFA发送指示信息包括： AAA Client在 资源预留请求 RR-Req 消息的业务流参数中携带指示信息； AAA Client 将 RR-Req消息发送给 Anchor SFA。 优选地， Anchor SFA将指示信息发送给基站包括： Anchor SFA在发送 给基站的数据通道登记请求 Path_Reg_Req 消息的业务流参数中携带指示信 息。 优选地， 基站根据指示信息对业务流进行加密处理包括： 基站确定一个 安全联盟 SA; 基站将 SA的标识 ID与业务流进行关联， 并将与业务流关联 的 SA的 ID发送移动台； 基站和 /或移动台使用 ID对应的 SA对业务流的数 据流进行加密和 /或解密。 为了实现上述目的， 根据本发明的另一方面， 还提供了一种业务流加密 处理系统。 才艮据本发明的业务流力口密处理系统， 包括： AAA Server, AAA Client, Anchor SFA、 基站； AAA Server向 AAA Client发送用于指示业务流是否需 要加密的指示信息； AAA Client向 Anchor SFA发送指示信息； Anchor SFA 将指示信息发送给基站；基站根据指示信息对业务流进行加密或不加密处理。 优选地， AAA Server包括： 第一设置模块， 用于在 Access Accept消息 中设置指示信息； 第一发送模块， 用于将 Access Accept 消息发送给 AAA Client。 优选地， 第一设置模块用于在 Access Accept消息的 QoS -Descriptor的子
TLV中增加 TLV, 增加的 TLV用于指示业务流是否需要加密。 优选地， AAA Client包括： 第二设置模块， 用于在 RR-Req消息的业务 流参数中携带指示信息； 第二发送模块， 用于将 RR-Req消息发送给 Anchor SFA。 通过本发明，解决了相关技术中基站不能根据用户的信息和 QoS属性来 配置业务流安全需求的问题，进而实现了根据用户信息和 QoS属性配置业务 流的安全需求。 本发明的其它特征和优点将在随后的说明书中阐述， 并且， 部分地从说 明书中变得显而易见， 或者通过实施本发明而了解。 本发明的目的和其他优 点可通过在所写的说明书、 权利要求书、 以及附图中所特别指出的结构来实 现和获得。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部 分， 本发明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的 不当限定。 在附图中： 图 1是才艮据本发明实施例的业务流加密处理方法的流程图； 图 2是才艮据本发明实施例的建立加密的业务流的流程图； 图 3是才艮据本发明实施例的业务流加密处理系统的结构框图。 具体实施方式 需要说明的是， 在不冲突的情况下， 本申请中的实施例及实施例中的特 征可以相互组合。 下面将参考附图并结合实施例来详细说明本发明。 在以下实施例中， 在附图的流程图示出的步 4聚可以在诸如一组计算机可 执行指令的计算机系统中执行， 并且， 虽然在流程图中示出了逻辑顺序， 但 是在某些情况下， 可以以不同于此处的顺序执行所示出或描述的步骤。 在本实施例， 提供了一种业务流加密方法， 图 1是根据本发明实施例的 业务流加密方法的流程图， 如图 1 所示， 该方法包括如下的步 4聚 S 102至步 骤 S 108: 步骤 S 102, AAA Server向 AAA Client发送用于指示业务流是否需要加 密的指示信息。 由于 AAA Server本身就是一个记录用户 Qos信息的集中点， 在此处可 以根据 AAA Server上记录的信息来设置业务是否需要加密。 需要说明的， AAA Client作为与 AAA Server进行交互的模块， 可以设置在业务流授权锚 点 ( Anchor Service Flow Authorization, 简称为 Anchor SFA ) 的内部， 也可 以设置于其他网元之中。 步骤 S 104, AAA Client向 Anchor SFA (或称为锚点数据通道功能实体 Anchor DPF )发送指示信息。 步骤 S 106 , Anchor SFA将该指示信息发送给基站。 步骤 S 108, 基站 居该指示信息对业务流进行加密或不加密处理。 通过上述步 4聚， 釆用在 AAA Server上对业务流安全需求进行配置， 并发 送给基站，从而解决相关技术中基站不能根据用户的信息和 QoS属性来配置 业务流安全需求的问题。 下面以业务流需要加密为例， 结合业务流的建立流程对上述步骤进行说 明， 需要说明的是， 以下只是优选的实施例。 图 2是才艮据本发明实施例的建立加密的业务流的流程图， 如图 2所示， 该流程包括如下步骤： 步 4聚 S201 , 在初始可扩展鉴权协议 ( Extensible Authentication Protocol, 简称为 EAP )鉴权成功后， AAA Server向 AAA客户端 （ Client )发送 R3接 入接受 （ Access Accept ) 消息， 该消息中携带有指示业务流是否需要加密的 指示信息， 其中， AAA Client也可以称为认证者 （ Authenticator )。 优选地， AAA Server可以通过 Access Accept消息向 AAA Client发送用 于指示业务流是否需要加密的指示信息，可以通过其他消息发送该指示信息， 例如， 通过一个新定义的消息， 在此 Access Accept消息只是对能够携带指示 信息的消息的一个举例说明， 但并不限于此， 只要是能够携带用于指示业务 流是否需要加密的指示信息的消息都可以起到相同的作用。当然，使用 Access Accept消息实现较为容易。 优选地， 在使用 Access Accept消息的携带上述指示信息的情况下， 可以 在 Access Accept消息的月艮务质量描述符 ( QoS -Descriptor ) 的子 TLV中增加 新的 TLV安全级别 （Security Level ) (在通信流域中， 按照 "数据类型、 数 据长度、数据数值"的格式组织数据的， 用英文表示就是 "Type类型， Length 长度， Value值"， 简称 TLV格式）， 大小为 1个字节。 Security Level的意义 见表 1 , 0表明用户对在此业务流上传输的数据无安全性要求； 1表明用户对 在此业务流上传输的数据有安全性要求。 需要说明的， 可以使用该消息中其 他字节的来指示业务流是否需要加密，下面以 TLV Security Level为例进行说 明。 表 1
Figure imgf000007_0001
为了更好的对本实施例进行说明， 在此首先对安全联盟 ( Security Alliance , 简称为 S A ) 流量加密密钥 （ Traffic Encryption Key , 简称为 TEK ) 进行说明。 在 SA TEK三步握手阶段， 移动台 （ Mobile Station, 简称为 MS ) 和 BS 十办商生成具有加密属性的安全联盟 SA, 其中， 在数据加密类型 （data crypt type ) 描述了加解密算法。 MS 用密钥请求 （ Key-Request )、 密钥回复 ( Key-Reply )消息完成 SA的 TEK交互， 成功之后 MS和 BS之间拥有相 同的 TEK密钥。 TEK是用来加解密业务流数据的密钥。 步骤 S202 ,在业务流建立阶段， Authenticator发送 RR_Req消息给 SFA ,
RR Req中每条业务流参数携带新增的 TLV Security Level。 需要说明的， 在 该步 4聚中， Authenticator可以在 RR_Req消息中携带用于指示每条业务流是 否需要加密的指示信息 （TLV Security Level是对该指示信息的举例说明）， 也可以在其他消息中携带上述指示信息。 步骤 S203 , SFA 发送数据通道登记请求 Path_Reg_Req 消息给 BS , Path_Reg_Req中每条业务流参数中新增 TLV Security Level。 在该步骤中， SFA可以在 Path_Reg_Req消息中携带上述指示信息， 当然， 可以在其他消 息中携带上述指示信息， 在本实施例中， Path_Reg_Req消息只是对此的一个 解释说明。 步骤 S204, 针对每条业务流中的 Security Level值， 如果 Security Level 为 0, 那么表明在此条业务流上传输的数据不必要加密， 所以不必为此条业 务流关联加密属性的安全联盟 SA , 那么 DSA_Req 中的 SAID 可以为 OxFFFF (表明不和加密的 S A关联）； 如果 S ecurity Level为 1 , 那么表明在此 条业务流上传输的数据具有安全需求， 需要加密传输。 BS根据策略， 从三步 握手阶段协商生成的 SA中选择数据加密类型（Date Crypt Type)非 0的一个 SA, 将其 SAID与此条业务流关联起来， 并通过 DSA_Req消息携带给 MS。 建立具有安全属性的业务流的其余步骤， 和现有业务流建立过程一致， 在此不再赘述。 在此之后， BS接收到具有安全需求（即， 需要加密）业务流 的数据流， 则查找到此业务流关联到的 SA (包括对应的 TEK), 然后， 用该 SA中 data crypt type指定的加密算法，釆用 TEK加密媒体数据，并组装 MAC PDU, PDU头中的 EC比特置 1 , 表明此 MAC PDU是经过力口密的， 通过空 口发送到 MS。 MS接收到 MAC PDU, 识别 EC位为 1 , 判定为加密包。 根 据 PDU头中的连接信息查找到对应的 S A ,用 S A中 data crypt type指定的解 密算法， 釆用 TEK解密媒体数据。 同理， MS在接收到具有安全需求的业务 流的数据流时使用类似的处理即可， 在此不再赞述。 通过上述步骤 S201至步骤 S204, 在网元 AAA Server中， 每条业务流参 数配置的 Security Level, 决定在空口传输的数据是否需要以加密的方式传 输。 在 AAA Server, 运营商可以基于用户配置特定的 Qos属性， 那么同样可 以基于用户的连接配置特定的安全属性。 与上述实施例相对应， 还提供了一种业务流加密处理系统， 上述已经进 行过说明的， 在此不再赘述， 该系统包括： AAA Server, AAA Client, Anchor SFA、 基站、 在该系统中， AAA Server向 AAA Client发送用于指示业务流是 否需要加密的指示信息； AAA Client向 Anchor SFA发送指示信息； Anchor
SFA将指示信息发送给基站； 基站根据指示信息对业务流进行加密或不加密 处理。 图 3是才艮据本发明实施例的业务流加密处理系统的结构框图， 如图 3所 示， AAA Server包括： 第一设置模块 32 , 该模块用于在 Access Accept消息 中设置指示信息； 第一发送模块 34 , 该模块用于将 Access Accept消息发送 给 AAA Client。 优选地， 第一设置模块 32用于在 Access Accept消息的 QoS-Descriptor 的子 TLV中增加 TLV, 增加的 TLV用于指示业务流是否需要加密。 如图 3所示， AAA Client包括： 第二设置模块 36 , 该模块用于在资源预 留请求 RR-Req消息的业务流参数中携带指示信息； 第二发送模块 38 , 该模 块用于将 RR-Req消息发送给 Anchor SFA。 在该系统中， AAA Server, AAA Client, Anchor SFA、基站之间的处理过程已经在上书实施例中进行了详细的 说明， 在 jt匕不再赘述。 在本实施例中，可以通过 AAA Server发送的 Access Accept消息中的 Qos Profile参数携带 Security Level参数。 从而在建立业务流的过程中， 用户的每 条业务流都有一个 Security Level值。 基站可以根据 Security Level值决定在 对应业务传输连接上数据是否需要以加密的方式传输。 由于 Qos Profile通常 在 AAA Server上基于用户和连接可配置，所以业务流是否加密传输也可以方 便实现基于用户和连接可配置。 综上所述， 通过上述实施例解决了相关技术中基站不能根据用户的信息 和 QoS属性来配置业务流安全需求的问题，进而实现了根据用户信息和 QoS 属性配置业务流的安全需求。
显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可 以用通用的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布 在多个计算装置所组成的网络上， 可选地， 它们可以用计算装置可执行的程 序代码来实现， 从而， 可以将它们存储在存储装置中由计算装置来执行， 或 者将它们分别制作成各个集成电路模块， 或者将它们中的多个模块或步骤制 作成单个集成电路模块来实现。 这样， 本发明不限制于任何特定的硬件和软 件结合。
以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本 领域的技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的^"神和 原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护 范围之内。

Claims

权 利 要 求 书
1. 一种业务流加密处理方法， 其特征在于， 包括：
认证 ·ί受权计费月艮务器 AAA Server 向认证 ·ί受权计费客户端 AAA Client发送用于指示业务流是否需要加密的指示信息；
所述 AAA Client向业务流 ·ί受权锚点 Anchor SFA发送所述指示信息；
Anchor SFA将所述指示信息发送给基站；
所述基站才艮据所述指示信息对所述业务流进行加密或不加密处理。
2. 才艮据权利要求 1所述的方法，其特征在于，所述 AAA Server向所述 AAA Client发送所述指示信息包括：
所述 AAA Server在接入接受 Access Accept消息中携带所述指示信 息；
所述 AAA Server将所述 Access Accept消息发送给所述 AAA Client,
3. 根据权利要求 2所述的方法，其特征在于，所述 AAA Server在所述 Access Accept消息中携带所述指示信息包括：
在所述 Access Accept消息的月艮务质量描述符 QoS-Descriptor的子类 型 /长度 /数值格式 TLV中增加 TLV,所述增加的 TLV用于指示所述业务 流是否需要加密。
4. 根据权利要求 1或 3所述的方法， 其特征在于， 所述 AAA Client向所述 Anchor SFA发送所述指示信息包括：
所述 AAA Client在资源预留请求 RR-Req消息的业务流参数中携带 所述指示信息；
所述 AAA Client将所述 RR-Req消息发送给所述 Anchor SFA。
5. 根据权利要求 1或 3所述的方法， 其特征在于， Anchor SFA将所述指示 信息发送给所述基站包括：
所述 Anchor SFA 在发送给所述基站的数据通道登记请求 Path_Reg_Req消息的业务流参数中携带所述指示信息。
6. 根据权利要求 1所述的方法， 其特征在于， 所述基站根据所述指示信息 对所述业务流进行加密处理包括： 所述基站确定一个安全联盟 SA;
所述基站将所述 SA的标识 ID与所述业务流进行关联， 并将与所述 业务流关联的 SA的 ID发送移动台；
所述基站和 /或移动台使用所述 ID对应的 SA对所述业务流的数据 流进行加密和 /或解密。
7. 一种业务流加密处理系统， 包括： AAA Server, AAA Client, Anchor SFA、 基站， 其特征在于， 所述 AAA Server向所述 AAA Client发送用于指示业务流是否需要 加密的指示信息；
所述 AAA Client向所述 Anchor SFA发送所述指示信息； 所述 Anchor SFA将所述指示信息发送给所述基站；
所述基站才艮据所述指示信息对所述业务流进行加密或不加密处理。
8. 根据权利要求 7所述的系统， 其特征在于， 所述 AAA Server包括： 第一设置模块， 用于在 Access Accept消息中设置所述指示信息； 第一发送模块， 用于将所述 Access Accept 消息发送给所述 AAA Client。
9. 根据权利要求 8所述的系统， 其特征在于， 所述第一设置模块用于在所 述 Access Accept消息的 QoS -Descriptor的子 TLV中增加 TLV, 所述增 加的 TLV用于指示所述业务流是否需要加密。
10. 根据权利要求 7或 9所述的系统， 其特征在于， 所述 AAA Client包括： 第二设置模块， 用于在 RR-Req消息的业务流参数中携带所述指示 信息；
第二发送模块， 用于将所述 RR-Req消息发送给所述 Anchor SFA。
PCT/CN2010/079093 2009-12-01 2010-11-24 业务流加密处理方法及系统 WO2011066779A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012541306A JP5795591B2 (ja) 2009-12-01 2010-11-24 サービスフローの暗号化処理方法及びシステム
KR1020127010617A KR101695050B1 (ko) 2009-12-01 2010-11-24 서비스 플로우의 암호화 처리 방법 및 시스템

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910246244.7A CN102083062B (zh) 2009-12-01 2009-12-01 业务流加密处理方法及系统
CN200910246244.7 2009-12-01

Publications (1)

Publication Number Publication Date
WO2011066779A1 true WO2011066779A1 (zh) 2011-06-09

Family

ID=44088777

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/079093 WO2011066779A1 (zh) 2009-12-01 2010-11-24 业务流加密处理方法及系统

Country Status (4)

Country Link
JP (1) JP5795591B2 (zh)
KR (1) KR101695050B1 (zh)
CN (1) CN102083062B (zh)
WO (1) WO2011066779A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103209402B (zh) 2012-01-17 2018-03-23 中兴通讯股份有限公司 终端组可及性确定方法及系统
JP6335516B2 (ja) * 2014-01-15 2018-05-30 キヤノン株式会社 通信装置、その制御方法、およびプログラム
WO2019174015A1 (zh) 2018-03-15 2019-09-19 Oppo广东移动通信有限公司 处理数据的方法、接入网设备和核心网设备
JP2021503743A (ja) * 2017-11-07 2021-02-12 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． データ処理方法とネットワーク装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101128061A (zh) * 2007-09-27 2008-02-20 中兴通讯股份有限公司 移动管理单元、演进基站、确定用户面是否加密的方法和系统
CN101488847A (zh) * 2008-01-18 2009-07-22 华为技术有限公司 一种数据加密的方法、装置和系统
EP2101526A1 (en) * 2008-03-10 2009-09-16 Nokia Siemens Networks Oy Indication of entry decisions to local networks

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101345679B (zh) * 2008-08-21 2013-01-16 中兴通讯股份有限公司 动态业务的QoS保证方法、系统以及AAA和Anchor SFA

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101128061A (zh) * 2007-09-27 2008-02-20 中兴通讯股份有限公司 移动管理单元、演进基站、确定用户面是否加密的方法和系统
CN101488847A (zh) * 2008-01-18 2009-07-22 华为技术有限公司 一种数据加密的方法、装置和系统
EP2101526A1 (en) * 2008-03-10 2009-09-16 Nokia Siemens Networks Oy Indication of entry decisions to local networks

Also Published As

Publication number Publication date
CN102083062B (zh) 2015-05-20
KR20120117731A (ko) 2012-10-24
JP2013512631A (ja) 2013-04-11
JP5795591B2 (ja) 2015-10-14
CN102083062A (zh) 2011-06-01
KR101695050B1 (ko) 2017-01-10

Similar Documents

Publication Publication Date Title
US10389831B2 (en) Method, apparatus and system for provisioning a push notification session
JP4649513B2 (ja) 無線携帯インターネットシステムの認証方法及び関連キー生成方法
US7945777B2 (en) Identification information protection method in WLAN inter-working
EP1811744B1 (en) Method, system and centre for authenticating in End-to-End communications based on a mobile network
EP2062189B1 (en) Method and system for secure processing of authentication key material in an ad hoc wireless network
WO2020052414A1 (zh) 一种数据保护方法、设备及系统
JP5480890B2 (ja) 制御信号の暗号化方法
US20200228977A1 (en) Parameter Protection Method And Device, And System
US20060059344A1 (en) Service authentication
JP2018523933A (ja) サービス層におけるコンテンツセキュリティ
WO2010078755A1 (zh) 电子邮件的传送方法、系统及wapi终端
KR20080077006A (ko) 관리 프레임 보호 장치 및 방법
WO2008006312A1 (en) A realizing method for push service of gaa and a device
WO2012083828A1 (zh) 本地路由业务的实现方法、基站及系统
WO2007028328A1 (fr) Procede, systeme et dispositif de negociation a propos d'une cle de chiffrement partagee par equipement utilisateur et equipement externe
WO2017197596A1 (zh) 通信方法、网络侧设备和用户设备
WO2010069202A1 (zh) 认证协商方法及系统、安全网关、家庭无线接入点
WO2011066779A1 (zh) 业务流加密处理方法及系统
WO2007147354A1 (fr) Procédé et système pour extraire une clé de messagerie instantanée
WO2007000100A1 (fr) Procédé d’identification de message de gestion d’exécution inversée
WO2022134089A1 (zh) 一种安全上下文生成方法、装置及计算机可读存储介质
WO2019015618A1 (zh) 通信隧道端点地址分离方法、终端、网关及存储介质
WO2015165250A1 (zh) 一种终端接入通信网络的方法、装置及通信系统
US20090136043A1 (en) Method and apparatus for performing key management and key distribution in wireless networks
Tschofenig et al. RSVP security properties

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: 10834212

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20127010617

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2012541306

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10834212

Country of ref document: EP

Kind code of ref document: A1