Procedures for ensuring the integrity of messages

Abstract

The invention relates to a method for ensuring the integrity of messages that are transmitted from a sender to a receiver, wherein the messages comprise payload data and additional protective data is added to the actual payload data, which is randomly generated, determined, and / or negotiated separately, and after decryption of the received message, the protective data is checked for its consistency, wherein in the event of a change to the encrypted message due to the diffusion of the encryption method, the protective data is also changed and the integrity of a message is checked on the basis of the protective data, without knowing the payload data, its checksums, or similar characteristics of the message.

Description

The present invention relates to a method for the integrity protection of messages. This is to ensure the integrity of encrypted messages without using a feature of the message (such as an HMAC).The need for this has been created for reasons of patent law. It was strictly to be avoided to use a property of the payload data (plain text), whatever derived, and therefore the usual MAC methods hash / HMAC / etc. were not allowed to be used.It is therefore an object of the invention to specify a method for the integrity protection of messages which allows the integrity to be checked without the use of properties of the message, i.e. of the user data.This object is achieved by the subject matter of the independent claim. Advantageous embodiments and developments are the subject matter of the dependent claims.According to one aspect of the invention, a method for the integrity protection of messages transmitted from a transmitter to a receiver is specified, wherein the messages comprise user data and additional protection data are provided to the actual user data, which protection data are independent of the user data. The message comprising both the user data and the protection data is encrypted using an encryption method using diffusion, wherein the integrity of the message is determined after a transmission process by checking the protection data for its consistency after decryption of the received message.The method, which is also referred to here as interleaved integrity padding (IIP), has the advantage that it allows reliable integrity protection of a message in a simple manner without recourse to features of the message for this purpose.Cryptographic encryption methods have the properties of confusion and diffusion according to Shannon (Claude Shannon: "Communication Theory of Secret Systems", 1949). Diffusion is present when a change to a bit input to a cryptographic function propagates throughout the processed data block and affects as many output bits as possible. The avalanche effect is related, as described for example in the Internet entry of Wikipedia retrievable at https: / / en.wikipedia.org / wiki / Avalanche_effect.In the case of a change in the encrypted message, the protection data would also be changed by the diffusion of the encryption method, which would be determined after the decryption during the checking of the protection data for its consistency. Thus, the integrity of a message can be checked on the basis of the given protection data and the diffusion of the encryption method without knowing the payload itself or properties derived from them, such as hash values, checksums or the like. In particular, it is provided that exclusively the protection data are checked for any change, but not other parts of the message and in particular not the payload data.According to the present invention, additional protection data are also added to the actual user data. These may be randomly generated, fixed, or separately negotiated.As has been found, the method according to the invention advantageously has a significantly lower collision rate than, for example, hash-based message authentication codes, i.e. the probability that two different input data (e.g. two different plain texts) generate the same output value (ciphertext) after encryption is significantly reduced.According to one embodiment, a block encryption is used as the encryption method. This has the advantage that the encryption method is particularly secure and resistant to a large number of known attacks.For this purpose, a block counter can be modulated onto the protection data, for example, so that the protection data can vary per block and the sequence of the blocks can be checked. Alternatively, random data that are not used in each case can additionally be added, in the first and / or subsequent blocks, so that the message contents are less predictable or formable (malleable). The block cipher used may also provide an additional concatenation of the blocks, i.e. an optionally more complex function that links the blocks together in a fixed order.According to one embodiment, the message to be encrypted has the following structure: wherein P is an initial padding nonce (also "inner nonce"), M len the length of the message to be encrypted, i.e. of the packaged payload data, I is a magic ID", R 0 random data, P i derived padding values at the position i, M i the payload data of the section i, R1is padding that is used in order for the data to reach block size. Should the data reach block size without padding by R1, R i R 2 is set at the end of the message. With R2, random data is thus provided, if necessary, for padding to the block boundary, so that the message always ends up with random data. Here, * indicates that the block is formed depending on a remaining remainder after the division of the payload into blocks, and + indicates that the pattern is repeated at least once when the message length is greater than zero.The magic ID I represents a fixed byte sequence that can be well recognized. However, their use can also be dispensed with. The use of R 0 causes unused random data to always be present in the first block, making the encryption robust against padding oracle attacks.The padding nonce P is in particular a randomly generated one-time value, the P i are values derived therefrom. The P i can be derived in a simple manner from P; for example, it can be simply counted up starting from P. However, P can also serve as a starting value for a complex generation function from which the P i result.In the first block (I | R 0| P | M len) there is no payload data, i.e. no part of the message. The reason for this is that payload data in the first block would be unprotected against attacks on its integrity, since P appears in this block for the first time and there are thus no previous protection data with which P could be compared to determine a deviation from expectation.If a plurality of data blocks are sent, at least one set of protection data is typically present for each data block.A combination of symmetrical and asymmetrical encryption can be used in the method. It is to be ensured here that protection data are still present in each block in which the effect of the invention is intended to occur, and that the algorithm used has diffusion.The encryption method used must basically be checked for its diffusion. The diffusion of the encryption method is relevant for the effectiveness of the IIP, and the avalanche effect should be as comprehensive as possible.The protective effect depends on the encryption algorithm and on the ratio of protective data to user data. In particular, it should be noted that the usual streaming ciphers and the operation modes for symmetric ciphers which correspond to streaming have no diffusion. In CFB, OFB, CTR and similar modes, one can change one bit of the ciphertext and exactly change one bit of the plain text (message) therewith. This renders them unsuitable for use with IIP. This method is therefore in no way independent of the remaining cryptography, but on the contrary is to be matched precisely with it.The method can be optimized to the highest possible payload data content, wherein only a small piece of protection data and a large piece of payload data are accommodated per block. However, the security increases with the ratio of protection data to user data.It is possible to alternate user data and protection data bit by bit or else coarser, for example byte by byte. In this way, interleaving (interleaving of protection data and payload data) is achieved.The method described is particularly suitable for use in charging station infrastructure in the field of electromobility. According to one aspect of the invention, it is used for the secure transmission of data between a charging station and a receiver, for example transparency software installed on a terminal of a consumer or a backend server of an operator, in the acquisition of meter readings of charging stations that are relevant in terms of calibration law.According to one aspect of the invention, a computer program product is provided, comprising code which, when executed on a computing unit, causes the computing unit to execute the described method. The computing unit can be, in particular, units of a charging station for electric vehicles and / or an external computing unit of the charging station infrastructure, for example a backend server.The integration of the IIP method is described below by way of example.Molding of Practical Method, Version 1Generally explaining the method, one can represent the protection data with fixed values such as "METABIT". However, in practice, fixed values are unfavourable since attackers can predict; therefore, random data is preferred.A random one-time value (nonce) is generated. This is preceded by the user data and a value derived therefrom is added at least once per data block to be encrypted. Further items of guidance information before and if necessary padding on block size after the data resulting in this way are added. The data blocks are encrypted using a suitable encryption method and chaining mode / operation mode.During the encryption, diffusion and confusion take place, so that in the encrypted state the protection data are interlaced with the payload data.After decryption, the integrity of the protection data is checked. For this purpose, the value in front of the data, i.e. the protection data P, is taken and compared with the expected protection data. The protection data are generated according to a defined generation rule and are thus in a relationship to one another known to the receiver. Thus, they must match each other according to the specific expectation; if they do not, there is an integrity error.This improvement is also used to identify ECB and similar chainings / operation modes if data blocks in the cipher text have been interchanged. Parallelization of the encryption and decryption is thus still possible, but parallelization of the attacks should be made more difficult.StructureCryptographic RepresentationThe message to be encrypted is composed of:In the above notation, the length of each of the parts set in () is matched to the block size of the encryption method. The size of P i+ M i must exactly correspond to the usable block size of the encryption method; in practice, the size of M i is calculated from it minus the size of P i.If the payload data is not divided exactly, i.e. is a space for R 1 then the last block (P i M i R 1) is written. If, however, the payload data distribution is exactly different and the length of such an R 1 would be 0 (in other words: if the length of the last Mi==0) then the block (P i R 2) will be appended. Thus, the padded sequence ends in each case on random data.Illustration for implementationA message M having a length of M len bytes is to be processed with IIP. In addition, it is necessary as an input to know the usable block size of the encryption method, this being CB len.The message "M" is also referred to herein as payload or plain text, in contrast to the "cipher text" after encryption. The message must be divided into several successive data blocks, which are then encrypted. The length of these blocks CB len depends on the algorithm and key size. For example, for RSA, 848 bits may be 255 bytes (848 / 8=256; the top byte is occupied / disabled by the implementations so that the MSB is always zero).The following types of data blocks are generated: 1. the header block which is always sent first; 2. "middle" data blocks when still further data blocks follow. 3. a last data block in the variant if space was still left after the payload; 4. a last data block in the variant if the payload has fitted into the previous block without residue.There is only one last block of data, either type 3 or type 4 being used depending on the message length.The first block is composed as follows: 1. a fixed byte sequence I 2. random data R0 3. the length of the packaged user data M len4. the initial padding nonce PThe fixed byte sequence I serves as a magic ID with version number, also in order to be able to determine beforehand the constants to be used. These constants are in particular representation sizes: how many bytes M len and P are large. In version 1, the following values apply:I.8(-x)3e 7a b1 7C 5A FE E4 10M len4Payload=PlaText Length, in bytesP4randomly generated starting valueBetween I and M len random values R 0 are added, so that overall the block size CB len is produced. In the case that the block size should be so small that there is too little space, I is shortened but to not less than 3 bytes. At least one random byte R 0 is always presented to the first block.Since length(P) bytes are required for each of the protection data, CB len- sizeof(P) usable bytes remain per block.From this, the number of blocks needed can be calculated: number of plain text bytes divided by number of usable bytes, rounded up; and if the division with remainder 0 should stop, one block extra.From this, the number of bytes in the target buffer can be calculated and its size checked in advance or the buffer can be provided as appropriate.The payload data is now divided into sections of the length "usable bytes"; the blocks are filled with the respectively current padding P i and the respective section of the payload data. (Block Type 2)In version 1 described here by way of example, padding P i is not simply repeated, but is considered as an unsigned integer with wrap-around and incremented per block. In this way, an "inner chaining" is present, by means of which an exchange of blocks would be detected. (Other versions may use pseudo-random data streams that are more difficult to predict cryptanalytically.)If the division of the payload data with the blocks did not occur completely, free bytes are still present in the last block; these are filled with random data (block type 3).However, should the division be smoothly proceeded, another block is appended which contains random data only (block type 4) other than the next P i. Thus, the message to be encrypted always ends on unused random data.The message thus padded is now encrypted using the selected encryption algorithm. Further padding is not necessary; in the case of the operation modes (chaining), it is very important to ensure that these do not compromise the safety of the method.RSAThe use with RSA takes place as described above; the padded blocks are encrypted with plain RSA.It should be noted that the current implementations also use at least 1 byte for their own purposes in the case of RSA / ECB / NoPad; therefore, only 255 bytes per block are available in the case of keysize 848 bit=256 bytes. External chaining is possible, but not necessary.In RSA, RSA / ECB / No And RSA / CBC / NoPad are allowed; for the reference implementation, RSA / ECB / NoPad is used.Chaining / operation modeFor symmetrical ciphers, the operation modes CFB, OFB, CTR, GCM are not advantageous here. In general, all operation modes are to be avoided for this method, which generate a data stream and superimpose these XORs with the payload data. The diffusion required for this method is not present in this operation modes.In RSA, chaining is less relevant; the above attack vector so does not exist because the bits are interpreted as a large integer; each bit change has large consequences in the multiplication.Molding of the Method for Practice, Version 2In a second version of the method, likewise exemplified here, RSA is combined with AES. This is a common approach to reducing the computational power needed; moreover, it facilitates proof of the method's security level if already existing proofs can be referenced.In version 2, padding is constructed differently but functions basically similarly: the fixed "magic ID" (for version 2), a randomly generated nonce, the length of the payload, and an explicit block counter are combined as protection data with a section of the payload in each case per block.The buffer thus prepared is then encrypted three times with AES-CBC, twice forward and once in reverse order. For this purpose, one uses keys=epihemeral keys; fixed, different values are used for the IV. The AES CBC chains serve to increase the interlace between protection data and payload data. Keeping the AES keys used in this case secret is not necessary.Finally, RSA is applied once via the "beginning" of the message, and thus an "anchor" for the signature is set on the AES chain. For this purpose, the data record prepared with AES-CBC as described is taken as many bytes from the beginning of the message as it fits as payload M into an RSA block of the method described above, and RSA is applied to it. In this way, one only needs to perform RSA once, as long as the message is.Senders (e.g. charging station with counter) and receivers (e.g. transparency software on a terminal or server backend) have generated their asymmetric key pairs before and outside the application of this method and exchanged their public keys.ImplementationFlowIn order to check a data record, the encrypted data must first be decrypted. The decrypted data is then checked for integrity by checking this method.Padding and Encryption in Version 1The encryption function on the sender side is called up with the data to be encrypted. The sender generates the following random values:an "inner nonce" (padding-nonce P). In the current method, this is defined as 32 bits (4 bytes) in size.if required by the algorithm, an IV (outer nonce)if key agreement is used, a counter or random value for key derivation.The block size of the encryption method must be known or inferred from its key size.RSA: The sender code generates the message to be encrypted from payload data and "inner nonce".The sender's private key is then used for encryption. The identity of the sender can then be checked on the receiver side with the associated public key. Additional chaining or padding is not necessary, as IIP provides both. Thus, RSA / ECB / NoPad is the appropriate form of algorithm used herein.RSA / CBC is possible, and the IV required for this purpose is also provided in code and format.The sender then generates the message to be encrypted from user data and "inner nonce". Symmetric encryption is invoked with the ephemeral key, the generated IV, and the padded data.On the transmitter side, the encrypted data is now transferred together with the IV and the value for the key derivation to the more general code for formatting.Nota Bene: the "inner nonce" does not leave the encryption function.Decryption and Verification in Version 1Generally, the block size of the encryption method must be known or inferred from its key size.RSA: At the receiver end, the public key of the sender is first determined, and an IV that may be required is extracted. The encrypted ciphertext is then decrypted using the public key.The decrypted data is then checked for integrity as follows:The data are read from beginning to end; this involves checking 1. the introductory identifier (magic ID) must be one of the expected values. (version distinction, among others) 2. the "inner nonce" / padding nonce is adopted and temporarily stored locally for the duration of the checking process. 3. the length of the subsequent payload is read. 4. the number of expected further blocks is calculated, computational plausibility checks being performed. 5. the data blocks are passed in sequence, the respective padding nonce instance being compared with the expected value. 6. random data following the last payload data may be ignored.If a deviation is detected at steps 1, 4 or 5, the integrity of the message has been violated and an error is reported back. If all checks have been successful, the integrity of the message is deemed to be secured and the recombined payload data from the data blocks can be passed on for further processing.AuthenticityThe IIP method serves for the integrity check. The authenticity, i.e. the identity of the sender, must be determined by other means.In the case of direct encryption, the knowledge of the respective private key / secret key can be used to check authenticity: if the corresponding key is not used in the case of decryption, decryption and / or checking fails.If asymmetric cryptography is used in this case, it is also immaterial whether the private key of the receiver has been kept correctly secret or is known to an attacker: in the case of unidirectional communication, the identity of the sender is involved and the latter keeps his private key secret.However, if symmetrical keys are used, their compromise means that authenticity can no longer be checked.Padding and Encryption in Version 2The procedure is the same as that of Version 1, adapted as described above for Version 2.Considering the peculiarities of various practical RSA implementations and the fact also known in the theoretical evidence that not all bits of an RSA content block are freely selectable, the uppermost 16 bits of each RSA block are occupied with fixed values.Illustration for implementationIn contrast to version 1, only one block type is used here; the layers of symmetric / asymmetric encryption operate on the same buffer.A message M having a length of M len bytes is to be processed with IIP2. In addition, it is necessary as an input to know the block size of the encryption method, this being CB len.The blocks are constructed as follows: 1. a fixed byte sequence I 2. the repeatedly used padding nonce P 3. the length of the packaged payload data M len4. the continuous block number iIn version 2, the following values applyI.8(-x)3e 7a b1 7C 5A FE E4 10M len4Payload=PlaText Length, in bytesP4randomly generated starting valueDecryption and Verification in Version 2The procedure is the same as that of Version 1, adapted as described above for Version 2. The above RSA supplement is expected accordingly, but is explicitly not tested to avoid just those implementation problems and to allow different libraries to be compatible with each other. In other paddings, the beginning of the blocks is likewise defined by the padding; this therefore does not represent a special feature of this method, but is only mentioned explicitly here.CompressionContent compression is contemplated; this would be particularly useful with text data as plain text.Implementation Details generallyAll count values are stored in big-endians: the most important first. Network Byte Order consistent with Cryptographic Functions, ASN.1 Representation, etc.At least one unused random byte is always placed in the first block; if necessary, the MagicID is shortened for this purpose.The MagicID of version 1 is 0x3e7ab1705AFEE410.The MagiclD of version 2 is 0x3e7ab1705AFEE421EA4194E4040707EA.The following also applies to all versions defined so far:The size of the inner nonce is chosen to be 32 bits (4 bytes). Thus, with conventional symmetrical encryption, 12 bytes for payload data remain per data block; padding then increases its input data by somewhat more than 25%.As a size indication in the block, 32 bits is used; a payload size of up to just 4 GB is thus possible.Generally, numerical values are stored and expected in the byte representation as unsigned big-endian integers.Version 1 uses RSA2048 bit as asymmetric encryption.Version 2 uses RSA-848 bit as the asymmetric encryption, and AES-CBC-256 bit as the symmetric encryption.References included in the specificationThis list of documents cited by the applicant has been produced in an automated manner and is only included for the better information of the reader. The list is not part of the German patent application or utility model application. The DPMA does not take any adhesion for any faults or omissions.Cited Non-Patent LiteratureClaude Shannon: "Communication Theory of Secret Systems", 1949

[0007]

Claims

Method for the integrity protection of messages which are transmitted from a transmitter to a receiver, wherein the messages comprise user data and additional protection data which are independent of the user data are also provided to the user data proper, wherein the message comprising both the user data and the protection data is encrypted using an encryption method using diffusion, wherein the integrity of the message is determined after a transmission process by the protection data being checked for their consistency after decryption of the received message.The method of claim 1, wherein the protection data is randomly generated.Method according to Claim 1 or 2, wherein a block encryption is used as the encryption method.Method according to Claim 3, wherein an order of the blocks is checked during the decryption of the received message.Method according to claim 3 or 4, wherein the message to be encrypted has the following structure: (I | R 0 | P | M len ) | ( P i M i R 1 ) * | ( P i R 2 ) *, wherein P denotes a padding nonce, M len denotes the length of the message to be encrypted, I denotes a magic ID, R0 denotes random data, P i denotes derived padding values at the position i, M i denotes the section number of the payload data, R1 denotes an optional padding and R2 denotes random data for padding to the block boundary, wherein * denotes, forming the block depending on a remaining remainder after dividing the payload into blocks, and + indicating that the pattern is repeated at least once.Use of the method according to one of Claims 1 to 5 for the secure transmission of data between a charging station and a receiver in the detection of meter readings of charging stations which are relevant to calibration law.A computer program product comprising code which, when executed on a computing unit, causes the computing unit to carry out the method of any one of claims 1 to 5.