CN1881870A - 一种设备间安全通信的方法 - Google Patents
一种设备间安全通信的方法 Download PDFInfo
- Publication number
- CN1881870A CN1881870A CN 200510123696 CN200510123696A CN1881870A CN 1881870 A CN1881870 A CN 1881870A CN 200510123696 CN200510123696 CN 200510123696 CN 200510123696 A CN200510123696 A CN 200510123696A CN 1881870 A CN1881870 A CN 1881870A
- Authority
- CN
- China
- Prior art keywords
- message
- seq
- equipment
- authentication
- sequence number
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提供了一种设备间安全通信的方法,包括:首先,直接进行互通的两个设备间进行认证加密参数协商和交换过程,用来完成消息认证随机数等参数的协商、交换与同步,使双方将得到一致的消息认证加密参数,该参数可包括用于认证加密的随机数参数和最大序列号参数;之后,任何一方向对端发送消息时都须携带消息认证信息,该信息包含消息认证加密参数以及据此生成的认证信息;而对端接收到消息后都须首先对消息进行认证,认证通过后才对消息进行处理,若认证未通过则丢弃消息。使用本发明,可提高通信双方的安全性,并且不必针对每个消息都增加状态机,减小通信双方的负担。
Description
技术领域
本发明涉及NGN通信安全技术领域,特别是指一种设备间安全通信的方法。
背景技术
随着IP技术在电信领域内的大量使用,IP网络本身的安全性和可靠性已逐渐成为该技术在高安全性要求的电信网络中商用的一个急需解决的关键问题。
由于IP网络的开放性,任何人只要能够接入IP网络,便可截获和分析IP网络中传送的通讯数据,或者随时向网络中任何设备发送任何格式的消息报文。由于IP包本身并不具有任何安全特性,因此IP包的地址可以被轻易的进行伪造仿冒。下面参见附图对消息的仿冒问题及其危害进行详细描述:
如图1所示,A向B发送请求消息请求完成某项业务,正常情况下B收到A的请求消息后执行请求命令并向A返回执行结果(即响应消息)。但是,当攻击者接入IP网络后可以截获A向B的请求消息并假冒B的身份向A返回一个仿冒的响应消息,而A收到这个仿冒消息后会当作是从真实的B设备收到的响应消息并完成某个动作。
以IP电话为例,网络服务器A向B发起呼叫建立请求,正常情况下B应该将呼叫路由到真正的被叫用户并等待被叫用户摘机后向A返回应答消息,但攻击者有可能向A立即返回失败响应消息造成呼叫无法正常接通,或者攻击者向A返回成功应答消息造成呼叫“假成功”,导致接续异常。
如图2所示,攻击者也有可能会仿冒A向B发送大量的请求消息,B收到仿冒消息后会当作是从真实的A设备收到的响应消息并完成某个动作,从而会消耗大量的B设备资源并造成正常业务中断,严重的时候会影响到用户业务和数据的安全性。
为了避免IP包的仿冒,提高IP网络基础的电信业务的安全性,目前,已经有一些方案来解决这个问题,下面进行说明:
会话发起协议(SIP)引用了HTTP DIGEST协议来完成SIP用户接入时的认证和鉴权,下面参见图3示出的呼叫流程对HTTP DIGEST认证过程进行描述。其中,仅对和认证相关的信令消息进行说明,包括以下步骤:
在需要向软交换设备B发起呼叫时,软交换设备A向B发送INVITE请求消息请求建立呼叫。该INVITE消息中并没有携带任何认证信息。
当软交换设备B收到A发起的不包含认证信息的INVITE后,向A返回407响应消息来发起呼叫认证过程,该响应消息中的一个头域Proxy-Authenticate携带的参数中包含了B生成的一随机数nonce。
收到响应消息后,软交换设备A重新向B发起INVITE请求消息,该消息通过一头域携带了A根据nonce生成的响应参数response和所述的nonce。
软交换设备B收到所述INVITE消息后,按照HTTP DIGEST方法进行验证,包括读取Proxy-Authorization头域,判断该消息中的nonce是否与其发送给软交换设备A的nonce相同,然后使用认证方式定义的加密算法以及参数生成response,判断是否与A发送过来的response相同,当nonce与response均相同时,B认为该消息合法,进行后续操作。
从上可以看出,HTTP DIGEST认证技术保证了发送消息双方身份的确定性,但是,该技术方案通常只对INVITE等呼叫外请求消息进行认证,而对于呼叫内的请求消息(如CANCEL、BYE等)并不进行认证。因此仅能够解决仿冒INVITE等呼外请求消息的问题,还无法解决仿冒其他消息的问题以及消息重播的问题。
若对每个请求消息均采用HTTP DIGEST进行认证,则消息流程将变得非常复杂。这是因为,各个设备已经存在对呼叫的状态机,该状态机已经比较复杂了,如果要对所有请求消息使用HTTP DIGEST方式进行认证,如对CANCEL、ACK、UPDATE呼叫内消息的认证,则需要对每个消息都要增加一个状态机以激活认证和生成认证参数,很明显会使得实现变得极其的复杂,因此不可能采用现有方式实现对响应消息安全性的保证。
发明内容
有鉴于此,本发明的主要目的在于提供了一种设备间安全通信的方法,以提高通信双方的安全性,并且不必针对每个消息都增加状态机。
本发明提供的设备间安全通信的方法,包括以下步骤:
A、进行互通的第一设备和第二设备通过协商确定一致的消息认证加密参数;
B、第一设备发送消息时携带根据所述消息认证加密参数生成的认证信息;
C、第二设备接收到所述消息后使用所述消息认证加密参数生成认证信息对接收的所述第一设备发送的消息所携带的认证信息进行认证,在认证通过后接受所述消息。
其中,步骤A所述协商的步骤包括:第一设备/第二设备生成至少包含随机数nonce、最大序列号maxseq的消息认证加密参数,并发送给第二设备/第一设备。
其中,进一步包括:收到所述消息认证加密参数的第二设备/第一设备根据其配置调整所述最大序列号maxseq,并返回给发送消息认证加密参数的第一设备/第二设备。
其中,步骤B所述生成的认证信息包括:表示不同消息的序列号seq,随机数nonce,根据序列号seq和随机数nonce生成的加密密文response。
其中,步骤B所述生成的认证信息包括:表示不同呼叫外消息的序列号seq和表示呼叫内不同消息的子序列号seq-sub,随机数nonce,根据序列号seq、子序列号seq-sub和随机数nonce生成的加密密文response。
其中,所述进行互通的第一设备和第二设备在一定条件下重新协商确定一致的消息认证加密参数。
其中,所述一定条件包括:定期,或序列号seq使用超过所述最大序列号maxseq的一定百分比。
其中,所述协商的步骤进一步包括:使用HTTP DEGEST的方式保证所述协商过程的安全性。
其中,步骤C所述使用所述消息认证加密参数生成认证信息对接收的消息所携带的认证信息进行认证的步骤包括:
根据第一设备同样的算法生成加密密文response,判断该加密密文response是否与接收的消息所携带的认证信息中的加密密文response一致,若是则认证通过,否则认证失败。
其中,认证信息包括表示不同消息的序列号seq、随机数nonce时,所述认证步骤进一步包括:
第二设备判断接收的消息所携带的认证信息中的随机数nonce值与其存储的随机数nonce相同时,进一步,
判断接收的消息所携带的序列号seq未被当前对端发起的其他消息使用过时,认证成功,否则认证失败。
其中,判断接收的消息所携带的序列号seq被当前对端发起的其他消息使用过时,进一步包括:判断该消息是否是上次使用相同序列号seq消息的应用层重传,若是,则应用层按照应用层协议或规范定义按照重传消息处理方式进行处理,否则认证失败。
其中,认证信息包括表示不同呼叫外消息的序列号seq和表示呼叫内不同消息的子序列号seq-sub、随机数nonce时,所述认证步骤进一步包括:
第二设备判断接收的消息所携带的认证信息中的随机数nonce值与其存储的随机数nonce相同时,进一步,
判断序列号seq与其保存的序列号seq一致、子序列号sub-seq参数未被之前的相同序列号seq的消息使用过时,认证成功;否则认证失败。
其中,判断子序列号sub-seq参数被使用过时,进一步包括:判断该消息是否是上次使用相同序列号seq、相同子序列号sub-seq消息的应用层重传,若是,则应用层按照应用层协议或规范定义按照重传消息处理方式进行处理,否则认证失败。
其中,认证失败后直接丢弃所述消息。
由上述方法可以看出,在通信双方进行通信时,本发明可以确定该消息是否来自对方而非作为攻击者的第三方,解决了消息被仿冒的问题,同时还可以避免消息的重放攻击。
具体来说,本发明所有消息中都需要携带一认证信息,因此可以有效的保证请求和响应消息的合法性,避免受到仿冒消息攻击和消息重播攻击。认证信息置于消息头域中,除了用于加密的随机数同步过程以外不会新增任何新的消息交互,因此不需要针对每个消息都增加状态机,并且仅占用固定量的较少的系统资源。
并且,由于用于加密的随机数定期交互和协商,进一步的提高了安全性,并且在密钥协商的过程中进一步采用加密方式来进行协商,提高了随机数传输的可靠性。
另一方面,使用了序列号、子序列号机制有效的防止重放攻击,完成了对响应消息的安全性保证。并且,本发明不限于所使用的协议,在SIP、MGCP、H.248、H.323等协议中均可使用。
附图说明
图1为向主叫方发起攻击的示意图。
图2为向被叫方发起攻击的示意图。
图3为采用HTTP DIGEST方式进行呼叫的示意图。
图4为本发明认证头域的认证和同步的流程图。
图5为认证过程流程图。
图6为本发明SIP通信的实施例流程图。
具体实施方式
本发明的主要思想是:进行互通的两个设备首先进行用于加密的随机数的协商和交换;使得在两个设备上均保存有该随机数,然后在后续的信令交互中,携带所述随机数,由对方对该随机数进行鉴权来保证信令传输的安全。
本发明可以分为以下两个部分:
第一部分:直接进行互通的两个设备间的认证加密参数协商和交换过程,这个过程用来完成用于消息加密的随机数等参数的协商、交换与同步。通过该过程双方将得到一致的消息认证加密参数,该参数可包括用于认证加密的随机数nonce参数和最大序列号maxseq参数。
第二部分:完成认证加密参数协商和交换后,任何一方向对端发送消息时都须携带消息认证信息,该信息包含认证加密参数以及据此生成的认证信息;而对端接收到消息后都须首先对消息进行认证,认证通过后才对消息进行处理,若认证未通过则丢弃消息。
下面首先参见图4示出的流程图,对本发明两个设备间的认证加密参数协商和交换过程进行详细说明。
设备初始加载后,设备间除了预先配置的认证密码外尚没有任何关于用于消息认证的数据,需要首先进行认证加密参数协商和交换过程,为了保证该过程的可靠性,本实施例中采用了HTTP DIGEST认证方式来保证认证加密参数交换过程的可靠性,包括以下步骤:
步骤401:软交换设备A进入工作状态后,首先向要进行通信的软交换设备B发起认证加密参数同步请求。由于在进行互通之前软交换设备A和B之间没有进行消息认证的任何信息,因此本步骤中认证加密参数同步请求消息中不携带任何认证信息。
其中,本实施例中采用了HTTP DIGEST方式保证认证加密参数同步过程中各消息的安全性以提高设备的抗攻击能力。但不难理解,也可以采用其他方式来保证软交换设备A与B之间同步过程的安全性,例如可以使用一种新的请求方法(如CASMAN-Create And Synchronize Message AuthenticateNonce),或使用现有SIP协议及其扩展定义的方法。
步骤402:软交换设备B检测到接收的认证加密参数同步请求中不包括任何设备间认证信息,向A返回响应消息发起设备间认证过程。本例中,通过该响应消息中的头域Proxy-Authenticate携带B生成的HTTP-DIGEST认证方法中必须的随机数。
步骤403:软交换设备A收到所述响应消息后,由HTTP-DIGEST的规定根据响应消息中携带的信息产生HTTP-DIGEST认证头域Proxy-Authenticate;同时,产生本发明所需的消息认证头域Message-Authenticate。然后向B设备重新发起认证加密参数同步请求,该同步请求包含所述HTTP-DIGEST认证头域Proxy-Authenticate以及所述消息认证头域Message-Authenticate。
其中,所述消息认证头域Message-Authenticate可以为以下格式:
Message-Authenticate:
MBMD,nonce=“j32423k54df5432654a52a4d32j52n3”,
seq=1,sub-seq=0,response=“98743215116413019551354”,
nnonce=“f84f1cec41e6cbe5aea9c8e88d359”,maxseq=1000000
其中“MBMD”为消息加密方法,表示本例采用MBMD(Message ByMessage Digest)加密方法;还包括随机数nonce参数、序列号seq参数、子序列号sub-seq参数、用于认证加密的新随机数nnonce参数、最大序列号maxseq参数以及经过特定算法得到的加密密文response参数等。其中,nnonce和maxseq仅存在认证加密参数协商和交换过程,sub-seq参数为可选参数,其余各参数存在于设备间采用MBMD进行消息认证的所有消息中。不难理解,实际实施过程中可能会增加新的参数或者使用其他参数名称。
对于response参数的生成,根据所采用的加密算法不同,生成的值会不同,加密算法可以是公知的加密算法。例如可以根据随机数nonce、密码password(软交换之间预先配置的交互密码password,该密码为一可打印字符组成的字符串)、序列号seq等信息生成,若消息中包含有sub-seq,则除了上述参数,还可包含sub-seq参数来生成response。
步骤404:软交换设备B收到消息认证加密参数同步请求消息后,首先根据HTTP-DIGEST认证头域Proxy-Authenticate对请求消息进行认证,这个过程和现有技术相同。
认证通过后,软交换设备B记录Message-Authenticate中的nnonce、maxseq等消息认证相关参数。若有必要,还根据本地数据配置缩小maxseq的值,然后根据请求消息中的消息认证头域生成响应消息中的消息认证头域,返回对请求消息的响应消息。
步骤405:软交换设备A收到响应消息后,首先根据响应消息中消息认证头域Message-Authenticate对响应消息进行认证,例如判断该消息中的response是否与步骤403生成的相等,A设备还会根据响应消息中消息认证头域更新步骤403生成的maxseq参数。
从上可以看出,经过上述步骤后,软交换设备A、B之间通过消息认证头域完成了以下消息认证过程必须的信息同步:
nonce:用于消息加密的随机数。
maxseq:最大序列号。
如图4示出的步骤406~407,是后续的认证同步过程。该过程可以是定时触发,也可以是根据某状态触发,例如当任何通信的一方发觉序列号seq的使用率已达到或超过某一阈值(可通过设备本地数据配置等方式获得,如75%)时,则发起新的协商过程重新同步nonce。下面对该过程进行详述:
步骤406:软交换设备A发觉序列号的使用率已达到或超过某一阈值后,向设备B发起认证加密参数同步过程,以同步新的nonce和相关参数。
发出的认证加密参数同步请求消息的消息认证头域中,包含nonce、seq、response等参数,同时还需要包含新的随机数nnonce以及最大序列号maxseq。
步骤407:收到所述认证加密参数同步请求消息后,软交换设备B首先对消息进行认证(认证过程在后文进行描述),认证通过后设备B记录用于消息认证加密的随机数nonce为nnonce的值,及maxseq参数,若有必要,还根据本地数据配置缩小maxseq的值。并根据请求消息中的消息认证头域生成响应消息中的消息认证头域,置于响应消息中返回给软交换设备A。
步骤408:软交换设备A收到响应消息后,首先根据响应消息中的消息认证头域对响应消息进行认证,并且,设备A还可能根据响应消息中消息认证头域更新消息认证maxseq参数。
考虑到产生新nonce的设备B在发送响应消息后到A方响应会有一段网络延时,因此响应方B可在发送请求消息后延时一段时间(建议10秒)后启用nnonce作为新的nonce。而响应接收方A在收到响应消息后立即启用nnoce作为新的nonce。
完成认证加密参数协商和交换后,任何一方向对端发送的消息中都包含Message-Authenticate头域,该头域中包含的认证信息如上述步骤403中所述,包括双方协商好的值为nnonce的nonce、本次所生成的seq、一个可选的子序列号sub-seq以及经过特定算法产生的加密密文response。
其中,seq是一个从未被本端发起的呼叫使用过的序列号,若之前使用过该seq,则该seq后续将不再次被使用(或称之为失效)。并且,本发明使用子序列号sub-seq来标识一个呼叫内不同的消息,当使用sub-seq时,sub-seq从0开始随消息发送顺序逐渐递增,每次递增增量为1。当然对于呼叫内的消息交互也可以只使用seq而不使用sub-seq。这里需要说明的是,对于非呼叫内的事务过程由于通常只有一个请求消息和一个响应消息,可以不使用sub-seq。
任何一方从对端接收到消息后,首先对消息进行认证,仅在认证通过后才对消息进行处理,否则丢弃消息。参见图5所示,该认证过程包括以下步骤:
步骤501:收到消息的软交换设备判断该消息中的nonce值是否与其存储的nonce相同,若是,则执行步骤502;否则认为认证失败。
步骤502:若判断是呼叫外消息(Out of a dialog)(呼叫内消息是指属于某个已经建立的对话的消息,而呼叫外消息是指不归属于任何一个已经建立的对话的消息。如,用于建立呼叫的INVITE消息属于呼叫外消息,而呼叫建立后用于媒体改向的INVITE,俗称re-INVITE,属于呼叫内消息),进一步判断seq是否被之前从当前对端发起的其他呼叫使用过,是则认证失败;否则执行步骤504;
若判断是呼叫内消息(Within a dialog),则进一步判断seq是否与设备保存的seq一致,若是,则执行步骤503;否则认证失败。
步骤503:判断所述消息包含的sub-seq参数是否被之前的相同seq的消息使用过,若未被使用过,则执行步骤504。
若被使用过,进一步判断该消息是否是上次使用相同seq、相同sub-seq的消息的应用层重传(本次之前收到完全相同的消息就认为是消息重传),若是,则应用层按照应用层协议或规范定义按照重传消息处理方式进行处理,否则认证失败。
步骤504:消息接收者根据消息发送者同样的算法生成加密密文response,判断该密文是否与消息中携带的加密密文response参数一致,若是则认证通过,否则认证失败。
上述任何一个步骤验证失败,则直接丢弃消息而不对消息作任何进一步的处理,若上述步骤依次执行完后认证通过,则按照现有的处理方式对消息进行处理。
下面参见图6示出的SIP通信的实施例,来对交互信令消息的加密和认证过程举例进行说明,包括以下步骤:
步骤601:呼叫发起方设备A在发送INVITE消息时选取一个尚未失效的加密序列号seq,并使用nonce等生成消息认证头域,其中nonce为随机数,seq为选取的尚未失效的加密序列号,sub-seq为0,以及加密后的密文response。
可采用下述算法计算response:
如果有sub-seq则:response=bASE64(nonce“:”seq“:”sub-seq“:”role),表示response依据参数nonce、seq、sub-seq、role来进行计算
如果无sub-seq则:response=bASE64(nonce“:”seq“:”role),表示response依据参数nonce、seq、role来进行计算
其中,如果是由本端发起的呼叫则参数role为“local”,否则为“remote”。如果业务初试请求是由本端发起则参数role为“local”,否则为“remote”。
步骤602:设备B收到所述INVITE请求消息后首先对消息进行认证。
认证通过后向A返回100响应消息,其中带有nonce、seq、sub-seq以及加密后的密文response,其中nonce、seq与INVITE请求消息中的nonce和seq分别一致,sub-seq为0,response为加密后的密文,计算response的加密算法与步骤601相同,这一点,以后不再说明。
设备A收到该响应消息后首先对消息进行认证(包括判断消息中的response是否合法),认证通过后对该响应消息进行处理。
步骤603~604:设备B向A发送180、200响应消息时同样需要生成消息认证头域,其中带有nonce、seq、sub-seq以及密文response,其中nonce、seq与INVITE请求消息中的nonce和seq分别一致,sub-seq分别为1和2,response为密文。
步骤605:收到180、200响应消息后设备A首先对消息进行认证,认证通过后对该响应消息进行处理。
如果是200响应消息,则设备A需要返回对200响应消息的ACK,ACK消息带有nonce、seq、sub-seq以及密文response,其中nonce、seq与INVITE请求消息中的nonce和seq分别一致,sub-seq分别为1,response为密文。
设备B收到该响应消息后首先对消息进行认证,认证通过后对该响应消息进行处理。
步骤606:用户挂机后设备A向B发送BYE请求消息,BYE消息带有nonce、seq、sub-seq以及密文response,其中nonce、seq与INVITE请求消息中的nonce和seq分别一致,sub-seq分别为2,response为密文。
步骤606:设备B收到该响应消息后首先对消息进行认证(包括判断消息中的response是否合法等),认证通过后对该响应消息进行处理。
设备B向A发送对BYE请求的200响应消息时同样需要生成消息认证头域,其中带有nonce、seq、sub-seq以及加密后的密文response,其中nonce、seq与INVITE请求消息中的nonce和seq分别一致,sub-seq分别为3,response为密文。
设备A收到该响应消息后首先对消息进行认证,认证通过后对该响应消息进行处理。
从上面实施例可以看出,本发明通信的两端采用nonce进行通信,所有消息中都需要携带认证信息,因此可以有效的保证请求和响应消息所有消息的合法性,避免受到仿冒消息攻击。认证信息置于消息头域中,除了nonce同步过程以外不会新增任何新的消息交互,因此不需要针对每个消息都增加状态机,并且仅占用固定量的较少的系统资源。并且,使用了两个序列号(seq、sub-seq)确保每个消息的唯一性,可以有效的防止重播攻击。并且,sub-seq可以减缓seq序列号的耗尽速度。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (14)
1、一种设备间安全通信的方法,其特征在于,该方法包括以下步骤:
A、进行互通的第一设备和第二设备通过协商确定一致的消息认证加密参数;
B、第一设备发送消息时携带根据所述消息认证加密参数生成的认证信息;
C、第二设备接收到所述消息后,使用所述消息认证加密参数生成认证信息对接收的所述第一设备发送的消息所携带的认证信息进行认证,在认证通过后接受所述消息。
2、根据权利要求1所述的方法,其特征在于,步骤A所述协商的步骤包括:
第一设备/第二设备生成至少包含随机数nonce、最大序列号maxseq的消息认证加密参数,并发送给第二设备/第一设备。
3、根据权利要求2所述的方法,其特征在于,进一步包括:
收到所述消息认证加密参数的第二设备/第一设备根据其配置调整所述最大序列号maxseq,并返回给发送消息认证加密参数的第一设备/第二设备。
4、根据权利要求2所述的方法,其特征在于,步骤B所述生成的认证信息包括:表示不同消息的序列号seq,随机数nonce,根据序列号seq和随机数nonce生成的加密密文response。
5、根据权利要求2所述的方法,其特征在于,步骤B所述生成的认证信息包括:表示不同呼叫外消息的序列号seq和表示呼叫内不同消息的子序列号seq-sub,随机数nonce,根据序列号seq、子序列号seq-sub和随机数nonce生成的加密密文response。
6、根据权利要求1所述的方法,其特征在于,所述进行互通的第一设备和第二设备在一定条件下重新协商确定一致的消息认证加密参数。
7、根据权利要求6所述的方法,其特征在于,所述一定条件包括:定期,或序列号seq使用超过所述最大序列号maxseq的一定百分比。
8、根据权利要求1或6所述的方法,其特征在于,所述协商的步骤进一步包括:使用HTTP DEGEST的方式保证所述协商过程的安全性。
9、根据权利要求1所述的方法,其特征在于,步骤C所述使用所述消息认证加密参数生成认证信息对接收的消息所携带的认证信息进行认证的步骤包括:
根据第一设备同样的算法生成加密密文response,判断该加密密文response是否与接收的消息所携带的认证信息中的加密密文response一致,若是则认证通过,否则认证失败。
10、根据权利要求9所述的方法,其特征在于,认证信息包括表示不同消息的序列号seq、随机数nonce时,所述认证步骤进一步包括:
第二设备判断接收的消息所携带的认证信息中的随机数nonce值与其存储的随机数nonce相同时,进一步,
判断接收的消息所携带的序列号seq未被当前对端发起的其他消息使用过时,认证成功,否则认证失败。
11、根据权利要求10所述的方法,其特征在于,判断接收的消息所携带的序列号seq被当前对端发起的其他消息使用过时,进一步包括:
判断该消息是否是上次使用相同序列号seq消息的应用层重传,若是,则应用层按照应用层协议或规范定义按照重传消息处理方式进行处理,否则认证失败。
12、根据权利要求9所述的方法,其特征在于,认证信息包括表示不同呼叫外消息的序列号seq和表示呼叫内不同消息的子序列号seq-sub、随机数nonce时,所述认证步骤进一步包括:
第二设备判断接收的消息所携带的认证信息中的随机数nonce值与其存储的随机数nonce相同时,进一步,
判断序列号seq与其保存的序列号seq一致、子序列号sub-seq参数未被之前的相同序列号seq的消息使用过时,认证成功;否则认证失败。
13、根据权利要求11所述的方法,其特征在于,判断子序列号sub-seq参数被使用过时,进一步包括:
判断该消息是否是上次使用相同序列号seq、相同子序列号sub-seq消息的应用层重传,若是,则应用层按照应用层协议或规范定义按照重传消息处理方式进行处理,否则认证失败。
14、根据权利要求1、9到13中的任一权利要求所述的方法,其特征在于,认证失败后直接丢弃所述消息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200510123696 CN1881870A (zh) | 2005-11-18 | 2005-11-18 | 一种设备间安全通信的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200510123696 CN1881870A (zh) | 2005-11-18 | 2005-11-18 | 一种设备间安全通信的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1881870A true CN1881870A (zh) | 2006-12-20 |
Family
ID=37519864
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200510123696 Pending CN1881870A (zh) | 2005-11-18 | 2005-11-18 | 一种设备间安全通信的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1881870A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101465739B (zh) * | 2009-01-15 | 2011-08-10 | 中兴通讯股份有限公司 | 一种实现认证方式平滑过渡的方法及设备 |
CN102726082A (zh) * | 2012-01-04 | 2012-10-10 | 华为技术有限公司 | X2安全通道建立方法与系统、以及基站 |
CN105207911A (zh) * | 2015-10-12 | 2015-12-30 | 安徽皖通邮电股份有限公司 | 一种is-is协议报文认证方法及其系统 |
CN111770048A (zh) * | 2020-05-08 | 2020-10-13 | 厦门亿联网络技术股份有限公司 | 一种防止sip设备被攻击的方法、主叫设备及被叫设备 |
CN111833488A (zh) * | 2019-12-31 | 2020-10-27 | 北京骑胜科技有限公司 | 一种开关锁方法、装置、电子锁及存储介质 |
-
2005
- 2005-11-18 CN CN 200510123696 patent/CN1881870A/zh active Pending
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101465739B (zh) * | 2009-01-15 | 2011-08-10 | 中兴通讯股份有限公司 | 一种实现认证方式平滑过渡的方法及设备 |
CN102726082A (zh) * | 2012-01-04 | 2012-10-10 | 华为技术有限公司 | X2安全通道建立方法与系统、以及基站 |
CN102726082B (zh) * | 2012-01-04 | 2014-11-05 | 华为技术有限公司 | X2安全通道建立方法与系统、以及基站 |
CN105207911A (zh) * | 2015-10-12 | 2015-12-30 | 安徽皖通邮电股份有限公司 | 一种is-is协议报文认证方法及其系统 |
CN105207911B (zh) * | 2015-10-12 | 2018-11-23 | 安徽皖通邮电股份有限公司 | 一种is-is协议报文认证方法及其系统 |
CN111833488A (zh) * | 2019-12-31 | 2020-10-27 | 北京骑胜科技有限公司 | 一种开关锁方法、装置、电子锁及存储介质 |
CN111770048A (zh) * | 2020-05-08 | 2020-10-13 | 厦门亿联网络技术股份有限公司 | 一种防止sip设备被攻击的方法、主叫设备及被叫设备 |
CN111770048B (zh) * | 2020-05-08 | 2023-04-07 | 厦门亿联网络技术股份有限公司 | 一种防止sip设备被攻击的方法、主叫设备及被叫设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9749318B2 (en) | Key management in a communication network | |
US9106648B2 (en) | Method and apparatus for data transmission | |
CN1214568C (zh) | 采用会话启动协议消息对服务器验证用户代理的验证方法 | |
TWI711293B (zh) | 驗證網路通話身份的方法及相關裝置 | |
JP2010086529A (ja) | 連続する再認証を必要としないsipシグナリング | |
CN1864384A (zh) | 用于保护网络管理帧的系统和方法 | |
WO2011022999A1 (zh) | 一种终端对视频会议数据进行加密的方法及系统 | |
CN1615626A (zh) | 在通信网中利用已验证的业务质量传输信息 | |
WO2010000171A1 (zh) | 一种通信的建立方法、系统和装置 | |
CN1992593A (zh) | 应用于分组网络的基于h.323协议的终端接入方法 | |
Rehman et al. | Security analysis of VoIP architecture for identifying SIP vulnerabilities | |
CN111756726A (zh) | 一种支持国密算法的sip安全认证方法 | |
CN1889562A (zh) | 对接收初始会话协议请求消息的设备进行认证的方法 | |
CN1881870A (zh) | 一种设备间安全通信的方法 | |
CN1881869A (zh) | 一种实现加密通信的方法 | |
CN100403742C (zh) | 一种媒体网关与媒体网关控制器之间安全认证的方法 | |
CN1571407A (zh) | 一种基于媒体网关控制协议的安全认证方法 | |
CN1698393A (zh) | 通信系统 | |
CN1239009C (zh) | Ip多媒体域用户呼叫的快速摘要认证方法 | |
US7480801B2 (en) | Method for securing data traffic in a mobile network environment | |
CN1571408A (zh) | 一种基于媒体网关控制协议的安全认证方法 | |
JP4571006B2 (ja) | ネットワーク制御装置、ネットワークシステム、及びプログラム | |
CN111770048B (zh) | 一种防止sip设备被攻击的方法、主叫设备及被叫设备 | |
JP2005142719A (ja) | メッセージ検証システム、メッセージ検証方法およびメッセージ検証プログラム | |
JP2011217031A (ja) | 通信装置及び発信者認証方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20061220 |