【IT168 技术文章】

    下一代网络(NGN)是基于分组网络的、多业务融合并开放网络能力的电信网络。其基于分组交换的核心网络为业务融合提供了传输基础设施;其网络能力的开放提高了业务的扩展性，为第三方业务提供者进入电信业务市场提供了良好的契机。但NGN中相对于传统电信网而言松耦合的、开放的业务结构特性和丰富的业务功能恰好与NGN基于通用计算平台和IP传输网络的基础设施在安全架构上形成了矛盾。采用基于IP的分组网络作为业务的承载网络使得许多针对IP网络的攻击行为在电信网络中成为可能，采用通用计算设备作为网络中的控制实体将计算机的安全问题引入到网络中的各个节点[1]。网络能力和业务能力的开放也带来了一系列业务层特有的安全问题。

    目前，已经有众多的安全机制用于保证网络和计算设备的安全，但这些安全机制都是针对某一个或某几个特定安全问题和特定的环境设计的，如密钥分配、实体认证、机密性保护、完整性保护等，NGN业务针对不同的业务特征和业务执行环境有着不同的、综合的安全需求。如何理清业务的安全需求，并尽量通过已有的网络安全能力是业务开发者面临的一个问题。

    鉴于业务开发过程面临的复杂的安全需求，本文提出使用形式化建模语言UMLsec[3，4]对业务安全需求进行分析，利用建模语言将业务所需的安全特性抽象成安全感知的类，通过这些类表达细粒度的安全功能，通过这些类的组合表达业务的安全需求。这些类的功能通过安全应用接口实现，如GSS-API[5]、NGSS-API[6]，从而将安全特征集成到业务中。以便业务开发者在业务开发过程中摆脱安全机制实现细节的困扰，并且使得开发出来的业务安全特征具备可移植性。

    一、NGN业务安全需求分析

    1.UMLsec扩展

    UMLsec是基于UML标准扩展机制的一个UMLprofile，通过在UML元模型中增加安全相关的约束、标签、定型等建模元素，使用UML图来表达安全相关的语义和系统需求与约束。但目前的UMLsec是基于计算机网络的环境定义的，将其用于NGN业务安全分析中来还需要进行相应的扩展。主要的扩展在于在UMLsec的元素中增加具备与NGN环境相关的定义，使其能够更明确、更有针对性地表达NGN业务的特点与需求。本文中将业务的承载、执行节点定义为NGN中业务的基础架构，并在UML元模型中对这些元素进行定义，如图1所示。

    该扩展针对Link和Node和两个元类增加了NGN中关于承载和节点的定型。可以根据需要对该模型作进一步扩展，如可以增加关于接入网承载的定型等。

    2.基于UMLsec的威胁分析

    针对图1中定义的定型以及对网络安全构成威胁的攻击者的类型，可以定义出威胁函数TheatA(s)。其中A表示攻击者类型，这里假定攻击者为具备一般能力的外部攻击者，即其可以窃听到广播信道上的数据流量，并可以插入或删除数据流量，能够利用系统漏洞入侵系统;表示为模型中定义的定型威胁函数的值域为{delete，read，insert，access}。根据NGN中承载网络和计算节点的特性，我们可以得出如下威胁函数，如表1所示。

    攻击者对于IP承载的数据能够执行读写和删除操作，故其能够针对IP承载的业务进行攻击。如攻击者可以修改正常的SIP消息以改变呼叫的路由，发出BYE等SIP消息拆除正常的SIP会话，通过截获RTP承载的语音包并解码以实现窃听，可以在IP网络中插入大量数据降低VoIP的QoS实现DoS攻击，等等。

    软设备通常基于通用的操作系统、数据库等软件。这些通用软件以及协议栈的实现都可能具备能被攻击者利用的漏洞。通过这些安全漏洞，攻击者可以对这些设备发起拒绝服务攻击(DoS)或获得设备的访问权。

    由于NGN的基础设施针对一般攻击者的攻击函数值通常都不为空，因此需要在业务开发和部署时利用安全机制来保证业务的安全。

    3.业务的安全需求分析

    业务的安全需求可能包括用户信息的机密性、完整性、业务本身的可用性等方面。NGN中不同类型的业务有着不同的安全需求，如会话类业务的主要安全需求是可用性，消息类业务的主要安全需求是完整性。同一类型的业务其安全需求应该也是可以根据业务场景定制的，如普通两方呼叫要求即使在网络中出现入侵的情况下也应保证呼叫的正确路由，并确保语音流的服务质量。而如果用户要求呼叫需被保密，则还需保证信令消息的机密性和语音流的机密性，需要对信令和语音流进行加密处理。不同业务的安全需求是安全特性的组合。利用建模语言，业务所需要的安全特性可以抽象成为安全感知的类来表示。这些类中的功能可以使用安全应用接口提供的安全能力实现，而业务的安全需求则表示为类的组合。为了清晰表达业务的安全需求，并便于业务安全需求的实现，本文将业务的安全需求抽象为细粒度的安全功能类，每个安全功能类表达了业务对其各个组件(如信令、媒体、业务功能等)的不同安全特性(如机密性、完整性、认证等)的需求。

    下面以基于SIP的两方会话为例说明如何使用UMLsec描述业务安全需求。假定两方呼叫发生在同一SIPProxy辖域的两个用户之间，要求保证用户UA与SIPProxy之间的信令的完整性，不能被非法入侵者篡改。该场景的用例图和部署图分别如图2、图3所示。

    图3中的UA代表UserA或UserB的UA，因为两个UA的信令交互需要通过Proxy，且其安全需求是一致的，故在图中只表现出一方。UA和Proxy均是基于通用计算平台的节点，其访问控制需要受到保护，故对其标记上定型《guardedaccess》。UA中除处理信令外，还需处理媒体流的编解码与控制，这个用例中只涉及信令的安全性，故在UA中只关注进行信令控制的组件。UA与Proxy之间的通信基于IP承载，根据表1定义的威胁函数：ThreatA(IP Carrier)={delete，read，insert}，信令的完整性在攻击下可能遭到破坏，需要采用相应的安全机制对信令交互加以保护。

    Sender类和Receiver类是通过对通信安全功能的抽象而得出的两个类。这两个类具备保证发送方和接收方之间消息传送的完整性的安全能力。通过在UA的信令控制功能和Proxy的呼叫控制功能中聚合这两个类，可以在高层的需求层面上满足UA和Proxy通信的信令完整性需求。

    AccessGuard类是用于隔离对保护对象的访问的类，通过在被保护对象上标识{guard=AccessGuard}标记，所有的对保护对象的访问请求需先提交给AccessGuard类，AccessGuard类根据具体的访问控制机制和访问控制策略进行访问权限的判定后，访问请求才能在被保护对象上执行。

    Sender类和Receiver类可以针对业务对安全需求的不同控制粒度进一步细化，通过对send()方法的重载加以实现。如在调用send()方法时可以使用QoP[5，7](QualityofProtection)参数说明业务对安全功能的保护级别的需求。QoP体现了处理安全问题的开销与安全保护需求之间的动态平衡。某一级别的QoP可以对应于某一具体安全机制中所采用的加密算法强度、密钥长度、认证机制强度等。但目前QoP的定义还依赖于具体的安全机制，且具有一定的随意性，没有一个客观的标准。

    在更细的粒度上，用户可以在send()方法中指定具体安全机制的相关参数，对所使用的安全机制进行更精确的控制。

    图5是对通信机密性进行保护的安全能力抽象类的类图。其send()方法应能保证消息的加密传输。Receiver类的receive()方法用于接收并解密消息。同完整性保护一样，更加细致和更加可控的机密性保护可通过对send()和receive()方法的重载实现。

    除了图4和图5中列举的用于保护通信完整性和机密性以及实体访问控制的安全能力抽象类外，还可以根据业务的实际安全需求抽象更多的安全能力抽象类。每个类实现某一特定的安全功能，如可以在多媒体会议中定义群密钥管理功能抽象类，用于满足群密钥生成、分发与认证的功能。

    二、业务安全的实现机制

    基于上述分析，可以将NGN业务的安全需求从安全特性上加以划分并进行抽象，形成一系列细粒度的安全功能抽象类。通过对每一个安全功能抽象类的实现可以满足业务的安全需求。文献[8]提出了一种基于模型驱动的细粒度的访问控制框架AC-PIM，将一个统一的高层的访问控制模型(AC-PIM)映射到多种具体的访问控制机制中，如OASIS的SAML(SecurityAssertionMarkupLanguage)和XACML(eXtensible Access Control Markup Language)，OMG的RAD(Resource Access Decision Facility)以及Java Authentication and Authorization中定义的Java访问控制模型。AC-PIM提供了一个实现图4中的AccessGuard抽象类的途径。

    下面说明如何利用GSS-API实现保证通信完整性的安全能力抽象类，通过状态图说明保证通信完整性的Sender类的send()方法及Receiver类的receive()方法的GSS-API实现。本文中给出的是一个示意性的说明，忽略了一些错误处理过程。

    图6中，在send()方法被调用后，Sender首先检测是否已有可用的安全上下文，如果可用的安全上下文已经存在，则可以利用该上下文的句柄作为参数之一，调用GSS-API的Get_GetMIC()方法。参数还包括有待进行签名的消息和可选的QoP。如果对消息签名可以正常完成，Sender就可以将消息与签名后生成的token一起送到目的地。如果签名发生异常，则可以通过返回的错误码判断原因。

 

    如果在调用GSS_GetMIC()方法之前不存在可用的安全上下文，则Sender需要首先与Receiver之间建立安全上下文，通过安全机制信息的交互建立好安全上下文后可以继续调用GSS_GetMIC()方法对需要发送的消息签名。

    通信完整性抽象类Receiver用于对消息完整性进行检测，过程如图7所示。经过GSS_VerifyMIC()方法检测接收到的消息及其签名是否一致以判定其完整性。如果没有合适的上下文可用，则应先建立安全上下文然后再调用GSS_VerifyMIC()。

 

    如果需要实现的机密性保护，则Sender类和Receiver类的约束用{secrecy}表示。可通过GSS-API的GSS_Warp()方法和GSS_Unwrap()方法实现Sender和Receiver的安全功能。

    Sender和Receiver还可以通过NGSS-API来实现。NGSS-API是ParlayAPI架构下的安全应用接口，对网络的安全能力进行抽象，并为业务提供安全能力。NGSS-API中提供了IpCredentialManager、IpContextManager、IpContext等类分别用于管理证书、管理安全上下文以及基于安全上下文的完整性、机密性等网络中的安全机制提供的安全能力。使用NGSS-API实现通信的完整性、机密性保护的过程与GSS-API类似。

    GSS-API和NGSS-API都可用于实现根据业务安全需求抽象出的安全功能抽象类。GSS-API通常由本地的程序语言类库实现，适合于运行在终端和网络实体上的业务实例使用，保证本地与目的地交互的安全性。NGSS-API基于ParlayAPI，主要面向应用服务器等第三方业务实体，适合于运行在应用服务器上、与Parlay网关进行交互的业务实例使用，其安全需求通过Parlay网关协调网络中的实体实现，保证整体的安全性。GSS-API考虑的安全粒度是消息级的，而NGSS-API考虑的安全粒度相对要大一些，从应用服务器业务逻辑的视点出发，保证一个呼叫方或一个用户接口的安全性。

    GSS-API和NGSS-API都独立于具体的安全机制，可以采用不同的安全机制和安全协议实现。

    三、结语

    本文根据NGN的网络特点对UMLsec进行了扩展，利用扩展后的UMLsec对NGN的网络环境和业务的安全需求进行了分析。将NGN业务的安全需求抽象成细粒度的安全能力抽象类，用UMLsec加以描述，通过这些类的组合完整表达NGN业务所需的安全特性。通过对安全能力抽象类的实现可以满足NGN业务的安全需求。本文通过用例说明了如何利用安全应用接口实现安全能力抽象类。基于安全应用接口的实现与具体安全机制的细节无关，且具有可移植性，使得业务的安全特性在不同的环境下可通过不同的安全机制实现。下一步的研究工作将包括对业务可用性等安全特征进行建模，并完善需求模型与实现模型之间的转换规则，以实现模型之间的自动转换与验证。