Cryptographic methods for verifying data
By mixing data with a randomly generated mixer number and hashing it, the method enhances data integrity and sender authentication, addressing vulnerabilities in existing hashing techniques and quantum computer threats.
Patent Information
- Application Number
- JP2021549168
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2019-02-19
- Filing Date
- 2020-02-17
- Publication Date
- 2025-01-17
- Estimated Expiration
- 2040-02-17
AI Technical Summary
Existing hashing techniques are vulnerable to errors and unauthorized modifications, particularly with the advent of quantum computers, necessitating improved methods for data validation and sender authentication.
A method involving mixing data with a mixer number using a mixing function and then hashing it, followed by comparing the resulting hash with a third dataset, ensuring that similar data creation is minimized, and incorporating random generation and encryption of the mixer number to enhance security.
This approach significantly reduces the likelihood of data tampering and ensures reliable authentication of the sender, even in the presence of quantum computers, by using randomly generated mixer numbers and disposable encryption keys.
Smart Images

Figure 0007617008000001 
Figure 0007617008000002 
Figure 0007617008000003
Abstract
Description
[Technical field]
[0001] The present invention relates to digital cryptography and security for computing and electronic devices, and in particular to digital signatures. [Background technology]
[0002] Computers and electronic devices are often connected to networks, either physically, wirelessly, by RFID, or by any other secure or insecure means, and sometimes it is necessary to know the identity of the device that sent certain data to these computers and electronic devices, for example to ensure that these data were not transmitted by another device that intercepted them and modified them before sending them to the legitimate recipient, or simply to identify beyond any doubt the identity of the sender of the data, be it, for example, an RFID tag worn by a car on a road network or a competitor during a sporting event, or for any other reason where the identity of the sender of the data is important to the recipient.
[0003] The data to be transmitted can be sent fully encrypted using a key that originates from the sender. However, all encryption of the data makes the use of disposable keys (one-time pads) difficult. In particular, all encryption of the data uses keys that are only valid for the duration of the data they encrypt, and these keys must be updated after use.
[0004] It is therefore necessary for computers or other electronic devices entering into communication, for example through the exchange of text, identifiers, numbers, computer programs, images, or video or audio codes, to verify the identity of the sending device using encryption of an amount of data that is less than the amount of data transmitted. It is for this reason that electronic signatures are used that consist of encrypting a hash of data. The term "hash" is used to refer to the result of a hash function that calculates a fingerprint that serves to quickly but imperfectly identify the initial data given as input. It is common to transmit an encrypted hash together with the data, which is then decrypted by the receiver and then compared with the hash of the received data. MD5, SHA1 and SHA256 are algorithms traditionally used for such hashing operations. However, data hashes are generally much smaller in size than the original data, and it may be possible to create other data similar to but slightly different from the original data, with a hash equal to the hash of the original data. These data may therefore be substituted for the original data without being rejected by the procedure for verifying the hash. Any type of data may be substituted, but as the complexity of the data increases (long texts, audio files, photos or videos), the possibility of detection by the user of the substitution decreases. To perform the substitution, it is not even necessary to decrypt the encrypted hash; simply computing the hash of the original data is sufficient. Furthermore, hash functions such as MD5 and SHA1 are currently relatively easy to circumvent.
[0005] Quantum computers, under development, may be able to optimize starting files to have preset hashes, and so it may soon be possible to circumvent the security offered by hash functions.
[0006] Methods are known in the prior art for improving the security of a system using hashing techniques.
[0007] CN101547184 uses multiple auxiliary authentication values exchanged between the server and the user.
[0008] In the method proposed in US Patent Application Publication No. 2011 / 0246433, a hash of the data to be transmitted is generated and concatenated with the data chunk to be transmitted and a random number tag.
[0009] EP 1 421 548 A1 describes a method for transmitting information, in which the message to be sent is concatenated with a random number that is subsequently hashed. The result of the hashing is sent unencrypted to the other party. The message is sometimes transmitted as such or encrypted. The random number is always signed and optionally encrypted and transmitted to the other party. The fact that the hash is not encrypted when the message itself is not encrypted makes the transmission vulnerable to very powerful or quantum computers that can calculate the random number that fits the unencrypted message and the result of the hash. Furthermore, encrypting the entire message has drawbacks when such encryption uses a one-time pad, which requires that both of the two corresponding parties have access to such a shared key, which is supposed to be uncrackable. [Prior art documents] [Patent documents]
[0010] [Patent Document 1] China Patent Application Publication No. 101547184 [Patent Document 2] US Patent Application Publication No. 2011 / 0246433 [Patent Document 3] European Patent Application Publication No. 1421548 Summary of the Invention [Problem to be solved by the invention]
[0011] There is a need to further improve the security of hashing techniques to reduce the probability of errors in verifying data and, where appropriate, to allow more reliable authentication of the senders of these data. [Means for solving the problem]
[0012] The present invention specifically aims to meet this need and achieves this objective by means of a method implemented by at least one device for comparing a first data set and a second data set, in particular for determining whether these two data sets are identical, said method comprising the following steps: a) mixing a number, referred to as a mixer number, with a first data set using a mixing function to obtain mixed data; b) hashing the mixed data using a hash function; c) comparing the hash thus obtained in step b) with a third data set, which is considered to be the hash of the second data set mixed with the same number of mixers as used in step a), using the same mixing function; Includes.
[0013] The present invention makes it highly unlikely that mixing a first data set with a mixer number, specifically before hashing, can create data similar to this first data set that has the same hash as the mixed first data set after being mixed with the same mixer number.
[0014] Preferably, the method according to the invention does not require that the two data sets be present simultaneously within the device.
[0015] Preferably, the mixer numbers are randomly generated.
[0016] The mixer numbers are preferably generated by the device, as a variant the mixer numbers are generated by another trusted device.
[0017] The generation of the mixer number may be based on a pair of input values, at least one of which is a constantly changing physical quantity, such as temperature and time, or on quantum phenomena. For example, such generation may be based on which of two Young's slits a photon chooses to use to pass through the plate.
[0018] Preferably, the mixing operation in step a) is performed by the device. As a variant, the mixing is performed by a separate reliable device.
[0019] The mixing function combines the first data set and the mixer number. Preferably, it is an XOR logic function that adds the bits of the first data set and the bits of the mixer number one by one. Since the size of the mixer number is generally smaller than the size of the first data set, it is possible to add the bits of the mixer number to the first or last bit of the first data set via XOR.
[0020] The number of mixers may have the same size as the first data set, in which case the addition via the XOR function is performed for every bit, one by one.
[0021] Alternatively, the mixing function consists of adding the mixer number to the end of the first data set.
[0022] The mixing function may even be an encryption function that uses the mixer number as an encryption key to encrypt the first data set.
[0023] Preferably, the data in step b) is hashed by the device. As a variant, the hashing is performed by a separate trusted device.
[0024] Preferably, the hash function is selected from SHA1, SHA2, SHA256 and MD5, and the Jenkins function.
[0025] A first variant of the method according to the invention is a method for verifying the integrity of a message originating from a sender by means of a device, the method comprising the steps of: i. a device receiving a message and an identifier of the message, said message forming a first data set; ii. generating a mixer number; iii. performing steps a) and b), in which the message is mixed with a mixer number and then hashed; iv. Optionally encrypting the mixer number; v. the device sending an identifier of the message and an optionally encrypted mixer number to the sender of the message; vi. receiving by the device an encrypted third set of data originating from the sender, preferably together with an identifier of the message; vii. Decrypting the third data set; viii. performing step c), where if the third data set decrypted in step vii and the hash obtained in step b) are identical, message integrity is ensured; Includes.
[0026] The "integrity" of a message should be understood to mean the absence of modification, for example by a malicious third party intercepting the message during transmission.
[0027] The message identifier may be a sequence of alphanumeric characters and / or symbols that can be converted into a digital word, especially via the ASCII code.
[0028] The message identifier may include a sender identifier and a message sequence number.
[0029] The authenticity of the sender is specifically ensured by the decryption operation in step vii.
[0030] This first variant of the invention makes it possible to guarantee both the integrity of the received message and the integrity of the identity of the sender of the message.
[0031] The steps relating to transmitting data and receiving data may be performed using the same or different communication protocols, for example data received in step i is received via Wi-Fi, data transmitted in step v is transmitted via 4G, and data received in step vi is received via WiMAX.
[0032] In step i, the device may also receive an identifier of the sender, which is useful when the device can receive messages from various senders, as such an identifier makes it possible to choose the encryption key to be used to encrypt or decrypt the information exchanged with the sender during the encryption and decryption operations described in this first variant of the invention.
[0033] Preferably, the method according to this first variant further comprises, between steps v and vi, - a sender receiving an identifier of a message and an optionally encrypted mixer number; - optionally decoding the mixer number; - identifying a message sent to the device using an identifier of the message; - mixing the message with the optionally decoded mixer number using a mixing function; - hashing the data resulting from the preceding step using a hash function; - encrypting the hash resulting from the preceding step; - sending the encrypted hash to the device, preferably together with an identifier for the message; Includes.
[0034] The optional encryption of the mixer number in step iv is preferably performed by the device.
[0035] The optional encryption of the mixer number makes it possible to prevent this number from being intercepted and altered by malicious third parties.
[0036] Preferably, the optional encryption of the mixer number is done using a one-time use key of size at least equal to the size of the number. Since the key is one-time use, a new key is used every time the mixer number is transmitted.
[0037] Encryption may also be performed using a symmetric encryption key that is kept secret between the sender and the device and is preferably updated after a certain number of transmissions.
[0038] Alternatively, the optional encryption of the mixer number is asymmetric, either using the sender's public key known to the device, or using the device's private key, whose public key is known to the sender, to enable decryption by the sender using the associated private key.
[0039] Thus, a third party is prevented from knowing or altering the mixer number.
[0040] Preferably, the decoding in step vii is performed by the device.
[0041] Preferably, if the encryption in step iv is performed using a one-time key, the decryption in step vii is performed using a symmetric key.
[0042] Alternatively, if the encryption in step iv is performed using a symmetric key, the decryption in step vii is performed using a one-time key.
[0043] The decryption in step vii may also be performed using other methods, for example using a public key known to the device that is associated with the sender's private key that served to encrypt the received hash in step vi, thus allowing the device to authenticate the sender's identity.
[0044] The mixer number has the same size as the symmetric key that serves to encrypt the mixer number, if such a symmetric key is used, and may also have the same size as the hash.
[0045] Preferably, the secret, symmetric, one-time use encryption key and mixer number are unguessable and unobservable by a third party device to prevent listening to the data transmitted by the sender or device from enabling it to generate and transmit a fraudulent second data set that would falsely identify the integrity of a message received by the device but transmitted by a sender other than the one legitimately supposed to hold the key.
[0046] If the encryption key X for mixer number x is known, the hash of the mixed message may be known, since it is sufficient to decrypt the encryption of x and compute the mixture of the message before hashing the message. Then the key Y that encrypts the hash may also be guessed or known to belong to a small population, and both the hash of the mixed message and its encryption with Y are known or observable. Thus, the encryption key Y is a function F of the encryption key X, or else the encryption key Y belongs to a population that depends on the encryption key X. Observation of multiple transmissions will result in multiple functions F, and the values of keys X and Y are in the intersection of these functions. It is preferable to avoid this situation. It is therefore recommended either to use values for key X or key Y that change during the transmission, or to use encryption functions such that for each observation of the exchange of a triple "message, encrypted number, encrypted hash", the population of keys Y for each possible X is large (hence the population resulting from the intersection of these populations that can be inferred at each observation). It is not recommended to take a randomly generated mixer number x for key Y. Specifically, if mixer number x is used as encryption key Y, or indeed key Y is calculated depending on mixer number x using a defined formula, then knowing key X, mixer number x, and thus the encrypted value C of mixer number x encrypted with Y, will be another function G of key X, and key X and key Y will be in the intersection of function F and this new function G. Preferably, key X or key Y is updated after each exchange.
[0047] The device may further include a counter of consecutive failed verification attempts that triggers blocking of the verification attempts when a defined number is reached, such that the device is not blocked during updates of the encryption key used to encrypt the mixer number or the encryption key used to encrypt the hash, as the case may be.
[0048] A second variant of the method according to the invention is a method for verifying the integrity of a message originating from a sender by means of a device, the method comprising the steps of: i. receiving by the device a message, an encrypted third data set, and an encrypted mixer number; ii. decoding the mixer number and the third data set; iii. performing steps a) to c), where message integrity is ensured if the hash obtained in step b) and the third data set decrypted in step ii are identical; Includes.
[0049] Preferably, the method according to this second variant of the invention further comprises, before step i, - a sender generating a mixer number; - mixing the mixer number with the message using a mixing function; - hashing the data resulting from the preceding step using a hash function; - encrypting the hash resulting from the preceding step to form a third data set; - encrypting the mixer number; - transmitting the message, the encrypted third data set, and the encrypted mixer number to the device; Includes.
[0050] These steps are taken by the genuine sender and allow tampering with the message by an unauthorized third party to be detected.
[0051] The decoding in step ii of the mixer number and the third data set is preferably performed by the device.
[0052] Preferably, the encryption of the mixer number is performed using a one-time key and the encryption of the third data set is performed using a symmetric key, which is preferably updated from time to time.
[0053] Alternatively, the encryption of the mixer number is performed using a symmetric key and the encryption of the third data set is performed using a one-time use key, the symmetric key being preferably updated from time to time.
[0054] The encryption of the mixer number and the encryption of the third data set may also be of the same type or of different types, these types of encryption possibly using symmetric or asymmetric keys.
[0055] Where an asymmetric key pair is used to encrypt the mixer numbers, the private key of the pair is preferably held by the device, and the corresponding public key is then known to the sender.
[0056] The encryption of the third data set is preferably performed using a private key held by the sender, the corresponding public key then being known to the device.
[0057] Thus, by decoding the mixer number and the third data set, the device is able to verify the identity of the sender.
[0058] The encryption of the mixer number and the encryption of the third data set may be performed using the same encryption function, in particular when the encryption of the mixer number is asymmetric.
[0059] Alternatively, the encryption of the mixer number and the encryption of the third data set are performed by two different encryption functions.
[0060] Preferably, the type of encryption function to be used forms part of the configuration of the sender and the device prior to setting up communications between the sender and the device.
[0061] A third variant of the method according to the invention is a method in which the first data set is present in a device and the second data set is present in a second device, the method comprising the steps of: i. performing step a) and step b); ii. encrypting the mixer number; iii. the device transmitting the encrypted mixer number to a second device; iv. receiving by the device an encrypted hash of the second data set; v. Decrypting the encrypted hash; vi. carrying out step c); Includes.
[0062] Preferably, the method according to this third variant of the invention further comprises, between steps iii and iv, - receiving the encrypted mixer number at a second device; - decoding a number of mixers; - creating a modified copy of the second data set using the mixer number and the blending function; - hashing the modified copy of the second data set using a hash function; - encrypting the hash resulting from the preceding step to form a third data set; - the second device transmitting an encrypted hash of the second data set to the device; Includes.
[0063] The encryption of the mixer number in step ii and the decryption of the encrypted hash in step v are preferably performed by the device.
[0064] Preferably, the encryption of the mixer number is performed using a symmetric encryption key shared with the second device.
[0065] Preferably, the encryption of the hash is done using a one-time key, and the encryption of the mixer number is done using a symmetric key that is updated from time to time.
[0066] Alternatively, the mixer number is encrypted using a one-time key, and the hash is encrypted using a symmetric key that is updated from time to time.
[0067] The encryption of the mixer number and the encryption of the hash may also be of the same type or of different types, these types of encryption possibly using symmetric keys, in particular one-time keys, or asymmetric keys.
[0068] A fourth variant of the method according to the invention is a method for verifying that a data set present in a device has not been modified between two times d1 and d2, said data sets forming a first data set at time d1 and a second data set at time d2, the method comprising: i. performing step a) and step b); ii. the device securely stores the mixer number and the hash obtained in step b); iii. creating a modified copy of the second data set using the mixer number and the blending function; iv. hashing the modified copy using a hash function to form a third data set; v. carrying out step c); Includes.
[0069] Advantageously, the method according to this fourth variant does not require the data set to be kept secure.
[0070] Another subject of the invention is a computer program product comprising instructions readable by a processor of a device for implementing the method according to the invention according to any one of the variants defined above.
[0071] The invention may be better understood on reading the following detailed description of non-limiting examples of its implementations and on examining the accompanying drawings, in which: [Brief description of the drawings]
[0072] [Figure 1]FIG. 2 shows a schematic representation of the data and functions necessary to implement the invention according to a first variant of the invention or according to a second variant of the invention. [Diagram 2] FIG. 2 shows a schematic diagram of an example of implementation of the invention according to a first variant of the invention. [Diagram 3] FIG. 4 shows a schematic diagram of an example of implementation of the invention according to a second variant of the invention. [Figure 4] FIG. 4 shows diagrammatically the data and functions used to implement the invention according to a third variant of the invention. [Diagram 5] FIG. 4 shows a schematic diagram of an example of implementation of the present invention according to a third variant of the present invention. [Figure 6] FIG. 13 shows a scheme of implementation of the invention according to a fourth variant of the invention. [Figure 7] FIG. 9 is a schematic diagram of data used to implement the example of FIG. 8; [Figure 8] FIG. 1 illustrates a first example of an implementation of the present invention applied to the validation of a software package. [Figure 9] FIG. 2 illustrates a second example of an implementation of the present invention applied to the validation of software packages. [Figure 10] FIG. 12 is a schematic diagram of devices and data used to implement the example of FIG. 11. [Figure 11] FIG. 1 illustrates an example of an implementation of the present invention applied to enhancing security in an Internet browser. [Figure 12] FIG. 14 is a schematic diagram of devices and data used to implement the example of FIG. 13. [Figure 13] FIG. 1 shows an example of an implementation of the present invention applied to enhancing email security. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0073] FIG. 1 shows diagrammatically the data and functions used to implement the invention according to the first variant of the invention or the second variant of the invention, in which a message 101 must be sent by device A to device B via a data transmission channel 109, which may be secure or non-secure.
[0074] Device A may be a personal computer or a smartphone, device B may be an email server, and message 101 may be, for example, an email sent by a computer or phone over the Internet.
[0075] Device A may also be a server sending an email or a web page, and device B may in turn be a personal computer or a smartphone receiving said email or web page.
[0076] Device A may for example even be a measuring device for measuring electricity, gas or water consumption or for measuring wear of parts in a machine and message 101 may in turn be the result of such a measurement, and device B may be a server that collects the measurements and communicates with the measuring device via a telecommunications network, for example the Internet of Things, a Wi-Fi network or an LTE network.
[0077] Device A and Device B may also be personal computers or smartphones.
[0078] Device A may be a web browser, device B may be a web server, message 101 may be a form filled out by a user of browser A, and receipt of the message may not need to be differentiated with respect to its transmission.
[0079] Device A and device B may each comprise a processor for carrying out the steps of the method according to the invention and a memory for storing data required for this execution.
[0080] Device B can obtain the encrypted / decrypted data 102B, such as a private key, and Device A can obtain the encrypted / decrypted data 102A, such as a public key associated with the private key 102B.
[0081] Device A can also obtain encryption / decryption data 103A, such as a private key associated with public key 103B present in device B.
[0082] Device A and device B possess random number generators 104A and 104B, respectively, a common mixing function 105, and a common hash function 106.
[0083] Device A and device B also have encryption functions 107A and 107B, respectively, and decryption functions 108A and 108B, respectively.
[0084] FIG. 2 shows an example of implementation of the method according to the first variant of the invention.
[0085] In step 201, a first number used to identify the message 101 is generated by device A. The first number may optionally be generated using a random number generator 104A.
[0086] In step 202, a first number is added to the message 101. This addition can be a concatenation in any order defined by the communication protocol used between the two devices.
[0087] In step 203 , device A transmits the data resulting from step 202 to device B via data transmission channel 109 .
[0088] In step 204, upon receipt of the data, device B randomly generates a second number using random number generator 104B.
[0089] In step 205, device B utilizes a mixing function 105 to mix a second number with the message 101. By way of example, this mixing function is an XOR operating between the bits of the second number and the same number of bits of the message 101. The mixing function 105 is known by device A.
[0090] In step 206, device B uses hash function 106 to hash the data obtained in the previous step. Device B also uses public encryption key 103B and encryption function 107B to encrypt a second number.
[0091] In step 207 , device B transmits the first number and the encrypted second number to device A over channel 109 .
[0092] In step 208, upon receipt of the two numbers, device A decrypts the second number using the private encryption key 103A associated with the public key 103B necessarily used for the encryption and the decryption function 108A associated with the encryption function 107B. If the second number was not encrypted by device B, its decryption will be incorrect.
[0093] Given the first number, device A can identify the message 101 and mix the decoded second number with the identified message 101 using the mixing function 105 .
[0094] In step 209, device A uses the hash function 106 to hash the data resulting from the previous steps.
[0095] In step 210, device A uses private encryption key 103A and encryption function 107A to encrypt the hash obtained in the previous step.
[0096] In step 211 , device A sends the encrypted hash to device B over channel 109 .
[0097] In step 212, upon receipt of the encrypted hash, device B decrypts the encrypted hash using the public encryption key 103B associated with the private key 103A necessarily used for encryption and the decryption function 108B associated with the encryption function 107A.
[0098] In step 213, device B compares the decrypted hash obtained in step 212 with the hash calculated in step 206. If the two hashes are identical, device B concludes that message 101 has not been altered.
[0099] Preferably, the second number used in mixing should be kept secret until the hashes are compared to perform verification, but this mixer number may be revealed before then if it is possible to trust the device computing the hash that the data has not been altered between the time the mixer number is revealed and the comparison of the hashes.
[0100] FIG. 3 shows a second example of implementation of the method according to the second variant of the invention, in which a message 101 needs to be sent by device A to device B.
[0101] Device A and device B may be personal computers or smartphones, and message 101 may be an email.
[0102] Device A and device B may be adjacent automobiles and the data exchanged may in turn be information about their movement, and the connection may be achieved via a data link between the two vehicles, for example a 5G link, a low energy Bluetooth link, an extremely high frequency RFID link, a Lora link or a Sigfox link.
[0103] In step 301, a random number is generated by device A using random number generator 104A.
[0104] In step 302 , device A mixes the message 101 with a random number using the mixing function 105 .
[0105] In step 303, device A hashes the mixed data resulting from the previous steps using hash function 106.
[0106] In step 304, device A encrypts the hash obtained in the previous step using encryption function 107A and private encryption key 103A.
[0107] In step 305, device A encrypts the random number using encryption function 107A and public encryption key 102A.
[0108] In step 306, the message 101, the encrypted random number, and the encrypted hash are sent over the transmission channel 109 to device B using the communication protocol agreed upon between the two devices.
[0109] In step 307, upon receipt of the data, device B uses the decryption function 108B and the public encryption key 103B to decrypt the hash, and the private encryption key 102B to decrypt the random number.
[0110] In this way, device B can authenticate device A.
[0111] In step 308 , device B mixes the message 101 with a random number using the mixing function 105 .
[0112] In step 309, device B hashes the mixed data resulting from the previous steps using hash function 106.
[0113] In step 310 , device B compares the hash it computed with the decrypted hash and draws a conclusion regarding the integrity of message 101 .
[0114] In this example, device B may forward the data received from device A to a third device. Device B uses private key 102B to decrypt the random number it received from device A before encrypting it again using the public key of the third device. Device B then transmits the encrypted random number and the hash encrypted by device A to the third device. A third device that can obtain the public key of device A can verify that this hash actually came from device A as long as device B did not modify the hash encrypted by device A. Thus, a given data set can be verified as authentic by many users. However, this option exposes the security of the authentication, and a fraudulent device can decrypt the random number and possibly modify the message so that it has the same random hash as the initial hash. Therefore, this implementation is preferably used to authenticate communications between computer systems formed from elements protected from such fraudulent use.
[0115] FIG. 4 shows diagrammatically the data and functions required to implement the invention according to a third variant of the invention for verifying that a file 401A present on device A is identical to a file 401B present on device B.
[0116] Device A and Device B communicate over a transmission channel 409, which may be, for example, a Wi-Fi network.
[0117] Device A owns a random number generator 404 .
[0118] Device A and device B have in common a mixing function 405 , a hash function 406 , and a symmetric encryption key 410 .
[0119] Device B can obtain the encryption function 407 .
[0120] Device A has access to the decryption function 408 .
[0121] FIG. 5 shows a third example of implementation of the method according to the third variant of the invention.
[0122] In step 501, a random number is generated in device A using the random number generator 404.
[0123] In step 502, a modified copy of file 401A is created using a mixed function 405 and a random number.
[0124] In step 503, the modified copy of file 401A is hashed using hash function 406.
[0125] In step 504 , the random number is encrypted using a symmetric encryption algorithm and a symmetric encryption key 410 and sent to device B over the transmission channel 409 .
[0126] In step 505, upon receipt of the encrypted random number, device B decrypts the encrypted random number and uses it in a mixing function 405 to create an altered copy of file 401B. By decrypting the random number, device B can verify the identity of device A.
[0127] In step 506 , the modified copy of file 401B is hashed with the same hash function 406 .
[0128] In step 507 , the hash of the modified copy is encrypted using the encryption function 407 and the encryption key 410 .
[0129] In step 508, the encrypted hash is sent to device A.
[0130] In step 509, upon receipt of the encrypted hash, device A decrypts the encrypted hash using the decryption function 408 and key 410.
[0131] In step 510, device A compares the decrypted hash with the hash it calculated in step 503, and thus can verify whether the two files 401A and 401B are identical.
[0132] FIG. 6 shows a fourth example of an implementation of a method according to a fourth variant of the invention for verifying that a file has not been modified between two times d1 and d2 while keeping a smaller data set between the two times completely secure, the set including a number that remains secret and a hash that remains secret and is preferably kept secret.
[0133] In step 601, a random number is generated.
[0134] In step 602, at time d1, a modified copy of the file is created using the generated random number and a mixed function, which may consist, for example, of appending a random number to the end of the file.
[0135] In step 603, a hash of the modified copy is created, for example using the SHA2 function.
[0136] In step 604, the random numbers and hashes are stored securely and secretly such that they cannot be altered and such that they are not disclosed to third parties.
[0137] In step 605, at time d2, a person or device with access to the information stored in step 604 wishes to compare the file at time d2 with the file used in steps 601 to 604. To do this, the stored random number is used to create a second, modified copy of the file at time d2, using the same mixing function as in step 602.
[0138] In step 606 , a hash is created of the second, modified copy using the same hash function as in step 603 .
[0139] In step 607, the hash created in the previous step is compared to the stored hash to ensure that the file has not been modified between times d1 and d2.
[0140] FIG. 7 shows diagrammatically the keys necessary to implement a fifth example, shown in FIG. 8, of the method according to the invention applied to the validation of software packages.
[0141] In the remainder of the description, the operation of mixing data with random mixer numbers followed by a hashing operation will be referred to as "random hashing" of this data.
[0142] The example shown in FIG. 8 is implemented between two devices: device A, referred to as the software distributor, and device B, referred to as the client device.
[0143] Device A possesses two keys 701 and 702 .
[0144] 701 is a key, preferably secret, that serves to encrypt the hash.
[0145] 702 is a key, preferably public, that serves to encrypt the random number.
[0146] Device B possesses two keys 703 and 704 .
[0147] 703 is a key, preferably public, used to decrypt the hash encrypted using key 701.
[0148] 704 is a key, preferably secret, used to decrypt the random number encrypted using key 702.
[0149] The pair of keys (701, 703) is sometimes referred to as the software distributor's key pair, and the software distributor can use that key pair to communicate with all devices on which one of the software packages that the software distributor distributes is installed.
[0150] The pair of keys (704, 702) is sometimes referred to as the client's key pair, and the client may use that key pair for all software packages that the client validates during download.
[0151] In step 801, software distributor A performs random hashing of the software package to be transmitted to client B in steps 301-305 described above with reference to FIG.
[0152] Software distributor A uses key 702 to encrypt a random number and key 701 to encrypt a random hash of the software package.
[0153] In step 802, software distributor A sends to client B a data set including the software package, an encrypted hash of the software package, and an encrypted random number over a transmission line, which may be secure or non-secure.
[0154] In step 803, upon receipt of the data set, client B decrypts the hash with key 703 and decrypts the random number with key 704. Client B then uses the random number to perform a random hashing of the received software package.
[0155] In step 804, if the calculated hash is identical to the received hash, client B either allows the received software package to execute or replaces the previous version of the software package with the version client B has just received.
[0156] In step 805, for better security, steps 803 and 804 are re-executed at pre-programmed time intervals to verify the authenticity of the software package.
[0157] FIG. 9 describes another possible implementation of random hashing to verify that the software package being downloaded is authorized by the software package running on the device.
[0158] In step 901, the device uses the method illustrated in FIG. 2 to verify that the received software package originates from a trusted source.
[0159] In step 902, steps 601-604 of FIG. 6 are performed to create a secure signature of the software package on the device.
[0160] Before using the software package in step 903, steps 605-607 of FIG. 6 are performed to verify that the software package has not been modified since step 902.
[0161] FIG. 10 shows the objects necessary to implement the example shown in FIG. 11, which allows for increased security of data displayed by a web browser.
[0162] The web browser 1001 has access to an asymmetric key pair consisting of a private key 1002p and a public key 1002u.
[0163] A server 1003s, which distributes the public key of a secure Internet site 1004s to browsers, possesses an asymmetric key pair 1003 consisting of a private key 1003p and a public key 1003u.
[0164] Internet site 1004s possesses an asymmetric key pair 1004 consisting of a private key 1004p and a public key 1004u.
[0165] In step 1101, the user enters into the address bar of the browser 1001 the URL address of the site that the user wishes to view.
[0166] In step 1102, the browser 1001 uses the key pair 1002 to obtain the following information: - the URL address of the site the User wishes to visit; - the browser's public key 1002u, and - The URL address of browser 1001 so that the server can respond to it is sent to the server 1003s.
[0167] In step 1103, the server 1003s uses the method according to the invention illustrated in FIG. 2 to securely transmit the public key 1004u of the site 1004s to the browser.
[0168] Public key 1002u is used by the server to decrypt the second number that the navigator sends to the server during the exchange.
[0169] In step 1104, the browser 1001 receives the following information: - the name of the page of the Site that the User wishes to view; - the browser's public key 1002u, and - The URL address of the browser so that the site can respond to it to site 1004s.
[0170] In step 1105, server 1004s uses the method according to the present invention illustrated in FIG. 2 to securely transmit the requested page to the browser.
[0171] FIG. 12 shows the objects required to implement the example shown in FIG. 13, which allows for increased security of email.
[0172] A first electronic device A, which may possibly be a computer or a smartphone, allows emails 1200 in the form of electronic files to be sent, received, archived, edited and displayed.
[0173] This first device A has access to an asymmetric key pair 1201c consisting of a public key 1201u and a private key 1201p.
[0174] The second electronic device B allows emails 1200 to be sent, received, archived, edited, and displayed.
[0175] This second device B has access to an asymmetric key pair 1202c consisting of a public key 1202u and a private key 1202p.
[0176] The server 1203 collects identification numbers and public keys of electronic devices such as A and B that are certified to maintain the integrity of received emails and the confidentiality of the random numbers associated with the random hashing method according to the present invention.
[0177] The server 1203 has access to a key pair 1203c consisting of a public key 1203u and a private key 1203p. Note that the server may have multiple key pairs, each pair dedicated to communicating with one well-defined electronic device.
[0178] The server 1204 associates one or more electronic devices with a destination address 1205 for the email.
[0179] The server 1204 has access to a key pair 1204c consisting of a public key 1204u and a private key 1204p. Note that the server may have multiple key pairs, each dedicated to communicating with one well-defined electronic device.
[0180] In step 1301 , a user requests that a first device A send an email 1200 to a destination address 1205 .
[0181] In step 1302, the first device A communicates the public key known by the first device A to the server 1204 using the method according to the invention shown in FIG. 2 to determine the identifier and public key of device B associated with the address 1205. After authentication of the first device A by the server 1204, the server 1204 transmits the identifier and public key of device B to the first device A. This is also done using the method shown in FIG. 2, the server 1204 knowing the public key of device A, and device A knowing the public key of server 1204. This method allows device A to receive unaltered data from the server 1204. The server 1204 itself is able to obtain the public key of device B from the server 1203 and at the same time verify the public key of device A.
[0182] In step 1303, a first device A communicates its identifier to device B.
[0183] In step 1304, device B, having received the identifier communicated in step 1303, communicates with server 1203 to determine the public key of the first device A. This information is sent to device B using the method of Figure 2, which allows device B to receive the information unaltered. Device B acknowledges receipt of this information to device A by sending an acknowledgment to device A.
[0184] In step 1305, upon receipt of the receipt confirmation sent in step 1304, the first device A uses the method according to the invention shown in Figure 2 to send the email 1200 to device B, which can then be sure that this information was sent by device A and was received unaltered. In addition, device A is sure that this information was authenticated only by device B.
[0185] Because encryption methods using asymmetric and symmetric keys may be vulnerable to quantum computers, these encryption methods may be replaced in the examples described above with encryption methods that use one-time keys.
[0186] The invention is not limited to the above described example embodiments, nor to the illustrated applications. The invention can in particular be used to increase the security of financial transactions. [Explanation of symbols]
[0187] 101 Messages 102A Encrypt / Decrypt Data, Public Encryption Key 102B Encrypt / Decrypt Data, Private Encryption Keys 103A Encrypt / Decrypt Data, Private Encryption Keys 103B Public Encryption Keys 104A, 104B Random number generator 105 Mixed Functions 106 Hash Functions 107A,107B Encryption functions 108A,108B Decoding functions 109 Data Transmission Channel 401A, 401B files 404 Random Number Generator 405 Mixed Functions 406 Hash Functions 407 Encryption Functions 408 Decryption Functions 409 Transmission Channel 410 Symmetric Encryption Keys 701,702,703,704 key 1001 Web Browser 1002 Key Pair 1002p private key 1002u public key 1003 Asymmetric Key Pair 1003p private key 1003s Server 1003u public key 1004 Asymmetric Key Pair 1004p Private Key 1004s Internet site, server 1004u Public Key 1200 Email 1201c Asymmetric Key Pair 1201p private key 1201u Public Key 1202c Asymmetric Key Pair 1202p private key 1202u public key 1203 Server 1203c Key Pair 1203p private key 1203u public key 1204 Server 1204c Key Pair 1204p private key 1204u Public Key 1205 Destination Address
Claims
1. A method for verifying the integrity of a message (101) originating from a sender (A) by means of a device (B), comprising: i. said device (B) receiving said message (101) and an identifier of said message, said message forming a first data set; ii. generating a number called a mixer number, said mixer number being randomly generated; iii. mixing the mixer number with the first data set using a mixing function (105) to obtain mixed data; iv. hashing the mixed data using a hash function (106) to obtain a hash; v. the device (B) sending the identifier of the message and the mixer number to the sender (A) of the message; vi. receiving by said device (B) an encrypted second set of data originating from said sender (A); vii. Decrypting the second data set; viii. comparing the hash obtained in step iv with the second data set decoded in step vii, which is assumed to be the hash of the message mixed with the same number of mixers as used in step iii, using the same mixing function (105), whereby if the second data set decoded in step vii and the hash obtained in step iv are identical, the integrity of the message is ensured; The method includes:
2. Between step v and step vi, - the sender (A) receiving the identifier and the mixer number of the message; - identifying said message (101) sent to said device (B) using said identifier of said message; - mixing said message with said mixer number using said mixing function (105); - hashing the data resulting from the preceding step using said hash function (106) to obtain a hash; - encrypting the hash resulting from the preceding step; - transmitting said encrypted hash to said device (B); 2. The method of claim 1, comprising:
3. Between step iv and step v, a step of encrypting the number of mixers is included, The method of claim 2 , further comprising the step of decoding the mixer number between steps v and vi.
4. The method of claim 3, wherein if the encryption of the mixer number is performed using a one-time key, then the decryption of the second data set in step vii is performed using a symmetric key.
5. The method of claim 3, wherein if the encryption of the mixer number is performed using a symmetric key, then the decryption of the second data set in step vii is performed using a one-time key.
6. A method for verifying that a data set present in a device (A; B) has not been modified between two times d1 and d2, said data sets forming a first data set at time d1 and a second data set at time d2, said method comprising: i. mixing a number, called a mixer number, with said first data set using a mixing function (105) to obtain mixed data, said mixer number being randomly generated; ii. hashing the mixed data using a hash function (106) to obtain a hash; iii. the device (A; B) securely storing the mixer number and the hash obtained in step ii; iv. creating a modified copy of said second data set using said mixer number and said blending function; v. hashing the modified copy using the hash function to obtain a hash; vi. comparing the hash obtained in step ii to the hash obtained in step v, where if the two hashes are identical, the data set has not been modified between the two times d1 and d2; The method includes:
7. A method for verifying the integrity of a message (101) originating from a sender (A) and forming a first data set, using a device (B), comprising: i. said device (B) receiving said message (101), an encrypted second data set, and an encrypted number called a mixer number, said mixer number being randomly generated; ii. decoding the number of mixers and the second set of data; iii. mixing said message (101) with said mixer number using a mixing function (105) to obtain mixed data; iv. hashing the mixed data using a hash function (106) to obtain a hash; v. comparing the hash obtained in step iv with the second data set decoded in step ii, which is assumed to be a hash of the first data set mixed with the same number of mixers as used in step iii, using the same mixing function (105), whereby if the hash obtained in step iv and the second data set decoded in step ii are identical, the integrity of the message is ensured; The method includes:
8. Before step i, - the sender (A) generating the mixer number; - mixing said mixer number with said message (101) using said mixing function (105); - hashing the data resulting from the preceding step using said hash function (106) to obtain a hash; - encrypting the hash resulting from the preceding step to form the second data set; - encrypting said mixer number; - transmitting said message (101), said encrypted second data set and said encrypted mixer number to said device (B); 8. The method of claim 7, comprising:
9. A method implemented by a first device (A) and a second device (B) for comparing a first data set (401A) present in said first device (A) with a second data set (401B) present in said second device (B), specifically for the purpose of determining whether said two data sets are identical, comprising: i. the first device (A) mixes numbers, called mixer numbers, with the first data set (401A) using a mixing function (405) to obtain mixed data, the mixer numbers being randomly generated; ii. the first device (A) hashing the mixed data using a hash function (406) to obtain a hash; iii. the first device (A) encrypting the mixer number; iv. the first device (A) transmitting the encrypted mixer number to the second device (B); v. the first device (A) receiving an encrypted hash of the second data set (401B); vi. decrypting the encrypted hash; vii. comparing the hash obtained in step ii with the decrypted hash in step vi; The method includes:
10. Between step iv and step v, - said second device (B) receiving said encrypted mixer number; - decoding said number of mixers; - creating a modified copy of said second data set (401B) using said mixer number and said blending function (405); - hashing the modified copy of the second data set (401B) using the hash function (406) to obtain a hash; - encrypting the hash resulting from the preceding step; - the second device (B) sending the encrypted hash of the second data set (401B) to the first device (A); 10. The method of claim 9, comprising:
11. 11. The method according to any one of claims 1 to 10, wherein the mixing function (105; 405) is an XOR logic function.
12. 11. The method according to any one of claims 1 to 10, wherein the mixing function (105; 405) consists of adding the mixer number to the end of the first data set.
13. 11. The method according to any one of claims 1 to 10, wherein said mixing function (105; 405) is an encryption function that uses said mixer number as an encryption key for encrypting said first data set.
14. 14. The method according to any one of claims 1 to 13, wherein the hash function (106; 406) is chosen from the group consisting of SHA1, SHA2, SHA256, MD5 and Jenkins functions.
15. A computer program comprising instructions readable by a processor of a device for carrying out the method according to any one of claims 1 to 14.
Citation Information
Patent Citations
Method and device for authenticating data block transmitted in network
CN101547184A
Encryption protocol
EP1421548A1
Electronic contracting method
JP1998240826A
Home page alteration monitoring system
JP2004144810A
Community-based de-duplication for encrypted data
JP2016154033A