Source: http://www.google.com/patents/US20080037775?dq=6,202,008
Timestamp: 2016-05-06 19:28:30
Document Index: 496815974

Matched Legal Cases: ['arty 120', 'arty 124', 'arty 120', 'arty 124', 'arty 120', 'arty 120', 'arty 124', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120']

Patent US20080037775 - Verifiable generation of weak symmetric keys for strong algorithms - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsThe present invention provides a method, system, and device for producing cryptographic keys. More specifically, the cryptographic keys may be produced such that they have an effective key size and an apparent key size that differs from the effective key size. Generally, the effective key size is not...http://www.google.com/patents/US20080037775?utm_source=gb-gplus-sharePatent US20080037775 - Verifiable generation of weak symmetric keys for strong algorithmsAdvanced Patent SearchPublication numberUS20080037775 A1Publication typeApplicationApplication numberUS 11/395,877Publication dateFeb 14, 2008Filing dateMar 31, 2006Priority dateMar 31, 2006Also published asCA2573436A1, CN101047499A, EP1841121A1Publication number11395877, 395877, US 2008/0037775 A1, US 2008/037775 A1, US 20080037775 A1, US 20080037775A1, US 2008037775 A1, US 2008037775A1, US-A1-20080037775, US-A1-2008037775, US2008/0037775A1, US2008/037775A1, US20080037775 A1, US20080037775A1, US2008037775 A1, US2008037775A1InventorsRobert R. GilmanOriginal AssigneeAvaya Technology LlcExport CitationBiBTeX, EndNote, RefManPatent Citations (36), Referenced by (13), Classifications (5), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetVerifiable generation of weak symmetric keys for strong algorithms
US 20080037775 A1Abstract
The present invention provides a method, system, and device for producing cryptographic keys. More specifically, the cryptographic keys may be produced such that they have an effective key size and an apparent key size that differs from the effective key size. Generally, the effective key size is not restricted by export regulations and the apparent key size may be restricted by export regulations.
1. A method for producing a cryptographic key, comprising:
a communication device generating a first key having a first apparent size and a first effective size that is less than a predetermined key size; determining a fixed key; choosing a fixed cryptographic algorithm; using the fixed key and the chosen algorithm to project the first key onto a second larger key space to create a second key, wherein the second key has a second apparent size that is larger than the predetermined key size and the first effective size that is less than the predetermined key size; and distributing the second key to at least one recipient communication device. 2. (canceled)
3. The method of claim 1, wherein the projection of the first key comprises employing at least one of an asymmetric encryption algorithm and a cryptographic hash algorithm that utilizes the fixed key.
4. The method of claim 1, wherein the projection of the first key comprises employing a symmetric encryption algorithm that utilizes the fixed key.
5. The method of claim 1, wherein the at least one recipient communication device comprises an authorized third party communication device, the method further comprising:
distributing the fixed key to the authorized third party communication device; and sending the second key to the authorized third party communication device; the authorized third party communication device using the fixed key to verify the first effective size of the second key. 6. The method of claim 1, wherein the projecting step comprises combining the first key with M-bits of zeros and/or ones to create a concatenated key, wherein M is greater than or equal to one, and wherein the M-bits of zeros and/or ones are at least one of placed in front of the first key, behind the first key, and interspersed within the first key.
determining a maximum effective size of a generated key; receiving the second key; analyzing the second key to determine the effective size of the second key and the apparent size of the second key; and determining that the effective size of the second key is not greater than the determined maximum effective size of the generated key. 8. The method of claim 1, wherein the first effective size is 64-bits, the first apparent size is 64-bits, and wherein the second apparent size is greater than 64-bits.
9. The method of claim 1, wherein the first effective size is not greater than an allowable key generation size according to export regulations, and wherein the second apparent size is greater than the allowable key generation size according to export regulations.
10. A computer readable medium comprising executable instructions operable to perform the method of claim 1.
11. A device for producing a cryptographic key, comprising:
a computer readable medium comprising processor executable instructions, the instructions comprising: a key generator operable to produce at least a first key having a first apparent size and a first effective size; a key expansion member operable to expand the first key in order to form a second key by concatenating the first key with M-bits of zeros and/or ones in order to form the second key, wherein M is greater than or equal to one, and wherein the M-bits of zeros and/or ones are distributed within the first key according to a predetermined pattern, wherein the second key has a second apparent size and the first effective; and a key encryptor operable to utilize a fixed key and a cryptographic algorithm to scramble the second key. 12. (canceled)
13. The device of claim 11, further comprising an interface operable to transmit the second key to at least one recipient.
14. The device of claim 11, wherein the encryption algorithm comprises at least one of an asymmetric encryption algorithm and a hash encryption algorithm.
15. The device of claim 11, wherein the encryption algorithm comprises a symmetric encryption algorithm.
16. The device of claim 13, wherein the at least one recipient comprises an authorized third party, wherein the fixed key is provided to the authorized third party, and wherein the projected second key is sent to the authorized third party via the interface such that the first effective size of the second key can be determined by the authorized third party using the fixed key.
17. The device of claim 11, wherein the predetermined pattern comprises at least one of placing the M-bits of zeros and/or ones in front of the first key, behind the first key, and interspersing them within the first key.
18. The device of claim 11, wherein the first effective size is 64-bits, the first apparent size is 64-bits, and wherein the second apparent size is greater than 64-bits.
19. The device of claim 11, wherein the first effective size is not greater than an allowable key generation size according to export regulations, and wherein the second apparent size is greater than the allowable key generation size according to export regulations.
20. A method for producing a cryptographic key, comprising:
a communication device generating a first key having a first key strength and a first apparent size; expanding the first key to create a second key, wherein the second key has a second key strength and a second apparent size, the second key strength being at least the first key strength but less than the key strength based on the second apparent size of the second key, and wherein the second apparent size is larger than the first apparent size; determining a fixed key; scrambling the second key using the fixed key; and distributing the second key to at least one recipient communication device. 21. (canceled)
22. The method of claim 20, wherein the scrambling the second key comprises employing an asymmetric encryption algorithm and a hash encryption algorithm that utilizes the fixed key.
23. The method of claim 20, wherein the scrambling the second key comprises employing a symmetric encryption algorithm that utilizes the fixed key.
24. The method of claim 20, wherein the at least one recipient communication device comprises an authorized third party communication device, the method further comprising:
distributing the fixed key to the authorized third party communication device; and sending the second key to the authorized third party communication device; the authorized third party communication device using the fixed key to reverse the scrambling of the second key such that the second key strength can be determined by the authorized third party. 25. The method of claim 20, wherein the expanding step comprises concatenating the first key with M-bits of zeros and/or ones, wherein M is greater than or equal to one, and wherein the M-bits of zeros and/or ones are at least one of placed in front of the first key, behind the first key, and distributed within the first key.
determining a maximum key strength of a generated key; receiving the second key; analyzing the second key to determine the second key strength and the second apparent size; and determining that the second key strength is not greater than the determined maximum key strength of the generated key. 27. The method of claim 20, wherein the second key strength is not greater than an allowable key generation size according to export regulations, and wherein the second apparent size is greater than the allowable key generation size according to export regulations.
28. The method of claim 1, wherein the cryptographic algorithm used to project the first key onto the second key space comprises a reversible algorithm.
29. The method of claim 11, wherein the scrambling of the second key is reversible using the fixed key.
30. The method of claim 6, further comprising using the fixed key to scramble the concatenated key comprising the additional M-bits thereby creating the second key.
[0001] The invention relates generally to encryption and particularly to producing apparently strong keys that occupy a weak key space.
[0002] An exemplary secured Internet communication session connects first and second communication devices, such as IP hardphones, softphones, Personal Computers (PCs), laptops, telephony servers, and Personal Digital Assistants (PDAs), via an untrusted or insecure network (such as the Internet). The communication devices seek to establish a secured session and must perform a key exchange. As will be appreciated, a random number generator usually located at a PBX server that connects the two endpoints is used to produce the keys that will be employed by each communication device during the secured session. The keys are used by each of the first and second communication devices to encrypt and decrypt and authenticate plain and cipher text. In symmetrical encryption, encryption and decryption are performed by inputting identical keys into the same encryption algorithm at each of the session nodes.
[0003] Many countries, such as the U.S., place strict export controls on cryptography technology and products for reasons of national security. In the U.S., export controls on commercial encryption products are administered by the Bureau of Industry and Security in the U.S. Department of Commerce, as authorized by the Export Administration Regulations or EAR, and by the Office of Defense Trade Controls (DTC) in the State Department, as authorized by the Information Technology Administration Regulations or ITAR. Historically, strict controls have been placed on granting export licenses for encryption products stronger than a certain level. Other countries have similar regulations.
[0004] An ongoing challenge for companies selling cryptographically enabled products internationally is controlling the strength of the encryption product effectively. For such products sold in the U.S., encryption strength is much more loosely controlled than for such products sold in other countries, particularly certain strictly export controlled countries, such as Iran, Cuba, and North Korea.
[0005] One approach to controlling encryption strength is to vary the encryption algorithm based upon product destination. This is done using a license file. By way of illustration, a license file utility controls whether or not the device supports first or second encryption algorithms of differing strengths. Examples of weaker encryption algorithms include the Data Encryption Standard-56 (DES) and of stronger encryption algorithms include Triple or Three DES and Advanced Encryption Standard or AES. As will be appreciated, DES is much weaker than Triple DES. A flag is set or unset in the license file when the device is not to support the stronger encryption algorithm. During a license check and/or session negotiation, the license utility will deactivate the stronger encryption algorithm and activate the weaker encryption algorithm when the flag indicates that the device is not to support the stronger encryption algorithm and activate the stronger encryption algorithm , thus overriding the weaker encryption algorithm when the flag indicates that the device is to support the stronger encryption algorithm.
[0006] In another approach that has been implemented by web browser and server vendors (e.g., Netscape™, Microsoft™, etc.), an application is not allowed to negotiate strong keys of long key lengths and associated cipher suites (encryption algorithms), unless the web server, web browser, and web browser certificate are of a version, type, and strength to allow for strong cipher suites and key sizes to be used. Otherwise, weak keys of short key lengths and associated cipher suites are used.
[0007] Problems with these approaches include the transparency, to a sophisticated observer, of the activation of the weaker encryption algorithm. Based on this knowledge, sophisticated users may attempt to alter the license file to activate the stronger encryption algorithm. This transparency is particularly a problem where the user can view freely the protocol exchange and determine if the software version is such that encryption is restricted.
[0008] Another problem is that if weak keys are generated then directly distributed to the communication devices, a potential attacker may be able to more easily determine the key size. Since substantial computing resources may be required to break certain encryption algorithms, attackers do not usually try to decrypt every message that is encrypted. Rather, they will choose messages that they know have been encrypted with smaller keys. This makes messages sent with the given smaller key more susceptible to interception and unauthorized decryption. On the other hand, attackers may not attempt to decrypt a message that they believe has been encrypted with a larger 128-bit key, since they do not wish to commit computing resources to such a task that they believe may be impossible. Currently, it is relatively easy for attackers to determine the size of key used to encrypt a particular message.
[0009] These and other needs are addressed by the various embodiments and configurations of the present invention. The present invention is directed generally to the variation of key size appearance, to produce a verifiable weak key having a strong key form, particularly for products to be exported. At least some embodiments of the present invention are typically applicable in encryption protocols in which a third party generates keys for other participants (i.e. principals). Examples of devices that may employ these protocols include, but are not limited to, an H.323 gatekeeper or a Kerberos server. In some cases (e.g., SRTP) the transmitter may generate the key and send it to the receiver. This last step generally requires a secure communication channel, of course.
[0010] In accordance with one embodiment of the present invention, a method is provided for producing a cryptographic key. The method comprises:
[0011] (a) generating a first key having a first apparent size and a first effective size;
[0012] (b) determining a fixed key;
[0013] (c) choosing a fixed cryptographic algorithm;
[0014] (d) using the fixed key and the chosen algorithm to project the first key onto a second key space to create a second key, wherein the second key has a second apparent size and substantially the first effective size, and wherein the second apparent size is different from the first apparent size;
[0015] (e) distributing the projected second key to at least one recipient.
[0016] In another embodiment, steps b and d are combined into a one-way cryptographic function, such as a keyed hash function, which both expands and scrambles the first key in the same process to form the second key.
[0017] In effect, a first key is generated within a confined key space, and is then “projected” onto some subspace of a larger key space, to form a second key, by applying a keyed cryptographic function to the first key, using a fixed key known only to the generator. When the fixed key used for the projection is unknown to an attacker, that attacker cannot identify the resulting subspace, and thus cannot limit his/her search for the second key to a small subspace. However, a third party that is privy to the fixed key can easily search the second key subspace by generating each possible first key and applying the projection.
[0018] The effective size of the first key is typically defined by the number of bits used to generate that key. For example, if the first key was generated to be a 64-bit key, the effective size of the first key would be 64-bits and the corresponding “key strength” of the first key would be 264. Typically, the first apparent size matches the first effective size.
[0019] The expansion and scrambling of the first key to create the second key results in a second key that has substantially the same effective size as the first key, but a different apparent size. In other words, continuing the example from above, the second key substantially still has an effective size of 64-bits and the corresponding substantial “key strength” of 264. The key strength of the second key is substantially equal to the original key strength. However, as can be appreciated by one of skill in the art, the key strength of the second key is substantially equal to the key strength of the first key. Likewise, the “effective key size” of the second key is substantially equal to the “effective key size” of the first key.
[0020] Due to the expansion of the first key, the second key has a larger apparent size. The second apparent size may be anywhere from 65-bits up to hundreds, thousands, or even millions of bits. It is generally advantageous to expand the first key to produce a second key that resembles a larger key that is used in common encryption algorithms. For instance, the second apparent size of the second key may be 128-bits. This may appear to be a 128-bit key having an effective key strength of 2128, although it only has an effective key size of 64-bits and the effective key strength of 264. However, the appearance of the second key may make a third party, without knowledge of the fixed key, believe that the second key is too large break and a potential attacker may be dissuaded from tampering with the key or any messages encrypted with the key.
[0021] The “scrambling” of the expanded key may be achieved by employing a symmetric encryption algorithm that utilizes the fixed key. or, alternatively, the scrambling and expansion may be done by using a public-key encryption system, a one-way cryptographic keyed hash or pseudo-random function, such as is used in some protocols (e.g., MIKEY, SRTP) for session key derivation from a shared session master key. In the event that a symmetric algorithm is used, an authorized third party with knowledge of the fixed key can easily reverse the projection of a projected key with the fixed key to verify the size of the generated key, and can also determine the key space occupied by any key generated. Alternatively, in the event that an asymmetric algorithm or a one-way hash-based function is employed, an authorized third party with knowledge of the fixed key can use the fixed key to determine the key space occupied by any generated key. Thereafter, the authorized third party can search the actual key space occupied by the generated key rather than having to search the larger key space that the second key appears to occupy. This scrambling/encryption process is used to preserve the security of the original keys and, typically, should be stronger than the keys it protects. Thus an attacker who knows the expansion/scrambling scheme and obtains a key generated thereby, but does not know the fixed key, will not be able to easily determine the fixed key. Furthermore, such an attacker, not knowing the fixed key, cannot easily determine the actual key space occupied by the second (projected) keys produced by the generator.
[0022] To conform to U.S. export laws, many times sample keys will need to be generated and sent to an authorized third party like the National Security Agency (NSA) or Department of Commerce. There, the generated key is analyzed to determine if the key was generated in compliance with key generation regulations. Since the second key has a second apparent size that may potentially be greater than regulations permit, the authorized third party may need to reverse, or test, the formation of the projected key (after removing any encryption used for secure transmission.) If the fixed key is shared with the authorized third party, that party may be able to discern easily that, though the second key has a second apparent size that may be greater than the allowable key generation size, the effective size of the second key is within allowable limits. Therefore, the authorized third party (e.g., the NSA) is able to quickly confirm that the first key was generated within allowable limits of export regulations.
[0023] These and other advantages will be apparent from the disclosure of the invention(s) contained herein. The above-described embodiments and configurations are neither complete nor exhaustive. As will be appreciated, other embodiments of the invention are possible utilizing, alone or in combination, one or more of the features set forth above or described in detail below.
[0024] As used herein, “at least one”, “one or more”, and “and/or” are open-ended expressions that are both conjunctive and disjunctive in operation. For example, each of the expressions “at least one of A, B and C”, “at least one of A, B, or C”, “one or more of A, B, and C”, “one or more of A, B, or C” and “A, B, and/or C” means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.
[0025] FIG. 1 is a block diagram of a communication network according to at least some embodiments of the present invention;
[0026] FIG. 2 is a block diagram of central key distributor, like a switch or server, according to at least some embodiments of the present invention;
[0027] FIG. 3 is a block diagram of communication devices utilizing encryption keys according to at least some embodiments of the present invention;
[0028] FIG. 4 is a block diagram of an endpoint utilized by an authorized third party according to at least some embodiments of the present invention;
[0029] FIG. 5 is a flowchart depicting a method of generating keys according to at least some embodiments of the present invention; and
[0030] FIG. 6 is a flowchart depicting a method of verifying key strength according to at least some embodiments of the present invention.
[0031] Referring initially to FIG. 1 an exemplary communication system 100 will be described in accordance with at least some embodiments of the present invention. The communication system 100 comprises a network 104 connecting a first communication device 108, a second communication device 112, a switch/server 116, an authorized third party 120, and an unauthorized third party 124. The communication devices 108 and 112 can be any of a number of packet-switched devices including, without limitation, Personal Computer (PC), laptop, Personal Digital Assistant (PDA), IP hardphone, IP softphone, wireless phone, cellular phone, instant messaging software, and networking equipment.
[0032] The network 104 may be any type of suitable communications network that is operable to transmit data from a first endpoint to a second endpoint, where typical endpoints include the communication devices 108 and 112, the switch/server 116, the authorized third party 120, and the unauthorized third party 124. Examples of suitable types of networks 104 include, but are not limited to, a Local Area Network (LAN), a Wide Area Network (WAN) like the Internet, and any other type packet-switched network known in the art.
[0033] The server 116 may be a part of an enterprise or service-provider network. The term “server” as used herein should be understood to include a PBX, an ACD, an enterprise server, an IVR server, or other type of communications system-server, as well as other types of processor-based communication control devices such as media servers, computers, adjuncts, etc.
[0034] The authorized third party 120 is typically a third party that is interested in analyzing keys generated by the server 116 to verify the strength of the keys generated. Devices used by the authorized third parties 120 to analyze the generated keys may be in the form of a server, super-computer, network of processors, a device emulating an endpoint, or other type of processing mechanism. Authorized third parties 120 are typically given information that allows them to analyze the strength of the generated keys. Information that is typically shared with an authorized third party 120 may include keys that were used to expand and/or scramble the generated key prior to distribution.
[0035] On the other hand, an unauthorized third party 124 is typically referred to as an attacker, a hacker, or any other untrusted party that is not intended to have information related to a secured communication session. Most types of unauthorized third parties 124 usually try to intercept encrypted messages, keys, and other sensitive data to exploit it for various reasons.
[0036] Referring now to FIG. 2 an exemplary server 116 will be described in accordance with at least some embodiments of the present invention. The server 116 typically comprises a key generator 204, a key expansion member 208, a key encryptor/scrambler 212, and an interface 216 for sending/receiving data to/from the network 104. Usually, encryption keys are required by communication devices 108 and 112 when a secured communication session is initiated between the two endpoints. Upon a request for an encryption key, the server 116 enables the key generator 204 to generate a key for use between the first and second communication devices 108 and 112 during the secured session. The key generator 204 may be a random number generator or any other type of mechanism that can be employed to generate keys of various strengths.
[0037] As will be appreciated, “key strength” or “effective key size” refers to a number of possible combinations or keys. Key strength is commonly a function of key length. For example, the key strength for a random 16-bit key is 216, a 32-bit key is 232, a 64-bit key is 264 and a 128-bit key is 2128. By using a first key having a weaker key strength, the effective cryptographic strength of encryption using the first key is less than that using a second key having a higher effective key strength. The stronger key may be used, for example, in non-export-restricted products, and the weaker key may be used in export-restricted products.
[0038] In accordance with at least one embodiment of the present invention, the key generator 204 generates a first key (KG) that has an effective key strength that is in accordance with export regulations. In other words, in order to comply with U.S. export regulations, KG may be generated to have a key length of 64-bits. Thus, the effective key size of KG would be 64. Of course, the key generator 204, depending upon the appropriate regulations and/or other desired operating parameters, may generate larger or smaller keys. For example a 56-bit key or a 72-bit key may be generated then expanded to any size depending upon the desired encryption algorithm.
[0039] The generated key having the first effective key strength is then sent to the key expansion member 208. The key expansion member 208 changes the apparent size of KG without changing the effective key strength. The key expansion member 208 may expand the apparent size of KG in a number of different ways. For example, a second key (KE) that is the expansion of KG may be formed as the concatenation of KG with 64-bits of zero, ones, or some other fixed, predictable binary pattern (e.g., a defined ordering of ones and zeros). The concatenation of KG with 64-bits of zero effectively creates a new key with an apparent key size of 128-bits but with an effective key size of the original 64-bits. As can be appreciated by one of skill in the art, zeros may be appended onto the beginning of KG or may be placed within KG at different points. However, in order to make verification of the effective key size of KE easier, it may be advantageous to keep the zeros together either on the end or the beginning of KG. Additionally, as can be further appreciated by one of skill in the art, ones may be used alone or in combination with other zeros to perform the function of the additional zeros. The apparent key size may be expanded to any size, depending upon the type of encryption algorithm that is to be used by the communication devices 108 and 112. Typically, because of U.S. export restrictions, a 64-bit key is generated at the key generator 204 and is expanded to the apparent key size of 128-bits because known encryption algorithms like the AES-128 and other 128-bit encryption algorithms are widely used. A 64-bit key or even a 128-bit key may be expanded to have an apparent key size of 256-bits or even larger, again depending upon the type of encryption algorithm that is desired.
[0040] The expanded key KE is then sent to the key encryptor 212, where it is encrypted or otherwise scrambled by a cryptographic algorithm using a system-wide fixed key, to have the appearance of a strong key. The key encryptor 212 may use any sort of suitable cryptographic algorithm using a fixed key (F). The fixed key may be a strong key used by, for example an AES-128 encryption algorithm. In one typical application, the encryption algorithm will use the fixed key F to encrypt the expanded key KE to form the projected key KS to be distributed to the parties which will use it. The key, KS, should be distributed securely so that it is not disclosed to any third party.
[0041] Any encryption algorithm, whether using symmetric or asymmetric keys, or any cryptographic hash function, can be used. Examples of suitable symmetric encryption algorithms include, but are not limited to, AES (Federal Information Processing Standard 197), triple DES, RC4, Lucifer, Madryga, NewDES, FEAL, REDOC, LOKI, Khufu and Khafre, RC2, IDEA, MMB, CA-1.1, Skipjack, GOST, CAST, Blowfish, SAFER, 3-Way, Crab, SXAL8/MBAL, RC5, knapsack algorithms, Pohlig-Hellman, Rabin, McEliece, Elliptic Curve Cryptosystems, LUC, finite automation public-key cryptosystems, Ong-Schnorr-Shamir, ESIGN, cellular automata, and the like. Examples of suitable asymmetric encryption algorithms include, but are not limited to, Rivest Shamir and Adelman (RSA), Diffie-Hellman, ElGamal, DSS, and the like. Keyed message authentication functions such as HMAC-SHA1, or keyed Pseudo-Random Functions based on hash functions (e.g., the MIKEY PRF) or encryption algorithms (e.g., the SRTP PRF) may be used with the fixed key, F, to both expand and scramble the weak first key. Note that KS might itself be used by the end parties as the master key of a similar PRF to generate session keys for, e.g., data privacy (encryption) and integrity (message authentication).
[0042] The distributed key KS generally has an apparent key size representing a relatively strong key (e.g., a 128-bit key) but it actually has an effective key size (e.g., a 64-bit key) of the smaller generated key KG. Because the projected key KS has the appearance of a strong key it is not easy for a third-party observer to deduce that the effective key size is actually reduced so long as the fixed encryption key F is held secret by the generator.
[0043] Once the second key KS has been prepared by the key expansion member 208 and key encryptor 212, the second key KS is sent to the interface 216 for distribution to the endpoints in a secure manner. As can be appreciated, the distribution protocol for KS may employ any of the above noted encryption algorithms or other type of suitable algorithm to secure the key for transmission across an unsecured network. The security afforded should be equivalent to an encryption algorithm utilizing a strong encryption key.
[0044] In one embodiment, the key generator 204, key expansion member 208, and key encryptor/scrambler 212 are embodied as software on a processor or controller in the server 116, as hardware (e.g., a logic circuit such as an Application Specific Integrated Circuit or ASIC), or as a combination thereof.
[0045] In one embodiment, the key generator 204, key expansion member 208 and key encryptor/scrambler 212 are embodied within one or more of the communication devices 108 and/or 112 which share a predetermined fixed secret key F. A communication device may generate the first key for use in the secured communication session and subsequently share that key with another communication device in a secure manner according to known protocols. Then the secured communication session between the communication devices may be performed using a projected key KS that has an apparent size that is larger than its effective size.
[0046] Referring now to FIG. 3, an exemplary communication session between two communication devices 108 and 112 utilizing the projected key will be described in accordance with at least some embodiments of the present invention. The projected key, typically is sent, in a secure manner, to both communication devices 108 and 112 for use in the communication session as key 304. The first communication device 108 generates some type of message in plain text that is then encrypted by the encryption algorithm 312. The encryption algorithm 312 utilizes the encryption key 304 that appears to have a key size that is actually larger than the effective key size or key strength of the key 304. It is recognized that, in some protocols, the key 304 may be used as a “session master key” from which session keys for encryption and authentication may be derived. The cipher text of the message 316 is then generated and transmitted over the network 104, which is usually an untrusted network like the Internet. The second communication device 112 receives the cipher text of the message at the receiving end 324 where it is decrypted by the encryption algorithm 328 utilizing the same key 304 that was used by the first communication device 108 to encrypt the text. The plain text message 332 may then be received and read by the user of the second communication device 112. As noted above, even though the effective key size of the key 304 may not be strong, the appearance of the key 304 makes it seem like a strong encryption key to third parties 120 and 124.
[0047] The fixed key F may be distributed to a customer (e.g., an owner of the first and/or second communication device 108 and 112) via the license file, presumably as part of the controls which specify that weak encryption must be used. This could be used to ensure that different customers will not use the same key subspace when conducting secured communications sessions. Thus two separate customers, each knowing the other is restricted to weak keys, cannot easily determine the other's keys because they don't know the fixed key used by the other's system to generate them.
[0048] Referring now to FIG. 4, an exemplary authorized third party verification device 120 will be described in accordance with at least some embodiments of the present invention. The authorized third party device 120 comprises an interface 404 for communicating with the network 104, a key decryptor 408, a key reduction member 412, and a verification agent 416. Generally, an authorized third party (like the NSA or Department of Commerce) needs to verify the actual key size of a key generated by systems that have been sold outside of the United States. The authorized third party is typically given the fixed key F that was used to encrypt the expanded KE into the projected key KS. The authorized third party then requests a distributed key and receives a distributed key KS at the interface 404. The distributed key KS is sent to the key decryptor 408 where the fixed key F is used to decrypt the distributed key KS, thus resulting in the expanded key KE. The authorized third party 120 may utilize the same encryption algorithm that was used by the server to encrypt the distributed key KS, in the event that the encryption algorithm used was a symmetric encryption algorithm. Alternatively, in the event that a hash encryption function or some asymmetric encryption function is used, the authorized third party 120 can utilize the fixed key F to determine the actual key space occupied by the generated key KG, therefore making it easier to search the key space of the generated key. Therefore, the authorized third party 120 will not only need the fixed encryption key F, but they will also need to know what encryption algorithm was used in order to decrypt the distributed key KS properly.
[0049] At this point the authorized third party will usually be able to determine that the expanded key KE is nothing more than a smaller generated key, for example KG, concatenated with a number of zeros, ones, or a fixed predictable pattern of ones and zeros. However, if the zeros were inserted into the generated key KG such that a simple examination of the expanded key KE cannot show that a smaller key was generated, the key reduction member 412 reduces the apparent key size of KE and the result is the original KG that was generated initially by the key generator 204. Then the key may be sent to the verification agent 416 that can confirm or deny that the effective key size of the generated key KG was smaller than the apparent key size of the distributed key KS and therefore was generated in compliance with applicable regulations.
[0050] Exposure of the fixed key F does assist the authorized third party 120 in reducing the distributed, apparently larger, key KS to the base generated key KG, but it does not offer additional aid in finding the keys for other sessions. This helps to build another layer of security around the generated, potentially weak, keys.
[0051] Referring now to FIG. 5 a method of generating a key and distributing that key will be described in accordance with at least some embodiments of the present invention. Initially a first key KG is generated having a first effective key size and matching apparent key size (step 504). Thereafter, the first key is expanded/projected to create a second key KE having the first effective key size and matching apparent key size (step 508). The expanded key KE may be generated in any number of ways. For example, assume that the generated key KG is N-bits long and has the following entries of X1, X2, X3 . . . XN, where typically N is greater than or equal to 1. Then KE may be derived in one embodiment by appending up to M-bits of zero (and/or ones) on the end of KG. Now KE would be equal to KG∥0N+1, 0N+2, 0N+3 . . . 0N+M, where typically M is greater than or equal to 1 and where the apparent key size of KE is N+M and the effective key size of KE is still N.
[0052] In an alternative embodiment KE may be derived by appending up to M-bits of zero onto the front of KG. The resulting KE would be 01−M, 02−M, 03−M . . . 0N−M∥KG and the apparent size of KE would still be equal to N+M while the effective key size of KE is N. As noted above, M-bits of one may be used instead of M-bits of zero. By placing the M-bits of zero on either the front or back of KG to form KE the verification of the effective key size of the generated key KG is relatively easy for an authorized third party that wishes to verify the size of the generated key KG.
[0053] In still a further alternative embodiment KE may be derived by interspersing the M-bits of zero (or one) between the bits of KG. The resulting KE would be X1, 01, X2, 02, X3 . . . XN. This may make it more difficult for the authorized third party to determine the effective key size of KG, but it may help to add another layer of security to the system utilizing the keys generated and distributed by the server 116.
[0054] In step 512, the expanded key KE is encrypted or otherwise projected onto the apparent key space using a keyed cryptographic algorithm that is determined in step 516. The determined cryptographic algorithm includes the use of a determined fixed key F. The fixed key F is used to scramble all expanded keys KE that are generated by the key generator 204 regardless of the session or time when the key is generated. This way, an authorized third party with knowledge of the fixed key F can verify the key space occupied by any key generated by the key generator 204. The encryption algorithm may be a stronger encryption algorithm utilizing a relatively strong encryption key F. The result of the projection of the expanded key KE is a projected key KS that can be distributed while complying with U.S. export laws.
[0055] In step 520, the recipients of the projected key KS are determined. After the recipients are determined, the projected key KS is distributed securely to the determined recipients (step 524). The recipient may then use the distributed KS to conduct a secured transmission of information between themselves and another communication device.
[0056] Referring now to FIG. 6, a method of verifying the actual size of a distributed key KS will be described in accordance with at least some embodiments of the present invention. Initially the distributed key KS is received at an authorized third party 120 (step 604). Generally, the key KS is generated and sent securely to the authorized third party 120 like any other key would be distributed to any other customer (e.g., in response to a call set up request with media encryption). This way the authorized third party can determine the key strength of distributed keys sent out in normal operations rather than determining key strength of keys specially generated for the authorized third party.
[0057] The authorized third party 120 has typically been given the fixed key F used to create the projected key KS. In step 608, the distributed key KS is decrypted/unscrambled using the projection encryption algorithm and the fixed key F that was supplied to the authorized third party 120 in step 612. Thereafter, the effective key size of the distributed key KS may be determined by the authorized third party 120 (step 616). As noted above, in the event that the distributed key KS was scrambled with a symmetric encryption algorithm, the authorized third party 120 can use the fixed key F to unscramble the key and see the expanded key that includes the generated key and the additional bits that were used to expand the key. In the event that the distributed key KS was scrambled with an asymmetric encryption algorithm, the authorized third party 120 can use the fixed key F to discover the key space occupied by the generated key KS. Then the authorized third party 120 can search the actual key space, rather than searching the larger apparent key space of the distributed key KS. The authorized third party 120 is able to make a determination of the effective size of the distributed key KS while they may not necessarily be given any further information relating to keys generated in other communication sessions.
[0058] The present invention, in various embodiments, includes components, methods, processes, systems and/or apparatus substantially as depicted and described herein, including various embodiments, subcombinations, and subsets thereof. Those of skill in the art will understand how to make and use the present invention after understanding the present disclosure. The present invention, in various embodiments, includes providing devices and processes in the absence of items not depicted and/or described herein or in various embodiments hereof, including in the absence of such items as may have been used in previous devices or processes, e.g., for improving performance, achieving ease and\or reducing cost of implementation.
[0059] The foregoing discussion of the invention has been presented for purposes of illustration and description. The foregoing is not intended to limit the invention to the form or forms disclosed herein. In the foregoing Detailed Description for example, various features of the invention are grouped together in one or more embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the following claims are hereby incorporated into this Detailed Description, with each claim standing on its own as a separate preferred embodiment of the invention.
[0060] Moreover, though the description of the invention has included description of one or more embodiments and certain variations and modifications, other variations and modifications are within the scope of the invention, e.g., as may be within the skill and knowledge of those in the art, after understanding the present disclosure. It is intended to obtain rights which include alternative embodiments to the extent permitted, including alternate, interchangeable and/or equivalent structures, functions, ranges or steps to those claimed, whether or not such alternate, interchangeable and/or equivalent structures, functions, ranges or steps are disclosed herein, and without intending to publicly dedicate any patentable subject matter.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4850017 *May 29, 1987Jul 18, 1989International Business Machines Corp.Controlled use of cryptographic keys via generating station established control valuesUS5323464 *Oct 16, 1992Jun 21, 1994International Business Machines CorporationCommercial data maskingUS5416841 *Dec 20, 1993May 16, 1995International Business Machines CorporationCryptography systemUS5764772 *Dec 15, 1995Jun 9, 1998Lotus Development CoporationDifferential work factor cryptography method and systemUS5815573 *Apr 10, 1996Sep 29, 1998International Business Machines CorporationCryptographic key recovery systemUS5850443 *Aug 15, 1996Dec 15, 1998Entrust Technologies, Ltd.Key management system for mixed-trust environmentsUS5912973 *Mar 29, 1996Jun 15, 1999Sanyo Electric Co., Ltd.Method for scrambling and/or descrambling FM subcarrier dataUS5949883 *Sep 28, 1995Sep 7, 1999Entrust Technologies Ltd.Encryption system for mixed-trust environmentsUS6125446 *Aug 29, 1997Sep 26, 2000Compaq Computer CorporationComputer architecture with automatic disabling of hardware/software features using satellite positioning dataUS6307936 *Sep 16, 1998Oct 23, 2001Safenet, Inc.Cryptographic key management schemeUS6363480 *Sep 14, 1999Mar 26, 2002Sun Microsystems, Inc.Ephemeral decryptabilityUS6424713 *Nov 18, 1997Jul 23, 2002General Instrument CorporationCryptographic system with concealed work factorUS6891950 *Aug 31, 2000May 10, 2005Kabushiki Kaisha ToshibaExtended key generator, encryption/decryption unit, extended key generation method, and storage mediumUS6947560 *Dec 15, 1999Sep 20, 2005Telefonaktiebolaget L M Ericsson (Publ)Method and device for effective key length controlUS7174020 *Oct 21, 2002Feb 6, 2007Telesecura CorporationSystem and method for real-time secure communication based on multi-level transform and encryptionUS7194090 *Jul 12, 2001Mar 20, 2007Kabushiki Kaisha ToshibaEncryption apparatus, decryption apparatus, expanded key generating apparatus and method therefor, and recording mediumUS7272500 *Mar 25, 2004Sep 18, 2007Avaya Technology Corp.Global positioning system hardware key for software licensesUS20020021802 *Jul 12, 2001Feb 21, 2002Hirofumi MurataniEncryption apparatus, decryption appatatus, expanded key generating apparatus and method therefor, and recording mediumUS20020061107 *Sep 6, 2001May 23, 2002Tham Terry K.Methods and apparatus for implementing a cryptography engineUS20020106080 *Jun 26, 2001Aug 8, 2002Broadcom CorporationMethods and apparatus for implementing a cryptography engineUS20020191784 *Jun 8, 2001Dec 19, 2002Nhu-Ha YupCircuit and method for implementing the advanced encryption standard block cipher algorithm in a system having a plurality of channelsUS20030007635 *Oct 24, 2001Jan 9, 2003C4 Technology, Inc.Encryption method, program for encryption, memory medium for storing the program, and encryption apparatus, as well as decryption method and decryption apparatusUS20030039355 *May 9, 2002Feb 27, 2003Mccanny John VincentComputer useable product for generating data encryption/decryption apparatusUS20030072444 *Sep 6, 2002Apr 17, 2003Yi HuData encryption/decryption apparatusUS20030084332 *Oct 26, 2001May 1, 2003Koninklijke Philips Electronics N.V.Method for binding a software data domain to specific hardwareUS20030198345 *Apr 15, 2002Oct 23, 2003Van Buer Darrel J.Method and apparatus for high speed implementation of data encryption and decryption utilizing, e.g. Rijndael or its subset AES, or other encryption/decryption algorithms having similar key expansion data flowUS20040134984 *Oct 27, 2003Jul 15, 2004Powell Kevin J.Optimization of a binary tree traversal with secure communicationsUS20040202318 *May 6, 2004Oct 14, 2004Chih-Chung LuApparatus for supporting advanced encryption standard encryption and decryptionUS20040260950 *Mar 29, 2004Dec 23, 2004Hirokazu OugiCryptographic communication method, encryption algorithm shared control method, encryption algorithm conversion method and network communication systemUS20050141716 *Nov 5, 2004Jun 30, 2005Prem KumarCoherent-states based quantum data-encryption through optically-amplified WDM communication networksUS20050157879 *Jan 21, 2004Jul 21, 2005Hidema TanakaCipher strength evaluation apparatusUS20050213756 *Jun 12, 2003Sep 29, 2005Koninklijke Philips Electronics N.V.Round key generation for aes rijndael block cipherUS20060009238 *Jun 3, 2004Jan 12, 2006Bart StancoPersonal communication devicesUS20060034456 *Apr 18, 2005Feb 16, 2006Secure Choice LlcMethod and system for performing perfectly secure key exchange and authenticated messagingUS20060204005 *Mar 14, 2005Sep 14, 2006Microsoft CorporationMethod and system for enhancing cryptography-based securityUS20070058814 *Sep 13, 2005Mar 15, 2007Avaya Technology Corp.Method for undetectably impeding key strength of encryption usage for products exported outside the U.S.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7668315 *May 22, 2001Feb 23, 2010Qualcomm IncorporatedLocal authentication of mobile subscribers outside their home systemsUS7751567Jun 1, 2005Jul 6, 2010Qualcomm IncorporatedLocal authentication of mobile subscribers outside their home systemsUS7986773 *Aug 29, 2006Jul 26, 2011Cisco Technology, Inc.Interactive voice response system securityUS8392711 *Mar 5, 2013Avaya Inc.Staged establishment of secure strings of symbolsUS20020091933 *May 22, 2001Jul 11, 2002Quick Roy F.Local Authentication in a communication systemUS20050257255 *Jun 1, 2005Nov 17, 2005Quick Roy F JrLocal authentication of mobile subscribers outside their home systemsUS20080056464 *Aug 29, 2006Mar 6, 2008Kalahasti Soumya KInteractive voice response system securityUS20100306526 *May 27, 2009Dec 2, 2010Avaya Inc.Staged Establishment of Secure Strings of SymbolsUS20120121080 *May 17, 2012Sap AgCommutative order-preserving encryptionUS20150304286 *Apr 20, 2015Oct 22, 2015Intel CorporationSymmetric key distribution framework for the internetWO2008143531A1 *May 21, 2008Nov 27, 2008Turner Technologies LimitedMessaging systemWO2009154959A2 *May 27, 2009Dec 23, 2009Adaptive Chips, Inc.Key exchange through a scramble methodology and systemWO2009154959A3 *May 27, 2009Feb 25, 2010Adaptive Chips, Inc.Key exchange through a scramble methodology and system* Cited by examinerClassifications U.S. Classification380/44International ClassificationH04L9/00Cooperative ClassificationH04L9/088European ClassificationH04L9/08C, H04L9/06Legal EventsDateCodeEventDescriptionMar 31, 2006ASAssignmentOwner name: AVAYA TECHNOLOGY LLC, NEW JERSEYFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GILMAN, ROBERT R.;REEL/FRAME:017724/0366Effective date: 20060330Nov 27, 2007ASAssignmentOwner name: CITIBANK, N.A., AS ADMINISTRATIVE AGENT, NEW YORKFree format text: SECURITY AGREEMENT;ASSIGNORS:AVAYA, INC.;AVAYA TECHNOLOGY LLC;OCTEL COMMUNICATIONS LLC;AND OTHERS;REEL/FRAME:020156/0149Effective date: 20071026Owner name: CITIBANK, N.A., AS ADMINISTRATIVE AGENT,NEW YORKFree format text: SECURITY AGREEMENT;ASSIGNORS:AVAYA, INC.;AVAYA TECHNOLOGY LLC;OCTEL COMMUNICATIONS LLC;AND OTHERS;REEL/FRAME:020156/0149Effective date: 20071026Nov 28, 2007ASAssignmentOwner name: CITICORP USA, INC., AS ADMINISTRATIVE AGENT, NEW YFree format text: SECURITY AGREEMENT;ASSIGNORS:AVAYA, INC.;AVAYA TECHNOLOGY LLC;OCTEL COMMUNICATIONS LLC;AND OTHERS;REEL/FRAME:020166/0705Effective date: 20071026Owner name: CITICORP USA, INC., AS ADMINISTRATIVE AGENT,NEW YOFree format text: SECURITY AGREEMENT;ASSIGNORS:AVAYA, INC.;AVAYA TECHNOLOGY LLC;OCTEL COMMUNICATIONS LLC;AND OTHERS;REEL/FRAME:020166/0705Effective date: 20071026Jun 26, 2008ASAssignmentOwner name: AVAYA INC, NEW JERSEYFree format text: REASSIGNMENT;ASSIGNOR:AVAYA TECHNOLOGY LLC;REEL/FRAME:021156/0689Effective date: 20080625Owner name: AVAYA INC,NEW JERSEYFree format text: REASSIGNMENT;ASSIGNOR:AVAYA TECHNOLOGY LLC;REEL/FRAME:021156/0689Effective date: 20080625RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services