SIP协议的轻量级双向认证技术研究
SIP协议的轻量级双向认证技术研究
摘 要： 提出一种会话过程中的轻量级双向认证机制，它基于HTTP摘要认证机制，可以实现逐跳认证，完成端到端的认证，抵抗身份欺骗和拒绝服务等类型的攻击，从而在系统开销小的情况下提供了较好的安全保护。?
关键词： SIP; 身份欺骗; HTTP摘要认证; 密钥协商; 安全机制
?
会话发起协议SIP（Session Initiation Protocol）[1]是位于应用层的信令协议，它可以发起、管理和结束分组网络中的语音或视频会话。SIP具有简单、开放和可扩展等特点，被广泛用于IP多媒体服务、蜂窝系统与Internet融合等应用领域，已成为下一代电信网络的主要信令协议之一。?
SIP基于文本的特性会带来许多安全隐患，而且其并没有自己独有的安全机制，只是推荐采用了现有的标准安全协议。推荐的传输层安全协议/数据报传输层安全协议（TLS/DTLS）[2-3]和HTTP摘要认证[4]只提供单向认证，无法很好地抵御外界攻击。?
针对这种情况，本文提出了一种SIP轻量级双向认证机制，这种机制基于共享密钥和改进的HTTP摘要认证，提供了信息完整性校验。该安全机制有效地利用了SIP已有的结构，只采用一次握手，并避免使用公钥系统，降低了系统开销，是种轻量级的机制。它可以抵抗身份欺骗、拒绝服务攻击等多种威胁[5-6]。?
1 安全现状及分析?
目前，认证是保证SIP通信安全性的常用手段之一。常用的单向认证却会导致较为严重的安全隐患，易受到中间人攻击MITM（Man-In-The-Middle）类型的安全威胁。攻击者通过将SIP注册消息中的“过期值”改为零伪造出“取消注册”的消息[8]，便可以立刻清除之前的注册信息，使被攻击用户A被服务器B移除并接收不到来自服务器B的所有后续消息，因为没有收到任何通知，用户A认为他与服务器B仍然是连接着的。攻击者随后向服务器B伪造REGISTER注册消息。把服务器B发往用户A的消息都转向了攻击者，同时攻击者冒充服务器B和用户A通信。所以，攻击者会在服务器和用户都不知情的情况下进行会话劫持。此外，MITM还能引发多种攻击：对用户A和服务器B进行窃听能够较容易地获得机密信息，例如私人数据和口令等；用户A可能会被攻击者利用，对服务器B或其他目标进行拒绝服务攻击。?
当前用于身份验证的方法包括HTTP摘要和TLS/DTLS。HTTP摘要是一种简单的认证机制，它采用杂凑式（hash）加密方法传送通信双方共享的口令，以避免其用明文传输；TLS/DTLS基于公钥技术，为两个通信实体之间提供数据的保密性和完整性。这两种认证方式都采用单项认证：使用HTTP摘要的客户端不能认证
服务器并且对消息完整性的保护也不够充分，比较容易遭受攻击；TLS/DTLS在实际应用中只是客户端认证服务器，但服务器不认证客户端。另外，TLS/DTLS对服务质量（QoS）也会有所影响。使用加密操作的安全协议都将引入处理延时，而SIP会话应该在可以接受的QoS级别内运用安全机制。TLS/DTLS采用了公钥技术，这项技术需要的计算开销远大于密钥技术和消息摘要技术，从而显著增加了SIP代理服务器的负担，这不仅影响了QoS，而且容易受到拒绝服务攻击[9]。除此之外，TLS/DTLS使用了逐跳的安全认证，使得两个用户间的通信路径上有一个环节缺少TLS/DTLS的保护时，整条路径都变得不安全。?
为克服上述缺陷，提出了一种轻量级双向认证机制，它通过加入共享密钥改善了HTTP摘要。?
2 轻量级双向认证机制?
2.1 认证机制实现?
这种认证方法的性能损失较小，其轻量级的特点体现在以下两点：?
（1）仅需要一个挑战—请求过程，握手次数较少。由于当今的处理器变得越来越强大，传输数据需要的时间已经逐渐成为认证开销的主要部分，所以减少消息交互时的握手次数可以减少开销，增强性能。?
（2）没有采用计算复杂的公钥算法。之所以不采用公钥算法是因为尽管它可以提供更高的安全性，但是计算开销较大，会对SIP会话的QoS有所影响。考虑到密钥算法和消息摘要算法在性能上的差别并不大（都是以字节为单位），使用了共享密钥并采用了AES加密算法，其快速和安全性可以平衡SIP通信中QoS和安全性的要求。?
如果缺少信息完整性保证，认证机制也可能受到攻击。这个轻量级认证机制用共享密钥提供了SIP消息部分头域的完整性保护，这些头域包括Contact、To和From等。选择性的加密而不是加密整个消息体可以避免分组过大而导致的分片，而分片在SIP实时通信中需要尽量避开[10]。?
这种轻量级双向认证机制的实现过程为：下游节点在对上游节点的挑战中加入被共享密钥加密的信息。当下游节点的身份通过解密被验证后，上游节点将返回一个请求，其中携带着针对下游节点挑战的认证，这个请求同样也被加密处理。当来自于上游节点的加密信息被下游节点解密验证后，身份信任会在两个节点间建立起来。?
2.1.1 WWW-Authenticate头域?
为实现轻量级的双向认证机制，对HTTP摘要里某些头域的参数值进行了修改。其中对WWW-Authenticate响应的修改如下：?
digest-challenge = 1#(realm/[domain]/req-auth-digest/[opaque]/[state]/[algorithm]/[qop-options]/[auth-param] )?
req-auth-digest='req-auth-digest''='req-auth-digest-value?
req-auth-digest-value = HEX
?
algorithm = 'algorithm' '=' ('AES'/token)?
如果终端是服务器，domain值必须被包括，而不像原标准那样只是可选项。如果缺少了domain值，当一个用户在多个服务器上配置了相同的密钥，则不同的服务器可能产生相同的挑战，从而使用户对于不同的服务器产生了相同的应答。监听者可能会伪装成用户将其发送的加密应答发往不同的服务器并获得认证。加入domain值可以识别服务器的身份，从而克服了上述问题。?
此双向认证机制加入了字符串req-auth-digest，处在其中的nonce和req-digest-string一起被共享密钥加密。在安全机制中，不同的nonce类型拥有不同的特点。大随机数被认为是最好的nonce类型，但需要较高的成本；时戳类型要求极好的时钟同步和精确度；序列号类型相对简单，但易于被预测。因此，当nonce值在明文中传送时，谨慎地选择nonce类型很有必要。本文提出的认证机制可以避免因选择nonce类型而出现的问题，它在挑战和请求中都对nonce进行了加密，这样即使是可被预测到的nonce值也能够使用，用户代理可以自行选择合适的nonce类型。字符串req-digest-string涉及到SIP消息头域的一个子集，其中包含了状态码、From、To、Contact、Cseq 和Call-ID。这个字符串采用16进制数编码，其定义如下：?
req-degist-string =
':' address-specification-in-To?
':' address-specification-in-Contact?
':' cseq-value?
':' called-value >?
在随后给出的计算方法中，使用共享密钥通过“secret”对数据内容“data” 加密。?
得到的字符串可表示成Ek(secret, data)，对数据内容“data”采用校验和算法产生的字符串由H(data)表示，unq(X)则表示引号内的字符串。如果是服务器，必须要求含有H(A1)值。字符串algorithm说明了加密所采用的算法，默认为“AES”。?
req-auth-digest-value = A1=unq (domain-value)?
2.1.2 Authorization头域?
Authorization头域修改如下：?
credentials= 'Digest' digest-response?
digest-response=1#( username/realm/digest-uri/resp-author-digest/[ algorithm ]/[cnonce]/[opaque]/[message-qop]/[nonce-count]/[auth-param])?
resp-author-digest='resp-author-digest''='requestdigest-value?
request-digest-value =
B1=unq (realm-value) [':' unq (domain-value)]?
B2=Method ':' digest-uri-value?
字符串resp-degist-string和WWW-Authenticate中的req-degist-string基本一致，只是少了状态码部分。K’表示一个新的密钥，这个密钥是按照协商好的算法由共享密钥计算得到的，如K-1等，其中K代表了初始共享密钥。?
2.2 双向认证过程?
?
图1显示了一个基于双向认证机制的SIP会话建立过程。假设用户A和用户B间的共享密钥在所示SIP会话发生之前已经配置完成（接下来将讨论共享密钥生成方法）。为了简化说明，设定SIP代理服务器、SIP注册服务器和位置服务器均在同一个主机上。?
?
?
用户A发起一个基于明文的INVITE请求，一旦接收到这个消息，用户B则认为需要对用户A进行身份验证，继而返回一个特殊的SIP错误消息作为挑战，要求用户A提供身份证明。错误消息401 Unauthorized即用户B发出的挑战，它包含了加密后的nonce和req-auth-digest，消息内容如下所示：?
SIP/2.0 401 Unauthorized?
WWW-Authenticate: Digest?
realm='test@https://www.360docs.net/doc/1e6324652.html,',?
req-auth-digest='B9248DC13E14A784604D8F70C8283?
CCA330D0FB19E548E01DEBBDBB31623A1F0FE7F1B?
9D5EC6536B722281FF4B4F7B6FBB9E37C8E1D7167FA?
65FE88242B0575927486CBABB7206A896FD3FD3E1C6?
BBCE'?
用户A收到错误消息后，用共享密钥对req-auth-digest进行解密，然后通过对nonce值和数据完整性的校验来验证用户B的身份。如果校验正确，用户A会通过已经协商好的算法使用初始共享密钥生成新的密钥，并对接收到的nonce值和自己所发消息的部分头域加密，重新产生序列。消息内容如下所示：?
INVITE sip:UserB@131.160.1.112 SIP/2.0?
Authorization: Digest username='UserA',?
realm='test@https://www.360docs.net/doc/1e6324652.html,',?
uri='/dir/index.html',?
resp-author-digest='DCB38CB9E982F7D2F767DE?
CF3683ECE0CF77A951D6F78C3FC77352B6629375?
E5B8AC4A0E8A6F7AFF1FE8F775C3F73D9F626B9?
BE6850EFD98D4792C01A1E60C05A66CE39FC7F6?
E1B027A79CE83FE8795C'?
若解密后的nonce值与保存的nonce值不匹配或者解密后的头域与消息里的头域不相符，用户B将不会做出回应并开始处理失败的认证；反之，用户B将返回200 OK。?
上述端到端的认证要求代理服务器在整个过程中始终处于透明状态，即它们必须原封不动地传递WWW-Authenticate和Authorization头域。如果代理服务器在向服务器或其他实体传递用户请求之前需要认证用户，可以用Proxy-Authenticate和Proxy-Authorization头域，它们与WWW-Authenticate 和 Authorization头域极其类似，被用于逐跳的安全保护。?
2.3 共享密钥协商?
这种双向认证机制需要会话双方进行共享密钥协商。完美前向保密性要求共享密钥应定期更新，所以共享密钥必须在首次使用或密钥更换时被安全地协商，建议使用Diffie-Hellman算法实现协商过程。为了抵抗MITM攻击，算法中p和q的数值可以通过带外信道传送或PKI发布，然后指数密钥即可在
不安全地信道里传送。为了传送指数密钥，提出了一个新的SIP头域——K-Exchange，它用于声明在INVITE请求和200 OK响应中包含了一个指数密钥。扩展后的消息交换。
?
?
通信双方拥有共享密钥之后，将会有足够的信息生成共享会话密钥，它能够保护随后媒体数据的完整性和机密性。例如，Ek(nonce)可以作为实时传输协议RTP（Real-time Transport Protocol）的共享会话密钥。?
本文提出了一种SIP轻量级双向认证机制，它采用通过Diffie-Hellman算法协商的共享密钥，在不增加握手次数的情况下实现了双向认证，减少了会话开销。此外，修改共享密钥得到的共享会话密钥能够用来保护随后的媒体数据。这种机制可以对诸如身份欺骗、拒绝服务等攻击提供较好的抵抗。?
目前对这种机制的性能优化程度还没有做定量的测试与分析，因此设计SIP通信系统模型并在其基础上进行不同认证机制的开销比较将成为今后的工作方向。