Source: http://www.google.com/patents/US7831825?dq=5631832
Timestamp: 2014-12-29 01:32:07
Document Index: 362100485

Matched Legal Cases: ['Application No. 60', 'art 500', 'art 1000', 'art 1100', 'art 1300', 'art 1600']

Patent US7831825 - Packet-based and pseudo-packet based cryptographic communications systems ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsThe disclosed technology provides a system and method of securely communicating data. An encryptor located at a transmitter can provide encrypted data to the transmitter. The transmitter can maintain a packet number indicating a particular packet for carrying the encrypted data and a sub-packet number...http://www.google.com/patents/US7831825?utm_source=gb-gplus-sharePatent US7831825 - Packet-based and pseudo-packet based cryptographic communications systems and methodsAdvanced Patent SearchPublication numberUS7831825 B2Publication typeGrantApplication numberUS 11/076,215Publication dateNov 9, 2010Filing dateMar 9, 2005Priority dateMar 19, 2004Fee statusPaidAlso published asUS8234491, US20050210242, US20110173442Publication number076215, 11076215, US 7831825 B2, US 7831825B2, US-B2-7831825, US7831825 B2, US7831825B2InventorsWalter Clark Milliken, Gregory Donald TroxelOriginal AssigneeVerizon Corporate Services Group Inc., Raytheon Bbn Technologies Corp.Export CitationBiBTeX, EndNote, RefManPatent Citations (6), Referenced by (6), Classifications (15), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetPacket-based and pseudo-packet based cryptographic communications systems and methodsUS 7831825 B2Abstract The disclosed technology provides a system and method of securely communicating data. An encryptor located at a transmitter can provide encrypted data to the transmitter. The transmitter can maintain a packet number indicating a particular packet for carrying the encrypted data and a sub-packet number indicating a position within the packet where the encrypted data is to be stored. The encryptor can produce the encrypted data using an encryptor seed generated based on the packet number and sub-packet number. A receiver can maintain a receiver packet number indicating a number of previously received packets and can compute a receiver sub-packet number. The receiver can receive a packet containing encrypted data and can decrypt the encrypted data using a decryptor seed generated based on the receiver packet number and sub-packet number.
1. A method of securely communicating data, the method comprising:
first receiving bytes of encrypted data in a bit-stream;
determining a current pseudo-packet number based on a previous pseudo-packet number for previously received encrypted data;
storing said encrypted data as a pseudo-packet, and storing said current pseudo-packet number associatively with said pseudo-packet in a database including stored pseudo-packets and associated pseudo-packet numbers;
receiving a transmission containing second encrypted data and a second pseudo-packet number;
searching said database to obtain a match between said second encrypted data and a portion of one pseudo-packet of said stored pseudo-packets;
adjusting said current pseudo-packet number based on a relation between said second pseudo-packet number and a pseudo-packet number associated with said one pseudo-packet to obtain an adjusted pseudo-packet number wherein said adjusting further comprises:
determining an offset of said portion from a beginning of said one pseudo-packet;
comparing said offset to a byte adjustment value for incrementing said current pseudo-packet number; and
when said offset is not equal to said byte adjustment value, discarding a number of bytes of said encrypted data and setting said byte adjustment value to equal said offset; and
returning to said first receiving using the adjusted pseudo-packet number as the previous pseudo-packet number when additional data is communicated.
2. The method of claim 1, wherein said discarding further comprises:
discarding a number of bytes equal to said offset when said offset is less than said byte adjustment value; and
discarding a number of bytes equal to said offset less said byte adjustment value when said offset is greater than said byte adjustment value. Description
RELATED APPLICATIONS This application claims priority to, and incorporates by reference, the entire disclosure of U.S. Provisional Patent Application No. 60/554,789, filed on Mar. 19, 2004. This application is co-pending with a related patent application Ser. No. 11/076,216 entitled �Packet-Based And Pseudo-Packet Based Cryptographic Synchronization Systems And Methods�, by the same inventors and having assignee in common, filed concurrently herewith and incorporated by reference herein in its entirety.
REFERENCE TO GOVERNMENT FUNDING The disclosed technology received funding under U.S. Government Contract No. MDA904-03-C-0969. The Government may have certain rights in the application.
In the most basic cryptographic systems and methods, an encryptor employs an encryption method that is known to a corresponding decryptor, which employs a decryption counter-method. An example of a primitive encryption method is a codebook, which for example contains rules for replacing instances of a particular character with another character. Consider a codebook with three rules that replace occurrences of �a� with �c�, �c� with �g�, and �g� with �a�. According to such a codebook, the word �grace� when encrypted would then become �arcge�, which would seem to be unintelligible to an observer having no knowledge of the codebook rules. However, an observer having an opportunity to observe multiple encrypted words or sentences may be able to recognize patterns/repetitions in the observations and/or may be able to decipher an encrypted word based on context. For example, utilizing the same codebook, the words �he walked with grace and dignity� becomes �he wclked with arcge cnd dianity�, which can be more readily recognized by the context and pattern of surrounding characters. An attempt to decipher encrypted messages without full knowledge of the encryption method is known as code breaking.
As code breaking efforts have become more effective, efforts to develop more complex cryptographic systems and methods have also improved. FIG. 1 shows an encryptor 102 and a decryptor 104 that utilize a �seed� value 106 to perform their respective encryption and decryption tasks. A seed value 106 can be used to initialize an encryption method and/or can be used during an encryption method 102, such that aside from code breaking, a message 108 encrypted using a particular seed value 106 can be deciphered only if the decryptor 104 also utilizes the same seed value 106. Thus, one manner in which data security can be improved involves periodically altering the seed value 106 provided to an encryptor and a decryptor. An encryptor and a decryptor are often located remotely with respect to each other, and rather than communicating a seed value from an encryptor to a decryptor, current implementations can provide the seed values 206, 208 by independently maintaining them at the encryptor 202 and at the decryptor 204, as shown in FIG. 2, thereby decreasing the risk of an unintended recipient learning the seed values.
In some cases, the problem can be mitigated by using a receiver communications protocol that is able to recognize when such data loss/data corruption occurs. However, in other cases, a receiver 214 will not always be able to recognize when encrypted data 216 becomes lost in transmission. Further, a receiver 214 may in some instances discard data that has been corrupted. In either case, the decryptor 204 generally does not receive any notification that a problem has occurred and continues to generate seed values 208 as before. Accordingly, in case of packet loss, a decryptor 204 may inadvertently apply a particular seed value to decrypt a non-corresponding encrypted data in place of a corresponding encrypted data that was never received, which can cause subsequently received data to also be decrypted using incorrect seed values. When a decryptor uses an incorrect seed value to decipher an encrypted message, the decryptor is said to be �unsynchronized�.
SUMMARY The disclosed technology provides systems and methods of securely communicating data. An encryptor located at a transmitter can provide encrypted data to the transmitter. The transmitter can maintain a packet number indicating a particular packet for carrying the encrypted data and a sub-packet number indicating a position within the packet where the encrypted data is to be stored. The encryptor can produce the encrypted data using an encryptor seed generated based on the packet number and sub-packet number. A receiver can maintain a receiver packet number indicating a number of previously received packets and can compute a receiver sub-packet number. The receiver can receive a packet containing encrypted data and can decrypt the encrypted data using a decryptor seed generated based on the receiver packet number and sub-packet number.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram of a cryptographic system for encrypting and decrypting data based on a seed value;
The encrypted data 308 is provided to a transmitter 310 to be transmitted. The transmitter can operate based on one or more communications protocols, such as, but not limited to, Asynchronous Transfer Mode (ATM), Synchronous Optical Network (SONET), Internet Protocol (IP), and Optical Transport Network (OTN). As used herein, a �packet� refers to a grouping of bits having control information coupled to non-control data, and can correspond to an ATM cell, an OTN frame, a SONET frame/super-frame, a Multiprotocol Label Switching (MPLS) packet, and an IP packet, among others. The transmitter can maintain packet numbers that correspond to individual transmitted packets, where the current packet number 312 maintained at the transmitter 310 corresponds to the next packet 314 to be transmitted. The next packet 314 may be empty or partially filled, and thus, encrypted data 308 may be placed into the packet 314 at the beginning of the packet payload or at another position within the packet. The transmitter 310 can monitor this position by maintaining a sub-packet number 316 which can be, for example, the next available bit location in the packet 314 or the number of existing groups of bits currently in the packet. Thus, by maintaining a packet number 312 and a sub-packet number 316, a transmitter 310 can possess fore-knowledge about the particular packet 314 and the particular position within the packet 314 where encrypted data 308 is to be placed.
Referring now to FIGS. 4A-4D, there is shown a number of packet arrangements for carrying encrypted data. A packet is formatted according to a particular communications protocol and generally includes a control information portion 402 coupled to a non-control �data.� Depending on the communications protocol used, a packet can carry a fixed amount of data or can carry a variable amount of data. For ease of explanation, it is assumed that packets referred to herein contain a fixed amount (e.g., fixed number of bytes) of data.
As previously provided herein, an encryptor 302 according to FIG. 3 uses an encryptor seed 306 that is generated based on a transmitter packet number 312 and a sub-packet number 316. In the illustrated example of FIGS. 4A-4D, the packet number can be initialized to �one� such that the first packet communicated by the transmitter can correspond to a packet number of �one�. Subsequently, packets that are communicated can correspond to packet numbers of �two�, �three�, �four�, etc. The sub-packet numbers in the illustrated example correspond to a byte-position within a particular packet where encrypted data can be stored. In the illustrated example, a sub-packet number of �zero� corresponds to the first available position in a packet. Accordingly, shown in FIG. 4A is a packet containing one-hundred fifty bytes of data 404 that was encrypted using an encryptor seed value that was generated using packet number=�one� and sub-packet number=�zero�. An encryptor seed value is denoted herein as SEED (packet number, sub-packet number) and is thus SEED (1,0). The encrypted data 404 is stored in the packet beginning at position zero, corresponding to a sub-packet number of zero. The packet can contain a maximum of one-hundred fifty bytes of data, so there is no remaining space in the packet.
In an embodiment shown in FIG. 4B, an encryptor can produce fifty bytes of encrypted data for each encryptor seed. The first fifty bytes of encrypted data 406 are produced using encryptor seed value SEED (1,0) and are stored in the packet. The packet can contain a maximum of one-hundred fifty bytes and thus has available space to carry more data. Accordingly, the packet number remains the same while the sub-packet number is updated to be �fifty.� The next encryptor seed is thus SEED (1,50) and is used to produce the next fifty bytes of encrypted data 408. After the second fifty bytes of encrypted data are stored in the packet, the sub-packet number is updated to be �one-hundred.� Then, the last fifty bytes of data 410 are encrypted based on SEED (1,100) and are stored in the remaining space of the packet.
Although the three fifty-byte blocks of encrypted data in FIG. 4B were stored into a single packet, the packet space for holding data may not always be a multiple of the amount of encrypted data per encryptor seed. For example, as shown in FIG. 4C, an encryptor can produce sixty bytes of encrypted data for each encryptor seed. The first and second sixty-byte groups of encrypted data 412, 414 can be stored in packet number �one�, but the third sixty-byte group 416 a, 416 b must be partitioned to be partially stored in packet number �one� 416 a and partially stored in the next packet, packet number �two� 416 b. Even so, the entire sixty-byte group of encrypted data 416 a, 416 b is encrypted based on the same seed value SEED (1,120). As shown in the figure, the next two sixty-byte groups 418, 420 are encrypted using seed values SEED (2,30) and SEED (2,90), respectively, and both are able to be completely stored in packet number �two.�
In one embodiment, an encryptor may produce a number of bytes of encrypted data per encryptor seed that is greater than the maximum space in a packet. Accordingly, as previously discussed, such encrypted data can be partitioned and stored into two or more separate packets. As shown in FIG. 4D, an encryptor can produce one-hundred eighty bytes of encrypted data 422 a, 422 b using seed value SEED(1,0). Thirty bytes of this data 422 b is stored in packet number �two�, which then has space to store one-hundred twenty bytes 424 a of encrypted data produced from SEED (2,30), and so on.
Referring now to FIG. 5, there is shown a flow chart 500 of an exemplary method for encrypting and transmitting data. The encryptor methodology is located on the left hand side of FIG. 5 and the transmitter methodology is located on the right hand side. In the exemplary method, the encryptor and transmitter are separate and are in communication with each other. Even so, as previously described, an encryptor can be a component within the transmitter in other embodiments. As shown in the FIG. 5 method 500, the transmitter initializes its packet number and the sub-packet number 502. In one embodiment, the packet number can be initialized to �one� to indicate that the current packet to be filled is the first packet, and the sub-packet number can be initialized to �zero.� In another embodiment, a packet number of �zero� can correspond to the first packet, and a sub-packet number of �one� can correspond to the first position within a packet.
In the embodiment of FIG. 5, the transmitter communicates encrypted data to a receiver in one or more packets. For the current packet, the transmitter can determine if the amount of encrypted data to be transmitted can fit into the packet 516. If the amount of encrypted data to be transmitted is greater than the remaining space in the current packet 516 a, the transmitter can fill the remaining space with a portion of the encrypted data 518, transmit the filled packet, and increment the packet number by �one� 520 to designate a new, empty packet. The transmitter can then check if the remaining encrypted data fits into this new, empty packet 516. If the amount of encrypted data is less than or equal to the remaining space in the current packet 516 b, the transmitter can place all of the encrypted data into the packet 522. If this results in the packet becoming full 524 a (e.g., no remaining space), the transmitter can transmit the full packet 526, and then increment the packet number by �one� and reset the sub-packet number to �zero� 528. If the transmitter determines that the packet is not full 524 b, then the packet number remains unchanged while the sub-packet number is updated to reflect the next available position in the packet for storing data 528. When all of the encrypted data has been placed in packets and/or transmitted, the encryptor can then receive more unencrypted data to be encrypted 504.
As shown in FIG. 9A, the receiver 912 is in possession of a transmit-side label 918 having a transmitter packet number of nine-hundred four and an encrypted data portion of �D�. The receiver 912 can access the memory 914 to search for a receive-side label having the same encrypted data portion �D� and locates such a receive-side label 903. The located receive-side label 903 has a packet number of nine-hundred three, which the receiver recognizes is not the same as the transmitter packet number in the transmit-side label 918. Thus, based on the discrepancy, the receiver 912 can conclude that the value of its current receiver packet number 916 reflecting a value of nine-hundred and eight is incorrect and that the decryptor is unsynchronized. In one embodiment, the receiver can attempt to resynchronize the decryptor by adjusting its receiver packet number. The receiver can adjust the value of the receiver packet number 916 by the amount of the difference between the transmitter packet number in the transmit-side label 918 and the receiver packet number in the receive-side label 903, which in the illustrated example is a difference of �one.� Accordingly, as shown in FIG. 9B, the value of the receiver packet number 916 is increased by �one� to nine-hundred and nine. In one embodiment, the receiver 912 can adjust the value of its receiver packet number 916 based on more than one transmit-side label. For example, referring again to FIG. 9A, the receiver 912 can adjust the value of the receiver packet number 916 after confirming, from receiving multiple transmit-side labels, that the value of the receiver packet number 916 is indeed incorrect.
It is possible that because there was a discrepancy between the transmit-side label 918 and its corresponding receive-side label 903, there will also be a discrepancy between receive-side labels 905-908 and their corresponding transmit-side labels, if any are received. If these subsequent discrepancies also have a packet number difference of �one,� the receiver 912 need not adjust the value of the receiver packet number 916 again since it was already adjusted based on transmit-side label 918. To recognize this situation, the receiver can maintain a total adjustments number 920 that represents the largest discrepancy between a transmitter packet number and a receiver packet number that has been accounted for. As shown in FIGS. 9A and 9B, the value of total adjustments 920 was �zero� in FIG. 9A before any adjustment was made and �one� in FIG. 9B after the adjustment is made. Thus, if a subsequent transmit-side label corresponding to one of the receive-side labels 905-908 is received, another adjustment to the receiver packet number 916 should be made only if the subsequent difference in packet number is greater than the value of total adjustments 920.
The receive-side labels can be stored in the memory in a number of ways. In one embodiment, a receive-side label can be stored in a memory location/address using a hash function. Many types of hash functions are well-known and can be used here. For example, a hash function can take the encrypted-data portion of a receive-side label and produce a memory address that is unique to the particular encrypted-data portion. Accordingly, there can be a one-to-one association between possible encrypted-data portions and memory addresses. Thus, the receiver can store the receiver packet number in a memory location produced by the hash function without storing the encrypted-data portion itself, since the receiver packet number is intrinsically associated with the encrypted-data portion by being stored in the particular memory location. In the case where a hash function does not provide a one-to-one association between encrypted-data portions and memory addresses, the hash function can produce the same memory address for different encrypted-data portions, which is referred to as a �collision.� The manners in which collisions are handled are well known and can be applied here. In one embodiment, when a transmit-side label received by the receiver corresponds to a memory address subject to collision, the incoming transmit-side label can be dropped. The dropping of the transmit-side label can result in a perceived need for an adjustment in the receiver to correct the supposed synchronization error that results from the dropped transmit-side label being missing from the hash table. However, by requiring multiple sequential labels to indicate the same receive count error, the potential adjustment can be made as improbable as desired.
Referring now to FIGS. 10A and 10B, there is shown a flow chart 1000 of an exemplary method of receiving packets and of maintaining packet numbers and sub-packet numbers at a receiver. The receiver can be initialized by setting its continuing flag value to �zero� and its group size value to a default value 1001. The continuing flag and group size values are used by the receiver to derive the correct sub-packet number and will be described below. The receiver can receive packets from an encrypted data channel 1002. Upon receiving a packet, the receiver can increment the receiver packet number by �one� 1004 and set the sub-packet number to �zero� 1006. The receiver then checks the value of the continue flag 1008. The continue flag can assume one of two values and is a true/false indicator of whether the encrypted data beginning at location �zero� of the received packet was encrypted using the same seed value as data in the previous packet. If the continue flag equals �zero,� it indicates that the encrypted data was encrypted using a new seed value, and the receiver generates a new decryptor seed value SEED (receiver packet number, 0) 1008 a. If the continue flag equals �one,� it indicates that the encrypted data was encrypted using the same decryptor seed as data from the previous packet, and the receiver does not generate a new seed value. Regardless of the value of the continue flag, the receiver forms a receive-side label containing the receiver packet number and an initial portion of the encrypted data in the received packet and stores the receive-side label in memory 1010.
With reference to FIG. 10B, the receiver maintains a group size value that indicates the amount of encrypted data, still to be retrieved from one or more packet(s), that was encrypted using the current seed value. The receiver can compare the group size value to the amount of encrypted data (remaining) in the packet 1012. If the group size is greater than the amount of encrypted data 1012 a, the receiver provides the entirety of the data to the decryptor 1014, reduces the group size value by the amount provided to the decryptor, and sets the continuing flag value to �one� 1016. The receiver then waits to receive another packet 1002. Thus, when the next packet arrives 1002, the receiver will recognize that an amount of data equal to the group size value was encrypted using the same seed value as the previous packet's data. If the group size value is less than or equal to the amount of encrypted data in the packet 1012 b, the receiver can provide an amount of data equal to the group size value to the decryptor 1018. The receiver can update the sub-packet number by increasing it by the group size value and can then set the group size to a default value 1020. As previously discussed, this �default value� indicates the amount of encrypted data to retrieve for the next decryptor seed value. The default value can be a fixed value, or it can be variable and can be computed by the receiver.
The packet could now be in one of two possible situations. The packet may be empty 1022 a, or the packet may still contain encrypted data to be decrypted 1022 b. The receiver makes this determination 1022, and if the packet is empty 1022 a, the receiver sets the continuing flag to �zero� 1024 and waits to receive the next packet 1002. When the next packet is received 1002, the receiver will recognize that continuing flag is �zero� and will generate a new decryptor seed 1008. If the receiver determines that there is still data in the packet to be decrypted 1022 b, the receiver can generate a new decryptor seed 1026 for the remaining data based on the receiver packet number, which has not changed for the current packet, and the sub-packet number, which was previously updated 1020. Then, the receiver again compares the group size value to the amount of encrypted data remaining in the packet 1012, repeating the receiver method starting from that comparison.
As shown in the exemplary method of FIGS. 10A to 10B, a new decryptor seed is calculated in two situations. In the first situation, the receiver receives a new packet and recognizes that the continue flag is �zero� 1008, which indicates that the encrypted data in the new packet was encrypted using a different seed value than the encrypted data in the previous packet. In this situation, the receiver packet number and sub-packet number were just updated 1004, 1006, and the new calculated decryptor value is SEED (receiver packet number, 0). In the second situation, the receiver has just provided the decryptor with all of the encrypted data corresponding to the current seed value 1018 and there is remaining data in the current packet corresponding to a new seed value 1022 b. In this situation, the receiver packet number remains unchanged and the sub-packet number was already updated to reflect the starting position of the remaining data 1020. Then, before the receiver provides the encrypted data to the decryptor, it calculates the new seed value 1026 based on the unchanged packet number and the updated sub-packet number. Based on this exemplary method, the different packet arrangements shown in FIGS. 4A through 4D can be properly received.
Referring now to FIG. 11A, there is shown a flow chart 1100 of an exemplary method of detecting whether a decryptor is unsynchronized. As previously discussed, a transmitter can periodically transmit a transmit-side label to allow a receiver to recognize when a decryptor is unsynchronized. A receiver can receive a transmit-side label 1102 having a transmitter packet number and an encrypted-data portion. The transmit-side label can arrive either before or after its corresponding packet is/was received by the receiver. In the illustrated embodiment, the receiver can determine whether the packet corresponding to a transmit-side label should have arrived by comparing the transmit-side label packet number with the receiver packet number 1103. If the transmit-side label packet number is greater than the receiver packet number 1103 a, the receiver can wait to receive another packet 1136 and then make the comparison again. The receiver may not actually �wait,� but rather can place the transmit-side label in a queue until the next packet is received. If the transmit-side label packet number is equal to or less than the receiver packet number 1103 b, the receiver can access memory to search for a receive-side label containing the same encrypted-data portion as that in the transmit-side label 1104. If such a receive-side label is located 1106 a, the receiver computes the difference between the transmitter packet number of the transmit-side label to the receiver packet number of the receive-side label 1108. The receiver can compare this difference to a total adjustment value maintained by the receiver 1110. As previously discussed with respect to FIGS. 9A and 9B, the total adjustment value represents the difference between the transmitter packet number and the corresponding receiver packet number that has already been accounted for. Accordingly, if the difference is equal to the total adjustment value 1110 a, the difference has already been accounted for and the receiver need not make any adjustments to the receiver packet number, where this method of detecting if a decryptor is unsynchronized ends. If the difference is greater than the total adjustment value 1110 b, the receiver has not yet accounted for all of the difference and can therefore adjust the current receiver packet number based on the difference 1114. In a third scenario, the difference can be less than the total adjustment value 1110 c. In this 1110 c scenario, the difference may be less than the total adjustment value because the receiver packet number from the receive-side label was a number that resulted from a previous adjustment by the receiver based on a previous transmit-side label, indicating that an attempt to resynchronize the decryptor occurred before the receive-side label was formed. In this case, the total adjustment value can be reset to �zero� 1112 and the difference can again be compared to the total adjustment value (now �zero�) 1110.
Shown in FIG. 11B is a flow chart of an exemplary method of adjusting the receiver packet number so that the receiver can also have the correct group size value and continue flag value. The flow chart of FIG. 11B continues from FIG. 11A and is analogous to FIGS. 10A and 10B in that each increase to the receiver packet number can be treated as if a new packet is received. However, since no new packet is actually received, the adjustment method maintains a �remaining data� value representative of the amount of data that would have been received in an actual packet. No encrypted data is provided to the decryptor, and the receiver does not form any receive-side labels. Also, the total adjustment value is increased by �one� 1116. For every increase in the total adjustment value by �one�, the receiver packet number 1118 is increased. Other than these differences, the adjustment methodology of FIG. 11B is otherwise the same as FIGS. 10A and 10B. For example, the sub-packet number is set to zero 1120 and the remaining data is set to the maximum packet size 1122. If the group size is greater than the remaining data 1124, then the group size is reduced by the size of the remaining data and the continuing flag is set to �one� 1126 and the method returns to 1110. If not, the sub-packet number is increased by the group size, the remaining data is decreased by the group size, and the group size is set to the default 1128. If the remaining data is not greater than zero 1130, than the continuing flag is set to zero 1132 and the method returns to 1110. If the remaining data is greater than zero, a new decryptor seed is then generated based on the packet number and sub-packet number 1134 and the method returns to 1124.
A = int ( P � int ( R � N P ) N + 1 ) , and B = mod ( P � int ( R � N P ) N ) where int(x) returns the highest integer less than x, and mod(x/y) returns the integer remainder of (x/y). Using these formulas, A and B are the packet number and sub-packet number, respectively, to use for generating the decryptor seed for decrypting the encrypted data in the next packet (R+1). Further, the number of bits already retrieved for the generated decryptor seed is (N−B), and the number of bits still to be retrieved (e.g., group size value) from the next packet is (P−(N−B)). Thus, to resynchronize the decryptor, a receiver can set the receiver packet number to assign to the next packet to (R+1), compute the decryptor seed based on A and B, set the group size value to (P−(N−B)), and set the continue flag value to �one� if A<(R+1) or to �zero� if A=(R+1). Using the formula for A in the example, in no case will A be greater than (R+1).
The disclosed technology can be applied to bit-streams in much the same way that it can be applied to packets. As previously described, a packet number can be associated with a packet containing a particular amount of encrypted data, and a sub-packet number can indicate the position in the packet where the encrypted data begins. Although the encrypted data in a bit-stream is not partitioned into packets, the same amount of encrypted data in a portion of a bit-stream, as would appear in a packet, can still be associated with a packet number. As used herein, a packet number applied to a group of encrypted data in a bit-stream is referred to as a �pseudo-packet number,� and the corresponding group of encrypted data is referred to as a �pseudo-packet.�
Shown in FIGS. 12A and 12B are bit-streams containing pseudo-packets of encrypted data. In one embodiment, a pseudo-packet can contain a fixed amount of encrypted data, and a sub-packet number can correspond to a beginning position in the pseudo-packet where the encrypted data is located. A transmitter can maintain the pseudo-packet number and the sub-packet number, and an encryptor seed value can be computed based on these numbers. Referring to FIG. 12A, there is shown a pseudo-packet number �one� containing one-hundred fifty bytes of encrypted data 1202-1206, and an initial portion of pseudo-packet number �two.� As shown, each seed value can be used to produce fifty bytes of encrypted data. Accordingly, the initial three fifty-byte groups 1202-1206 are encrypted based on SEED (1,0), SEED (1,50), and SEED (1,100), respectively. The three groups of encrypted data 1202-1206 fit into one pseudo-packet, and in this example, no encrypted data is carried over into the next pseudo-packet. Thus, the next fifty-byte group of data 1208 is encrypted based on SEED (2,0), and so on. Referring now to FIG. 12B, each seed value in the illustrated embodiment can be used to produce sixty bytes of encrypted data. The initial three sixty-byte groups of encrypted data 1210-1214 are produced based on SEED (1,0), SEED (1,60), and SEED (1,120), respectively. In the group of encrypted data 1214 corresponding to SEED (1,120), thirty bytes are located in pseudo-packet number �one� and the other thirty bytes are located in pseudo-packet number �two.� Thus, the next sixty-byte group data would be encrypted based on SEED (2, 30).
Referring now to FIG. 13, there is shown a flow chart 1300 of an exemplary method of encrypting data and transmitting the encrypted data in a bit-stream. The encryptor methodology is shown on the left hand side of FIG. 13, and the transmitter methodology is shown on the right hand side. A transmitter initializes its pseudo-packet number and the sub-packet number 1302. In one embodiment, the pseudo-packet number can be initialized to �one� to indicate that newly produced encrypted data currently fall within the first pseudo-packet, and the sub-packet number can be initialized to �zero.� An encryptor can receive an arbitrary amount of unencrypted data to be encrypted 1304. When the encryptor is ready to begin encrypting data, it can provide a request to the transmitter for a pseudo-packet number and a sub-packet number 1306. In response, the transmitter can access the current values for those numbers and provide those values to the encryptor 1308 or to an encryptor seed generator, which can be separate from or part of the encryptor. The encryptor or the seed generator can then generate the encryptor seed 1310 based on the received pseudo-packet number and sub-packet number. The encryptor then uses the encryptor seed to encrypt the unencrypted data 1312 and provides the resulting encrypted data to the transmitter 1314.
In the embodiment of FIG. 13, the transmitter communicates encrypted data to a receiver in a bit-stream. One of ordinary skill in the field of digital communications will recognize that while the transmitter can transmit the encrypted data one bit at a time, a transmitter can also transmit a group of bits at a time using what is known as �symbols,� where each distinct group of bits is represented by a different symbol. If the transmitter communicates one bit at a time, then each bit in the stream will be spaced the same amount of time apart, so that the receiver can read the stream at a fixed frequency. Similarly, if the transmitter communicates a group of bits at a time using symbols, each symbol in the stream will be spaced the same amount of time apart, so that the receiver can read the stream of symbols at a fixed frequency. The exemplary transmitter of FIG. 13 transmits one-byte (e.g., eight bits) of encrypted data at a time 1316, and thus, communicates the encrypted data using symbols. Because the transmitter communicates the symbols at a fixed frequency, the transmitter therefore must update the pseudo-packet number and sub-packet number 1318-1324 after transmitting a symbol and before transmitting the next symbol. As shown in FIG. 13, after the transmitter communicates one-byte of encrypted data 1316, it increases the sub-packet number by �one� 1318 and determines whether the sub-packet number is at the end of the current pseudo-packet 1320. If so 1320 a, the transmitter increases the pseudo-packet number by �one� 1322 and resets the sub-packet number to �zero� 1324. In both cases 1320 a, 1320 b, the transmitter determines whether there is still more encrypted data to communicate 1326. If there is more data to communicate 1326 a, the transmitter again transmits one-byte of encrypted data 1316 and repeats the pseudo-packet number and sub-packet number update process. If there is no more encrypted data to decrypt 1326 b, the encryptor can wait to receive more unencrypted data 1304.
As the bit-stream is communicated to the receiver, the bits and symbols in the stream, like packets, are susceptible to corruption by noise. However, the receiver reads bits/symbols from the stream at a fixed frequency regardless of whether the bits/symbols have been corrupted. Accordingly, even though the received encrypted data may not be entirely correct, the decryptor will continue to be synchronized. Referring now to FIGS. 14A and 14B, a problem can occur during transmission of encrypted data in a bit-stream 1402 when heavy traffic and/or equipment failure causes the bit-stream to be re-routed to a different path to the receiver. The re-routing can take a certain amount of time to occur, which results in the introduction of a �time gap� 1404 into the bit-stream received by the receiver that does not correspond to any encrypted data 1402. However, the receiver is unaware of the re-routing and continues to read incoming �data� at a fixed frequency during the gap 1404. The receiver is not actually receiving encrypted data and is, in effect, erroneously increasing its sub-packet number and/or pseudo-packet number. As a result, the receiver pseudo-packet number and/or sub-packet number can become mismatched with respect to the transmitter pseudo-packet boundaries in the bit-stream, as shown in FIG. 14B, such that the receiver may regard the middle (or another portion) of a transmitted pseudo-packet as the beginning of a received pseudo-packet. In another scenario, as shown in FIG. 14C, a problem can occur where bits in a bit-stream are lost 1406, which can happen when, for example, the frequency at which the receiver reads the data �slips.� Thus, a receiver cannot be relied upon to know the correct boundaries of the pseudo-packets in a bit-stream. Accordingly, forming a receive-side label containing what a receiver regards as an initial portion of a received pseudo-packet can be ineffective.
Referring now to FIG. 15A, there is shown a pseudo-packet number �two� 1502 containing the encrypted data �MNOPQRSTUVW.� As shown in FIG. 15B, the transmitter can form a transmit-side label 1504 containing the transmitter pseudo-packet number 1506 and an initial portion of the corresponding pseudo-packet encrypted data 1508. Suppose that this initial portion 1508 is �MNOP.� Referring again to the illustrated example in FIG. 14B, a time gap can be introduced into the bit-stream containing pseudo-packet number �two� during transmission, such that the a time gap is introduced immediately before pseudo-packet number �two� in the bit-stream. Accordingly, the receiver can be unaware of the time gap and can regard the time gap as being part of pseudo-packet number �two.� Thus, referring again to FIG. 15B, the initial portion �MNOP� of the transmitted pseudo-packet number �two� 1508 now appears in the middle of the received pseudo-packet number �two.� In one embodiment as shown in FIG. 15C, a receive-side label 1510 can be formed to contain the entirety of the encrypted data in a received pseudo-packet 1514. Accordingly, although a received encrypted data 1514 may contain a time gap, the time gap �xxxx� can be stored in a receive-side 1510 label along with a portion of the actual, transmitted pseudo-packet �MNOPQRS�. When the transmit-side label 1504 arrives at the receiver, the receiver can determine whether the encrypted data portion �MNOP� in the transmit-side label 1508 appears anywhere within the stored pseudo-packet 1514 of a receive-side label 1510. Since the receive-side labels contain the entirety of received pseudo-packets, the receiver can find �MNOP� 1508 in a portion of received encrypted data 1514.
Referring now to FIG. 16, shown is a flow chart 1600 of an exemplary method of receiving encrypted data from a bit-stream. The receiver can be coordinated with the transmitter such that the receiver receives symbols at a fixed frequency. In the exemplary method of FIG. 16, each symbol represents one-byte of encrypted data 1602. The received byte of encrypted data is stored in the current receive-side label 1604, and the sub-packet number is increased by �one� 1606. The receiver can determine whether the received byte is the last one of the current pseudo-packet 1608. If the sub-packet number has reached the end of the current pseudo-packet 1608 a, the pseudo-packet number is increased by �one� to designate the next pseudo-packet 1610, and the sub-packet number is reset to �zero� 1612. Also, the current receive-side label is stored in memory 1614, and a new receive-side label is formed to contain the updated pseudo-packet number 1616. In either case 1608 a, 1608 b, the group size number is decreased by one to reflect that a byte of encrypted data was received 1618. The receiver can determine whether a new decryptor seed needs to be calculated by checking if the updated group size is zero 1620. If the group size number is equal to zero 1620 a, the receiver calculates a new decryptor seed 1622, resets the group size value to a default group size value 1624, and waits to receive the first byte of encrypted data for the new decryptor seed 1602. If the group size value is not zero 1620 b, the receiver can wait to receive another byte of encrypted data for the current decryptor seed 1602. Note that the group size may not reach zero at a pseudo-packet boundary. Accordingly, as shown in FIG. 16, a receiver can determine when a pseudo-packet boundary is reached 1608 separately from when it determines if the group size is zero 1620.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5319712 *Aug 26, 1993Jun 7, 1994Motorola, Inc.Method and apparatus for providing cryptographic protection of a data stream in a communication systemUS5528693 *Jan 21, 1994Jun 18, 1996Motorola, Inc.Method and apparatus for voice encryption in a communications systemUS6697490Oct 19, 1999Feb 24, 2004Lucent Technologies Inc.Automatic resynchronization of crypto-sync informationUS7043022 *Nov 22, 1999May 9, 2006Motorola, Inc.Packet order determining method and apparatusUS7243202Mar 27, 2002Jul 10, 2007Stmicroelectronics LimitedSearching for packet identifiersUS20040131014 *Jan 3, 2003Jul 8, 2004Microsoft CorporationFrame protocol and scheduling system* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS8218768 *Mar 25, 2002Jul 10, 2012Qualcomm IncorporatedCryptosync design for a wireless communication systemUS8364808 *Sep 28, 2006Jan 29, 2013Seiko Epson CorporationDevice management systemUS8423789May 22, 2008Apr 16, 2013Marvell International Ltd.Key generation techniquesUS20030206538 *Mar 25, 2002Nov 6, 2003Ramin RezaiifarCryptosync design for a wireless communication systemUS20070262138 *Apr 3, 2006Nov 15, 2007Jean SomersDynamic encryption of payment card numbers in electronic payment transactionsUS20140133653 *Oct 17, 2012May 15, 2014Cisco Technology, Inc.Timeslot Encryption in an Optical Transport Network* Cited by examinerClassifications U.S. Classification713/160, 380/260, 713/162International ClassificationH04K1/04, H04L29/06, H04L9/12Cooperative ClassificationH04L63/18, H04L63/0428, H04L63/16, H04L9/0891, H04L9/12European ClassificationH04L9/12, H04L63/04B, H04L63/18, H04L63/16Legal EventsDateCodeEventDescriptionJul 28, 2014ASAssignmentFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VERIZON CORPORATE SERVICES GROUP INC.;REEL/FRAME:033421/0403Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEYEffective date: 20140409Apr 9, 2014FPAYFee paymentYear of fee payment: 4Jun 11, 2010ASAssignmentOwner name: RAYTHEON BBN TECHNOLOGIES CORP.,MASSACHUSETTSFree format text: CHANGE OF NAME;ASSIGNOR:BBN TECHNOLOGIES CORP.;REEL/FRAME:24523/625Effective date: 20091027Free format text: CHANGE OF NAME;ASSIGNOR:BBN TECHNOLOGIES CORP.;REEL/FRAME:024523/0625Owner name: RAYTHEON BBN TECHNOLOGIES CORP., MASSACHUSETTSDec 4, 2008ASAssignmentOwner name: BANK OF AMERICA, N.A., MASSACHUSETTSFree format text: INTELLECTUAL PROPERTY SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:BBN TECHNOLOGIES CORP.;REEL/FRAME:021926/0017Effective date: 20081124Owner name: BANK OF AMERICA, N.A.,MASSACHUSETTSFree format text: INTELLECTUAL PROPERTY SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:BBN TECHNOLOGIES CORP.;US-ASSIGNMENT DATABASE UPDATED:20100316;REEL/FRAME:21926/17Free format text: INTELLECTUAL PROPERTY SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:BBN TECHNOLOGIES CORP.;US-ASSIGNMENT DATABASE UPDATED:20100413;REEL/FRAME:21926/17Free format text: INTELLECTUAL PROPERTY SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:BBN TECHNOLOGIES CORP.;REEL/FRAME:21926/17RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google