JP5795591B2 - Service flow encryption processing method and system - Google Patents

Description

  The present invention relates to the communication field, and more particularly, to a service flow encryption processing method and system.

  WiMAX (Worldwide Interoperability for Microwave Access, hereinafter abbreviated as WiMAX) provides a complete security mechanism as a new era of broadband wireless access technology, guaranteeing the interests of managers (providers) and users. For example, the 802.16e protocol provides a data encryption transmission mechanism by air, guarantees confidentiality of data transmission in an open wireless environment, and can prevent illegal theft of sensitive information.

Transmission of data in the air in the WiMAX system is based on connections, and each connection has a specific quality of service (hereinafter referred to as QoS) attribute. Each active service flow and service transmission connection correspond one by one. The QoS attribute of the service flow is assigned by an authentication / authorization / accounting (hereinafter referred to as AAA) server (Server) and transmitted to a base station (Base Station). Used when the BS constructs a service flow.
When a user has a high security requirement for a certain service flow, data must be encrypted and transmitted. For example, a user A in which two best effort (hereinafter referred to as BE) service flows are arranged in advance. In the case of user B in which two unsolicited grant services (hereinafter abbreviated as UGS) service flows are arranged in advance, there is a high security requirement in the air transmission of data of user A, and user B has a request Absent. Alternatively, in the case of user C (including BE and UGS) in which a plurality of service flows are arranged in advance, high security is required for data transmitted through the UGS service, and there is no security requirement for data transmitted through the BE service flow. .

  In the existing NWG network protocol, the security requirements of the service flow are not explained in the R3 and R6 message interfaces, which is inconvenient for realizing the encrypted data transmission demand based on the connection. When the service flow (connection) security request is explained or arranged in the BS, the BS does not grasp the user information and the QoS attribute of the connection as a distributed access point. A security request for a specific service flow of a specific user cannot be placed based on the QoS attribute.

  The present invention has been made in view of the problem that a base station cannot place a service security request on the basis of user information and QoS attributes in the related art, and a service flow encryption process that can solve such a problem. It aims to provide a method.

To achieve the above object, according to an aspect of the present invention, a service flow encryption processing method is provided.
In the service flow encryption processing method according to the present invention, the AAA server transmits to the AAA client instruction information indicating whether or not the service flow needs to be encrypted, and the AAA client instructs the anchor SFA. The information is transmitted, and the anchor SFA transmits the instruction information to the base station, and the base station performs encryption processing or non-encryption processing on the service flow based on the instruction information.

  The step in which the AAA server transmits the instruction information to the AAA client includes a step in which the AAA server includes the instruction information in an access permission message, and a step in which the AAA server transmits an access permission message to the AAA client. It is preferable.

  The step in which the AAA server includes the instruction information in the access permission message includes performing encryption processing on the service flow in the sub-type TLV of the “type / length / number” format of the quality of service descriptor (QoS-Descriptor) of the access permission message. Preferably it includes the step of adding a TLV indicating whether it needs to be done or not.

  The AAA client transmits the instruction information to the anchor SFA. The AAA client includes the instruction information in the service flow parameter of the resource reservation request (RR-Req) message, and the AAA client transmits the RR-Req message to the anchor SFA. Preferably including the step of transmitting.

  The step in which the anchor SFA transmits the instruction information to the base station preferably includes the step of including the instruction information in the service flow parameter of the data route registration request (Path_Reg_Req) message transmitted from the anchor SFA to the base station.

  The base station encrypts the service flow based on the instruction information. The base station determines one security alliance (SA), and the base station associates the SA mark ID (SA-ID) with the service flow. The SA-ID of the SA associated with the service flow is transmitted to the mobile station, and the base station and / or the mobile station performs an encryption process and / or a decryption process on the data stream of the service flow using the SA corresponding to the ID. Preferably, the step of performing is included.

In order to achieve the above object, according to another aspect of the present invention, a service flow encryption processing system is provided.
The service flow encryption processing system according to the present invention includes an AAA server that transmits instruction information indicating whether or not it is necessary to perform encryption processing on a service flow to an AAA client, and an AAA client that transmits instruction information to an anchor SFA. And an anchor SFA that transmits instruction information to the base station, and a base station that performs encryption processing or non-encryption processing on the service flow based on the instruction information.

  Preferably, the AAA server has a first setting block for setting instruction information in the access permission message and a first transmission block for transmitting the access permission message to the AAA client.

  Preferably, the first setting block adds a TLV indicating whether or not the service flow needs to be encrypted to the sub-TLV of the service quality descriptor of the access permission message.

  Preferably, the AAA client has a second setting block that includes the instruction information in the service flow parameter of the RR-Req message, and a second transmission block that transmits the RR-Req message to the anchor SFA.

According to the present invention, in the related art, the problem that the base station cannot arrange the service flow security request based on the user information and the QoS attribute is solved, and the arrangement of the service flow security request based on the user information and the QoS attribute is realized. it can.
Other features and advantages of the invention will become more apparent from the description in the specification, or may be learned by practice of the invention. The objectives and other advantages of the invention may be realized by the structure particularly pointed out in the written description, claims and drawings.

The drawings described herein are for understanding the present invention, constitute part of the present invention, and are for interpreting the present invention together with embodiments in the present invention. It is not limited. In the drawing
These are the flowcharts which show the encryption processing method of the service flow based on the Example of this invention. These are the flowcharts which show the construction | assembly of the encrypted service flow based on the Example of this invention. These are block diagrams which show the structure of the encryption processing system of the service flow which concerns on the Example of this invention.

  Here, as long as there is no contradiction, the embodiments described in the present application and the features described in the embodiments can be combined with each other. Hereinafter, the present invention will be described in detail with reference to the drawings and embodiments.

  In the following embodiments, the steps shown in the flowcharts in the drawings can be performed in a set of computer systems capable of executing commands by, for example, a computer, and the flowcharts show some logic order, but in some cases other The steps shown or described in the drawing in sequence can be performed.

  In this embodiment, a service flow encryption method is provided, and FIG. 1 is a flowchart showing a service flow encryption method according to an embodiment of the present invention. As shown in FIG. Step S108 is included.

  The AAA server transmits instruction information indicating whether or not it is necessary to perform encryption processing on the service flow to the AAA client (step S102).

  Since the AAA server itself is a centralized point for recording the user's QoS information, it can be set here whether the service needs to be encrypted based on the information recorded in the AAA server. The AAA client can set a block that interacts with the AAA server inside a service flow authorization anchor (Anchor Service Flow Authorization, hereinafter abbreviated as an anchor SFA), but can also be set in another network element. .

  The AAA client transmits the instruction information to the anchor SFA (or anchor data route functional entity, also referred to as “anchor DPF” for short) (step S104).

  The anchor SFA transmits the instruction information to the base station (step S106).

  Based on the instruction information, the base station performs encryption processing or non-encryption processing on the service flow (step S108).

  By arranging the service flow security request in the AAA server and transmitting it to the base station through the above steps, the base station arranges the service flow security request based on the user information and the QoS attribute in the related art. Solved the problem of not being able to.

  In the following, the above steps will be described by combining the service flow construction flow, taking as an example the case where the service flow needs to be encrypted. However, the following embodiments are only preferred embodiments.

  FIG. 2 is a flowchart showing the construction of an encrypted service flow according to an embodiment of the present invention, and includes the following steps as shown in FIG.

  After successful authentication of the initial extended authentication protocol (Extensible Authentication Protocol, hereinafter referred to as EAP), the AAA server sends an R3 access permission (Access Accept) message to the AAA client (step S201), and the message is sent to the service flow. It includes instruction information for instructing whether or not it is necessary to perform encryption processing. Among them, the AAA client is also called an authenticator.

  If the AAA server can send instruction information indicating whether or not it is necessary to perform encryption processing on the service flow to the AAA client via the access permission message, another message, for example, a newly defined message can be transmitted. It is preferable that the instruction information can be transmitted via the Internet. Here, the access permission message is an example of a message that can include instruction information, and is not limited to this. The access permission message includes instruction information that indicates whether the service flow needs to be encrypted. Any message that can do the same thing. It is even easier to use an access permission message.

  When the access permission message includes the instruction information, a new TLV security level (Security Level) (in the communication field, “data type, data length, data quality descriptor (QoS-Descriptor)) sub-TLV A data format formatted in the form of “data numerical value” is expressed in English as “Type, Length, Value” and abbreviated as TLV format), and its size is 1 bit. The meaning of the security level can be referred to Table 1. 0 indicates that there is no security request for data transmitted by the user in the service flow, and 1 indicates security for data transmitted by the user in the service flow. Indicates that there is a request. Note that it is possible to instruct whether or not it is necessary to perform encryption processing on the service flow with another bit in the message. Hereinafter, the TLV security level will be described as an example.

  In order to further describe the present embodiment, first, a security alliance (hereinafter abbreviated as SA) traffic encryption key (Traffic Encryption Key, hereinafter abbreviated as TEK) will be described.

  In the SA-TEK three-way handshake stage, a mobile station (hereinafter abbreviated as MS) and a BS negotiate to generate a security alliance SA having an encryption attribute, among which a data encryption type (data cryptot). Type) describes the encryption / decryption mechanism. The MS completes the TEK exchange of the SA via a key request (Key-Request) and key response (Key-Reply) message, and after successful completion, the MS and BS have the same TEK key. TEK is a key for encrypting / decrypting service flow data.

  In the service flow construction stage, the authenticator (AAA client) transmits an RR_Req (resource reservation request) message to the anchor SFA (hereinafter also simply referred to as SFA) (step S202), and each service flow parameter of RR_Req is newly added. TLV security level. Here, in this step, the authenticator uses the RR_Req message to indicate instruction information indicating whether or not each service flow needs to be encrypted (the TLV security level is only an example of the instruction information). The instruction information can be included in another message.

  The SFA transmits a data route registration request (Path_Reg_Req) message to the BS (step S203), and a new TLV security level is added to each service flow parameter in Path_Reg_Req. In this step, the SFA can include the instruction information in the Path_Reg_Req message, but the instruction information can also be included in other messages. In this embodiment, the Path_Reg_Req message is merely an example of the interpretation.

  As for the security level value in each service flow, when the security level is 0, it indicates that it is not necessary to perform encryption processing on the data transmitted in the service flow. It is not necessary to associate the alliance SA, and the SA mark ID (SA-ID) in DSA_Req transmitted from the BS to the MS is 0xFFFF (indicating that the SA is not associated with the encrypted SA). On the other hand, when the security level is 1, it indicates that there is a security request for the data to be transmitted in the service flow, so it must be encrypted and transmitted (step S204). Based on the countermeasure, the BS selects an SA whose data encryption type (Date Crypt Type) is not 0 from the SAs generated by discussion from the three-way handshake stage, associates the SA-ID with the service flow, and DSA_Req Inform the MS via a message.

  The other steps for constructing a service flow with a security attribute coincide with the construction process of an existing service flow, and a description thereof will be omitted. After that, when the BS receives a data stream of a service flow with a security request (that is, encryption processing is required), it examines the SA (including the corresponding TEK) associated with the service flow, and then the SA. Using the encryption algorithm specified by the data encryption type (data crypto type) in the data, adopting TEK encrypted media data, incorporating the MAC PDU, setting the EC bit in the PDU head to 1, and the MAC PDU Indicates that the data is encrypted, and sends it to the MS via air. After receiving the MAC PDU, the MS recognizes that the EC bit is 1, and determines that the packet is an encrypted packet. Based on the connection information in the PDU head, the corresponding SA is examined and the TEK decryption media data is used according to the decryption algorithm specified by the data encryption type in the SA. For the same reason, when the MS receives a data stream of a service flow with a security request, similar processing can be performed, and thus the description thereof is omitted.

  From step S201 to step S204, it is determined in the network element AAA server whether or not it is necessary to transmit the data to be transmitted by the encryption method according to the security level arranged in each service flow parameter. In the AAA server, the manager can place a specific QoS attribute for the user, and similarly, can place a specific security attribute based on the connection of the user.

  Corresponding to the above embodiment, a service flow encryption processing system is provided, and the description of the contents described above is omitted. The system includes an AAA server, an AAA client, an anchor SFA, and a base station. In the system, the AAA server instructs the AAA client whether or not it is necessary to perform encryption processing on the service flow. Send instruction information. The AAA client transmits instruction information to the anchor SFA. The anchor SFA transmits instruction information to the base station. The base station performs encryption processing or non-encryption processing on the service flow based on the instruction information.

  FIG. 3 is a block diagram showing the structure of the service flow encryption processing system according to the embodiment of the present invention. As shown in FIG. 3, the AAA server sets the instruction information in the access permission message. Block 32 and a first transmission block 34 for transmitting an access grant message to the AAA client.

  The first setting block 32 preferably adds a TLV that indicates whether or not the service flow needs to be encrypted to the sub-TLV of the QoS-Descriptor of the access permission message.

  As shown in FIG. 3, the AAA client has a second configuration block 36 in which the service flow parameter of the resource reservation request RR-Req message includes instruction information, and a second transmission block that transmits the RR-Req message to the anchor SFA. 38. In this system, the processing flow among the AAA server, the AAA client, the anchor SFA, and the base station has been described in detail in the above embodiment, and is omitted here.

  In the present embodiment, the security level parameter can be included in the QoS profile (Profile) parameter in the access permission message transmitted by the AAA server. Thus, during construction of a service flow, each user service flow has a single security level value. Based on the security level value, the base station determines whether the data in the corresponding service transmission connection needs to be transmitted in an encrypted manner. Normally, since the QoS profile e can be arranged on the AAA server based on the user and connection, whether or not the service flow needs to be encrypted and transmitted can be arranged based on the user and connection.

  As described above, according to the above embodiment, the problem that the base station cannot place the service flow security request based on the user information and the QoS attribute in the related art is solved, and the service flow based on the user information and the QoS attribute is solved. Security request arrangement can be realized.

  For those skilled in the art, each block or step of the present invention described above can be implemented by a common computing device, concentrated on a single computing device, or distributed over a network composed of multiple computing devices, and Since they can be realized by code of a program executable by a computing device, they can be stored in a storage device and executed by the computing device, or each can be fabricated in an integrated circuit block, or a plurality of blocks or steps in them can be a single integrated circuit It will be clear that this can be achieved by building blocks. Thus, the present invention is not limited to any particular hardware and software combination.

The above are only preferred embodiments of the present invention, and do not limit the present invention. Those skilled in the art can make various modifications and variations to the present invention, and any modifications, substitutions, improvements and the like within the spirit and scope of the present invention are included in the protection scope of the present invention.

Claims (9)

Authentication, Authorization, Accounting (Authentication Authorization Accounting, hereinafter, AAA abbreviated) server, sends instruction information for instructing the AAA client, whether it is necessary to perform the encryption process to the service flow,
The AAA client sends the instruction information to a service flow authorization anchor (Anchor Service Flow Authorization, hereinafter abbreviated as an anchor SFA).
The anchor SFA sends the indication information to a base station;
Said base station, you see contains a step of performing whether to perform encryption processing, or non-encryption process to the service flow based on the instruction information,
The base station performing an encryption process on the service flow based on the instruction information,
The base station establishes one security alliance (SA),
The base station associates the SA mark ID (SA-ID) with the service flow, and transmits the SA SA-ID associated with the service flow to the mobile station;
The service flow encryption comprising: a step in which the base station and / or the mobile station performs an encryption process and / or a decryption process on the data stream of the service flow using the SA corresponding to the SA-ID Processing method. The AAA server transmits the instruction information to the AAA client,
The AAA server including the instruction information in an access permission message;
The method of claim 1, comprising: the AAA server sending the access grant message to the AAA client. The AAA server includes the instruction information in the access permission message,
Added TLV indicating whether or not encryption processing needs to be performed on the service flow in the subtype TLV of “type / length / numeric” format of the quality of service descriptor (QoS-Descriptor) of the access permission message The method of claim 2 including the step of: The AAA client sends the instruction information to the anchor SFA,
The AAA client including the instruction information in a service flow parameter of a resource reservation request (RR-Req) message;
The method according to claim 1 or 3, comprising the step of the AAA client sending the RR-Req message to the anchor SFA. The anchor SFA transmitting the indication information to the base station comprises:
4. The method according to claim 1, further comprising the step of including the indication information in a service flow parameter of a data route registration request (Path_Reg_Req) message transmitted from the anchor SFA to the base station. An AAA server that transmits instruction information indicating whether or not it is necessary to perform encryption processing on the service flow to the AAA client;
The AAA client transmitting the instruction information to an anchor SFA;
The anchor SFA for transmitting the indication information to a base station;
Have a, and the base station whether to perform encryption processing, or perform non-encryption process to the service flow based on the instruction information,
When the base station performs encryption processing on the service flow based on the instruction information,
The base station establishes one security alliance (SA),
The base station associates the SA mark ID (SA-ID) with the service flow, and transmits the SA SA-ID associated with the service flow to the mobile station;
The service flow encryption processing system, wherein the base station and / or the mobile station performs encryption processing and / or decryption processing on the data stream of the service flow using the SA corresponding to the SA-ID . The AAA server is
A first setting block for setting the instruction information in an access permission message;
The system according to claim 6 , further comprising: a first transmission block that transmits the access permission message to the AAA client. The first setting block is:
The system according to claim 7 , wherein a TLV that indicates whether or not an encryption process needs to be performed on the service flow is added to a sub-TLV of a service quality descriptor of the access permission message. The AAA client
A second setting block for including the instruction information in a service flow parameter of the resource reservation request message;
The system of claim 6 or 8, wherein a, a second transmission block configured to transmit the resource reservation request message to the anchor SFA.

Images