US7127604B2 - Changing a codec or MAC size without affecting the encryption key in PacketCable communication - Google Patents

Changing a codec or MAC size without affecting the encryption key in PacketCable communication Download PDF

Info

Publication number
US7127604B2
US7127604B2 US10/190,543 US19054302A US7127604B2 US 7127604 B2 US7127604 B2 US 7127604B2 US 19054302 A US19054302 A US 19054302A US 7127604 B2 US7127604 B2 US 7127604B2
Authority
US
United States
Prior art keywords
new
codec
timestamp
rc4
mac
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.)
Active, expires
Application number
US10/190,543
Other versions
US20040008844A1 (en
Inventor
David Lide
Dunling Li
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Texas Instruments Inc
Telogy Networks Inc
Original Assignee
Texas Instruments Inc
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 Texas Instruments Inc filed Critical Texas Instruments Inc
Priority to US10/190,543 priority Critical patent/US7127604B2/en
Assigned to TELOGY NETWORKS, INC. reassignment TELOGY NETWORKS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LI, DUNLING, LIDE, DAVID
Publication of US20040008844A1 publication Critical patent/US20040008844A1/en
Application granted granted Critical
Publication of US7127604B2 publication Critical patent/US7127604B2/en
Application status is Active legal-status Critical
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communication the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/12Transmitting and receiving encryption devices synchronised or initially set up in a particular manner

Abstract

A technique is described to change the codec or MAC (message authentication code) size in a packet security unit for PacketCable communications during realtime voice transmissions is described. An algorithm that provides fast RC4 key advancing to prevent MIPS (millions of instruction cycles per second) overflow is used to perform codec or MAC size changes. The invention is performed without changing the keying material, where the sender and receiver must continue the RC4 encryption process from its state prior to the codec or MAC size change. A sender needs to preserve continuity of the timestamp across a codec change, since the timestamp reflects realtime. Changing the codec or MAC size is likely to change the frame parameters. To preserve continuity of the RC4 state and the timestamp across the codec/MAC size change, the sender TX and receiver RX generates a new frame number. The new frame number is applied to the first frame generated by the new codec or MAC size.

Description

FIELD OF THE INVENTION

The present invention relates to changing the codec or MAC size during PacketCable voice transmissions without changing the keying material, where the sender and receiver must continue the RC4 encryption process from its state prior to the codec or MAC size change.

BACKGROUND OF THE INVENTION

PacketCable is a project conducted by Cable Television Laboratories and its member companies whose goal is to identify, qualify, and support packet-based voice and video products over cable systems. PacketCable is a set of protocols and associated element functional requirements developed to deliver Quality-of-Service enhanced secure communications services using packetized data transmission technology to a consumer's home over the cable television hybrid fiber-coaxial data network. The PacketCable Security Specification is hereby incorporated by reference; and interim PacketCable Security Specification document PKT-SP-SEC-I01-991201, released Dec. 1, 1999 is specifically referenced.

The RC4 (Rivest Cipher 4) algorithm is a stream cipher designed by Rivest for RSA Data Security and is a variable key-size stream cipher with byte-oriented operations. The algorithm is based on the use of a random permutation. It is commonly used to protect Internet traffic using the SSL (Secure Sockets Layer) protocol. RC4 is a variable-key-size cipher developed in 1987 by Ron Rivest for RSA Data Security, Inc. RC4 is used to encrypt media flows for voice and video over packet cable. The algorithm used variable length keys. For PacketCable the key length is set to 128 bits. RC4 is a pseudo-random number generator in output feedback mode. The key-stream is independent of the plaintext. The output stream is generated from the key and stored with the plaintext. There is no integrity protections on the data. RC4 uses a 256 entry substitution box which must be initialized. The entries are a permutation of the number 0 through 255, and the permutation is a function of the variable-length key.

Referring to FIG. 1, an example of a voice encryption system for using RC4 is illustrated. A packet security unit (“PSU”) implements a single channel functionality for encryption/decryption and authentication of voice payload. A PSU is implemented as an independent module, but it is highly correlated to Packetized Voice Protocol Unit (“PVP”) 10 and PVP uses PSU functions through a function pointer. PSU also supports Real Time Protocol (“RTP”) with voice payload only. PSU can be configured to support authentication or encryption with or without authentication. RC4 algorithm is used in encryption, while authentication is based on Multi-linear Modula Hash Message Authentication Code (“MMH-MAC”) algorithm. The MMH-Message Authentication Code (“MAC”) is the message authentication code option for media flows. The MMH-MAC is computed over the RTP header and the payload generated by the codec 22.

A message authentication code (“MAC”) provides security to each packet of a media stream. A MAC ensures the receiver that the packet came from the legitimate sender and that it has not been tampered with en route. A MAC defends against a variety of potential known attacks, such as replay and clogging. It also may defend against as-yet-undiscovered attacks. Typically, a MAC consists of eight or more octets appended to the message being protected. A two or four byte MAC can be chosen during configuration for PacketCable. The encryption keys and keys lengths are configurable, for example the RC4 key can require 128 bits. A MAC key and key length are configurable as well. The maximum MAC key length should be the maximum RTP packet length plus the number of MAC digits. An exemplary voice payload size is 240 bytes (30 ms*80 PCM samples/10 ms). The maximum RTP header length should be 12 bytes plus the maximum contributing source identifiers (CSRC) length of 64 bytes, or 72 bytes. The MAC key length should then be at least 316 bytes. The RC4 and MAC keys are initialized by loading key messages from MIC.

In FIG. 1, in the PVP transmit side (TX) 12, the PSU receives packets from the codec 22, encrypts one frame of voice payload, and performs the message authentication on one RTP packet. Packets are sent to and received from a network driver unit (NDU)20. At the PVP receive end (RX) 14, the PSU performs the message authentication on the receive packets first, then decrypts the voice payload. After the receiving packets through PSU RX 14, packets are sent to a voice playout unit (VPU) 16, after which they are sent back to the codec 22. According to the RC4 algorithm, RC4 states must be synchronized with an RTP packet timestamp and the RC4 state adjustments are involved in both PVP TX 12 and RX 14 directions. Because of network packet delay jittering and voice activity detection operations, PVP 10 may not receive any packets for a long period of time. The next received packet will require a large amount of RC4 states adjustments in that case. In order to avoid interrupting a conversation by adjusting the RC4 states during voice transmissions, RC4 decryption states are adjusted during a no packet arrival period. A 2.5 ms local clock is used in the RC4 decryption states advance function.

The RC4 algorithm has been specified for use in an RTP (Real Time Protocol) stream in PacketCable. The algorithm applies only to the RTP payload, not the header, and does not add any additional bytes to the voice packets. The algorithm assumes that voice payload packets are part of one large data stream. The state must be maintained over packet boundaries, however, and even over codec 22 changes. The timestamp field in the RTP header is used to keep the sender and receiver RC4 states synchronized. The state of the RC4 encryption process is preserved between frame encodings. The RC4 process operates as if the payload of each frame is padded up to length (Ne+Nm) octets, where Ne is the maximum size of the payload of an event packet (the value of Ne is at least as large as Nc which is the number of octets in one frame of compressed audio; Nc is a consent value that depends on the voice codec and on the audio frame size; the payload of a voice packet contains the Nc octets making up one frame of compressed audio), and Nm is the number of MAC octets; with a value of zero if the optional MAC is not selected, or two or four which represents the MAC size if the optional MAC is selected. The payloads of all packets are concatenated into a single stream. The stream is encrypted by a single RC4 encryption process.

RC4 encryption state Nk is the number of keystream octets that have been previously generated by the RC4 encryption process, whether used or discarded. Nk has value 0 immediately after the RC4 process is initialized with a new key and increments with each generated octet of keystream. Nk is used both in RC4 encryption and MAC process. For each frame, the RC4 encryption state Nk should be set to the value Nf(Ne+Nm), where Nf is the codec frame number, and Ne is the maximum size of the payload of an event packet; and Nm is the number of MAC octets. This value is 0, if the optional MAC is not selected, or 1 or 2 which represents the MAC size if the optional MAC is selected. The octets of the packet's payload are encrypted using the RC4 encryption process and inserted into the payload field. If there are B octets to be encrypted, then they are encrypted using octets Nk+Nm to Nk+Nm+B−1, inclusive and in order in the RC4 key-stream. The Nm octets from Nk to Nk+Nm−1 are used in MAC digit calculation. Not all of the key-stream octets generated by the RC4 process are necessarily used. The RC4 encryption process is advanced for silent codec frames that are not actually transmitted, since the value of Nf increments even for silent frames. Since the codec calls operates continuously at codec frame rate during conversation, TX RC4 encryption state synchronization involves updating Nk to Nf (Ne+Nm) according to the current frame number Nf The next expected frame number Nf_next (16 bits) is used to represent the RC4 state.

Prior to decrypting the packet's payload or verifying its Mac digits, RC4 decryption state at the receiver side, RX, must match the RC4 encryption state of sender side TX. The RC4 decryption state Nk should be set to the value Nf*(Ne+Nm) as well, where the maximum payload size Ne and the number of MAC octets Nm should be the same as the transmit side TX during the channel setup. The frame number Nf is computed from the value of timestamp field in the packet header. The timestamp field is a 32-bit value that reflects the sampling instant of the first uncompressed speech sample encoded in the packet. The timestamp field is used by the receiver to synchronize its decryption process to the encryption process of the sender. The starting times of two communicating parties are independent and their time difference is arbitrary. The starting time differences could be beyond the timestamp threshold in timestamp check. A MIPS based RC4 state adjustment algorithm is used for RC4 states adjustment in the first receive packet.

Therefore, the timestamp value is very crucial for RC4 decryption state synchronization, the receiver should perform a check on the timestamp value in the RTP header. A timestamp check state is used to check if the timestamp of the current packet is in a reasonable range of the value expected based on the receiver's local clock. The packet will be rejected if the time stamp is invalid. When no packets are sent during silence periods or during packet losses, the RC4 states are advanced using a local clock. RC4 state synchronization will advance RC4 state forwards or backwards in order to make RC4 states Nk equal to Nf_next (Ne+Nm). An authentication check is performed on a MAC key and one random pad from RC4. The states transitions are controlled by the system configuration parameters and received packet timestamps.

Although the PacketCable Security Specification provides guidance for security measures in its implementation, the standard will not operate correctly when a codec or MAC change occurs during a call transmission. The lack of a proper timestamp for transitioned packets prevents the receiver from synchronizing with the transmitter. Therefore, what is needed is a way to adjust the RC4 state to synchronize between the transmitter and the receiving when changing a codec or MAC during PacketCable communications.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention are discussed hereinafter in reference to the drawings, in which:

FIG. 1 is a prior art diagram of an packet security unit for PacketCable communications.

FIG. 2 is diagram of a switchover to a new codec in PacketCable communications.

DETAILED DESCRIPTION OF THE INVENTION

There is described herein a technique that computes a new frame number to apply to the first frame generated by a new codec. This technique allows a PacketCable coder/decoder (“codec”) or message authentication code (“MAC”) to be changed in realtime without requiring new encryption key material.

Referring to FIG. 1, speech 24 from a sender is transmitted to a codec 26, such as G.729 that converts the speech into digital packets. The digital transmission is then encrypted and sent to a receiver. If the codec or MAC size is changed, such as a change to G.711 codec 28, during transmissions without changing the keying material, the sender and receiver must continue the RC4 encryption process from its state prior to the codec change. It cannot reset the state to zero, since a stream cipher such as RC4 may not reuse a keystream without exposing plaintext. The sender also needs to preserve continuity of the timestamp across the codec change, since the timestamp reflects realtime. Since the RC4 state is a function of the timestamp, it must be adjusted 32 to its timestamp corresponding position before any encryption or MAC performs. Due to the packet loss, the starting time difference of the communication parties, key changes, or codec/MAC switching, a large amount of RC4 states adjustments are not avoidable. The limitation of system MIPS will not allow a very large adjustment of the amount of RC4 states during the same instance. However, a MIPS-based RC4 state adjustment algorithm can accomplish the task. The algorithm adjusts the maximum possible number of RC4 states possible without exceeding maximum system MIPS during each instance in time. The current packets drop until RC4 reaches its required states. The number of packets dropped will show in the PVP statistics.

Changing the codec or MAC size is likely to change the frame parameters. Changing the codec is likely to change the number of octets carried in the payload of a voice packet, which changes the proportionality constant that relates the RC4 state to the timestamp. To preserve continuity of the RC4 state and the timestamp across the codec/MAC size change, the sender TX and receiver RX must compute a new frame number. The new frame number is applied to the first frame generated by the new codec or MAC size. The new frame number is calculated according to

N f , new = roof [ ( N f , old + 1 ) ( N e , old + N m ) N e , new + N m ] ( 1 ) N f , new = roof [ ( N f , old + 1 ) ( N e + N m , old ) N e + N m , new ] ( 2 )
where Ne and Nm reflect the maximum coding size for the new switched coded, e.g. Ne,old for G.729=10 bytes and Ne,new for G.711=80 bytes; and where equations (1) and (2) are corresponding to the codec change and MAC size change, respectively. Nf,new is the new frame number; Nf,old is the frame number used to encode the last packet under the old codec; Ne,old and Ne,new are the values of Ne under the old and new codecs, respectively; and roof(x) is the function that returns the smallest integer no less than x.

The amount by which RC4 states need to be advanced during codec/MAC size change should be
Nf,new(Ne,new+Nm)−(Nf,old+1)(Ne,old+Nm) or Nf,new(Ne+Nm,new)−(Nf,old+1)(Ne+Nm,old)
which is less than (Ne,new+Nm) or (Ne+Nm,new). However, the new frame number Nf,new is not equal to the real frame number Nf, where

N f = Timestamp - Intial _ Timestamp N u
Therefore, the new RC4 state is highly dependent on the codec/MAC size change timing, Nf,old. The sender and receiver can not synchronize the new RC4 states to each other unless TX and RX can switch over at the same time or Micro can provide exact switching over time, for example switch over with the same timestamp. Practically, the codec and MAC size switches for both TX and RX can not occur simultaneously. Occasionally on only the TX or RX end, only one side needs to be changed and the opposite end will remain in status quo. Since the new frame number Nf,new can not be calculated from the timestamp, the codec/MAC size change algorithm has TX and RX synchronization problems.

Other network related issues occur at the receiver side only. First of all, if the packets arrive out of order, the receiver should push the RC4 process backwards as well as forwards in order to match the state of the sender's RC4 process. Secondly, the packet delay may vary because of network delay jittering, causing the receiver to adjust its RC4 decryption state to avoid too much backward RC4 process. Third, the codec with VAD has discontinuous transmission behavior. The RC4 encryption process is advanced for silent codec frames that are not actually transmitted, since the value of Nf increments even for silent frames.

The receiver RX in the Packet Security Unit (“PSU”) of FIG. 1 must advance its RC4 decryption state based on its local clocks during a silent period in order to catch up to its state for the next packet and limit the decryption peak MIPS consumption in a reasonable range. Therefore, RC4 decryption state Nk should be advanced if the duration of no packet arrival is beyond a threshold. It can be difficult to determine the threshold since the above problems are interactive to each other. If this threshold is high, RC4 decryption state will be advanced to its current right state and on, RC4 backward process must be performed. However, if the threshold is low, RC4 decryption state will be behind its state, the receiver must advance its RC4 decryption state before decrypting the current packet. Therefore, this threshold is very crucial to the overall MIPS (millions of instruction cycles per second) consumption. The ideal threshold should minimize the backward process and peak MIPS. Theoretically, the threshold should be adaptive to the current network traffic condition and the duration of no packet arrival. The average packet delay is a very good feature to represent current network traffic conditions, and the current system MIPS consumption will affect the average packet delay. To conserve MIPS during the decryption state synchronization, received packets will be dropped if packet arrival delay is beyond a threshold, which is the maximum jitter size, and if packets arrive out of order.

As stated previously, although the PacketCable Security Specification provides guidance for security measures in its implementation, the standard will not operate correctly when a codec or MAC change occurs during a call transmission. The lack of a proper timestamp for transitioned packets prevents the receiver from synchronizing with the transmitter. The following is an example of the problem with a MAC size change from two to zero, which shows the TX and RX out of synch after the change. The system is configured as one frame per packet; the frame size is 10 ms, for Nu=80; G.729 codec Ne=10; and MAC size Nm=2. The initial timestamp is assumed zero and Nm,new=0.

If MAC size changes occurred at the third packet in the TX direction then Nf,old=2 and timestamp=240. Current RC4 states Nk,old=(Nf,old+1)*(Ne+Nm,old)=3*(10+2)=36. According to equation (2), Nf,new=roof[(2+1)*(10+2)/(10+0)]=roof[3.6]=4. The new RC4 states Nk,new=Nf,new*(Ne+Nm,new)=4*(10+0)=40. So, TX needs to advance (40−36)=4 RC4 states forward during the MAC size change. After the MAC size is changed, the new RC4 states can be calculated as follows:

N k = N k , new + Timestamp - 240 N u * ( N e + N m , new )

If timestamp=16*80=1280, then its new RC4 states Nk=40+(280−240)/80*(10+0)=40+13*10=170 in the TX direction.

If MAC size change occurred at the 15th packet in the RX direction, the Nf,old=14 and timestamp=15*80=1200. The current RC4 states Nk,old=(Nf,old+1)(Ne+Nm,old)=15*(10+2)=180. Based on Equation (2), Nf,new=roof[(14+1)*(10+2)/(10+0)]=18. The new RC4 states Nk,new=Nf,new*(Ne+Nm,new)=18*(10+0)=180. RX does not need to adjust RC4 states for the MAC size change. If the timestamp=1280, then RX corresponding new RC4 states Nk=180+(1280−1200)/80*(10+0)=190. Thus, based on the codec/MAC size change algorithm, the TX RC4 state (Nk=170) is different from the RX RC4 state (Nk=190) for the same packet (timestamp=1280). In the case which only one side needs to perform a codec/MAC size change, TX and RX are totally out of synch.

To solve this problem, the following timestamp-based algorithm can be applied in codec/MAC size changes. The basis of the solution of the present invention is that the frame number is always equal to the real frame number, which can be calculated from the current timestamp. The new RC4 states can be calculated by equations (3) for codec and (4) for MAC size changes. Equation (5) can be used to calculation new RC4 states for both codec and MAC size changes.
Nk, new=Timestamp−Intial_Timestamp/Nu(Ne, new+Nm)  (3)
Nk, new=(Timestamp−Intial_Timestamp)/Nu(Ne+Nm, new)  (4)
Nk, new=(Timestamp−Intial_Timestamp)/Nu(Ne, new+Nm, new)  (5)

The number of RC4 states to be adjusted is equal to Nk,new−Nk,old. Equations (6) and (7) are the number of RC4 states to be adjusted during codec and MAC size changes, respectively. Equations (5) and (8) are generalized cases which can handle switching codec and MAC size at the same time.

Δ N k = ( Timestamp - Intial _ Timestamp ) N u ( N e , new - N e , old ) ( 6 ) Δ N k = ( Timestamp - Intial _ Timestamp ) N u ( N m , new - N m , old ) ( 7 ) Δ N k = ( Timestamp - Intial _ Timestamp ) N u ( N e , new + N m , new - N e , old - N m , old ) ( 8 )

If ΔNk is positive, RC4 states need to be advanced forward; and if ΔNk is negative, RC4 states need to be advanced backwards. ΔNk could be a large number if the switching over time is far from the beginning of the call. Therefore, this algorithm could suffer a large RC4 state adjustment during the codec/MAC size change.

Table 1 shows the dynamic range of |ΔNk| for different codec and MAC sizes and switch timings. In some situations, |ΔNk| could be very large such that a processor does not have adequate MIPS to adjust ΔNk RC4 states in one frame. In such situations, the packet drop method is used to break down |ΔNk| into pieces based on the maximum available MIPS of the system. The communication will temporarily stop during the codec/MAC size change if the change occurs at an elapsed time far enough from the beginning of the call. Npacket is the number of dropped packets during codec/MAC size change while the maximum available MIPS for RC4 adjustment is 2.5 MIPS. Table 1 shows how the MAC size change will not affect communication if the switchover occurs within 10 minutes from the beginning of the call. For codec change, the worst case is the switchover between G.723 and PCM, which is very close to the case between G.729 and PCM. If the codec switch occurs in five minutes from the beginning of the call, both sides will not notice the packet drop effects. However, if this occurs at ten minutes, the system will lose 420 ms of voice. If the switch occurs at 30 minutes, the system will lose 1.3 seconds of voice, and if the switch occurs at one or two hours, the system will lose 2.52 or 5.04 seconds of voice, respectively.

TABLE 1
Adjusted RC4 States and Number of Dropped Packets*
First
Codec G.729 (Ne = 10) < > MAC size MAC size
Duration PCM (Ne = 80) (0 < > 2 or 2 < > 4) (Nm = 0 < > Nm = 4
Time |ΔNk| Npacket |ΔNk| Npacket |ΔNk| Npacket
10 ms 70 0 2 0 4 0
 1 sec 7000 0 200 0 400 0
 1 min 420,000 5 12,000 0 24,000 0
 2 min 840,000 9 24,000 0 48,000 0
 5 min 2,100,000 21 60,000 0 120,000 2
10 min 4,200,000 42 120,000 2 240,000 3
30 min 12,600,000 130 360,000 4 720,000 8
1 hour 25,200,000 252 720,000 8 1,440,000 15
2 hours 50,400,000 504 1,440,000 15 2,880,000 29
*1 frame/packet, frame length = 10 ms

Because many varying and different embodiments may be made within the scope of the inventive concept herein taught, and because many modifications may be made in the embodiments herein detailed in accordance with the descriptive requirements of the law, it is to be understood that the details herein are to be interpreted as illustrative and not in a limiting sense.

Claims (10)

1. A method for changing the codec without changing the encryption key in PacketCable communications, comprising:
computing a new frame number by the sender;
computing a new frame number by the receiver,
wherein the new frame number is determined by finding the real frame number, which is calculated using a timestamp-based algorithm using a timestamp simultaneous to the real frame number, the calculation for the new frame number being performed according to
N f , new = roof [ ( N f , old + 1 ) ( N e , old + N m ) N e , new + N m ]
applying the new frame number to the first frame generated by the new codec; and
calculating a new RC4 state after changing the codec.
2. The method of claim 1,
wherein the finding a new RC4 state after changing the codec is calculated using the formula
N k , new = Timestamp - Intial _ Timestamp N u ( N e , new + N m ) .
3. The method of claim 1, wherein the finding a new RC4 state after changing the codec is calculated using the formula
N k , new = ( Timestamp - Intial _ Timestamp ) N u ( N e , new + N m , new ) .
4. The method of claim 1, further comprising:
finding the number of RC4 states to be adjusted during codec changes using a timestamp-based algorithm.
5. The method of claim 4, further comprising:
dropping packets during a codec change when required processing resources are greater than a maximum threshold.
6. A method for changing a message authentication code (MAC) without changing the encryption key in PacketCable communications, comprising:
computing a new frame number by the sender;
computing a new frame number by the receiver,
wherein the new frame number is determined by finding the real frame number, which is calculated using a timestamp-based algorithm using a timestamp simultaneous to the real frame number, the calculation for the new frame number being performed according to
N f , new = roof [ ( N f , old + 1 ) ( N e + N m , old ) N e + N m , new ]
applying the new frame number to the first frame generated by the new MAC size; and
calculating a new RC4 state after changing the MAC size.
7. The method of claim 6, wherein the finding a new RC4 state after changing the MAC size is calculated using the formula
N k , new = ( Timestamp - Intial _ Timestamp ) N u ( N e , new + N m , new ) .
8. The method of claim 6, further comprising:
finding the number of RC4 states to be adjusted during MAC size changes using a timestamp-based algorithm.
9. The method of claim 8, further comprising:
dropping packets during MAC size change when required processing resources are greater than a maximum threshold.
10. The method of claim 6,
wherein the finding a new RC4 state after changing the MAC size using the formula
N k , new = ( Timestamp - Intial _ Timestamp ) N u ( N e + N m , new ) .
US10/190,543 2002-07-09 2002-07-09 Changing a codec or MAC size without affecting the encryption key in PacketCable communication Active 2024-12-16 US7127604B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/190,543 US7127604B2 (en) 2002-07-09 2002-07-09 Changing a codec or MAC size without affecting the encryption key in PacketCable communication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/190,543 US7127604B2 (en) 2002-07-09 2002-07-09 Changing a codec or MAC size without affecting the encryption key in PacketCable communication

Publications (2)

Publication Number Publication Date
US20040008844A1 US20040008844A1 (en) 2004-01-15
US7127604B2 true US7127604B2 (en) 2006-10-24

Family

ID=30114067

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/190,543 Active 2024-12-16 US7127604B2 (en) 2002-07-09 2002-07-09 Changing a codec or MAC size without affecting the encryption key in PacketCable communication

Country Status (1)

Country Link
US (1) US7127604B2 (en)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040196978A1 (en) * 2001-06-12 2004-10-07 Godfrey James A. System and method for processing encoded messages for exchange with a mobile data communication device
US20060036865A1 (en) * 2004-08-10 2006-02-16 Research In Motion Limited Server verification of secure electronic messages
US20070101025A1 (en) * 2005-10-27 2007-05-03 Research In Motion Limited Synchronizing certificates between a device and server
US20070118874A1 (en) * 2005-11-18 2007-05-24 Research In Motion Limited System and method for handling electronic messages
US20070123307A1 (en) * 2005-11-30 2007-05-31 Research In Motion Limited Display of secure messages on a mobile communication device
US20070123217A1 (en) * 2005-11-30 2007-05-31 Research In Motion Limited Display of secure messages on a mobile communication device
US20070299921A1 (en) * 2006-06-23 2007-12-27 Research In Motion Limited System and method for handling electronic mail mismatches
US20080016359A1 (en) * 2001-06-12 2008-01-17 Godfrey James A System and method for compressing secure e-mail for exchange with a mobile data communication device
US20090061912A1 (en) * 2007-09-04 2009-03-05 Research In Motion Limited System and method for processing attachments to messages sent to a mobile device
US20090080661A1 (en) * 2007-09-24 2009-03-26 Research In Motion Limited System and method for controlling message attachment handling functions on a mobile device
US20090292916A1 (en) * 2001-06-12 2009-11-26 Little Herbert A Certificate Management and Transfer System and Method
US8019081B2 (en) 2001-08-06 2011-09-13 Research In Motion Limited System and method for processing encoded messages
US8209530B2 (en) 2004-09-02 2012-06-26 Research In Motion Limited System and method for searching and retrieving certificates
US8296829B2 (en) 2004-09-01 2012-10-23 Research In Motion Limited Providing certificate matching in a system and method for searching and retrieving certificates
US8355701B2 (en) 2005-11-30 2013-01-15 Research In Motion Limited Display of secure messages on a mobile communication device
US8572389B2 (en) 2005-10-14 2013-10-29 Blackberry Limited System and method for protecting master encryption keys
US8589677B2 (en) 2004-09-01 2013-11-19 Blackberry Limited System and method for retrieving related certificates
US20150016463A1 (en) * 2009-12-10 2015-01-15 Vocality International Ltd. Media over ip performance enhancement
US9628269B2 (en) 2001-07-10 2017-04-18 Blackberry Limited System and method for secure message key caching in a mobile communication device

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3821086B2 (en) * 2002-11-01 2006-09-13 ソニー株式会社 Streaming systems and streaming method, the client terminal and the data decoding method, and program
US7602905B2 (en) * 2004-09-01 2009-10-13 Texas Instruments Incorporated Processes, circuits, devices, and systems for encryption and decryption and other purposes, and processes of making
KR101215615B1 (en) * 2006-01-10 2012-12-26 삼성전자주식회사 Codec change method and apparatus for the video and the reproduction of the audio data stream encoded using different codecs from the same channel
US8705348B2 (en) * 2007-04-18 2014-04-22 Cisco Technology, Inc. Use of metadata for time based anti-replay
FR2941583A1 (en) * 2009-01-27 2010-07-30 St Nxp Wireless France Process for decrypting a packet number in a wireless communication device and corresponding device
CN104869117B (en) * 2015-05-14 2018-08-24 新华三技术有限公司 Kinds of security authentication method and device

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
PacketCable Security Specification document PKT-SP-SEC-l01-991201; Dec. 1, 1999. *
Peterson et al.; Computer Networks; 2000; Academic Press; 2<SUP>nd </SUP>Edition; Chapter 6. *

Cited By (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7827406B2 (en) 2001-06-12 2010-11-02 Research In Motion Limited System and method for processing encoded messages for exchange with a mobile data communication device
US20050163320A1 (en) * 2001-06-12 2005-07-28 Brown Michael S. System and method for processing encoded messages for exchange with a mobile data communication device
US8291212B2 (en) 2001-06-12 2012-10-16 Research In Motion Limited System and method for compressing secure E-mail for exchange with a mobile data communication device
US8447980B2 (en) 2001-06-12 2013-05-21 Research In Motion Limited System and method for processing encoded messages for exchange with a mobile data communication device
US8015400B2 (en) 2001-06-12 2011-09-06 Research In Motion Limited Certificate management and transfer system and method
US9172540B2 (en) 2001-06-12 2015-10-27 Blackberry Limited System and method for processing encoded messages for exchange with a mobile data communication device
US20040196978A1 (en) * 2001-06-12 2004-10-07 Godfrey James A. System and method for processing encoded messages for exchange with a mobile data communication device
US8527767B2 (en) 2001-06-12 2013-09-03 Blackberry Limited System and method for processing encoded messages for exchange with a mobile data communication device
US20080016359A1 (en) * 2001-06-12 2008-01-17 Godfrey James A System and method for compressing secure e-mail for exchange with a mobile data communication device
US8539226B2 (en) 2001-06-12 2013-09-17 Blackberry Limited Certificate management and transfer system and method
US8898473B2 (en) 2001-06-12 2014-11-25 Blackberry Limited System and method for compressing secure E-mail for exchange with a mobile data communication device
US20090292916A1 (en) * 2001-06-12 2009-11-26 Little Herbert A Certificate Management and Transfer System and Method
USRE45087E1 (en) 2001-06-12 2014-08-19 Blackberry Limited Certificate management and transfer system and method
US7657736B2 (en) 2001-06-12 2010-02-02 Research In Motion Limited System and method for compressing secure e-mail for exchange with a mobile data communication device
US7653815B2 (en) 2001-06-12 2010-01-26 Research In Motion Limited System and method for processing encoded messages for exchange with a mobile data communication device
US8205084B2 (en) 2001-06-12 2012-06-19 Research In Motion Limited System and method for processing encoded messages for exchange with a mobile data communication device
US9628269B2 (en) 2001-07-10 2017-04-18 Blackberry Limited System and method for secure message key caching in a mobile communication device
US8661267B2 (en) 2001-08-06 2014-02-25 Blackberry Limited System and method for processing encoded messages
US8019081B2 (en) 2001-08-06 2011-09-13 Research In Motion Limited System and method for processing encoded messages
US9398023B2 (en) * 2004-08-10 2016-07-19 Blackberry Limited Server verification of secure electronic messages
US20150334120A1 (en) * 2004-08-10 2015-11-19 Blackberry Limited Server verification of secure electronic messages
US20060036865A1 (en) * 2004-08-10 2006-02-16 Research In Motion Limited Server verification of secure electronic messages
US9094429B2 (en) * 2004-08-10 2015-07-28 Blackberry Limited Server verification of secure electronic messages
US8561158B2 (en) 2004-09-01 2013-10-15 Blackberry Limited Providing certificate matching in a system and method for searching and retrieving certificates
US8589677B2 (en) 2004-09-01 2013-11-19 Blackberry Limited System and method for retrieving related certificates
US8296829B2 (en) 2004-09-01 2012-10-23 Research In Motion Limited Providing certificate matching in a system and method for searching and retrieving certificates
US8566582B2 (en) 2004-09-02 2013-10-22 Blackberry Limited System and method for searching and retrieving certificates
US8209530B2 (en) 2004-09-02 2012-06-26 Research In Motion Limited System and method for searching and retrieving certificates
US8572389B2 (en) 2005-10-14 2013-10-29 Blackberry Limited System and method for protecting master encryption keys
US20070101025A1 (en) * 2005-10-27 2007-05-03 Research In Motion Limited Synchronizing certificates between a device and server
US20110196989A1 (en) * 2005-10-27 2011-08-11 Research In Motion Limited Synchronizing certificates between a device and server
US8645684B2 (en) 2005-10-27 2014-02-04 Blackberry Limited Synchronizing certificates between a device and server
US7953971B2 (en) 2005-10-27 2011-05-31 Research In Motion Limited Synchronizing certificates between a device and server
US8099595B2 (en) 2005-10-27 2012-01-17 Research In Motion Limited Synchronizing certificates between a device and server
US8191105B2 (en) 2005-11-18 2012-05-29 Research In Motion Limited System and method for handling electronic messages
US20070118874A1 (en) * 2005-11-18 2007-05-24 Research In Motion Limited System and method for handling electronic messages
US8355701B2 (en) 2005-11-30 2013-01-15 Research In Motion Limited Display of secure messages on a mobile communication device
US20070123217A1 (en) * 2005-11-30 2007-05-31 Research In Motion Limited Display of secure messages on a mobile communication device
US20070123307A1 (en) * 2005-11-30 2007-05-31 Research In Motion Limited Display of secure messages on a mobile communication device
US7840207B2 (en) 2005-11-30 2010-11-23 Research In Motion Limited Display of secure messages on a mobile communication device
US8611936B2 (en) 2005-11-30 2013-12-17 Blackberry Limited Display of secure messages on a mobile communication device
US8473561B2 (en) 2006-06-23 2013-06-25 Research In Motion Limited System and method for handling electronic mail mismatches
US20070299921A1 (en) * 2006-06-23 2007-12-27 Research In Motion Limited System and method for handling electronic mail mismatches
US8943156B2 (en) 2006-06-23 2015-01-27 Blackberry Limited System and method for handling electronic mail mismatches
US7814161B2 (en) 2006-06-23 2010-10-12 Research In Motion Limited System and method for handling electronic mail mismatches
US8312165B2 (en) 2006-06-23 2012-11-13 Research In Motion Limited System and method for handling electronic mail mismatches
US7949355B2 (en) 2007-09-04 2011-05-24 Research In Motion Limited System and method for processing attachments to messages sent to a mobile device
US8315601B2 (en) 2007-09-04 2012-11-20 Research In Motion Limited System and method for processing attachments to messages sent to a mobile device
US20090061912A1 (en) * 2007-09-04 2009-03-05 Research In Motion Limited System and method for processing attachments to messages sent to a mobile device
US20110195690A1 (en) * 2007-09-04 2011-08-11 Research In Motion Limited System and method for processing attachments to messages sent to a mobile device
US8195128B2 (en) 2007-09-04 2012-06-05 Research In Motion Limited System and method for processing attachments to messages sent to a mobile device
US20090080661A1 (en) * 2007-09-24 2009-03-26 Research In Motion Limited System and method for controlling message attachment handling functions on a mobile device
US8804966B2 (en) 2007-09-24 2014-08-12 Blackberry Limited System and method for controlling message attachment handling functions on a mobile device
US8254582B2 (en) 2007-09-24 2012-08-28 Research In Motion Limited System and method for controlling message attachment handling functions on a mobile device
US20150016463A1 (en) * 2009-12-10 2015-01-15 Vocality International Ltd. Media over ip performance enhancement

Also Published As

Publication number Publication date
US20040008844A1 (en) 2004-01-15

Similar Documents

Publication Publication Date Title
McGrew et al. The secure real-time transport protocol (SRTP)
US7308575B2 (en) Data scrambling system for a shared transmission media
EP1223705B1 (en) Methods and systems for generating encryption keys using random bit sequences
ES2339742T3 (en) A technique for compressing a header field in a data packet.
US7397825B2 (en) Transport stream dejitterer
US7433472B2 (en) Digital content distribution system
US6141788A (en) Method and apparatus for forward error correction in packet networks
EP0987894B1 (en) A dejittering and clock recovery technique for real-time audio/visual network applications
US20030156715A1 (en) Apparatus, system and method for validating integrity of transmitted data
CN1030879C (en) Method and apparatus for maintaining continuous synchrounous encryption and decryption in a wireless communication system throughout a hand-off
EP1813115B1 (en) Buffering packets of a media stream
CN100550720C (en) Clock synchronisation over a packet network
CA2360785C (en) Multiple level public key hierarchy for performance and high security
US20010023454A1 (en) Codec-independent technique for modulating band width in packet network
US6901069B2 (en) Sub-packet insertion for packet loss compensation in voice over IP networks
US20020164024A1 (en) Data transmission method and data relay method
CN1906909B (en) Data reception device
US5966450A (en) Variable mask for encryption generated independently at communications stations
CA2087615C (en) Resynchronization of encryption systems upon handoff
US9071664B2 (en) Methods and apparatus for secure and adaptive delivery of multimedia content
JP4566488B2 (en) The estimation of the time stamp in the real-time packet communication
US20020172229A1 (en) Method and apparatus for transporting a synchronous or plesiochronous signal over a packet network
US6792111B1 (en) Cryptation system for packet switching networks based on digital chaotic models
US7450601B2 (en) Method and communication apparatus for controlling a jitter buffer
KR101258380B1 (en) Message synchronization over a stochastic network

Legal Events

Date Code Title Description
AS Assignment

Owner name: TELOGY NETWORKS, INC., MARYLAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIDE, DAVID;LI, DUNLING;REEL/FRAME:013126/0362

Effective date: 20020628

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553)

Year of fee payment: 12