WO2012103720A1 - 维护llc层加解密参数的方法及装置 - Google Patents

维护llc层加解密参数的方法及装置 Download PDF

Info

Publication number
WO2012103720A1
WO2012103720A1 PCT/CN2011/076560 CN2011076560W WO2012103720A1 WO 2012103720 A1 WO2012103720 A1 WO 2012103720A1 CN 2011076560 W CN2011076560 W CN 2011076560W WO 2012103720 A1 WO2012103720 A1 WO 2012103720A1
Authority
WO
WIPO (PCT)
Prior art keywords
encryption
decryption
frame
ciphertext
parameter
Prior art date
Application number
PCT/CN2011/076560
Other languages
English (en)
French (fr)
Inventor
唐刚
王蓉
Original Assignee
华为技术有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN2011800010008A priority Critical patent/CN102301645A/zh
Priority to PCT/CN2011/076560 priority patent/WO2012103720A1/zh
Publication of WO2012103720A1 publication Critical patent/WO2012103720A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • the present invention relates to the field of information security, and in particular, to a method and apparatus for maintaining LLC layer encryption and decryption parameters. Background technique
  • the LLC (Logical Link Control) layer protocol is used for packet data transmission between LLC entities and is encrypted to ensure the reliability and confidentiality of data transmission.
  • ADM Asynchronous Di sconnected Mode
  • N (U) Unconfirmed Sequenc e number, unconfirmed sequence number
  • N (U) is the sequence number of the next UI frame to be sent, and the value range is 0.
  • N (U) is incremented by 1 each time a UI frame is successfully transmitted.
  • the sender encrypts the UI frame according to the encryption and decryption parameters agreed by both parties, and then sends the UI frame to the receiver according to the agreed encryption and decryption parameters; after receiving the encrypted UI frame, the receiver encrypts and decrypts according to the agreement The parameter is decrypted to get the UI frame.
  • the sender and the receiver update the encryption and decryption parameters agreed by the two parties, and then the sender and the receiver use the updated encryption and decryption parameters to perform the UI frame on the UI frame. Corresponding encryption and decryption operations.
  • Embodiments of the present invention provide a method and apparatus for maintaining LLC layer encryption and decryption parameters to avoid decryption failure caused by the receiver not updating the encryption and decryption parameters.
  • An embodiment of the present invention provides a method for maintaining an encryption and decryption parameter of an LLC layer, where the method includes: Decrypting the received non-confirmation information UI frame ciphertext by using the ith encryption and decryption parameter, the initial value of i is 1; when the ith ciphertext decryption parameter fails to decrypt the UI frame ciphertext, The i+1th encryption and decryption parameter is used as the current i-th encryption and decryption parameter, and returns to perform the operation of decrypting the received non-confirmation information UI frame ciphertext by using the ith encryption and decryption parameter until the UI is The frame ciphertext is decrypted successfully.
  • An apparatus for maintaining a LLC layer encryption and decryption parameter comprising: a first decryption module, a second decryption module, and an update module;
  • the first decryption module is configured to decrypt the received ciphertext by using the ith encryption and decryption parameter, and the initial value of i is 1;
  • the second decrypting module is configured to: when the ith encryption and decryption parameter is used to decrypt the received ciphertext, use the i+1th encryption and decryption parameter as the current i-th encryption and decryption parameter, and notify the The first decryption module performs an operation of decrypting the received ciphertext by using the ith encryption and decryption parameter until the ciphertext is successfully decrypted;
  • the update module is configured to update the used encryption and decryption parameters when the ciphertext is successfully decrypted.
  • the i+1th encryption and decryption parameter is decrypted as the current i-th encryption and decryption parameter, thereby avoiding receiving the received The problem that the UI frame ciphertext cannot be decrypted.
  • FIG. 1 is a flowchart of a method for maintaining a LLC layer encryption and decryption parameter according to Embodiment 1 of the present invention
  • FIG. 2 is a flowchart of a method for maintaining a LLC layer encryption and decryption parameter according to Embodiment 2 of the present invention
  • FIG. 3 is a flowchart of a method for maintaining a LLC layer encryption and decryption parameter provided in Embodiment 3 of the present invention
  • FIG. 4 is a block diagram of an apparatus for maintaining LLC layer encryption and decryption parameters provided in Embodiment 4 of the present invention. detailed description
  • Example 1 Referring to FIG. 1, a method for maintaining an encryption and decryption parameter of an LLC layer, the execution body of the method includes but is not limited to an MS (Mobi stat, Mobile Device) and a Serving General Packet Radio Service Support Node (SGMS). Support nodes) and other devices, the specific steps are as follows:
  • Step 101 Decrypt the received UI message ciphertext by using the i-th encryption and decryption parameter, and the initial value of i is 1;
  • Step 102 When the ic text of the UI frame fails to be decrypted by using the ith encryption and decryption parameter, the i+1th encryption and decryption parameter is used as the current ith encryption and decryption parameter, and the ith encryption and decryption parameter is used for receiving.
  • the non-confirmation information UI frame ciphertext is decrypted until the decryption of the UI frame ciphertext is successful;
  • the i+1th encryption and decryption parameter is obtained by adding 512 to the i-th encryption and decryption parameter.
  • the method may further include: updating the adopted i encryption and decryption parameters.
  • updating the used i encryption and decryption parameters includes: adding the ith encryption and decryption parameter to the 512*j to obtain the updated i-th encryption and decryption parameter, j Equal to i_l.
  • the method further includes: when the ic message is successfully decrypted by using the ith encryption and decryption parameter, determining whether the unconfirmed sequence number of the decrypted UI frame is 511, and if yes, the ith The value of the encryption and decryption parameter is 512.
  • the receiver locally stores an encryption and decryption parameter, and then, in order to ensure that the encryption and decryption parameters maintained by the receiver are consistent with the encryption and decryption parameters of the sender, the user can decrypt the ciphertext of the UI frame.
  • the embodiment of the present invention provides a method for a receiver to maintain an encryption and decryption parameter of an LLC layer, where the receiver and the sender include but are not limited to an MS (Mobi station, mobile device) or an SGSN (Serving General Packet Radio Service) Support Node, packet wireless service support node) and other devices, the specific steps are as follows:
  • Step 201 The sender encrypts the UI frame to be sent by using the currently stored encryption and decryption parameter 0C, and sends the encrypted UI frame ciphertext to the receiver.
  • the sender sends an N (U) (Unconfirmed sequence number) when transmitting the UI frame, and N (U) is the sequence number of the UI frame to be sent next, and the value range is 0.
  • N (U) is incremented by 1.
  • N ( U) When the value of N ( U) reaches 511, it will start from 0 again, that is, N ( U) will cycle between 0 and 51 1 .
  • the sender will update the locally maintained 0C. Specifically, the sender will add 512 to the locally stored 0C to get the updated 0C. After that, send The party uses the updated 0C to encrypt the UI frame to be sent;
  • the above process is illustrated by way of example:
  • the initial value of 0C stored by the sender is a, then the sender adopts the value a.
  • 0C encrypts the first round of N (U) UI frames with values from 0 to 511, and sends each encrypted ciphertext to the receiver.
  • the sender sets the UI frame with N (U) value of 511
  • the value of 0C is updated to a+512 ; after that, the sender uses the 0C with the value a+512 to respectively perform the second round of N (U) values of UI frames of 0 to 511.
  • Encrypting, and sending the encrypted ciphertext to the receiver and when the sender encrypts the UI frame with the N (U) value of 511 in the second round with 0C encrypted to a+512, the value of 0C is updated. It is a+512+512 ; after that, the sender uses the 0C with the value a+512+512 to encrypt the UI frame with the value 0 to 511 in the third round, and so on.
  • Step 202 When receiving the ciphertext of the UI frame, the receiver decrypts the received UI frame ciphertext by using the currently stored encryption and decryption parameters.
  • the receiver decrypts the received ciphertext by using the locally stored encryption and decryption parameter 0C1 to obtain a UI frame.
  • the receiver updates the stored 0C1. Specifically, the receiver adds 512 to the locally stored 0C1, and then the receiver decrypts the received ciphertext by using the updated 0C1, where the initial value of the encryption and decryption parameter locally stored by the receiver is locally related to the sender.
  • the stored encryption and decryption parameters have the same initial values.
  • the above process is exemplified.
  • the initial value of 0C1 stored by the receiver is the same as the initial value of the 0C stored by the sender, and the receiver adopts the 0C1 pair with the value a to receive the first round of N (U).
  • the ciphertext of the UI frame is decrypted.
  • the value of 0C1 is updated to a+512; after that, the received second is received by the 0C1 pair with the value a+512.
  • the ciphertext of the round UI frame is decrypted.
  • the sender adopts 0C values of a, a+512 and a+512+512 for the first round, the second round and the third round N (U) respectively.
  • the UI frame with a value of 0 to 511 is encrypted, and the ciphertext is sequentially sent to the receiver; the receiver adopts 0C1 with the values a, a+512, and a+512+512 for the first round, the second round, and the third.
  • the ciphertext of the round UI frame is decrypted to obtain the corresponding UI frame. Since the values of the encryption and decryption parameters used by both parties are consistent, the receiver must decrypt the received ciphertext successfully.
  • step 202 When the receiver decrypts the received ciphertext of the first round of UI frames by using 0C1 with a value of a, the final decryption does not obtain a UI frame with N (U) of 511. , the receiver is not on 0C1 Update, that is, the value of 0C1 is still a; the reason why the receiver can not decrypt the UI frame with N ( U) 511 may be: The receiver did not receive the sender's sent because of the unstable network link and other factors. In the first round, N (U) is the ciphertext of the 511 UI frame.
  • the receiver must not decrypt the UI frame whose N ( U) is 511 in the first round; after that, the receiver is When receiving the ciphertext of the second round of the UI frame, the ciphertext of the second round of the UI frame is decrypted by using 0C1 with the value a, and the sender sends the ciphertext encrypted by the 0C with the value of a+512. If the second round of N ( U) is a ciphertext of a UI frame of 0 to 511, the receiver must use the 0C1 with a value of a to decrypt the ciphertext of the received second round of the UI frame, and then the receiver fails.
  • the receiver decrypts the ciphertext of the UI frame whose value is 0 to 511 in the first round of N (U) sent by the sender using 0C1 with a value of a, and finally decrypts the obtained N (U) to 511.
  • UI frame then update 0C1 to a+512; after that, the ciphertext received the second round of N (U) UI frame is decrypted by 0C1 with the value of a+512, and the decryption succeeds, but in the current round of decryption process
  • the UI frame with the N ( U) value of 511 is not decrypted, then 0C1 is not updated, that is, the value of 0C1 is a+512; when the receiver receives the value sent by the sender, the value is a+512+512.
  • the third round of N (U) obtained by 0C encryption is a ciphertext of a UI frame of 0 to 511
  • the ciphertext cannot be decrypted; after that, since NC1 is not decrypted in the second round, the N (U) value is 511.
  • the UI frame causes 0C1 to fail to coincide with the sender's 0C in the subsequent process, causing the subsequent decryption process to end in failure.
  • the receiver can perform the following operations as follows:
  • Step 203 The receiver determines whether the decrypted UI frame ciphertext is successful.
  • step 204 If not, perform step 204;
  • step 205 If successful, perform step 205;
  • Step 204 The receiver adds the currently stored encryption and decryption parameter to 512 as the current new encryption and decryption parameter, and returns to step 203, until the decrypted ciphertext is successfully decrypted, and step 205 is performed;
  • step 202 From the description of step 202, it can be known that when the receiver receives the second round of N (U) sent by the sender, the ciphertext of the UI frame from 0 to 511 is received.
  • the 0C1 with the current value of a+512 is used to decrypt the UI frame ciphertext successfully, but when the UI frame with the N (U) value of 511 is not decrypted, the 0C1 with the value a+512 is not updated; then, when receiving The third round of N ( U) sent by the sender is from 0 to 511.
  • the UI frame ciphertext received by this round is decrypted by 0C1 with the value of a+512, then the decryption of the UI frame ciphertext will fail, because the third round of N(U) values from 0 to
  • the ciphertext of the UI frame of 511 is obtained by transmitting 0C encrypted with the value of a+512+512; the receiver adds 512 with the current value of a+512 to get the current new value a+512+512.
  • 0C1 using the current new 0C1 to decrypt the ciphertext of the third round of UI frames received at this time, the decryption of the ciphertext is successful.
  • Step 205 The receiver determines whether the N (U) number of the UI frame obtained after decrypting the UI frame ciphertext is 511, and if yes, adds the value of the current encryption and decryption parameter to 512;
  • the sender will encrypt the third round of N (U) values from 0 to 511 with 0C with a value of a + 512 + 512, and after encrypting the UI frame with N (U) 511, Update the 0C value to a+512+512+512. After that, the fourth round of UI frame is encrypted with 0C with the value of a+512+512+512. Then, the receiver adopts the value of a+512+512.
  • the receiver After 0C1 decrypts the ciphertext of the third round of UI frames sent by the sender, in order to ensure that the ciphertext of the fourth round of the N (U) UI frame sent by the sender can be successfully decrypted, the receiver obtains the decryption.
  • the current decryption 0C1 is updated by 512, so that the 0C and 0C1 maintained by the receiver and the sender respectively are consistent.
  • the receiver after receiving the ciphertext of the UI frame with the N (U) of 511, the receiver can still obtain the encryption and decryption parameters maintained by the local device and the encryption and decryption parameters maintained by the receiver. The values are consistent, and the situation in which the receiver cannot decrypt the UI frame ciphertext is avoided.
  • Example 3
  • the receiver locally stores N encryption and decryption parameters, where N is an integer greater than or equal to 2, wherein the i+1th encryption and decryption parameter is obtained by adding 512 to the ith encryption and decryption parameter.
  • i is an integer greater than or equal to 1 and less than or equal to N.
  • the initial value of the first encryption/decryption parameter is the same as the initial value of the encryption and decryption parameter maintained by the sender, and the initial value is obtained in advance by both parties.
  • the value of the i-th encryption-decryption parameter saved by the receiver is a+512* (i_l);
  • the embodiment of the present invention provides a method for the receiver to maintain the LLC layer encryption and decryption parameters, where the receiver and the sender include but not It is limited to devices such as the MS (Mobile station) and the SGSN (Serving General Packet Radio Service Support Node). The specific steps are as follows:
  • Step 301 The sender encrypts the UI frame to be sent by using the locally stored encryption and decryption parameter 0C, and sends the encrypted UI frame ciphertext to the receiver.
  • the sender encrypts the UI frame to be sent by using the locally stored encryption and decryption parameter 0C, and sends the encrypted UI frame ciphertext to the receiver.
  • Step 302 When receiving the ciphertext of the UI frame, the receiver decrypts the received ciphertext by using the currently stored ith encryption and decryption parameter.
  • step 202 For a detailed description of this step, refer to step 202 in Embodiment 2, and details are not described herein again.
  • Step 303 The receiver determines whether the received ciphertext is successfully decrypted by using the i-th encryption and decryption parameter, and the initial value of i is 1.
  • step 304 If it is not successful, go to step 304;
  • step 306 If successful, performing step 306;
  • Step 304 The receiver uses the stored i+1th encryption and decryption parameter as the current i-th encryption and decryption parameter, and returns to step 303, until the decryption of the UI frame ciphertext is successful, step 305 is performed;
  • Step 305 The receiver updates the local encryption and decryption parameters stored in step 306;
  • Step 306 The receiver determines whether the N (U) number of the UI frame obtained after the decryption of the ciphertext is successful is 511. If yes, the current N encryption and decryption parameters are all added 512 to obtain the updated N encryption and decryption parameters; If not, do nothing;
  • the process described in the above steps 303 to 306 is exemplified: when the receiver receives the ciphertext of the first round of UI frames encrypted by the 0C encrypted by the sender, the first value of the current value is a.
  • the encryption and decryption parameters 0C1 decrypt the ciphertext and succeed, but the UI frame with the N(U) value of 511 is not decrypted, and the saved value is 0C1 of a and the ith of the value a+512*(i-1)
  • the encryption and decryption parameters are not updated; then, when the receiver receives the ciphertext sent by the sender with the second round of UI frames encrypted by the value a+512, the first encryption and decryption parameter 0C1 with the value a is decrypted.
  • the UI ciphertext is successfully decrypted by using the second encryption/decryption parameter 0C2 with the value of a+512.
  • the 0C1 with the value a is updated to a+512, and the value is a+512* (i- 1)
  • the obtained N encryption and decryption parameters are respectively added to 512 to obtain the updated N encryption and decryption parameters respectively;
  • the receiver After receiving the UI frame ciphertext sent by the sender, the receiver decrypts the received ciphertext by using the first encryption and decryption parameter obtained by the current update. If the ciphertext is unsuccessful, the next update obtained by the current update is used. The decryption parameter decrypts the received ciphertext until the ciphertext of the UI frame is successfully decrypted, and the current N encryption and decryption parameters are updated again by the methods of steps 305 to 306 above, and so on.
  • the receiver receives the ciphertext of the UI frame whose value is 0 to 511 in the first round of N (U) encrypted by the encryption and decryption parameter 0C of the sender with a value of 0, where N (U) is a UI frame of 511
  • N (U) is a UI frame of 511
  • the ciphertext is lost during transmission due to unstable factors of the network link;
  • the receiving party receives the ciphertext of the second round of UI frame encrypted by the sender using the encryption and decryption parameter 0C with a value of 512, and decrypts the received ciphertext with 0C1 with a value of 0, then the decryption necessarily fails, then, If the encryption and decryption parameters with a value of 512 are used for decryption, the decryption is successful. After that, the value of 0C1 is updated to 512, and the value of 0C2 is updated to 512+512.
  • the receiver determines whether the N (U) value of the UI frame obtained by the 0C2 decryption is 511. If yes, the receiver has received all the ciphertexts of the UI frame whose value is 0 to 511 in the second round. After decryption, update 0C1 to 512+512, 0C2 to 512+512+512;
  • the receiver receives the ciphertext of the UI frame with the value of 0 to 511 in the third round of N (U) encrypted by the encryption and decryption parameter 0C, which is sent by the sender with the value of 512+512, and then uses the updated ciphertext.
  • the 0C1 decryption UI frame cipher with a value of 512+512 succeeds, and when the UI frame with N (U) 511 is decrypted, 0C1 and 0C2 are respectively added with 512 for updating;
  • the receiver When the receiver receives the ciphertext of the fourth round of UI frame encrypted by the encryption and decryption parameter 0C with the value of 512+512+512 sent by the sender, the 0C1 decryption reception with the value of 512+512 obtained by the current update is received. The UI frame ciphertext will fail. Then, the current update will be decrypted by 0C2 with the value of 512+512+512. The decryption will succeed. At this time, the value of 0C1 is updated to 512+512+512 again, 0C2. The value is updated to 512+512+512+512 to ensure that the receiver can still decrypt the UI frame ciphertext successfully after the UI frame with the N (U) value of 511 is not received again.
  • the receiving party when the receiving party continuously receives the ciphertext of the UI frame, the receiving party uses neither 0C1 nor 0C2.
  • the method guarantees the success of decrypting the ciphertext of the subsequently received UI frame after receiving the ciphertext of the UI frame with the N (U) of 0 to 511 twice in succession; normally, a large number of UIs are continuously lost in the LLC layer.
  • the probability of the ciphertext of the frame is extremely low, and the receiver can basically guarantee the success of decrypting the received ciphertext by maintaining two encryption and decryption parameters.
  • the receiver can maintain three or more encryption and decryption parameters to ensure the success of decrypting the received ciphertext.
  • the method for the receiver to maintain three or more encryption and decryption parameters is the same as the method for maintaining the two encryption and decryption parameters.
  • the following describes the specific maintenance process by taking the case where the receiver maintains three encryption and decryption parameters as an example:
  • 0C1 decryption fails, use 0C2 for decryption.
  • any one of the encryption and decryption parameters of the maintenance is obtained by adding 512 to the previous encryption and decryption parameter. Then, each time the receiver receives the ciphertext of the UI frame, it first tries to decrypt using the first encryption and decryption parameter. When the first encryption and decryption parameter fails, the next encryption and decryption parameter is used for decryption until the reception is received. When the ciphertext of the UI frame is successfully decrypted, all the encryption and decryption parameters that are maintained are updated.
  • the received ciphertext of the received UI frame is decrypted by maintaining two or more encryption and decryption parameters, so that the ciphertext of the received UI frame can be successfully decrypted when the UI frame is continuously lost.
  • the receiving party can still enable the locally maintained encryption and decryption in the case that the ciphertext of the UI frame with N (U) of 511 is not received and the ciphertext of a large number of UI frames is continuously lost.
  • the parameter is consistent with the value of the encryption and decryption parameters maintained by the receiver, and avoids the situation where the receiver cannot decrypt the UI frame ciphertext.
  • an apparatus for maintaining a LLC layer encryption and decryption parameter is specifically matched with an execution body in a method embodiment, and includes: a first decryption module 401 and a second decryption module 402.
  • the first decryption module 401 is configured to decrypt the received ciphertext by using the ith encryption and decryption parameter, and the initial value of i is 1;
  • a second decryption module 402 configured to: when the ciphertext is decrypted by using the ith encryption and decryption parameter, The i+1 encryption and decryption parameters are used as the current i-th encryption and decryption parameter, and the first decryption module is notified to perform the operation of decrypting the received ciphertext by using the ith encryption and decryption parameter until the ciphertext is successfully decrypted;
  • the i+1th encryption and decryption parameter is obtained by adding 512 to the i-th encryption and decryption parameter.
  • the apparatus may further include: an update module, configured to: when the second decryption module successfully decrypts the ciphertext, update the used encryption and decryption parameters.
  • the updating module is configured to add the ith cryptographic parameter to the ith 512*j to obtain the updated ith cryptographic parameter, and j is equal to i_l.
  • the device further includes: an execution module, configured to determine, when the ic message of the received UI frame is successfully decrypted by using the ith encryption and decryption parameter, whether the unconfirmed serial number of the decrypted UI frame is 511, and if yes, the The value of the i encryption and decryption parameters is 512.
  • the receiver can still enable the locally maintained encryption and decryption in the case that the ciphertext of the UI frame with N (U) of 511 is not received and the ciphertext of a large number of UI frames is continuously lost.
  • the parameter is consistent with the value of the encryption and decryption parameters maintained by the receiver, and avoids the situation where the receiver cannot decrypt the UI frame ciphertext.
  • a person skilled in the art may understand that all or part of the steps of implementing the above embodiments may be completed by hardware, or may be instructed by a program to execute related hardware, and the program may be stored in a computer readable storage medium.
  • the storage medium mentioned may be a read only memory, a magnetic disk or an optical disk or the like. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., which are within the spirit and scope of the present invention, should be included in the protection of the present invention. Within the scope.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种维护加解密参数的方法及装置，属于信息安全领域。方法包括：采用第i个加解密参数对接收到的非确认信息UI帧密文进行解密，i的初始值为1；当采用所述第i个加解密参数对所述UI帧密文解密失败时，将第i+1个加解密参数作为当前的第i个加解密参数，返回执行所述采用第i个加解密参数对接收到的非确认信息UI帧密文进行解密的操作，直到对所述UI帧密文解密成功。通过上述技术方案的实现，避免了对密文无法解密的问题。

Description

维护 LLC层加解密参数的方法及装置 技术领域
本发明涉及信息安全领域， 特别涉及一种维护 LLC层加解密参数的方法及装置。 背景技术
LLC (Logical Link Control ,说逻辑链路控制）层协议用于 LLC 实体之间进行分组数据 的传输， 并通过加密来保证数据传输的可靠性和机密性。
LLC在 ADM (Asynchronous Di sconnected Mode , 异步非连接模式） 模式下， 使用 UI
( Unconfirmed Informat ion frames , 非确认信息） 帧进行分组数据的传输。 发送方在发 送 UI帧时对应发送一个 N (U) ( Unconfirmed sequenc书e number, 非确认序列号），其中， N (U) 为下一次要发送的 UI帧的序列号， 取值范围是 0到 511， 每当一 UI帧成功发送后， N (U) 就加 1。
那么， 为了保证 UI帧传输的可靠性和机密性， 发送方将 UI帧按照双方约定的加解密 参数加密后发送给接收方； 接收方接收到加密后的 UI帧后， 根据双方约定的加解密参数解 密得到 UI帧。
其中， 当 UI帧中的 N ( U)值由 511翻转为 0时， 发送方和接收方更新双方约定的加解 密参数， 之后， 发送方和接收方采用更新后的加解密参数对 UI帧进行相应的加密和解密操 作。
由上所述， 接收方必须要正确接收到 N (U) =511的 UI帧后才能对加解密参数进行更新。 那么， 接收方因为一些因素 （如 N (U) =511 的 UI帧在发送过程中丢失） 而无法接收到 发送方所发送的 N ( U) =511 的 UI帧， 即发送方在对加解密参数进行更新后， 接收方并未 对加解密参数进行相应的更新。 之后， 在新收到的发送方使用更新后的加解密参数加密后 的 UI帧时， 将使用未更新的加解密参数对接收到的加密后的 UI帧进行解密， 解密必将失 败， 并且不可恢复。 发明内容
本发明实施例提供了一种维护 LLC层加解密参数的方法及装置， 以避免由于接收方没 有对加解密参数进行更新导致的解密失败。
本发明实施例提供一种维护 LLC层加解密参数的方法， 所述方法包括： 采用第 i个加解密参数对接收到的非确认信息 UI帧密文进行解密， i的初始值为 1 ; 当采用所述第 i个加解密参数对所述 UI帧密文解密失败时， 将第 i+1个加解密参数作 为当前的第 i个加解密参数， 返回执行所述采用第 i个加解密参数对接收到的非确认信息 UI帧密文进行解密的操作， 直到对所述 UI帧密文解密成功；
当对所述 UI帧密文解密成功时， 将采用的 i个加解密参数进行更新。
一种维护 LLC层加解密参数的装置， 所述装置包括： 第一解密模块、 第二解密模块和 更新模块；
所述第一解密模块， 用于采用第 i个加解密参数对接收到的密文进行解密， i的初始值 为 1 ;
所述第二解密模块， 用于当采用所述第 i 个加解密参数对接收到的密文解密失败时， 将第 i+1个加解密参数作为当前的第 i个加解密参数，通知所述第一解密模块执行采用第 i 个加解密参数对接收到的密文进行解密的操作， 直到对所述密文解密成功；
所述更新模块， 用于当对所述密文解密成功时， 将采用的 i个加解密参数进行更新。 本发明实施例在采用第 i个加解密参数对接收到的密文解密失败时， 将第 i+1个加解 密参数作为当前的第 i个加解密参数进行解密操作， 避免了对接收到的 UI帧密文无法解密 的问题。 附图说明
为了更清楚地说明本发明实施例中的技术方案， 下面将对实施例描述中所需要使用的 附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本发明的一些实施例， 对于本 领域普通技术人员来讲， 在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的 附图。
图 1是本发明实施例 1中提供的一种维护 LLC层加解密参数的方法流程图;
图 2是本发明实施例 2中提供的一种维护 LLC层加解密参数的方法流程图;
图 3是本发明实施例 3中提供的一种维护 LLC层加解密参数的方法流程图;
图 4是本发明实施例 4中提供的一种维护 LLC层加解密参数的装置框图。 具体实施方式
为使本发明的目的、 技术方案和优点更加清楚， 下面将结合附图对本发明实施方式作 进一步地详细描述。
实施例 1 参见图 1， 一种维护 LLC 层加解密参数的方法， 该方法的执行主体包括但不限于 MS ( Mobi le stat ion, 移动设备) 禾口 SGSN ( Serving General packet Radio Service Support Node , 分组无线业务服务支持节点） 等设备， 具体步骤如下：
步骤 101 : 采用第 i个加解密参数对接收到的非确认信息 UI帧密文进行解密， i的初 始值为 1 ;
步骤 102 : 当采用第 i个加解密参数对 UI帧密文解密失败时， 将第 i+1个加解密参数 作为当前的第 i个加解密参数， 返回执行采用第 i个加解密参数对接收到的非确认信息 UI 帧密文进行解密的操作， 直到对 UI帧密文解密成功；
其中， 第 i+1个加解密参数是由第 i个加解密参数加 512得到的。
需要说明的是， 当采用第 i个加解密参数对 UI帧密文解密失败时， 将第 i+1个加解密 参数作为当前的第 i个加解密参数， 返回执行采用第 i个加解密参数对接收到的非确认信 息 UI帧密文进行解密的操作， 直到对 UI帧密文解密成功之后， 该方法还可以包括： 将采 用的 i个加解密参数进行更新。
具体地， 当对 UI帧密文解密成功时， 将采用的 i个加解密参数进行更新包括： 将第 i个加解密参数加上 512*j后得到更新后的第 i个加解密参数， j等于 i_l。
另外， 该方法还包括： 当采用第 i个加解密参数对接收到的 UI帧密文解密成功时， 判 断解密得到的 UI帧的非确认序列号是否为 511， 如果是， 则将第 i个加解密参数的值加上 512。
通过本发明实施例所提供的技术方案的实现， 避免了对接收到的 UI帧密文无法解密的 问题。 实施例 2
参见图 2， 本发明实施例中接收方本地保存一个加解密参数， 那么， 为了保证接收方所 维护的加解密参数与发送方的加解密参数相一致， 而使得自身可以解密 UI帧的密文成功， 本发明实施例提供了一种接收方维护 LLC层加解密参数的方法， 其中， 接收方和发送方包 括但不限于 MS ( Mobi le stat ion,移动设备）或 SGSN( Serving General packet Radio Service Support Node , 分组无线业务服务支持节点） 等设备， 具体步骤如下：
步骤 201 : 发送方采用当前存储的加解密参数 0C对所要发送的 UI帧进行加密， 并将加 密得到的 UI帧密文发送给接收方；
具体地， 发送方在发送 UI帧时将对应发送一个 N (U) ( Unconfirmed sequence number, 非确认序列号）， N (U)为下一次要发送的 UI帧的序列号， 取值范围是 0到 511， 每当一 UI 帧成功发送后， N (U)就加 1， 当 N ( U) 的取值达到 511后， 将再次从 0开始取值， 即 N ( U) 在 0到 51 1之间循环取值。 而每当 N ( U) 的取值从 511变为 0时， 发送方将更新本地所维 护的 0C， 具体地， 发送方将将本地存储的 0C加上 512得到更新后的 0C; 之后， 发送方采 用更新后的 0C对所要发送的 UI帧进行加密；
现举例说明上述过程： 发送方本地所存储 0C的初始值为 a， 则， 发送方采用值为 a的
0C分别将第一轮 N ( U) 取值为 0到 511的 UI帧进行加密， 并将加密得到的各密文分别发 送给接收方， 当发送方将 N ( U)值为 511的 UI帧采用值为 a的 0C加密后， 将 0C的值更新 为 a+512 ; 之后， 发送方采用值为 a+512的 0C分别将第二轮 N ( U) 取值为 0到 511的 UI 帧进行加密， 并将加密得到的各密文发送给接收方， 而当发送方将第二轮中 N ( U)值为 511 的 UI帧采用值为 a+512的 0C加密后， 将 0C的值更新为 a+512+512 ; 之后， 发送方采用值 为 a+512+512的 0C分别对第三轮取值为 0到 511的 UI帧进行加密， 依次类推。
步骤 202 : 接收方接收到 UI帧的密文时， 采用当前存储的加解密参数对接收到的 UI帧 密文进行解密；
具体地， 接收方采用本地存储的加解密参数 0C1对接收到的密文进行解密得到 UI帧， 当解密得到的 UI帧的 N ( U)取值为 511时， 接收方将存储的 0C1进行更新， 具体地， 接收 方将本地存储的 0C1加上 512， 之后， 接收方采用更新后的 0C1对接收到的密文进行解密， 其中， 接收方本地存储的加解密参数的初始值与发送方本地存储的加解密参数的初始值相 同。
现举例说明上述过程，接收方存储的 0C1的初始值与发送方所存储的 0C的初始值一样， 均为 a， 则接收方采用值为 a的 0C1对接收到的第一轮 N ( U) UI帧的密文进行解密， 当解 密密文得到 N ( U) 为 511的 UI帧时， 将 0C1的值更新为 a+512 ; 之后， 采用值为 a+512的 0C1对接收到的第二轮 UI帧的密文进行解密， 当解密密文得到 N ( U) 为 511的 UI帧时， 将 0C1的值更新为 a+515+512 ; 之后采用值为 a+512+512的 0C1对接收到的第三轮 UI帧的 密文进行解密， 以此类推。
由步骤 201和步骤 202 中的举例的描述可以知道： 发送方分别采用值为 a、 a+512和 a+512+512的 0C对第一轮、 第二轮和第三轮 N ( U) 取值为 0到 511的 UI帧进行加密， 并 将密文依次发送给接收方； 接收方采用值为 a、 a+512和 a+512+512的 0C1对第一轮、 第二 轮和第三轮 UI帧的密文进行解密得到相应的 UI帧。 由于双方所采用的加解密参数的值一 致， 则接收方必然会对接收到的密文解密成功。
但是， 由步骤 202中的举例可以知道： 当接收方在采用值为 a的 0C1对接收到的第一 轮 UI帧的密文进行解密时， 最终解密未得到 N ( U) 为 511的 UI帧， 则接收方并不对 0C1 进行更新， 即 0C1的值仍然为 a; 接收方之所以解密不到 N ( U) 为 511的 UI帧的原因可能 为： 接收方因为网络链路不稳定等因素未接收到发送方所发送的第一轮中 N (U) 为 511的 UI帧的密文， 那么， 在这种情况下， 接收方必然解密不到第一轮中 N ( U) 为 511的 UI帧； 之后， 接收方在接收第二轮 UI帧的密文时， 采用值为 a的 0C1对第二轮 UI帧的密文进行 解密， 由于发送方发送的是采用值为 a+512的 0C对 UI帧加密得到的第二轮 N ( U) 取值为 0到 511的 UI帧的密文，则接收方采用值为 a的 0C1对接收到的第二轮 UI帧的密文解密时 必然失败； 之后， 接收方由于本次未解密出 N ( U) 值为 511的 UI帧而使 0C1与发送方的 0C的更新不再同步， 将导致接收方对以后接收到的 UI帧的密文都将无法成功解密。
另外， 接收方在采用值为 a的 0C1对发送方发送的第一轮 N ( U) 取值为 0到 511的 UI 帧的密文进行解密， 并最终解密得到的 N ( U) 为 511的 UI帧， 则将 0C1更新为 a+512 ; 之 后， 采用值为 a+512的 0C1对接收到第二轮 N ( U) UI帧的密文进行解密， 并解密成功， 但 在本轮解密过程中未解密得到 N ( U) 值为 511的 UI帧， 那么， 0C1不做更新处理， 即 0C1 的值为 a+512 ; 当接收方接收到发送方所发送的以值为 a+512+512的 0C加密得到的第三轮 N (U) 取值 0到 511的 UI帧的密文时， 将无法解密密文； 之后， 由于 0C1在第二轮中未解 密出 N ( U) 值为 511的 UI帧而导致 0C1在之后的过程中无法与发送方的 0C—致， 从而导 致后续的解密过程以失败而告终。
由上述的描述可以知道， 一旦接收方在解密发送方所发送的各轮 N ( U) 值为 0到 511 的 UI帧的密文， 并出现解密其中一轮 UI帧的密文而得不到 N ( U)值为 511的 UI帧时， 都 将导致接收方所存储的 0C1无法与发送方的 0C得到同步的更新，而使接收方在后续解密 UI 帧密文时解密失败。
那么， 为了避免上述接收方无法对接收到的密文进行解密的情况， 接收方可以执行如 如下的操作：
步骤 203 : 接收方判断解密所接收到的 UI帧密文是否成功，
如果不成功， 执行步骤 204;
如果成功， 执行步骤 205 ;
步骤 204: 接收方将当前存储的加解密参数加上 512之后作为当前新的加解密参数， 返 回执行步骤 203， 直到解密接收到的密文成功， 执行步骤 205 ;
现举例说明上述步骤 203和 204所描述的过程： 由步骤 202的描述可以知道， 当接收 方在接收到发送方发送的第二轮 N ( U)取值从 0到 511的 UI帧的密文，采用当前值为 a+512 的 0C1进行解密 UI帧密文并成功， 但未解密得到 N ( U) 值为 511的 UI帧时， 值为 a+512 的 0C1不进行更新； 那么， 当接收方接收到发送方发送的第三轮 N ( U) 取值从 0到 511的 UI帧的密文， 则采用值为 a+512的 0C1解密此轮接收到的 UI帧密文， 那么解密 UI帧密文 将失败，这是由于第三轮 N(U)取值从 0到 511的 UI帧的密文是由发送发使用值为 a+512+512 的 0C加密得到的； 接收方将当前值为 a+512的 0C1加上 512得到当前新的值为 a+512+512 的 0C1， 采用当前新的 0C1对此时接收到的第三轮 UI帧的密文进行解密， 则解密密文成功。
步骤 205: 接收方判断解密 UI帧密文成功后得到的 UI帧的 N (U) 号是否为 511， 如果是， 则将当前的加解密参数的值加上 512;
如果不是， 不做任何操作；
例如， 发送方将采用值为 a+512+512的 0C将第三轮 N (U) 取值从 0到 511的 UI帧进 行加密， 并在对 N (U) 为 511的 UI帧加密后， 将 0C值更新为 a+512+512+512， 之后， 采 用值为 a+512+512+512的 0C对第四轮 UI帧进行加密， 那么， 接收方在采用值为 a+512+512 的 0C1对发送方所发送的第三轮 UI帧的密文进行解密后， 为了保证在接收到发送方所发送 的第四轮 N (U) UI帧的密文能够解密成功， 接收方在解密得到第三轮中 N (U)值为 511的 UI帧时， 将当前解密用的 0C1加上 512进行更新， 以使得， 接收方和发送方所分别维护的 0C和 0C1相一致。
通过上述技术方案的实现， 使得接收方在未接收到的 N (U) 为 511的 UI帧的密文后， 依然能够使得本地所维护的加解密参数与接收方所维护的加解密参数的取值相一致， 而避 免接收方无法解密 UI帧密文的情况出现。 实施例 3
参见图 3， 本发明实施例中接收方本地保存 N个加解密参数， N为大于等于 2的整数， 其中， 第 i+1个加解密参数为第 i个加解密参数加上 512得到的， i为大于等于 1小于等于 N的整数， 第 1个加解密参数的初始取值与发送方所维护的加解密参数的初始值相同， 该初 始值由双方预先协商得到。
例如， 接收方保存的第一个加解密参数 0C1的初始值为 a， 则接收方保存的第 i个加解 密参数的值为 a+512* (i_l)；
那么， 为了保证接收方所维护的加解密参数可以解密 UI帧的密文成功， 本发明实施例 提供了一种接收方维护 LLC层加解密参数的方法， 其中， 接收方和发送方包括但不限于 MS (Mobile station, 移动设备) 禾口 SGSN (Serving General packet Radio Service Support Node, 分组无线业务服务支持节点） 等设备， 具体步骤如下：
步骤 301 : 发送方采用本地存储的加解密参数 0C对所要发送的 UI帧进行加密， 并将加 密得到的 UI帧密文发送给接收方； 有关本步骤的详细描述请参见实施例 2中的步骤 201， 此处就不再赘述。
步骤 302 : 接收方接收到 UI帧的密文时， 采用当前存储的第 i个加解密参数对接收到 的密文进行解密；
有关本步骤的详细描述请参见实施例 2中的步骤 202， 此处就不再赘述。
步骤 303: 接收方判断采用第 i个加解密参数解密所接收到的密文是否成功， i的初始 值为 1，
如果不成功， 执行步骤 304;
如果成功， 执行步骤 306;
步骤 304: 接收方采用存储的第 i+1个加解密参数作为当前的第 i个加解密参数， 返回 执行步骤 303， 直到解密 UI帧密文成功， 执行步骤 305;
步骤 305: 接收方将本地所存储的 i个加解密参数进行更新， 执行步骤 306;
具体地， 将本地存储的 i个加解密参数更新包括， 将第 i个加解密参数加上 512*j后 得到更新后的第 i个加解密参数， 其中， j=i_l ;
步骤 306: 接收方判断解密密文成功后得到的 UI帧的 N (U) 号是否为 511， 如果是， 将当前的 N个加解密参数均加上 512得到更新后的 N个加解密参数； 如果不是， 不做任何操作；
现举例说明上述步骤 303至 306所描述的过程： 当接收方在接收到发送方发送的以值 为 a的 0C加密得到的第一轮 UI帧的密文时， 采用当前值为 a的第 1个加解密参数 0C1解 密密文并成功，但未解密得到 N(U)值为 511的 UI帧，则保存的值为 a的 0C1和值为 a+512* ( i-1 )的第 i个加解密参数不进行更新；那么， 当接收方接收到发送方发送的以值为 a+512 加密得到的第二轮 UI帧的密文时， 采用值为 a的第一个加解密参数 0C1解密 UI帧密文失 败， 则采用值为 a+512的第二个加解密参数 0C2解密 UI帧密文成功， 则将值为 a的 0C1更 新为 a+512， 值为 a+512* ( i-1 ) 的 OCi更新为 a+512* ( i-1 ) +512*j， j=i_l ; 判断解密密 文成功后得到的 UI帧的 N (U) 是否为 511， 如果是， 则将上述更新后得到的 N个加解密参 数分别加上 512再次得到更新后的 N个加解密参数；
之后， 接收方在接收到发送方发送的 UI帧密文后， 采用当前更新得到的第一个加解密 参数对接收到的密文进行解密， 不成功时， 则采用当前更新得到的下一个加解密参数对接 收到的密文进行解密， 直到对 UI帧密文解密成功， 并再次采用上述步骤 305至 306的方法 对当前的 N个加解密参数进行更新， 以此类推。
下面以接收方保存两个加解密参数为例来详细说明上述流程：
接收方本地保存两个加解密参数 0C1和 0C2， 且 0C1=0， 0C2=512; 接收方接收到发送方采用值为 0的加解密参数 0C加密得到的第一轮 N (U)取值为 0到 511的 UI帧的密文， 其中， N (U)为 511的 UI帧的密文在发送过程中由于网络链路的不稳 定因素而丢失；
接收方采用 0C1对接收到的 UI帧的密文进行解密并解密成功， 由于 N (U) 为 511的 UI帧的密文在发送过程中由于网络链路的不稳定因素而丢失，故接收方在解密得到 (U) =510 的 UI帧后， 并未解密得到 N (U) 为 511的 UI帧， 此时， 接收方所保存的 0C1的值依然为 0， 0C2的值依然为 512;
接收方接收到发送方采用值为 512的加解密参数 0C加密得到的第二轮 UI帧的密文， 采用值为 0的 0C1对接收到的密文进行解密， 则解密必然失败， 那么， 便采用值为 512的 加解密参数进行解密，则解密成功，之后，将 0C1的值更新为 512， 0C2的值更新为 512+512;
接收方判断采用 0C2解密成功得到的 UI帧的 N (U) 值是否为 511， 如果是， 则说明接 收方对接收到的第二轮取值为 0到 511的 UI帧的密文已全部接收并解密完毕， 将 0C1更新 为 512+512， 0C2更新为 512+512+512;
之后， 接收方接收到发送方所发送的采用值为 512+512的加解密参数 0C加密得到的第 三轮 N (U) 取值为 0到 511的 UI帧的密文， 则采用更新后的值为 512+512的 0C1解密 UI 帧密文成功， 并在解密得到 N (U)为 511的 UI帧时， 再次将 0C1和 0C2分别加上 512进行 更新；
这里之所以将 0C2 也同步进行更新， 则是为了如下情况出现时， 使得接收方依然可以 解密 UI帧密文成功：
接收方接收到发送方所发送的采用值为 512+512的加解密参数 0C加密得到的第三轮 UI 帧的密文， 其中， N (U) 为 511 的 UI帧的密文在发送过程中由于网络链路的不稳定因素 而丢失， 故接收方在解密得到（U) =510的 UI帧后， 并未解密得到 N (U) 为 511的 UI帧； 接收方采用所保存的值为 512+512的 0C1对接收到的第三轮 UI帧的密文进行解密并成 功， 此时由于未能解密得到 N (U) 为 511 的 UI 帧， 所以， 值为 512+512 的 0C1和值为 512+512+512的 0C2未能得到更新；
接收方再次接收到发送方所发送的采用值为 512+512+512的加解密参数 0C加密得到的 第四轮 UI帧的密文时， 采用当前更新得到的值为 512+512的 0C1解密接收到的 UI帧密文 将失败， 则， 采用当前更新得到的值为 512+512+512的 0C2进行解密， 将解密成功， 此时， 再次将 0C1的值更新为 512+512+512, 0C2的值更新为 512+512+512+512, 以保证接收方在 后续再次出现未接收到 N (U) 值为 511的 UI帧时， 依然能够解密 UI帧密文成功。
需要说明的是， 当接收方连续接收 UI帧的密文失败时， 接收方使用 0C1和 0C2均无 法保证在连续两次接收 N ( U) 为 0到 511的 UI帧的密文失败后， 对后续接收到的 UI帧的 密文解密的成功性； 通常情况下， LLC层中连续丢失大量 UI帧的密文的概率极低， 接收方 通过维护两个加解密参数即可基本保障对接收的密文解密的成功性。
那么， 考虑到大量 UI帧的密文连续丢失的情况， 接收方可以维护三个或更多的加解密 参数来保证对接收密文解密的成功性。
接收方维护三个或更多的加解密参数的方法与上述维护两个加解密参数时的方法相 同， 下面， 以接收方维护三个加解密参数的情况为例来说明具体的维护过程： 接收方本地 保存三个加解密参数， 分别为 0C1、 0C2 和 0C3， 其中， 0C1 为当前使用的加解密参数， 0C2=0C1+512 , 0C3=0C2+512 ; 那么， 在接收到 UI帧的密文时， 首先使用 0C1进行解密， 当 使用 0C1解密失败时，则使用 0C2进行解密，当使用 0C2解密成功时，将 0C1更新为 0C1=0C2、 0C2=0C+512 , 0C3=0C2+512 ; 当使用 0C2解密失败时， 则使用 0C3进行解密， 当使用 0C3解 密成功时，将 0C1更新为 0C1=0C3，0C2在更新后的 0C1的基础上加上 512得到更新后的 0C2， 和 0C3在更新后的 0C2的基础上增加 512得到更新后的 0C3 ;
相应地， 在接收方本地维护三个以上的加解密参数时， 其中， 维护的加解密参数中的 任意一个加解密参数由其前一个加解密参数加 512得到。则接收方每次收到 UI帧的密文时， 都首先使用第一个加解密参数尝试解密， 当使用第一个加解密参数失败时， 使用下一个加 解密参数进行解密， 直到对接收到的 UI帧的密文进行解密成功时， 将所维护的所有加解密 参数进行更新， 具体地， 第 i个加解密参数加上 512*j， 得到更新后的第 i个加解密参数， j=i-l， 在以后接收到 UI 帧的密文时， 分别使用更新后的加解密参数对接收到的密文进行 解密。
这样， 通过维护两个或两个以上的加解密参数来对接收到的 UI帧密文进行解密， 使得 在连续出现 UI帧丢失时， 也可以保证对接收到的 UI帧密文解密成功。
通过上述技术方案的实现， 使得接收方在未接收到的 N ( U)为 511的 UI帧的密文和连 续的丢失大量的 UI帧密文的情况下， 依然能够使得本地所维护的加解密参数与接收方所维 护的加解密参数的取值相一致， 而避免接收方无法解密 UI帧密文的情况出现。
实施例 4
参见图 4， 一种维护 LLC层加解密参数的装置， 该装置具体与方法实施例中的执行主体 相一致， 包括： 第一解密模块 401和第二解密模块 402
其中， 第一解密模块 401， 用于采用第 i个加解密参数对接收到的密文进行解密， i的 初始值为 1 ;
第二解密模块 402， 用于当采用第 i 个加解密参数对接收到的密文解密失败时， 将第 i+1个加解密参数作为当前的第 i个加解密参数，通知第一解密模块执行采用第 i个加解密 参数对接收到的密文进行解密的操作， 直到对密文解密成功；
其中， 第 i+1个加解密参数是由第 i个加解密参数加 512得到的。
该装置还可以包括： 更新模块， 用于当第二解密模块对密文解密成功时， 将采用的 i 个加解密参数进行更新。
具体地， 更新模块， 用于将第 i个加解密参数加上 512*j后得到更新后的第 i个加解 密参数， j等于 i_l。
装置还包括： 执行模块， 用于当采用第 i个加解密参数对接收到的 UI帧密文解密成功 时， 判断解密得到的 UI帧的非确认序列号是否为 511， 如果是， 则将第 i个加解密参数的 值加上 512。
通过上述技术方案的实现， 使得接收方在未接收到的 N (U)为 511的 UI帧的密文和连 续的丢失大量的 UI帧密文的情况下， 依然能够使得本地所维护的加解密参数与接收方所维 护的加解密参数的取值相一致， 而避免接收方无法解密 UI帧密文的情况出现。 本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完 成， 也可以通过程序来指令相关的硬件完成， 所述的程序可以存储于一种计算机可读存储 介质中， 上述提到的存储介质可以是只读存储器， 磁盘或光盘等。 以上所述仅为本发明的较佳实施例， 并不用以限制本发明， 凡在本发明的精神和原则 之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权 利 要 求 书
1、 一种维护 LLC层加解密参数的方法， 其特征在于， 所述方法包括：
采用第 i个加解密参数对接收到的非确认信息 UI帧密文进行解密， i的初始值为 1 ; 当采用所述第 i个加解密参数对所述 UI帧密文解密失败时， 将第 i+1个加解密参数作 为当前的第 i个加解密参数， 返回执行所述采用第 i个加解密参数对接收到的非确认信息 UI帧密文进行解密的操作， 直到对所述 UI帧密文解密成功。
2、 根据权利要求 1所述的方法， 其特征在于， 第 i+1个加解密参数是由第 i个加解密 参数加 512得到的。
3、 根据权利要求 1所述的方法， 其特征在于， 所述当采用所述第 i个加解密参数对所 述 UI帧密文解密失败时， 将第 i+1个加解密参数作为当前的第 i个加解密参数， 返回执行 所述采用第 i个加解密参数对接收到的非确认信息 UI帧密文进行解密的操作， 直到对所述 UI帧密文解密成功之后， 所述方法还包括： 将采用的 i个加解密参数进行更新。
4、 根据权利要求 3所述的方法， 其特征在于， 所述将采用的 i个加解密参数进行更新 包括：
将第 i个加解密参数加上 512*j后得到更新后的第 i个加解密参数， j等于 i_l。
5、 根据权利要求 1所述的方法， 其特征在于， 所述方法还包括： 当采用所述第 i个加 解密参数对接收到的 UI帧密文解密成功时， 判断解密得到的 UI帧的非确认序列号是否为 511 , 如果是， 则将所述第 i个加解密参数的值加上 512。
6、 一种维护 LLC层加解密参数的装置， 其特征在于， 所述装置包括： 第一解密模块和 第二解密模块；
所述第一解密模块， 用于采用第 i个加解密参数对接收到的密文进行解密， i的初始值 为 1 ;
所述第二解密模块， 用于当采用所述第 i 个加解密参数对接收到的密文解密失败时， 将第 i+1个加解密参数作为当前的第 i个加解密参数，通知所述第一解密模块执行采用第 i 个加解密参数对接收到的密文进行解密的操作， 直到对所述密文解密成功。
7、 根据权利要求 6所述的装置， 其特征在于， 第 i+1个加解密参数是由第 i个加解密 参数加 512得到的。
8、 根据权利要求 6所述的装置， 其特征在于， 所述装置还包括： 更新模块， 用于当所 述第二解密模块对所述密文解密成功时， 将采用的 i个加解密参数进行更新。
9、 根据权利要求 8所述的装置， 其特征在于， 所述更新模块， 具体用于将第 i个加解 密参数加上 512*j后得到更新后的第 i个加解密参数， j等于 i_l。
10、 根据权利要求 6所述的装置， 其特征在于， 所述装置还包括： 执行模块， 用于当 采用所述第 i个加解密参数对接收到的 UI帧密文解密成功时， 判断解密得到的 UI帧的非 确认序列号是否为 511， 如果是， 则将所述第 i个加解密参数的值加上 512。
PCT/CN2011/076560 2011-06-29 2011-06-29 维护llc层加解密参数的方法及装置 WO2012103720A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN2011800010008A CN102301645A (zh) 2011-06-29 2011-06-29 维护llc层加解密参数的方法及装置
PCT/CN2011/076560 WO2012103720A1 (zh) 2011-06-29 2011-06-29 维护llc层加解密参数的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/076560 WO2012103720A1 (zh) 2011-06-29 2011-06-29 维护llc层加解密参数的方法及装置

Publications (1)

Publication Number Publication Date
WO2012103720A1 true WO2012103720A1 (zh) 2012-08-09

Family

ID=45360532

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/076560 WO2012103720A1 (zh) 2011-06-29 2011-06-29 维护llc层加解密参数的方法及装置

Country Status (2)

Country Link
CN (1) CN102301645A (zh)
WO (1) WO2012103720A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116932015B (zh) * 2023-09-18 2023-12-15 中汽智联技术有限公司 一种车辆软件远程升级方法、装置、系统及电子设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1526217A (zh) * 2001-05-23 2004-09-01 ��ķɭ���ó�׹�˾ 保护和识别消息的保密设备和方法
CN1723501A (zh) * 2002-12-10 2006-01-18 英特尔公司 公开密钥媒体密钥块

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100734941B1 (ko) * 2006-10-26 2007-07-06 삼성전자주식회사 휴대 단말기의 에러 정정 시스템 및 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1526217A (zh) * 2001-05-23 2004-09-01 ��ķɭ���ó�׹�˾ 保护和识别消息的保密设备和方法
CN1723501A (zh) * 2002-12-10 2006-01-18 英特尔公司 公开密钥媒体密钥块

Also Published As

Publication number Publication date
CN102301645A (zh) 2011-12-28

Similar Documents

Publication Publication Date Title
US20240073686A1 (en) Methods providing non-3gpp access using access network keys and related wireless terminals and network nodes
US8504833B2 (en) Relay device, wireless communications device, network system, program storage medium, and method
US8627092B2 (en) Asymmetric cryptography for wireless systems
TWI332345B (en) Security considerations for the lte of umts
EP2702741B1 (en) Authenticating a device in a network
US11617082B2 (en) Methods providing NAS connection identifications and related wireless terminals and network nodes
JP5347067B2 (ja) 暗号化エラー検出および回復のためのシステム、方法、および装置
JP5575914B2 (ja) マルチ・バンド／マルチ・リンクの安全キー生成及び配信プロトコル
JPWO2008096396A1 (ja) 無線通信装置および暗号鍵更新方法
JP4608000B2 (ja) セキュアで帯域効率の良い暗号化同期方法
US9872175B2 (en) Packet processing method, apparatus, and system
WO2012083828A1 (zh) 本地路由业务的实现方法、基站及系统
WO2020133543A1 (zh) 通信方法和相关产品
CN105429753A (zh) 提高VoLTE通信安全性的语音数据方法、系统及移动终端
US20100020973A1 (en) Transmission device and reception device for ciphering process
US7400733B1 (en) Key refresh at the MAC layer
JP6179815B2 (ja) 暗号化データ通信装置、暗号化データ通信方法、プログラム、及び、記録媒体
WO2018076190A1 (zh) 通信方法、终端、核心网用户面设备和接入网设备
JP2023015282A (ja) 第２の通信装置
JP5835162B2 (ja) 暗号通信システム及び暗号通信方法
WO2012103720A1 (zh) 维护llc层加解密参数的方法及装置
CN109905345B (zh) 通信方法、通信装置和通信设备
Omar et al. ARQ secrecy: From theory to practice
JP2008011176A (ja) 無線通信方法および無線通信システム
WO2012072053A1 (zh) 非确认模式下的上行加密参数同步方法和设备

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180001000.8

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11857939

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11857939

Country of ref document: EP

Kind code of ref document: A1