专利名称：业务流加密处理方法及系统的制作方法
技术领域：
本发明涉及通信领域，具体而言，涉及一种业务流加密处理方法及系统。
背景技术：
微波接入全球互通(Worldwide Interoperability for Microwave Access,简称 为WiMAX)作为新一代的宽带无线接入技术，提供了完善的安全机制来保证运营商和用户 的利益。例如，802. 16e协议提供空口数据加密传输机制，保证在开放的无线环境下数据传 输的机密性，可以有效防止敏感信息被非法窃取。WiMAX系统中数据在空口的传输是基于连接的，每个连接都具有特定的服务质量 (Quality ofkrvice，简称为QoQ属性。每条激活的业务流和业务传输连接一一对应。业 务流的Qos属性在接入时由认证授权计费(Authentication Authorization Accounting, 简称为AAA)服务器(Server)分配下来并发送给基站(Base Mation，简称为BS)，BS在建 立业务流时使用。如果某个用户的某条业务流具有高的安全需求，需要加密传输数据，例 如，预配置两条尽力而为(Best Effort，简称为BE)业务流的用户A和预配置两条主动授 予服务(Unsolicited Grant krvice，简称为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发送指示信息包括:kkk krver在接入接 受Access Acc印t消息中携带指示信息；AAA Server将Access Acc印t消息发送给AAA Client。优选地，AAA krver在Access Acc印t消息中携带指示信息包括在AccessAccept消息的服务质量描述符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、AAAClient、Anchor SFA, 基站；AAA Server向AAA Client发送用于指示业务流是否需要加密的指示信息；AAA Client向Anchor SFA发送指示信息；Anchor SFA将指示信息发送给基站；基站根据指示信 息对业务流进行加密或不加密处理。优选地，AAA Server包括第一设置模块，用于在Access Acc印t消息中设置指示 信息；第一发送模块，用于将Access Acc印t消息发送给AAA Client。优选地，第一设置模块用于在Access Accept消息的QoS-Descriptor的子TLV中 增加TLV，增加的TLV用于指示业务流是否需要加密。优选地，AAA Client包括第二设置模块，用于在RR-Req消息的业务流参数中携 带指示信息；第二发送模块，用于将RR-Req消息发送给Anchor SFA。通过本发明，采用在AAA Server上对业务流安全需求进行配置，并发送给基站，解 决了相关技术中基站不能根据用户的信息和QoS属性来配置业务流安全需求的问题，进而 实现了根据用户信息和QoS属性配置业务流的安全需求。本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变 得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明 书、权利要求书、以及附图中所特别指出的结构来实现和获得。
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发 明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中图1是根据本发明实施例的业务流加密处理方法的流程图；图2是根据本发明实施例的建立加密的业务流的流程图；图3是根据本发明实施例的业务流加密处理系统的结构框图。
具体实施例方式需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相 互组合。下面将参考附图并结合实施例来详细说明本发明。在以下实施例中，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以 不同于此处的顺序执行所示出或描述的步骤。根据本发明的实施例，提供了一种业务流加密方法，图1是根据本发明实施例的 业务流加密方法的流程图，如图1所示，该方法包括如下的步骤S102至步骤S108 步骤S102，AAA krver向AAA Client发送用于指示业务流是否需要加密的 指示信息。由于AAA krver本身就是一个记录用户Qos信息的集中点，在此处可以根 据AAA krver上记录的信息来设置业务是否需要加密。需要说明的，AAA Client作 为与AAA krver进行交互的模块，可以设置在业务流授权锚点(Anchor Service Flow Authorization，简称为Anchor SFA)的内部，也可以设置于其他网元之中。步骤S104，AAA Client向Anchor SFA(或称为描点数据通道功能实体Anchor DPF)发送指示信息。步骤S106，Anchor SFA将指示信息发送给基站。步骤S108，基站根据指示信息对业务流进行加密或不加密处理。下面以业务流需要加密为例，结合业务流的建立流程对上述步骤做详细的说明。图2是根据本发明实施例的建立加密的业务流的流程图，如图2所示，该流程包括 如下步骤步骤S201，在初始可扩展鉴权协议(ExtensibleAuthentication Protocol，简称 为ΕΑΡ)鉴权成功后，AAA krver向AAA客户端(Client)发送R3接入接受(Access Accept) 消息，该消息中携带有指示业务流是否需要加密的指示信息，其中，AAA Client也可以称为 lAilE# (Authenticator) 。iftit;lft，AAA Server njL^MjlAccess AcceptAAA Client 发送用于指示业务流是否需要加密的指示信息，可以通过其他消息发送该指示信息，例如， 通过一个新定义的消息，在此Access Accept消息只是对能够携带指示信息的消息的一个 举例说明，但并不限于此，只要是能够携带用于指示业务流是否需要加密的指示信息的消 息都可以起到相同的作用。当然，使用Access Acc印t消息实现较为容易。优选地，在使用Access Accept消息的携带上述指示信息的情况下，可以在Access Accept消息的服务质量描述符(QoS-Descriptor)的子TLV中增加新的TLV安全级别 (Security Level)(在通信流域中，按照“数据类型、数据长度、数据数值”的格式组织数据 的，用英文表示就是“Type类型，Length长度，Value值”，简称TLV格式)，大小为1个字节。 Security Level的意义见表1，O表明用户对在此业务流上传输的数据无安全性要求；1表 明用户对在此业务流上传输的数据有安全性要求。需要说明的，可以使用该消息中其他字 节的来指示业务流是否需要加密，下面以TLV Security Level为例进行说明。表 1
TLV名类型长度Μ/Ο意义Security Level待定1 byteO0:无安全要求； 1:有安全要求； 为了更好的对本实施例进行说明，在此首先对安全联盟(Security Alliance，简 称为SA)流量加密密钥(Traffic Encryption Key，简称为TEK)进行说明。
在SA TEK三步握手阶段，移动台(Mobile Station，简称为MS)和BS协商生成具 有加密属性的安全联盟SA，其中，在data crypt type描述了加解密算法。MS用密钥请求 (Key-Request)、密钥回复(Key-R印Iy)消息完成此SA的TEK交互，成功之后MS和BS之间 拥有相同的TEK密钥。TEK是用来加解密业务流数据的密钥。步骤S202，在业务流建立阶段，Authenticator发送RR_Req消息给SFA，RR_ Req中每条业务流参数携带新增的TLV Security Level.需要说明的，在该步骤中， 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(表明不和加密的SA关联)；如果 SecurityLevel为1，那么表明在此条业务流上传输的数据具有安全需求，需要加密传输。 BS根据策略，从三步握手阶段协商生成的SA中选择数据加密类型(Date Crypt Type)非O 的一个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头 中的连接信息查找到对应的SA，用SA中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 Acc印t消息中设置指示信息；第一发 送模块34，该模块用于将Access Acc印t消息发送给AAA Client。优选地，第一设置模块32用于在Access Acc印t消息的QoS-Descriptor的子TLV中增加TLV，增加的TLV用于指示业务流是否需要加密。如图3所示，AAA Client包括第二设置模块36，该模块用于在资源预留请求 RR-Req消息的业务流参数中携带指示信息；第二发送模块38，该模块用于将RR-Req消息发 送给Anchor SFA。在该系统中，AAA Server、AAA Client、Anchor SFA、基站之间的处理过 程已经在上书实施例中进行了详细的说明，在此不再赘述。综上所述，在本实施例中，可以通 过AAA Server发送的Access Acc印t消息中的 Qos Profile参数携带Security Level参数。从而在建立业务流的过程中，用户的每条业 务流都有一个Security Level值。基站可以根据Security Level值决定在对应业务传输 连接上数据是否需要以加密的方式传输。由于Qos Profile通常在AAA Server上基于用 户和连接可配置，所以业务流是否加密传输也可以方便实现基于用户和连接可配置。显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用 的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成 的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储 在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们 中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的 硬件和软件结合。以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技 术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修 改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种业务流加密处理方法，其特征在于，包括认证授权计费服务器AAA krver向认证授权计费客户端AAA Client发送用于指示业 务流是否需要加密的指示信息；所述AAA Client向业务流授权锚点Anchor SFA发送所述指示信息； Anchor SFA将所述指示信息发送给基站；所述基站根据所述指示信息对所述业务流进行加密或不加密处理。
2.根据权利要求1所述的方法，其特征在于，所述AAAkrver向所述AAA Client发送 所述指示信息包括所述AAA krver在接入接受Access Accept消息中携带所述指示信息； 所述AAA krver将所述Access Acc印t消息发送给所述AAA Client。
3.根据权利要求2所述的方法，其特征在于，所述AAAkrver在所述Access Accept 消息中携带所述指示信息包括在所述Access Accept消息的服务质量描述符QoS-Descriptor的子类型/长度/数 值格式TLV中增加TLV，所述增加的TLV用于指示所述业务流是否需要加密。
4.根据权利要求1或3所述的方法，其特征在于，所述AAAClient向所述Anchor SFA 发送所述指示信息包括所述AAA Client在资源预留请求RR-Req消息的业务流参数中携带所述指示信息； 所述AAA Client将所述RR-Req消息发送给所述Anchor SFA。
5.根据权利要求1或3所述的方法，其特征在于，AnchorSFA将所述指示信息发送给 所述基站包括所述Anchor SFA在发送给所述基站的数据通道登记请求I^th_Reg_Req消息的业务流 参数中携带所述指示信息。
6.根据权利要求1所述的方法，其特征在于，所述基站根据所述指示信息对所述业务 流进行加密处理包括所述基站确定一个安全联盟SA ；所述基站将所述SA的标识ID与所述业务流进行关联，并将与所述业务流关联的SA的 ID发送移动台；所述基站和/或移动台使用所述ID对应的SA对所述业务流的数据流进行加密和/或解密。
7.一种业务流加密处理系统，包括AAA Server, AAA Client、Anchor SFA、基站，其特 征在于，所述AAA krver向所述AAA Client发送用于指示业务流是否需要加密的指示信息； 所述AAA Client向所述Anchor SFA发送所述指示信息； 所述Anchor SFA将所述指示信息发送给所述基站； 所述基站根据所述指示信息对所述业务流进行加密或不加密处理。
8.根据权利要求7所述的系统，其特征在于，所述AAAkrver包括 第一设置模块，用于在Access Accept消息中设置所述指示信息； 第一发送模块，用于将所述Access Acc印t消息发送给所述AAA Client。
9.根据权利要求8所述的系统，其特征在于，所述第一设置模块用于在所述AccessAccept消息的QoS-Descriptor的子TLV中增加TLV，所述增加的TLV用于指示所述业务流 是否需要加密。
10.根据权利要求7或9所述的系统，其特征在于，所述AAA Client包括 第二设置模块，用于在RR-Req消息的业务流参数中携带所述指示信息； 第二发送模块，用于将所述RR-Req消息发送给所述Anchor SFA。
全文摘要
本发明公开了一种业务流加密处理方法及系统，该方法包括认证授权计费服务器AAA Server向认证授权计费客户端AAA Client发送用于指示业务流是否需要加密的指示信息；AAA Client向业务流授权锚点Anchor SFA发送指示信息；Anchor SFA将指示信息发送给基站；基站根据指示信息对业务流进行加密或不加密处理。通过本发明实现了根据用户信息和QoS属性配置业务流的安全需求。
文档编号H04W12/02GK102083062SQ20091024624
公开日2011年6月1日 申请日期2009年12月1日 优先权日2009年12月1日
发明者颜文波 申请人:中兴通讯股份有限公司