WO2008059475A1 - Communication sécurisée - Google Patents

Communication sécurisée Download PDF

Info

Publication number
WO2008059475A1
WO2008059475A1 PCT/IL2007/000679 IL2007000679W WO2008059475A1 WO 2008059475 A1 WO2008059475 A1 WO 2008059475A1 IL 2007000679 W IL2007000679 W IL 2007000679W WO 2008059475 A1 WO2008059475 A1 WO 2008059475A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
text
secret
module
recovery text
Prior art date
Application number
PCT/IL2007/000679
Other languages
English (en)
Inventor
Itsik Mantin
Original Assignee
Nds Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nds Limited filed Critical Nds Limited
Publication of WO2008059475A1 publication Critical patent/WO2008059475A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • the present invention relates to secure communication, and in particular, but not exclusively to, secure communication between two devices using a key.
  • Secure communication usually relies on secure keys.
  • the secure keys are either stored in advance in the communicating devices or generated during a session establishment protocol.
  • a secure communication protocol when the communicating parties have a shared secret key, the parties may use the key to securely communicate with a very high level of confidence regarding the confidentiality and the integrity of the sent messages.
  • Various methods of establishing a secure communication protocol are known to those ordinarily skilled in the art.
  • one known way to establish a secure communication protocol includes deriving two sub keys Kl and K2 from a shared key K, which is known to both parties.
  • Kl is equal to a hash of a concatenation of the first part of K with a first fixed vector Vl and K2 is equal to a hash of a concatenation of the second part of K with a second fixed vector V2, where the hash is performed using a cryptographic hash function, for example, but not limited to, SHA-I.
  • Messages are then encrypted using a block cipher algorithm, such as AES, with Kl as the encryption key.
  • MACs Message authentication codes
  • Other suitable block ciphers and MAC schemes are known to those ordinarily skilled in the art for use as conventional building blocks of secure protocols.
  • Other ways to mount a secure communication channel based on a shared key are known to those ordinarily skilled in the art.
  • the above-mentioned scheme may be attacked by an attacker that runs a trial and error search on the key K.
  • a countermeasure against the attack is to make the key K too long for guessing using available technology or the particular application, for example, but not limited to, a 128 bit key.
  • each pair of communicating devices needs to have a shared key in order to communicate securely, meaning that the number of keys in the system is typically proportional to the number of possible pairs, which is
  • N-I keys for secure communication with the other N-I devices. So for example, using a secure key of 128 bits, results in a large storage burden for each device.
  • a solution for low-resource devices is to use symmetric key cryptography with manually entered keys. For example, a key generated by a first device is provided to a user of a second device and entered into the second device prior to mounting the secure communication channel.
  • a similar problem exists with respect to devices which do not allow for a sufficiently long shared key for example, but not limited to, low resource devices such as RFID devices, mobile phones and Bluetooth devices. Such devices may have insufficient storage capabilities or may be required to base security on user passwords. Thus, it may be impossible to provide a sufficiently long key, for example, but not limited to, a 64 or 128 bit key, for many devices.
  • the keys on which the secure communication is based are too short and may be broken through a brute force attack. It is well known in the art that keys that are shorter than 48 bits are considered breakable through brute force attack. As technology improves, the definition of too short and sufficiently long will probably change.
  • the present invention seeks to provide an improved secure communication system.
  • the system of the present invention in preferred embodiments thereof, includes a secure communication system for providing a sufficiently long cryptographic key for use in encrypted communication between devices while allowing the users of the devices to share a manageable shared secret which is generally, but not always, too short for the specific security needs.
  • the system of the present invention in preferred embodiments thereof, is particularly useful for: devices that are weak, and/or only have a small secure storage for keys; and/or devices that rely on volatile secrets and use inputs instead of non-volatile keys; and/or Bluetooth secure specification which relies on
  • 4-digit secret keys and/or communication between mobile devices; and/or secure communication between a strong reader and an RFID device implemented with some suitable randomness.
  • a first device to securely communicate with a second device, the first device and the second device sharing a secret, the second device holding a cryptographic key which is at least partially based on the secret, the second device being operative to use a one-way function and the key to determine a first key recovery text
  • the first device including a receiving module to receive the first key recovery text from the second device, a key determination module to determine the key at least based on the secret and the first key recovery text by trial and error, and a communication module to receive the key from the key determination module, and securely communicate with the second device using the key.
  • the communication module is operative to securely communicate using encrypted communication. Still further, in accordance with a preferred embodiment of the present invention the communication module is operative to securely communicate using digital authentication.
  • the one-way function is a cryptographic hash function and the first key recovery text is a hash of the key.
  • the key determination module includes a test key generation module to determine a test key based on the secret, a hash module to hash the test key yielding an output text, and a comparison module to compare the output text to the first key recovery text.
  • the key determination module determines more than one key based on the secret and the first key recovery text
  • the receiving module is operative to receive another key recovery text from the second device, the other key recovery text being a hash of a new key
  • the key determination module is operative to determine the new key at least based on the secret and the other key recovery text by trial and error.
  • the second device is operative to determine the first key recovery text with the one-way function using the key and a second key recovery text as input, the first device and the second device share the second key recovery text, the key determination module is operative to determine the key at least based on the secret, the first key recovery text and the second key recovery text by trial and error.
  • the key determination module includes a test key generation module to determine a test key based on the secret, a cipher module to cryptographically transform one of the first key recovery text and the second key recovery text using the test key yielding an output text, and a comparison module to compare the output text to one of the first key recover text and the second key recovery text.
  • the second key recovery text is plaintext
  • the first key recovery text is ciphertext
  • the key determination module includes a test key generation module to determine a test key based on the secret, a cipher module to encrypt the second key recovery text using the test key yielding an output text, and a comparison module to compare the output text to the first key recovery text.
  • the second key recovery text is plaintext
  • the first key recovery text is ciphertext
  • the key determination module includes a test key generation module to determine a test key based on the secret, a cipher module to decrypt the first key recovery text using the test key yielding an output text, and a comparison module to compare the output text to the second key recovery text.
  • the key determination module determines more than one key based on the secret, the first key recovery text and the second key recovery text
  • the receiving module is operative to receive a third key recovery text from the second device, the third key recovery text being a fourth key recovery text cryptographically transformed using the key
  • the key determination module is operative to determine the key at least based on the secret, the third key recovery text and the fourth key recovery text.
  • the determination of the test key includes concatenating the secret with another string.
  • the determination of the test key includes concatenating a value based on the secret with another string.
  • the determination of the test key includes performing a function on the secret.
  • the device includes a confirmation module to send a confirmation message to the second device confirming, that the key has been determined.
  • the device includes a user input interface to allow input of the secret by a user.
  • the device includes a secret determination module to determine the secret based on a plurality of random bits.
  • the device includes an output interface to output the secret for entry by a user of the second device into the second device.
  • the device includes a storage arrangement having the secret burned therein.
  • the device includes a wireless interface to securely communicate wirelessly between the first device and the second device using the key.
  • a device to securely communicate with another device including a secret determination module to determine a secret, an output interface to output the secret for entry by a user of the other device, a key generation module to generate a cryptographic key at least based on the secret, and a communication module to use a one-way function and the key to determine a key recovery text, send the key recovery text to the other device, and securely communicate with the other device using the key.
  • the device includes a random number generator to generate. a random number, the key generation module being operative to generate the key at least based on the secret and the random number.
  • the key determination module is operative to determine the key by concatenating the secret with the random number.
  • the communication module is operative to securely communicate using encrypted communication.
  • the communication module is operative to securely communicate using digital authentication.
  • the one-way function is a cryptographic hash function and the key recovery text is a hash of the key.
  • the device includes a random number generator to generate a plurality of random bits wherein the secret determination module is operative to determine the secret based on the random bits.
  • a key recovery system associated with a first device to facilitate secure communication between the first device and a second device, the first device and the second device sharing a secret, the second device holding a cryptographic key which is at least partially based on the secret, the second device being operative to use a one-way function and the key to determine a first key recovery text
  • the system including a receiving module to receive the first key recovery text from the second device, and a key determination module to determine the key at least based on the secret and the first key recovery text by trial and error, and transfer the key to a communication module of the first device in order to facilitate secure communication between the first device and the second device using the key.
  • the secure communication includes encrypted communication.
  • the secure communication includes digital authentication.
  • the one-way function is a cryptographic hash function and the first key recovery text is a hash of the key.
  • the key determination module includes a test key generation module to determine a test key based on the secret, a hash module to hash the test key yielding an output text, and a comparison module to compare the output text to the first key recovery text.
  • the key determination module determines more than one key based on the secret and the first key recovery text
  • the receiving module is operative to receive another key recovery text from the second device, the other key recovery text being a hash of a new key
  • the key determination module is operative to determine the new key at least based on the secret and the other key recovery text using trial and error.
  • the second device is operative to determine the first key recovery text with the one-way function using the key and a second key recovery text as input, the first device and the second device share the second key recovery text, the key determination module is operative to determine the key at least based on the secret, the first key recovery text and the second key recovery text by trial and error.
  • the key determination module includes a test key generation module to determine a test key based on the secret, .
  • a cipher module to cryptographically transform one of the first key recovery text and the second key recovery text using the test key yielding an output text
  • a comparison module to compare the output text to one of the first key recover text and the second key recovery text.
  • the second key recovery text is plaintext
  • the first key recovery text is ciphertext
  • the key determination module includes a test key generation module to determine a test key based on the secret, a cipher module to encrypt the second key recovery text using the test key yielding an output text, and a comparison module to compare the output text to the first key recovery text.
  • the second key recovery text is plaintext
  • the first key recovery text is ciphertext
  • the key determination module includes a test key generation module to determine a test key based on the secret, a cipher module to decrypt the first key recovery text using the test key yielding an output text, and a comparison module to compare the output text to the second key recovery text.
  • the key determination module determines more than one key based on the secret, the first key recovery text and the second key recovery text
  • the receiving module is operative to receive a third key recovery text from the second device, the third key recovery text being a fourth key recovery text cryptographically transformed using the key
  • the key determination module is operative to determine the key at least based on the secret, the third key recovery text and the fourth key recovery text.
  • the determination of the test key includes concatenating the secret with another string.
  • the determination of the test key includes concatenating a value based on the secret with another string.
  • the determination of the test key includes performing a function on the secret.
  • the system includes a confirmation module to send a confirmation message to the second device confirming that the key has been determined.
  • FIG. 1 is a partly pictorial, partly block diagram view of a secure communication system constructed and operative in accordance with a preferred embodiment of the present invention
  • Fig. 2 is a partly pictorial, partly block diagram view of encrypted communication using a key in the system of Fig. 1;
  • Fig. 3 is a block diagram view of a device for generating a key in the system of Fig. 1;
  • Fig. 4 is a block diagram showing a preferred method of key generation by the device of Fig. 3;
  • Fig. 5 is a block diagram showing a first alternative preferred method of key generation by the device of Fig. 3 ;
  • Fig. 6 is a block diagram showing a second alternative preferred method of key generation by the device of Fig. 3;
  • Fig. 7 is a block diagram view of a device showing a preferred method of determining a key in the system of Fig. 1;
  • Fig. 8 is a block diagram view of a device showing an alternative preferred method for determining a key in the system of Fig. 1;
  • Fig. 9 is a pictorial view of a secure communication system constructed and operative in accordance with another preferred embodiment of the present invention
  • Fig. 10 is a pictorial view of a secret being outputted in the system of Fig. 9;
  • Fig. 11 is a pictorial view of the secret of Fig. 10 being manually transferred
  • Fig. 12 is a pictorial view of a secret being displayed in the system of Fig. 9;
  • Fig. 13 is a pictorial view of the secret of Fig. 12 being verbally conveyed to another user in the system of Fig. 9;
  • Fig. 14 is a pictorial view of wireless encrypted communication in the system of Fig. 9;
  • Fig. 15 is a block diagram view of a device for use in a secure communication system constructed and operative in accordance with yet another preferred embodiment of the present invention
  • Fig. 16 is a block diagram view of another device for use in the system of Fig. 15.
  • Fig. I 5 is a partly pictorial, partly block diagram view of a secure communication system 10 constructed and operative in accordance with a preferred embodiment of the present invention.
  • the secure communication system 10 is operative to facilitate secure communication between a device 12 and a device 14.
  • devices 12, 14 are mobile telephones.
  • devices 12, 14 can be any suitable devices that need to communicate using secure communication.
  • a user 16 of the device 12 and a user 18 of the device 14 agree on sharing a secret 20 which is preferably easy to remember and/or easy to enter into the devices 12, 14.
  • the secret 20 is then entered into the devices 12, 14 by the respective users 16, 18.
  • the device 12 then generates a cryptographic key 22 based on the secret 20 (block 30) and typically on an additional input, such as a plurality of random bits, for example true random bits, and/or pseudo random bits, and/or or bits that are derived from chaotic user input such as mouse movement or random key strokes.
  • a cryptographic key 22 is described in more detail with reference to Fig. 3.
  • the secret 20 may be entered by the users 16, 18 using any suitable user input interface such as a keypad 21, or a keyboard or mouse when the communication.device is equipped with a keyboard or mouse.
  • the device 12 generates the secret 20 based on a plurality of random bits, discussed in more detail with reference to Fig. 3.
  • the secret 20 is then outputted by the device 12, using any suitable output interface, for example, but not limited to, a display screen 23 of the device 12, so that the user 16 of device 12 can share the secret 20 with the user 18 of the device 14.
  • the user 18 of the device 14 then enters the secret 20 into the device 14 using the keypad 21 of the device 14.
  • the secret 20 may be generated by the device 14 for output to an output interface, such as a display screen 25 of the device 14, for sharing with the user 16 of the device 12.
  • the secret 20 may be burned into the device 12 and/or the device 14. If the secret 20 is only burned into one of the devices 12, 14, then the secret 20 needs to outputted for entry into the other device 12, 14.
  • the user 16 of the device 12 also preferably shares with the user 18 of the device 14 how the secret 20 is associated with the cryptographic key 22.
  • the user 18 then inputs the information into device 14, for example by entering an index of one of a list of algorithms for associating the secret 20 with the cryptographic key 22.
  • the device 12 and the device 14 also share a known key recovery- plaintext 24, for example, but not limited to, a string of 64 zeros or a string of 64 ones or any other suitable plaintext of any suitable length.
  • the device 12 is preferably operative to determine a key recovery ciphertext 26, which is the plaintext 24 cryptographically transformed using a oneway function (encrypted) using the cryptographic key 22 (block 30).
  • the ciphertext 26 is then preferably sent by the device 12 to the device 14 (block 34).
  • the plaintext 24 is. sent to device 14 by the device 12 with the ciphertext 26..
  • the plaintext 24 may be sent in advance to the device 14 or handed to the user 18 of the device 14 for entering manually into the device 14, by way of example only.
  • the term "infeasible” as used in the specification and claims is defined as a problem that while theoretically is possible to solve, in practice is not, due to practical limitations in the amount of time and hardware available.
  • the device 14 is preferably associated with a key recovery system 28 which receives the ciphertext 26.
  • the key recovery system 28 then generally performs trial and error operations in order to determine the cryptographic key 22 based on the secret 20 (including how the secret 20 is associated with the cryptographic key 22), the plaintext 24 and the ciphertext 26.
  • the determination of the cryptographic key 22 based on the secret 20, the plaintext 24 and the ciphertext 26 is described in more detail with reference to Figs. 7 and 8.
  • a confirmation message 36 is sent from the device 14 to the device 12.
  • the secret 20 and the cryptographic key 22 are chosen such that the device 14 can perform trial and error operations in order to determine the cryptographic key 22 based on the secret 20 in a reasonable amount of time, for example, but not limited to, within a number of seconds, whereas an attacker, not knowing the secret 20, will find it extremely difficult, or almost impossible, to determine the cryptographic key 22.
  • the cryptographic key 22 is a concatenation of the secret 20 and another string. If the secret is a 9 digit password which translates into a 30 bit binary value and the other string is a binary value with a length of 34 bits, the cryptographic key 22 has a length of 64 bits which generally affords a reasonably high level of security in many scenarios. As the device 14 already knows the secret 20 which is 30 bits of the cryptographic key 22 (and how the secret 20 is associated with the cryptographic key 22), the device 14 only needs to run a trial and error search on the remaining 34 bits of the cryptographic key 22 in relation to the unknown other string. The trial and error search on the remaining 34 bits is a relatively straightforward task for most
  • Fig. 2 is a partly pictorial, partly block diagram view of encrypted communication between the user 16 of the device 12 and the user 18 of the device 14 using the key 22 in the system 10 of Fig. 1.
  • system and method of the present invention may implemented with any suitable encrypted communication between two devices, for example, but not limited to, data communication between infrared ports of two mobile devices.
  • Fig. 3 is a block diagram view of the device 12 for generating the cryptographic key 22 in the system 10 of Fig. 1.
  • the device 12 preferably includes a communication module 38, a random number generator 40 and a key generation module 42.
  • the communication module 38 is preferably operative to facilitate secure communication with other devices, such as the device 14 (Figs. 1 and 2).
  • Secure communication includes encrypted communication and/or digital authentication, for example, but not limited to, digital signatures.
  • the communication module 38 also performs cryptographic transforms (encrypting and/or decrypting) using a suitable cryptographic key, such as the cryptographic key 22.
  • the random number generator 40 is preferably operative to generate a random number 44 for use by the key generation module 42.
  • the random number 44 is typically a binary string.
  • the random number generator 40 is any suitable random number generator, for example, but not limited to, a pseudorandom number generator with a random seed or a true-random number generator or a module for obtaining pseudo-random input from an external source such as random keystrokes or random mouse movements, by way of example only.
  • the key generation module 42 is preferably operative to generate the cryptographic key 22 based on the secret 20 and the random number 44.
  • the key generation module 42 first generates the cryptographic key 22 and then the secret 20 is derived from the cryptographic key 22 by the key generation module 42, typically based on the random number 44.
  • the secret 20 is typically: determined by the users 16, 18; or generated by one of the devices 12, 14 and then outputted for manually entry into the other device 12, 14; or burned into both of the devices 12, 14; or burned into one of the devices 12, 14 and then outputted for manual entry into the other device 12, 14. Therefore, device 12 may include: a user input interface 27 (typically the keypad 21 (Fig. I)) for manual entry of the secret 20; and/or a secret determination module (SDM) 29 for generating the secret based on a plurality of random bits typically generated by the random number generator 40; and/or a storage arrangement 31 for burning the secret 20 therein.
  • a user input interface 27 typically the keypad 21 (Fig. I)
  • SDM secret determination module
  • the plaintext 24 (known to both the device 12 and the device 14) is then cryptographically transformed using a one-way function (typically encrypted) by the communication module 38 yielding the ciphertext 26.
  • Fig. 4 is a block diagram showing a preferred method of key generation by the device 12 of Fig. 3.
  • the cryptographic key 22 is formed by concatenating the secret 20 with the random number 44.
  • the above method is particularly useful when both the secret 20 and the random number 44 are in the same format, for example, but not limited to, binary format. It will be appreciated by those ordinarily skilled in the art that the secret 20 does not need to be placed only at the beginning or the end of the cryptographic key 22, the secret 20 may be placed at any suitable location in the cryptographic key 22 or even broken into two or more segments for disposal at different suitable locations within the cryptographic key 22.
  • Fig. 5 is a block diagram showing a first alternative preferred method of key generation by the device 12 of Fig. 3.
  • the secret 20 for example, an alphanumeric password
  • the binary representation 46 is then concatenated with the random number 44, which is in binary format, to form the cryptographic key 22.
  • Fig. 6 is a block diagram showing a second alternative preferred method of key generation by the device 12 of Fig. 3.
  • the cryptographic key 22 is formed from the output of a function 48 using the secret 20 and the random number 44 as input.
  • the function is a cryptographic Hash function, such as SHA-I.
  • SHA-I cryptographic Hash function
  • Fig. 7 is a block diagram view of the device 14 showing a preferred method of determining the cryptographic key 22 in the system 10 of Fig. 1.
  • the device 14 preferably includes a communication module 50 and the key recovery system 28.
  • the communication module 50 is preferably operative to receive and/or transmit encrypted data packets, for example, to and from the device 12 (Figs. 1-3).
  • the communication module 50 is also preferably operative to encrypt and/or decrypt data as required.
  • the ciphertext 26 sent by the communication module 38 of the device 12 is preferably received by the communication module 50 (arrow 78).
  • the communication module 50 does not have a cryptographic key with which to decrypt the ciphertext 26
  • the ciphertext 26 is forwarded to the key recovery system 28 in order to determine the cryptographic key 22 for use in encrypted communication between the device 12 and the device 14 (arrow 80).
  • the key recovery system 28 is typically implemented as part of the device 14 using suitable elements of the device 14. Alternatively, the key recovery system 28 may be implemented as a plug-in for connection to the device 14.
  • the functionality of the key recovery system 28 may be implemented partly using elements of the device 14 and partly using a plug-in.
  • the key recovery system 28 preferably includes a receiving module 52, a key determination module 54 and a confirmation module 66.
  • the receiving module 52 is typically operative to receive the ciphertext 26 from the device 12, typically via the communication module 50 (arrow 80).
  • the receiving module 52 forwards the ciphertext 26 to the key determination module 54 for processing (arrow 74).
  • the key determination module 54 determines the cryptographic key 22 based on the secret 20 (and how the secret 20 is associated . with the cryptographic key 22), the plaintext 24 and the ciphertext 26 by trial and error. After the cryptographic key 22 has been determined, the cryptographic key 22 is transferred to the communication module 50 in order to facilitate secure communication between the device 12 and the device 14 using the cryptographic key 22 (arrow 68).
  • the secure communication typically includes encrypted communication and/or digital authentication, for example, but not limited to, digital signatures.
  • the encrypted communication may be two-way or one-way (in either direction) between the device 12 (Figs. 1-3) and the device 14.
  • the key determination module 54 preferably includes a test key generation module 56, a cipher module 58 and a comparison module 60.
  • the test key generation module 56 is preferably operative to determine a test key 62 based on the secret 20 and in the way that the secret 20 is associated with the cryptographic key 22 by the key generation module 42 of the device 12 (arrow 76) (see Figs. 3-6).
  • the cipher module 58 is preferably operative to ciyptographically transform (encrypt) the plaintext 24 using the test key 62 yielding an output text 64 (ciphertext) (arrow 82). It will be appreciated by those ordinarily skilled in the art that the cipher module may be the same encryption/decryption module used by the communication module 50 or a separate encryption/decryption module.
  • the cryptographic algorithm used to determine the cryptographic key 22 for use between the device 12 and the device 14 may be the same as, or different from, the cryptographic algorithm used for other encrypted communication between the device 12 and the device 14 using the cryptographic key 22.
  • the comparison module 60 is preferably operative to compare the output text 64 with the ciphertext 26.
  • the comparison module 60 preferably receives the ciphertext 26 from the receiving module 52 (arrow 74). If the output text 64 is equal to the ciphertext 26, then the test key 62 is generally a possible candidate for being the cryptographic key 22.
  • test key generation module 56 The steps performed by the test key generation module 56, cipher module 58 and the comparison module 60 are repeated for all possible values of the test key 62, based on the secret 20 (arrow 72) and the way that the secret 20 is associated with the cryptographic key 22, in order to rule out spurious results, as it may be possible for the key determination module 54 to determine more than one matching key based on the secret 20, the plaintext 24, the ciphertext 26 and the way that the secret 20 is associated with the cryptographic key 22.
  • the unique test key 62 is defined as the cryptographic key 22 and the cryptographic key 22 is transferred to the communication module 50 for use in encrypted communication between the device 12 and the device 14 (arrow 68).
  • the communication module 50 receives the cryptographic key 22 from the comparison module 60 of the key determination module 54.
  • the confirmation module 66 receives a command 84 from the comparison module 60 to send the confirmation message 36 to the device 12, via the communication module 50, confirming that the cryptographic key 22 has been determined (arrows 70).
  • a message (not shown) is sent to the device 12 typically by the confirmation module 66 via the communication module 50 requesting receipt of a new key recovery ciphertext (not shown) being a cryptographic transform (encryption) of a new key recovery plaintext (not shown), known by the device 14, using the same cryptographic key 22.
  • the receiving module 52 receives the new ciphertext from the device 12 via the communication module 50.
  • the plaintext 24 is sent to device 14 by the device 12 with the ciphertext 26.
  • the plaintext 24 may be sent in advance to the device 14 or handed to the user 18 of the device 14 for entering manually into the device 14, by way of example only.
  • the key determination module 54 is then operative to determine the cryptographic key 22 based on the secret 20, the new ciphertext, the new plaintext and the way that the secret 20 is associated with the cryptographic key 22, as described above with reference to the test key generation module 56, the cipher module 58 and the comparison module 60. If the new ciphertext does not yield a unique result for the cryptographic key 22, then another new key recovery ciphertext and plaintext is generally requested. The process is repeated until a unique result for the cryptographic key 22 is found.
  • the secret 20 is typically: determined by the users 16, 18; or generated by one of the devices 12, 14 and then outputted for manually entry into the other device 12, 14; or burned into both of the devices 12, 14; or burned into one of the devices 12, 14 and then outputted for manual entry into the other device 12, 14. Therefore, the device 14 may include a user input interface (typically the keypad 23 (Fig. I)) for manual entry of the secret 20 or the key recovery system 28 may include: a secret determination module 33 (SDM) for generating the secret based on a plurality of random bits; or a storage arrangement 35 for burning the secret 20 therein.
  • SDM secret determination module 33
  • Fig. 8 is a block diagram view of the device 14 showing an alternative preferred method for determining the cryptographic key 22 in the system 10 of Fig. 1.
  • the alternative preferred method is substantially the same as the method described with reference to Fig. 7 except for the following differences.
  • the cipher module 58 is preferably operative to receive the ciphertext 26 from the receiving module 52 (arrow 88) and to decrypt the ciphertext 26 using the test key 62 yielding an output text 86 (arrow 90).
  • the comparison module is preferably operative to compare the output text 86 with the plaintext 24. If the output text 86 is equal to the plaintext 24, then the test key 62 is a possible candidate for being the cryptographic key 22.
  • the stronger of the two communicating devices 12, 14 is chosen to perform the trial-and-error operations and the weaker of the two communicating devices (for example, but not limited to, the weaker of the devices 12, 14) is selected to determine the cryptographic key 22 (Fig. 1).
  • the device with the capability to determine and output the cryptographic key 22 is typically chosen as the device to determine and output the cryptographic key 22.
  • the secure communication system 10 is particularly useful for the following cases: secure communication between devices that are weak and/or have only a small secure storage for keys; and/or secure communication between devices that rely on volatile secrets and use inputs instead of non-volatile keys; and/or Bluetooth secure specification which relies on 4-digit secret keys; and/or secure communication between mobile devices; and/or secure communication between a strong reader with an RFID device implemented with some randomness.
  • FIG. 9 is a pictorial view of a secure communication system 92 constructed and operative in accordance with another preferred embodiment of the present invention.
  • the secure communication system 92 is described to further illustrate different methods of secret sharing. It will be appreciated that the methods of secret sharing described with reference to the secure communication system 92 may be used with the secure communication system 10 of Fig. 1.
  • a user 94 is using a computer system 98 and a user 96 is using a computer system 100.
  • Each computer system 98, 100 preferably includes a wireless interface 102 to enable wireless communication between the computer systems 98, 100.
  • Each computer system 98, 100 typically includes a user input interface 104 (keyboard and preferably a mouse) as well as a display screen 106 and a processor 108.
  • the computer system 98 also preferably includes a printer 110.
  • Fig. 10 is a pictorial view of a secret 112 being outputted in the system 92 of Fig. 9.
  • the processor 108 of the computer system 98 preferably generates the secret 112.
  • the secret 112 is then typically outputted to the printer 110 (output interface) and printed onto a sheet of paper 114.
  • Fig. 11 is a pictorial view of the secret 112 of Fig. 10 being manually transferred.
  • the paper 114 is typically handed by the user 94 to the user 96 so that the user 96 can manually enter the secret 112 (Fig. 10) into the computer system 100 (Fig. 9).
  • Fig. 12 is a pictorial view of the secret 112 being displayed. Instead of the secret 112 being printed out, the secret 112 is displayed ori to the display screen 106 (output interface) of the computer system 98.
  • Fig. 13 is a pictorial view of the secret 112 of Fig. 12 being verbally conveyed by the user 94 to the user 96 in the system of Fig. 9. The user 96 then preferably manually enters the secret 112 into the computer system 100 (Fig. 9).
  • Fig. 14 is a pictorial view of, wireless encrypted communication in the system 92 of Fig. 9.
  • the computer system 100 determines the encryption key by trial and error. Once the key has been determined, the computer system 98 and the computer system 100 securely communicate wirelessly using the key via the wireless interfaces 102.
  • Fig. 15 is a block diagram view of a device 116 for use in a secure communication system 118 constructed and operative in accordance with yet another preferred embodiment of the present invention.
  • the system 118 is substantially the same as the secure communication system 10 of Figs. 1-8 except for the following differences described with reference to Figs. 15 and 16.
  • the system 118 is preferably operative to enable secure communication between the device 116 and a device 122 described with reference to Fig. 16.
  • the device 116 is substantially the same as the device 12 of Fig. 3, except for the following differences.
  • the communication module 38 is preferably operative to use a cryptographic hash function, for example, but not limited to, SHA-I, to determine a key recovery text which is a hash value 120 of the key 22.
  • the hash value 120 is then typically sent by the communication module 38 to the device 122.
  • Fig. 16 is a block diagram view of the device 122 for use in the system 118 of Fig. 15.
  • the device 122 is substantially the same as the device 14 of Fig. 7 except for the following differences.
  • the hash value 120 is preferably received by the communication module 50 of the device 122.
  • the receiving module 52 is preferably operative to receive the hash value 120 (key recovery text) from the communication module 50.
  • the key determination module 54 is operative to: determine the key 22 based on the secret 20 and the hash value 120 by trial and error; and transfer the key 22 to the communication module 50 in order to facilitate secure communication between the device 116 and the device 122.
  • the secure communication is typically encrypted communication and/or digital authentication.
  • the key determination module 54 includes a hash module 124 instead of the cipher module 58 of Fig. 7.
  • the hash module 124 receives the test key 62 from the test key generation module 56 and hashes the test key 62 using the cryptographic hash function of Fig. 15 yielding an output text 126.
  • the comparison module 60 compares the output text 126 to the hash value 120 (key recovery text).
  • the comparison module 60 preferably receives the hash value 120 from the receiving module 52 (arrow 74). If the output text 126 is equal to the hash value 120, then the test key 62 is generally a possible candidate for being the cryptographic key 22.
  • test key generation module 56 hash module 124 and the comparison module 60 are repeated for all possible values of the test key 62, based on the secret 20 (arrow 72) and the way that the secret 20 is associated with the cryptographic key 22, in order to rule out spurious results, as it may be possible for the key determination module 54 to determine more than one matching key based on the secret 20, the hash value 120 and the way that the secret 20 is associated with the cryptographic key 22.
  • test keys 62 are a possible candidate for being the cryptographic key 22
  • the unique test key 62 is defined as the cryptographic key 22 and the cryptographic key 22 is transferred to the communication module 50 for use in encrypted communication between the device 116 and the device 122 (arrow 68).
  • a message (not shown) is typically sent to the device 116 by the confirmation module 66 via the communication module 50 requesting receipt of a new key recovery text (not shown) being a hash of a new cryptographic key (not shown) using the cryptographic hash function.
  • the receiving module 52 receives the new key recovery text from the device 116 via the communication module 50.
  • the key determination module 54 is then operative to determine the new cryptographic key based on the secret 20 and the new key recovery text and the way that the secret 20 is associated with the new cryptographic key using trial and error, as described above with reference to the test key generation module 56, the hash module 124 and the comparison module 60. If the new key recovery text does not yield a unique result for the new cryptographic key, then another new key recovery ciphertext is generally requested. The process is repeated until a unique cryptographic key is found.
  • the cryptographic hash-function is preferably configured to avoid collision by expanding the input using padding for example by repeating the input (typically many times) to form a concatenated value which is then hashed.
  • software components of the present invention may, if desired, be implemented in ROM (read only memory) form.
  • the software components may, generally, be implemented in hardware, if desired, using conventional techniques.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un premier dispositif pour communiquer en toute sécurité avec un second dispositif, ceux-ci partageant un secret. Le second dispositif contient une clé cryptographique, au moins partiellement basée sur le secret, le second dispositif pouvant utiliser une fonction unidirectionnelle et la clé pour déterminer un premier texte de récupération de clé. Le premier dispositif comprend un module de réception pour recevoir le premier texte de récupération de clé du second dispositif, un module de détermination de clé pour déterminer la clé, au moins basée sur le secret et le premier texte de récupération de clé par essai et erreurs, ainsi qu'un module de communication pour : recevoir la clé du module de détermination de clé et communiquer en toute sécurité avec le second dispositif à l'aide de la clé. L'invention concerne également un appareil et des procédés associés.
PCT/IL2007/000679 2006-11-12 2007-06-04 Communication sécurisée WO2008059475A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IL179202A IL179202A0 (en) 2006-11-12 2006-11-12 Secure communication
IL179202 2006-11-12

Publications (1)

Publication Number Publication Date
WO2008059475A1 true WO2008059475A1 (fr) 2008-05-22

Family

ID=38529973

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2007/000679 WO2008059475A1 (fr) 2006-11-12 2007-06-04 Communication sécurisée

Country Status (2)

Country Link
IL (1) IL179202A0 (fr)
WO (1) WO2008059475A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009001718A1 (de) * 2009-03-20 2010-09-23 Compugroup Holding Ag Verfahren zur Bereitstellung von kryptografischen Schlüsselpaaren
US8661247B2 (en) 2009-12-18 2014-02-25 CompuGroup Medical AG Computer implemented method for performing cloud computing on data being stored pseudonymously in a database
US8677146B2 (en) 2009-12-18 2014-03-18 CompuGroup Medical AG Computer implemented method for sending a message to a recipient user, receiving a message by a recipient user, a computer readable storage medium and a computer system
US8699705B2 (en) 2009-12-18 2014-04-15 CompuGroup Medical AG Computer implemented method for generating a set of identifiers from a private key, computer implemented method and computing device
US8868436B2 (en) 2010-03-11 2014-10-21 CompuGroup Medical AG Data structure, method, and system for predicting medical conditions
KR20170021767A (ko) * 2014-04-09 2017-02-28 액틸리티 통신 네트워크에서 프레임을 인코딩 및 디코딩하기 위한 방법
WO2017185804A1 (fr) * 2016-04-28 2017-11-02 宇龙计算机通信科技(深圳)有限公司 Procédé et terminal de commande d'appel chiffré

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020186846A1 (en) * 2001-06-08 2002-12-12 Nokia Corporation Method for ensuring data transmission security, communication system and communication device
GB2390270A (en) * 2002-06-27 2003-12-31 Ericsson Telefon Ab L M Escrowing with an authority only part of the information required to reconstruct a decryption key
WO2004025921A2 (fr) * 2002-09-16 2004-03-25 Telefonaktiebolaget L M Ericsson (Publ) Acces securise a un module d'abonnement

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020186846A1 (en) * 2001-06-08 2002-12-12 Nokia Corporation Method for ensuring data transmission security, communication system and communication device
GB2390270A (en) * 2002-06-27 2003-12-31 Ericsson Telefon Ab L M Escrowing with an authority only part of the information required to reconstruct a decryption key
WO2004025921A2 (fr) * 2002-09-16 2004-03-25 Telefonaktiebolaget L M Ericsson (Publ) Acces securise a un module d'abonnement

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PERRIG A ET AL: "ELK, a new protocol for efficient large-group key distribution", PROCEEDINGS OF THE IEEE SYMPOSIUM ON SECURITY AND PRIVACY. S&P 2001. OAKLAND, CA, MAY 14 - 16, 2001, May 2001 (2001-05-01), IEEE COMP. SOC, LOS ALAMITOS, CA, US, pages 247 - 262, XP010543221, ISBN: 0-7695-1046-9 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9288044B2 (en) 2009-03-20 2016-03-15 CompuGroup Medical AG Method for providing cryptographic key pairs
WO2010105915A2 (fr) 2009-03-20 2010-09-23 Compugroup Holding Ag Procédé de fourniture de paires de clefs cryptographiques
DE102009001718B4 (de) * 2009-03-20 2010-12-30 Compugroup Holding Ag Verfahren zur Bereitstellung von kryptografischen Schlüsselpaaren
US8605899B2 (en) 2009-03-20 2013-12-10 CompuGroup Medical AG Method for providing cryptographical key pairs
DE102009001718A1 (de) * 2009-03-20 2010-09-23 Compugroup Holding Ag Verfahren zur Bereitstellung von kryptografischen Schlüsselpaaren
US8661247B2 (en) 2009-12-18 2014-02-25 CompuGroup Medical AG Computer implemented method for performing cloud computing on data being stored pseudonymously in a database
US8677146B2 (en) 2009-12-18 2014-03-18 CompuGroup Medical AG Computer implemented method for sending a message to a recipient user, receiving a message by a recipient user, a computer readable storage medium and a computer system
US8695106B2 (en) 2009-12-18 2014-04-08 CompuGroup Medical AG Computer implemented method for analyzing data of a user with the data being stored pseudonymously in a database
US8699705B2 (en) 2009-12-18 2014-04-15 CompuGroup Medical AG Computer implemented method for generating a set of identifiers from a private key, computer implemented method and computing device
US8887254B2 (en) 2009-12-18 2014-11-11 CompuGroup Medical AG Database system, computer system, and computer-readable storage medium for decrypting a data record
US8868436B2 (en) 2010-03-11 2014-10-21 CompuGroup Medical AG Data structure, method, and system for predicting medical conditions
KR20170021767A (ko) * 2014-04-09 2017-02-28 액틸리티 통신 네트워크에서 프레임을 인코딩 및 디코딩하기 위한 방법
US10129789B2 (en) 2014-04-09 2018-11-13 Actility Methods for encoding and decoding frames in a telecommunication network
KR102251121B1 (ko) * 2014-04-09 2021-05-12 액틸리티 통신 네트워크에서 프레임을 인코딩 및 디코딩하기 위한 방법
EP3130168B1 (fr) * 2014-04-09 2021-11-10 Actility Procédés de codage et décodage de trames dans un réseau de télécommunication
WO2017185804A1 (fr) * 2016-04-28 2017-11-02 宇龙计算机通信科技(深圳)有限公司 Procédé et terminal de commande d'appel chiffré
CN107343275A (zh) * 2016-04-28 2017-11-10 宇龙计算机通信科技(深圳)有限公司 加密通话控制方法和终端

Also Published As

Publication number Publication date
IL179202A0 (en) 2008-01-20

Similar Documents

Publication Publication Date Title
EP1554834B1 (fr) Communications securisees
US7424615B1 (en) Mutually authenticated secure key exchange (MASKE)
Saraf et al. Text and image encryption decryption using advanced encryption standard
KR100506076B1 (ko) 패스워드를 기반으로 한 상호 인증 및 키 교환방법과 그장치
US20050154896A1 (en) Data communication security arrangement and method
EP1825632B1 (fr) Interface securisee pour support de fonction de derivation de cle polyvalente
KR20070057871A (ko) 다항식에 기초한 인증 방법
WO2008059475A1 (fr) Communication sécurisée
Joshy et al. Text to image encryption technique using RGB substitution and AES
JPWO2006019152A1 (ja) メッセージ認証子生成装置、メッセージ認証子検証装置、およびメッセージ認証子生成方法
KR101014849B1 (ko) 제 3의 신뢰기관의 도움 없이 공개키에 대한 상호 인증 및키 교환 방법 및 그 장치
EP1456997B1 (fr) Systeme et procede de cryptographie symetrique
JP2012050075A (ja) 暗号化通信システム及び暗号化通信方法
JP2005167635A (ja) 装置、及び、データ送受信方法
El Bakry et al. Implementation of a hybrid encryption scheme for sms/multimedia messages on android
Almuhammadi et al. Double-hashing operation mode for encryption
JP6216662B2 (ja) 暗号化通信装置、暗号化通信システム、及び暗号化通信方法
EP4123956A1 (fr) Procédé pour le transfert sécurisé de valeurs d'éléments de données
US20200287710A1 (en) Single stream one time pad with encryption with expanded entropy
Ahmad et al. Attack Robustness and Security Enhancement with Improved Wired Equivalent Protocol
JP3230726B2 (ja) 暗号化通信方法
Ayane et al. Message Authentication in wireless Networks using HMAC algorithm
Chaudhari et al. Enhanced SAFER+ algorithm for bluetooth to withstand against key pairing attack
KR20040085113A (ko) 무선 이동통신망에서 일회용 암호 키 생성 및 사용 방법
Huang et al. Random Cladding with Feedback Mechanism for encrypting mobile messages

Legal Events

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

Ref document number: 07736419

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07736419

Country of ref document: EP

Kind code of ref document: A1