CN1414730A - 验证数据安全传输的方法 - Google Patents
验证数据安全传输的方法 Download PDFInfo
- Publication number
- CN1414730A CN1414730A CN 02117818 CN02117818A CN1414730A CN 1414730 A CN1414730 A CN 1414730A CN 02117818 CN02117818 CN 02117818 CN 02117818 A CN02117818 A CN 02117818A CN 1414730 A CN1414730 A CN 1414730A
- Authority
- CN
- China
- Prior art keywords
- sequence number
- security association
- packet
- card
- seq
- 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.)
- Granted
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
一种使用安全联盟序列号验证数据安全传输的方法,是在每条安全联盟(SA)的结构中添加发送序列号(card_send_seq)、接收序列号(card_recv_seq)和验证序列号(card_last_recv_seq)三个序列号标示和一个状态标示符(card_last_check_result)字段,通过对这些标示的检测来验证加密卡在使用安全联盟(SA)进行数据处理的过程中是否发生错误;同时,主机定时检测加密卡所使用的每条安全联盟(SA),利用这些标示来确定发生问题的安全联盟的具体位置,并及时更新纠错。该方法比较方便、简捷,可以避免使用错误的安全联盟继续验证处理相关数据包,保证数据安全传输。
Description
所属领域
本发明涉及一种对数据传输进行加密验证的处理方法,确切地说,涉及一种验证数据安全传输的方法。属于数字信息传输中的保密或安全通信装置的技术领域。
背景技术
随着互联网络的迅速发展,网上数据传输的安全问题越来越受到业内人士的倍加关注。现在,许多通信协议、规程和方法都提供了对数据的加密或验证功能,来保证数据的安全传输。目前应用较为广泛的是IPSec(Internet ProtocolSecurity)协议。
IPSec协议是一种协议套件,包括有:AH(Authentication Header)验证头协议、ESP(Encapsulation Security Protocol)封装安全载荷协议、IKE(InternetKey Exchange)互联网密钥交换协议等。IPSec协议支持通过手动配置方式或者IKE协议自动协商方式生成安全联盟SA(Security Association)。该安全联盟SA是IPSec的基础,它决定了用来保护数据包安全的IPSec协议中的转码方式、密钥以及密钥的有效存在时间等。总之,安全联盟SA是对数据进行加密或验证的基本依据,也可以说每一个需要进行加密或验证处理的数据包都会配置或生成相应的特定安全联盟SA。
现在,虽然大部分的加密验证工作是在主机系统(即路由器的主机软件系统)中完成的,也有一些公司将数据的加密验证转移到单板(即加密卡)上来实现,这样可以大大提高数据的处理速度。申请人研制的加密卡就是一块基于IPSec协议、专门用于数据加密验证的硬件板卡。由于安全联盟SA的产生、维护都是由主机完成的,加密卡本身只是根据其保存的主机安全联盟SA的备份来完成数据的加密或验证处理,所以在对数据的控制上,主机和加密卡存在一定的分离,因此产生了如何保证加密卡安全联盟SA和主机安全联盟SA的一致问题。为此,申请人定义了一系列对加密卡的控制命令,包括安全联盟SA的添加、删除、捆绑(应用于AH+ESP协议)等。
为了实现加密卡和主机之间的通信,申请人定义了一种特殊的消息帧头结构,其中包含有消息类型(命令/数据/其他)、消息属性(命令属性/数据属性/其他)、以及其他与数据有关的信息。例如每个数据包对应的安全联盟SA的标示都是全局唯一的,即每个安全联盟SA拥有不同的标示;每个数据包的序列号标示对于某个SA也是唯一的,即和某个SA相关的所有数据包分别具有不同的序列号标示等等。这个消息帧头随同数据包本身一起在加密卡和主机之间进行传输。现在,随着人们对数据加密、安全传输性能需求的不断提高,使用加密卡已经成为一种发展趋势。目前的主机系统对SA的管理方法,如果不使用加密卡,或者不需要对主机系统所维护的SA进行实时监控时,已经达到了很好的效果。同时,通过IKE协议提供的时间超时、流量超时机制来定期更新安全联盟SA,可以比较可靠地保证SA的正确性。但是,当使用周期相对较长或者不使用超时机制,就没有办法对在数据处理中发生错误的安全联盟及时进行更新。
在正常情况下,主机和加密卡之间的SA信息是保持一致的,加密卡对主机下发的数据包也都能正确地进行加密或验证等处理。但是,一旦出现异常情况,如果需要具体定位加密卡上的哪条安全联盟SA在处理数据时发生了错误,并对相应的安全联盟SA进行更新,实时维护加密卡和主机之间的安全联盟SA的一致性时,现有的处理机制就显得无能为力了。
目前,加密卡所保存的某个安全联盟SA出现的问题,主要分为两种情况:第一种,加密卡在使用安全联盟对主机下发的数据包进行加密验证发现错误时,它会丢弃该数据包,并向主机系统返回一个包含有该数据包错误的消息帧头。此时,主机系统可以通过自己的统计信息纪录被丢失的数据包个数;但是却没有办法确定数据包的丢失是否与该加密卡有关,或者具体是由于哪一条安全联盟而引起的,从而使得后续发送的与该错误安全联盟SA对应的数据包将继续被丢失的现象无法得到及时纠正。第二种,加密卡上根本不存在主机下发的数据包所对应的安全联盟SA,或者在处理过程中丢弃了该数据包,并且没有向主机反馈任何信息。在这种情况下,主机如果没有办法获知该安全联盟SA已经发生问题,将导致加密卡继续丢弃该SA对应的数据包。
发明内容
本发明的目的是提供一种使用安全联盟序列号验证数据是否安全传输的实现方法,该方法是解决上述加密卡两种异常问题的较好办法,能够比较方便地在加密卡上检测各个安全联盟是否发生错误,并定位找出发生问题的安全联盟和及时更新之,以避免对该安全联盟相关数据包的处理再次发生错误。本发明的目的是这样实现的:一种使用安全联盟序列号验证数据是否安全传输的实现方法,其特征在于:该方法是在每条安全联盟(SA)的结构中添加发送序列号(car_send_seq)、接收序列号(card_recv_seq)和验证序列号(card_last_recv_seq)三个序列号标示和一个状态标示符(card_last_check_result)符号,接着,检测这些标示来验证加密卡在使用安全联盟(SA)进行数据处理的过程中是否发生错误;同时,主机定时检测加密卡所使用的每条安全联盟(SA),利用这些标示来确定发生问题的安全联盟(SA)的具体位置。
所述的安全联盟(SA)的发送序列号(card_send_seq)是标记主机向加密卡所发送的每个数据包的序列号。
所述的安全联盟(SA)的发送序列号是在主机需要向加密卡发送数据包时,根据该数据包本身的特征,确定它所对应的安全联盟(SA)而得到的;然后再将该发送序列号加1,作为该数据包的序列号保存在其消息帧头中,发送给加密卡。
所述的该数据包本身的特征包括有:该IP数据包报文的源地址、目的地址类的信息。
所述的安全联盟(SA)接收序列号(card_recv_seq)是标记主机已经从加密卡接收到的数据包的序列号。
所述的安全联盟(SA)接收序列号是在主机接收到加密卡返回的数据包时,根据其消息帧头中的安全联盟(SA)标示,找到相应的安全联盟(SA)而得到的;然后比较该接收序列号和数据包消息帧头中保存的接收序列号的数值是否相等,判断该数据包是否为所期望接收的数据包。
所述的安全联盟(SA)验证序列号(card_last_recv_seq)是标记上一次对每一条安全联盟(SA)进行检测时,该被检测的安全联盟(SA)的接收序列号。
所述的安全联盟(SA)验证序列号是用于定时检测安全联盟SA时,与该安全联盟(SA)的发送序列号、接收序列号相配合,来确定该安全联盟(SA)当前的状态是否正常。
所述的安全联盟(SA)状态标示符(card_last_check_result)是标记安全联盟(SA)的当前状态的符号。
所述的安全联盟(SA)状态标示符有两种:当状态标示符为0时,说明上一次检测安全联盟(SA)时,该安全联盟(SA)正常;当状态标示符为1时,说明上一次检测安全联盟(SA)时,该安全联盟(SA)已经出现异常。
该方法包括有下列操作步骤:
A、首先使用IPSec协议通过IKE自动协商或者手工配置生成安全联盟(SA),并对该安全联盟(SA)的发送序列号、接收序列号和验证序列号以及状态标示符进行初始化;
B、主机与加密卡之间互相发送数据,并对其中相应的安全联盟(SA)的三个序列号以及状态标示符分别进行处理;
C、主机通过定时器对加密卡使用的每一条安全联盟(SA)定时进行检测,利用三个序列号和状态标示符之间的关系,确定发生问题的安全联盟的具体位置。
所述的A步骤中对三个序列号和标识符的初始化是分别设置发送序列号、接收序列号、验证序列号和状态标示符均为0。
所述的B步骤中主机与加密卡之间互相发送数据,并对其中相应的安全联盟(SA)的三个序列号以及状态标示符分别进行处理的过程包括有下列步骤:
B1、首先由主机根据数据本身特征查找到所对应的安全联盟(SA),得到该安全联盟(SA)的发送序列号(card_send_seq);并将该发送序列号(card_send_seq)加1后的值作为该数据包的序列号(DataSequence)添加在数据包的消息帧头中,同时将能够在全局唯一地标示该安全联盟(SA)的标示添加到该数据包的消息帧头中,连同数据包一起发送到加密卡进行处理;还将该安全联盟(SA)的发送序列号加1,表示主机向加密卡发送了一个序列号为(DataSequence)的数据包;
B2、加密卡接收到主机发送来的数据包,先根据该数据包消息帧头中的安全联盟(SA)标示找到对应的安全联盟(SA),藉由该安全联盟(SA)的信息对该数据包进行验证处理;接着根据验证结果生成新的消息帧头:若验证成功,则生成加密验证后的数据包,其消息帧头中的安全联盟(SA)标示以及数据包序列号(DataSequence)均和主机发送来的数据包消息帧头中的原始值保持一致,若验证失败,则生成错误信息;然后将该消息帧头或者所产生的错误信息连同处理后的数据包一起发回给主机系统;
B3、主机系统接收到加密卡返送回来的数据包,从该数据包的消息帧头中得到安全联盟(SA)标示和该数据包的序列号(DataSequence);然后根据安全联盟(SA)的标示得到相应的安全联盟(SA),并对该安全联盟(SA)的序列号进行下述处理:如果该数据包的序列号(DataSequence)等于该安全联盟(SA)的接收序列号(card_recv_seq)加1,说明该安全联盟(SA)所对应的数据包的验证处理属于正常状态,该数据包为主机当前所期望从加密卡得到的数据包,并设置接收序列号(card_recv_seq)等于接收到的该数据包的序列号(DataSequence);如果数据包的序列号(DataSequence)不等于该安全联盟(SA)的接收序列号(card_recv_seq)加1,说明加密卡在使用该安全联盟(SA)处理数据包过程中,已经有数据包被丢失,该数据包不是主机当前所期望从加密卡得到的数据包,此时输出提示信息“该SA已经有数据包被丢弃”,同时设置该安全联盟(SA)的接收序列号(card_recv_seq)为接收到的该数据包的序列号(DataSequence)。
所述的C步骤中主机通过定时器对加密卡使用的每一条安全联盟(SA)进行定时检测的过程包括有下列步骤:首先判断该安全联盟(SA)的验证序列号(card_last_recv_seq)是否等于其接收序列号(card_recv_seq),接着判断该安全联盟(SA)的验证序列号(card_last_recv_seq)是否等于其发送序列号(card_send_seq),还要判断该安全联盟(SA)的状态标示符(car_last_check_result)是否等于1,再根据上述序列号和状态标示符的不同情况分别进行相应的处理:
如果该安全联盟的验证序列号等于接收序列号,而且验证序列号不等于发送序列号时,则分为两种情况处理:
(1)如果状态标示符为0,则将状态标示符设置为1;
(2)如果状态标示符为1,则对该安全联盟(AS)进行更新纠错,并向用户发出相应的提示信息;
对于序列号的其他情况,则认为加密卡对数据包的处理正常,同时设置验证序列号等于接收序列号。
在使用加密卡进行数据验证处理时,主机和加密卡要分别维护一套相同的安全联盟,由于安全联盟的数量比较多,使用这些安全联盟进行加密验证的数据量也相对较大,如果加密卡验证数据时发现错误,要具体定位是哪一条安全联盟出现错误,现有技术是很难实现的。本发明的方法是通过对安全联盟设置若干序列号和状态符,再针对这些序列号和状态符的不同情况进行分析判断,可以方便、简捷地检测各个安全联盟是否发生错误,并定位找到发生问题的安全联盟所处位置,然后可以通过触发该安全联盟的协商或者重新向加密卡添加正确的安全联盟,进行更新纠错;从而避免再次发生错误,保证数据安全传输。
附图说明
图1是主机和加密卡使用本发明方法中的安全联盟序列号和数据包序列号检测其对应的安全联盟是否正确的流程图。
图2是主机使用本发明方法定时检测每一条安全联盟,以找出发生问题的安全联盟的确切位置的流程图。
具体实施方式
本发明是一种使用安全联盟序列号验证数据是否安全传输的实现方法,其是在每条安全联盟SA的结构中添加发送序列号(card_send_seq)、接收序列号(card_recv_seq)和验证序列号(card_last_recv_seq)三个序列号标示和一个状态标示符(card_last_check_result)符号,通过对这些标示的检测来验证加密卡在使用安全联盟SA进行数据处理的过程中是否发生错误;同时,主机定时检测加密卡所使用的每条安全联盟SA,利用这些标示来确定发生问题的安全联盟的具体位置。
该方法包括有下列操作步骤:
A、首先使用Sec协议通过IKE自动协商或者手工配置生成安全联盟(SA),并对该安全联盟(SA)的发送序列号、接收序列号和验证序列号以及状态标示符进行初始化;该初始化是分别设置发送序列号、接收序列号、验证序列号和状态标示符均为0;用以标示当前该安全联盟(SA)没有向加密卡发送、也没有从加密卡接收数据包,同时该安全联盟(SA)的状态正常。
B、主机与加密卡之间互相发送数据,并对其中相应的安全联盟(SA)的三个序列号以及状态标示符分别进行处理的过程包括有下列步骤(参见图1):
B1、首先由主机根据其要向加密卡发送的数据本身特征查找到所对应的安全联盟(SA),得到该安全联盟(SA)的发送序列号(card_send_seq);并将该发送序列号(card_send_seq)加1后的值作为该数据包的序列号(DataSequence)添加在数据包的消息帧头中,还将能够在全局唯一地标示该安全联盟(SA)的标示添加到该数据包的消息帧头中的该安全联盟(SA)标示域,连同数据包一起发送到加密卡进行处理;同时将该安全联盟(SA)的发送序列号加1,表示主机向加密卡发送了一个序列号为DataSequence的数据包;
B2、加密卡接收到主机发送来的数据包,先根据该数据包消息帧头中的该安全联盟(SA)标示找到对应的安全联盟(SA),通过该安全联盟(SA)的信息对该数据包进行验证处理,接着根据验证结果生成新的消息帧头:若验证成功,则生成加密验证后的数据包,其消息帧头中的安全联盟(SA)标示以及数据包序列号(DataSequence)均和主机发送来的原始数据包消息帧头中的数值保持一致,若验证失败,则生成错误信息;然后将该消息帧头或者所产生的错误信息连同处理后的数据包一起发回给主机系统;
B3、主机系统接收到加密卡返送回来的数据包,先从该数据包的消息帧头中得到该安全联盟(SA)标示和该数据包的序列号(DataSequence);然后根据该安全联盟(SA)的标示得到相应的安全联盟(SA),并对该安全联盟(SA)的序列号进行下述处理:如果该数据包的序列号(DataSequence)等于该安全联盟(SA)的接收序列号(card_recv_seq)加1,说明该安全联盟(SA)所对应的数据包的验证处理属于正常状态,该数据包为主机当前所期望从加密卡得到的数据包,设置接收序列号(card_recv_seq)等于接收到的该数据包的序列号(DataSequence);如果该数据包的序列号(DataSequence)不等于该安全联盟(SA)的接收序列号(card_recv_seq)加1,说明加密卡在使用该安全联盟(SA)处理数据包过程中,已经有数据包被丢失,该数据包并不是主机当前所期望从加密卡得到的数据包,此时输出提示信息“该安全联盟(SA)已经有数据包被丢弃”,同时设置该安全联盟(SA)的接收序列号(card_recv_seq)为接收到的该数据包的序列号(DataSequence)。这是因为在此时,凡是其数据包序列号(DataSequence)大于当前接收序列号(card_recv_seq)、且小于当前接收到的数据包序列号(DataSequence)的所有数据包都已经在加密卡的处理过程中被丢弃了,且它们相应的错误信息也没有返回。这样处理的目的是为了使加密卡在继续进行验证处理时避免再次发生错误。
C、主机通过定时器对加密卡使用的每一条安全联盟(SA)定时进行检测,利用三个序列号和状态标示符确定发生问题的安全联盟的具体位置。其过程包括有下列步骤(参见图2):
主机在定时检测每个安全联盟(SA)时,首先判断该安全联盟(SA)的验证序列号是否等于其接收序列号,接着判断该安全联盟(SA)的验证序列号是否等于其发送序列号,还要判断该安全联盟(SA)的状态标示符是否等于1,再根据上述序列号和状态标示符的不同情况分别进行相应的处理:
如果初始值为0的某一条安全联盟(SA)的验证序列号(card_last_recv_seq)等于接收序列号(card_recv_seq),且不等于发送序列号(card_send_seq),即发送序列号(card_send_seq)和接收序列号(card_recv_seq)不相等,说明在本检测周期内主机没有从加密卡接收到数据包,但向加密卡已发送过数据包;即在本检测周期中与该安全联盟(SA)相关的数据包在加密卡上的处理可能出现错误,该错误是指丢弃数据包,且没有任何错误信息反馈给主机,或者是加密卡反馈的信息尚在传输的过程中。这是因为主机系统和加密卡系统是相对独立的,有可能是该加密卡反馈的信息还在两者之间传输的“路上”。这时,分为两种情况分别进行处理:
(1)如果该安全联盟(SA)的状态标示符(card_last_check_result)为0,表示该安全联盟(SA)在上一次检测中是正常的,则设置该安全联盟(SA)的状态标示符(card_last_check_result)为1,以纪录本次检测周期中该安全联盟(SA)在加密卡上的对应副本可能发生错误,也可能正在加密卡上处理,随后将发送回主机;
(2)如果该安全联盟(SA)的状态标示符(card_last_check_result)为1,表示前一个周期该安全联盟(SA)在加密卡上的副本已经发生错误(甚至在加密卡上根本不存在该安全联盟(SA)的副本),并进行了标记。这时需要通过下发添加安全联盟(SA)的命令来对加密卡上的该条安全联盟(SA)进行更新纠错,同时向用户提示:该条安全联盟(SA)发生错误;
对于序列号的其他情况都认为加密卡对数据包的处理是正常的。例如该安全联盟(SA)的验证序列号(card_last_recv_seq)不等于其的接收序列号(card_recv_seq),说明在本检测周期内曾经接收到加密卡反馈的与该安全联盟(SA)相关的数据包,即在已经过去的一段时间内加密卡向主机反馈该安全联盟(SA)相关数据包的处理过程是正常的,可以认为该安全联盟(SA)在加密卡上的副本是正确的,设置该安全联盟(SA)的验证序列号(card_last_recv_seq)等于它的接收序列号(card_recv_seq),同时设置其状态标示(card_last_check_result)为0,标明该安全联盟(SA)状态正常。
又例如该安全联盟(SA)的发送序列号(card_send_seq)等于其接收序列号(card_recv_seq),即该安全联盟(SA)相关的向加密卡发送的数据包全部得到了加密卡的反馈,说明该安全联盟(SA)在加密卡上的副本是正确的,则设置该安全联盟(SA)的验证序列号(card_last_recv_seq)等于接收序列号(card_recv_seq),同时设置其状态标示(card_last_check_result)为0,标明该安全联盟(SA)状态正常。
这是因为在本发明的上述处理过程中,每个安全联盟(SA)的发送序列号(card_send_seq)始终等于主机系统向加密卡发送的、与该安全联盟(SA)相关的所有数据包中最新(即序列号数目最大)的数据包序列号(DataSequence)。而每个安全联盟(SA)的接收序列号(card_recv_seq)也始终等于主机系统从加密卡接收到的、与该安全联盟(SA)相关的所有数据包中最新(即序列号数目最大)的数据包序列号(DataSequence)。这样在理论上,如果加密卡对每个数据包的处理结果都反馈给了主机(无论是正确处理后得到的加密验证后的数据包,还是处理过程中发现错误后给出的错误信息),对于同一个安全联盟(SA)来说,它的发送序列号(card_send_seq)应该是和它的接收序列号(card_recv_seq)相等的(假设加密卡对该安全联盟(SA)相关的所有数据包都已处理完毕,其所反馈的信息也都被主机接收到)。
本发明的方法已经在计算机进行过仿真模拟和测试,并且在申请人研制的加密卡项目中进行实施试验,试验的实践和测试证明,该方法是可行的,且工作可靠,实现了预期的发明目的。
Claims (14)
1、一种验证数据安全传输的方法,其特征在于:该方法是在每条安全联盟(SA)的结构中添加发送序列号(card_send_seq)、接收序列号(card_recv_seq)和验证序列号(card_last_recv_seq)三个序列号标示和一个状态标示符(card_last_check_result)符号,接着,检测这些标示来验证加密卡在使用安全联盟(SA)进行数据处理的过程中是否发生错误;同时,主机定时检测加密卡所使用的每条安全联盟(SA),利用这些标示来确定发生问题的安全联盟(SA)的具体位置。
2、根据权利要求1所述的验证数据安全传输的方法,其特征在于:所述的安全联盟(SA)的发送序列号(card_send_seq)是标记主机向加密卡所发送的每个数据包的序列号。
3、根据权利要求2所述的验证数据安全传输的方法,其特征在于:所述的安全联盟(SA)的发送序列号是在主机需要向加密卡发送数据包时,根据该数据包本身的特征,确定它所对应的安全联盟(SA)而得到的;然后再将该发送序列号加1,作为该数据包的序列号保存在其消息帧头中,发送给加密卡。
4、根据权利要求3所述的验证数据安全传输的方法,其特征在于:所述的该数据包本身的特征包括有:该IP数据包报文的源地址、目的地址类的信息。
5、根据权利要求1所述的验证数据安全传输的方法,其特征在于:所述的安全联盟(SA)接收序列号(card_recv_seq)是标记主机已经从加密卡接收到的数据包的序列号。
6、根据权利要求5所述的验证数据安全传输的方法,其特征在于:所述的安全联盟(SA)接收序列号是在主机接收到加密卡返回的数据包时,根据其消息帧头中的安全联盟(SA)标示,找到相应的安全联盟(SA)而得到的;然后比较该接收序列号和数据包消息帧头中保存的接收序列号的数值是否相等,判断该数据包是否为所期望接收的数据包。
7、根据权利要求1所述的验证数据安全传输的方法,其特征在于:所述的安全联盟(SA)验证序列号(card_last_recv_seq)是标记上一次对每一条安全联盟(SA)进行检测时,该被检测的安全联盟(SA)的接收序列号。
8、根据权利要求7所述的验证数据安全传输的方法,其特征在于:所述的安全联盟(SA)验证序列号是用于定时检测安全联盟SA时,与该安全联盟(SA)的发送序列号、接收序列号相配合,来确定该安全联盟(SA)当前的状态是否正常。
9、根据权利要求1所述的验证数据安全传输的方法,其特征在于:所述的安全联盟(SA)状态标示符(card_last_check_result)是标记安全联盟(SA)的当前状态的符号。
10、根据权利要求9所述的验证数据安全传输的方法,其特征在于:所述的安全联盟(SA)状态标示符有两种:当状态标示符为0时,说明上一次检测安全联盟(SA)时,该安全联盟(SA)正常;当状态标示符为1时,说明上一次检测安全联盟(SA)时,该安全联盟(SA)已经出现异常。
11、根据权利要求1所述的验证数据安全传输的方法,其特征在于:该方法包括有下列操作步骤:
A、首先使用IPSec协议通过IKE自动协商或者手工配置生成安全联盟(SA),并对该安全联盟(SA)的发送序列号、接收序列号和验证序列号以及状态标示符进行初始化;
B、主机与加密卡之间互相发送数据,并对其中相应的安全联盟(SA)的三个序列号以及状态标示符分别进行处理;
C、主机通过定时器对加密卡使用的每一条安全联盟(SA)定时进行检测,利用三个序列号和状态标示符之间的关系,确定发生问题的安全联盟的具体位置。
12、根据权利要求11所述的验证数据安全传输的方法,其特征在于:所述的A步骤中对三个序列号和标识符的初始化是分别设置发送序列号、接收序列号、验证序列号和状态标示符均为0。
13、根据权利要求11所述的验证数据安全传输的方法,其特征在于:所述的B步骤中主机与加密卡之间互相发送数据,并对其中相应的安全联盟(SA)的三个序列号以及状态标示符分别进行处理的过程包括有下列操作步骤:
B1、首先由主机根据数据本身特征查找到所对应的安全联盟(SA),得到该安全联盟(SA)的发送序列号(card_send_seq);并将该发送序列号(card_send_seq)加1后的值作为该数据包的序列号(DataSequence)添加在数据包的消息帧头中,同时将能够在全局唯一地标示该安全联盟(SA)的标示添加到该数据包的消息帧头中,连同数据包一起发送到加密卡进行处理;还将该安全联盟(SA)的发送序列号加1,表示主机向加密卡发送了一个序列号为(DataSequence)的数据包;
B2、加密卡接收到主机发送来的数据包,先根据该数据包消息帧头中的安全联盟(SA)标示找到对应的安全联盟(SA),藉由该安全联盟(SA)的信息对该数据包进行验证处理;接着根据验证结果生成新的消息帧头:若验证成功,则生成加密验证后的数据包,其消息帧头中的安全联盟(SA)标示以及数据包序列号(DataSequence)均和主机发送来的数据包消息帧头中的原始值保持一致,若验证失败,则生成错误信息;然后将该消息帧头或者所产生的错误信息连同处理后的数据包一起发回给主机系统;
B3、主机系统接收到加密卡返送回来的数据包,从该数据包的消息帧头中得到安全联盟(SA)标示和该数据包的序列号(DataSequence);然后根据安全联盟(SA)的标示得到相应的安全联盟(SA),并对该安全联盟(SA)的序列号进行下述处理:如果该数据包的序列号(DataSequence)等于该安全联盟(SA)的接收序列号(card_recv_seq)加1,说明该安全联盟(SA)所对应的数据包的验证处理属于正常状态,该数据包为主机当前所期望从加密卡得到的数据包,并设置接收序列号(card_recv_seq)等于接收到的该数据包的序列号(DataSequence);如果数据包的序列号(DataSequence)不等于该安全联盟(SA)的接收序列号(card_recv_seq)加1,说明加密卡在使用该安全联盟(SA)处理数据包过程中,已经有数据包被丢失,该数据包不是主机当前所期望从加密卡得到的数据包,此时输出提示信息“该SA已经有数据包被丢弃”,同时设置该安全联盟(SA)的接收序列号(card_recv_seq)为接收到的该数据包的序列号(DataSequence)。
14、根据权利要求11所述的验证数据安全传输的方法,其特征在于:所述的C步骤中主机通过定时器对加密卡使用的每一条安全联盟(SA)进行定时检测的过程包括有下列步骤:首先判断该安全联盟(SA)的验证序列号(card_last_recv_seq)是否等于其接收序列号(card_recv_seq),接着判断该安全联盟(SA)的验证序列号(card_last_recv_seq)是否等于其发送序列号(card_send_seq),还要判断该安全联盟(SA)的状态标示符(card_last_check_result)是否等于1,再根据上述序列号和状态标示符的不同情况分别进行相应的处理:
如果该安全联盟的验证序列号等于接收序列号,而且验证序列号不等于发送序列号时,则分为两种情况处理:
(1)如果状态标示符为0,则将状态标示符设置为1;
(2)如果状态标示符为1,则对该安全联盟(AS)进行更新纠错,并向用户发出相应的提示信息;
对于序列号的其他情况,则认为加密卡对数据包的处理正常,同时设置验证序列号等于接收序列号。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 02117818 CN1223137C (zh) | 2002-05-22 | 2002-05-22 | 验证数据安全传输的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 02117818 CN1223137C (zh) | 2002-05-22 | 2002-05-22 | 验证数据安全传输的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1414730A true CN1414730A (zh) | 2003-04-30 |
CN1223137C CN1223137C (zh) | 2005-10-12 |
Family
ID=4744529
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 02117818 Expired - Fee Related CN1223137C (zh) | 2002-05-22 | 2002-05-22 | 验证数据安全传输的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1223137C (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102075427A (zh) * | 2011-01-18 | 2011-05-25 | 中兴通讯股份有限公司 | 基于安全联盟的IPSec报文处理方法及装置 |
CN104735060A (zh) * | 2015-03-09 | 2015-06-24 | 清华大学 | 路由器及其数据平面信息的验证方法和验证装置 |
-
2002
- 2002-05-22 CN CN 02117818 patent/CN1223137C/zh not_active Expired - Fee Related
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102075427A (zh) * | 2011-01-18 | 2011-05-25 | 中兴通讯股份有限公司 | 基于安全联盟的IPSec报文处理方法及装置 |
WO2012097614A1 (zh) * | 2011-01-18 | 2012-07-26 | 中兴通讯股份有限公司 | 基于安全联盟的IPSec报文处理方法及装置 |
CN104735060A (zh) * | 2015-03-09 | 2015-06-24 | 清华大学 | 路由器及其数据平面信息的验证方法和验证装置 |
CN104735060B (zh) * | 2015-03-09 | 2018-02-09 | 清华大学 | 路由器及其数据平面信息的验证方法和验证装置 |
Also Published As
Publication number | Publication date |
---|---|
CN1223137C (zh) | 2005-10-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6427169B1 (en) | Parsing a packet header | |
US7159030B1 (en) | Associating a packet with a flow | |
US10243928B2 (en) | Detection of stale encryption policy by group members | |
US8245032B2 (en) | Method to authenticate packet payloads | |
US6728265B1 (en) | Controlling frame transmission | |
US8391485B2 (en) | Stealth message transmission in a network | |
CN111447276A (zh) | 一种具有密钥协商功能的加密续传方法 | |
WO2022099683A1 (zh) | 一种数据传输方法、装置、设备、系统及存储介质 | |
US20090113065A1 (en) | Integrity mechanism for file transfer in communications networks | |
CN112615820A (zh) | 重放攻击检测方法、装置、设备和存储介质 | |
CN1149787C (zh) | 在简单网络管理协议上增加用户安全验证的方法 | |
US20190132119A1 (en) | Method for exchanging messages between security-relevant devices | |
US7634655B2 (en) | Efficient hash table protection for data transport protocols | |
CN113905012A (zh) | 一种通信方法、装置、设备及介质 | |
CN1223137C (zh) | 验证数据安全传输的方法 | |
CN111193730B (zh) | 一种IoT可信场景构建方法及装置 | |
CN109617672B (zh) | 一种新型的灌装秘钥方法 | |
CN100596350C (zh) | 工业控制数据的加密解密方法 | |
CN101115055B (zh) | 通信网络中报告隧道数据包中各级错误的装置及方法 | |
US6968498B1 (en) | System and method for verifying validity of transmission data based on a numerical identifier for the data | |
EP1838038A1 (en) | Method for transfering network event protocol messages | |
US20210165870A1 (en) | Authentication system, electronic apparatus used in authentication system, and authentication method | |
CN112291270B (zh) | 一种数据传输方法及装置 | |
CN118413392B (zh) | 一种可信的指令传输系统 | |
US20220393856A1 (en) | Securely and reliably transmitting messages between network devices |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C17 | Cessation of patent right | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20051012 Termination date: 20110522 |