Method and apparatus for providing a message authentication code suitable for short messages

Abstract

The present application relates to an apparatus and method for authenticating messages exchanged between a transmitter and a receiver on a network, the method comprising: on the transmitter side, in order to transmit a message, generating a truncated MAC code by selecting or generating predetermined bits from a message authentication code (MAC), the message authentication code being calculated on a concatenation of a predetermined portion of the message and at least one predetermined portion of a previously transmitted message; wherein the bit length of the truncated MAC code is less than the bit length of the message authentication code (MAC), and the truncated MAC code is attached to the message for transmission; on the receiver side, in order to authenticate a message, receiving a previously transmitted message, the message and the truncated MAC code; generating an expected truncated MAC code by selecting or generating predetermined bits from a message authentication code (MAC), the message authentication code being calculated on a concatenation of a predetermined portion of the message and at least one predetermined portion of a previously transmitted message; if the received truncated MAC code is the same as the expected truncated MAC code, the message and the previously transmitted message are authenticated.

Description

Technical Field

[0001] The present invention relates to a method and apparatus for providing a message authentication code suitable for authenticating a short message. In particular, the present invention relates to a transmitter apparatus and method for transmitting a message and a corresponding authentication code and a corresponding receiving apparatus and method for authenticating a received message.

[0002] The present invention relates to the field of authentication of messages transmitted over a network (eg a mobile network, a Wi-Fi network, a Bluetooth network). Background Art

[0003] The field of Internet of Things (IoT) devices is becoming ubiquitous. It is expected that many of these devices (e.g., sensor devices) will periodically send very short messages, such as a 32-bit user or sensor ID, a 32-bit timestamp, and an 8-bit sensor value. A known problem with all these cheap devices is the relatively weak security associated with them. One of the related security issues is that malicious messages are inserted into the network, so the transmission from such IoT devices needs to be integrity protected. A well-known technique for doing this is to add a message authentication code (MAC) to the message. The input for the MAC calculation is a secret key known to the sender and the receiver and the bits of the message that need to be protected. The output of the MAC calculation is n bits that look random. If only one bit in the message changes, then the output of the MAC calculation will be very different in an unpredictable way for someone who does not know the key. For a good MAC, just like for a good cryptographic hash, if only one bit in the input changes, then about half of the output bits will change. An example function that can be used to calculate a MAC is the HMAC algorithm class (keyed hash message authentication code or hash-based message authentication code, see, for example, [RFC2104]). An example of an HMAC is HMAC-SHA256, see [RFC 4868].

[0004] The output of HMAC-SHA256 is a 256-bit number. When the key is not known, the probability of guessing the correct HMAC-SHA256 output is 2^-256, which is so low that it is actually impossible to guess correctly. However, having to add 256 bits to protect a 72-bit message, as shown in the example above, adds a huge overhead to the message.

[0005] It is certainly possible to reduce the number of bits in the MAC, but this would make it easier for an attacker to guess the correct MAC for a message, making it easier for an attacker to forge messages. Therefore, for increased protection, longer MAC sizes are desirable.

[0006] A potential solution to avoid the large overhead is to concatenate several messages together, thereby expanding the size of one message, and provide message authentication for the concatenated messages using a regular sized MAC. However, the processing or display of the first measurement result to be transmitted is delayed at the receiver side. This is not attractive because some transmissions may be time sensitive, and waiting for other messages for the concatenation may affect the functionality of the system. Summary of the invention

[0007] The object of the present invention is to provide a method for providing a message authentication code suitable for short messages, which method alleviates at least one of the above mentioned problems. This object is achieved by a method according to claim 1. Basically, the solution exploits the fact that a transmitter (e.g. an IoT device) usually sends more than one message.

[0008] When a transmitter (e.g., an IoT device) sends a message, most or all of the bits to be protected in at least one earlier message are also used as input to a MAC calculation for integrity protection of the second message. This can be accomplished by concatenating (e.g., prepending or appending) the bits to be protected of the first message with the bits to be protected of the second message and using the result as input for the MAC calculation. The resulting MAC is truncated to N bits to produce a truncated MAC for the second message. For example, N can be a byte, i.e., 8 bits. After the second message is transmitted, the attacker has a probability of 1 in 2^(2*N) to forge the previous message and a probability of 1 in 2^N to forge the next message. Therefore, when using the method according to the present invention, MAC protection for the next message increases the confidence level in the earlier message. When a predetermined number of messages (M) are combined, the probability of an attacker forging the earliest message is reduced to 1 in 2^(M*N).

[0009] One may consider a system where the first M-1 messages are sent without any MAC protection, and then message number M is sent with a MAC protection of normal length (i.e., length M*N) calculated over the previous M messages and message number M. The claimed method has two advantages over this system. First, the earlier messages already have significant integrity protection, which is relevant in systems where trust in the data must exist and the use of the data is time-sensitive. Second, all messages have a truncated MAC of the same size. For many systems, it is advantageous to have a fixed message length.

[0010] Further preferred embodiments of the device and the method according to the invention are given in the attached dependent claims, the disclosure content of which is incorporated herein by reference.

[0011] In an embodiment of the present invention, a transmitter (e.g., an IoT device) adds a truncated MAC to the first message it sends, without relying on previous messages. Advantageously, such a first message can be marked with a specific identifier to allow the receiver to know that a MAC must be calculated on that single message.

[0012] In an embodiment of the invention, the number of messages to be included in the integrity protection of a new message is defined. This can be done by adding this number to the message (and as part of the message to be integrity protected), so for example it is 0 for the first message to be sent ("use 0 previously sent messages to calculate a truncated MAC for this message"). This value can also be predetermined or specified in the standard.

[0013] In another embodiment of the present invention, in order to save message bit length, only one bit can be used to indicate whether this is the first message for integrity protection, or all previously sent messages up to and including the first message have the following indication: the first message must be included in the truncated MAC calculated for the current message.

[0014] Note that a hash function with strong cryptographic properties needs to mix all the input bits so that the probability of a bit flipping is 0.5 for any change in the input bits, and the flipping of any one of the output bits is uncorrelated with the flipping of any other output bits. Therefore, if the desired protection strength is N-bit integrity protection (i.e., a guessing probability of 2^(-N) obtained by using N / L shorter hashes), the input mixing property of large hashes is required. For example, in SHA256, the message is broken into 512-bit blocks. The bit manipulation algorithm is applied 64 times ("rounds") to obtain an output for the block value. Internally, 2048 bits of state are used per round. The outputs of the different blocks are combined to calculate the hash over the entire message. The combination is a simple exor, so it is possible to reduce the number of calculations a little here, and only calculate the first 8 bits of the final result. Therefore, by selecting or generating predetermined bits from a message authentication code (MAC) calculated on a concatenation of a predetermined portion of the message with at least one predetermined portion of a previously sent message, this means that all required calculations are performed according to the corresponding algorithm to obtain the desired bits, independent of the final operations required to calculate the unused bits.

[0015] Regarding the input from the message to the authentication method, the complete message or predetermined bits thereof (eg excluding header bits which may have known structure / values) should be used.

[0016] For some unknown reason, the number of messages to be included in the integrity protection of a new message must be defined. This can be done by adding this number to the message (and as part of the message to be integrity protected), so for example it is 0 for the first message to be sent ("use 0 previously sent messages to calculate the truncated MAC for this message"). This value can also be specified in the standard. To save space, only one bit can be used to indicate that this is the first message for integrity protection, or all previously sent messages up to and including the first message have the following indication: the first message must be included in the calculation of the truncated MAC for the current message.

[0017] In this application, the term message indicates any set of bits sent from one party to one (unicast) or multiple (multicast, broadcast) receivers at any level in the communication stack. Examples of lower-level messages may be PHY layer packets or MAC packets (Media Access Control; due to the fact that MAC may mean both Media Access Control and Message Authentication Code, some specifications use the term Message Integrity Code instead of Message Authentication Code) or MAC frames, in which case link security can be present. Examples of higher-level messages may be IP packets, UDP packets, TCP-IP packets, IPsec packets, etc., in which case there is security between the sender and the receiver, which can be extended over several links. Other examples of messages are MPEG transport stream packets, MPEG program stream packets, elementary stream packets multiplexed in the payload of MPEG TS packets or MPEG PS packets, etc. Applications can also define their own messages, where security is typically end-to-end.

[0018] A message (or data packet) typically has a header and a payload. The payload is the content or information transmitted from the sender to the receiver(s). The header may contain the source address of the sender. The header may contain one or more destination addresses of the intended receiver(s). The header may indicate the length of the payload. The header may indicate security measures, such as whether the payload is encrypted and / or whether the payload is cryptographically integrity protected. Typically, the payload will have a CRC appended to it, but this is not a cryptographically protected value. The CRC is often used to quickly determine transmission errors and request retransmission if errors occur.

[0019] The payload of a message (or data packet) may also have a message authentication code (MAC) or message integrity code appended to it. The creation of both a MAC and a MIC requires knowledge of a secret key, so neither a MAC nor a MIC is easily forged. Usually, but not always, the header of a message or data packet indicates the presence of a MAC or MIC, its size, the encryption algorithm used, an indication of the key to be used, etc.

[0020] A typical way of using the invention is as follows: Note that it is easiest to use the invention with message types that have been assigned some form of cryptographic protection, but this is not necessary to be able to use the invention with a particular message type.

[0021] A previously reserved bit in a message (or data packet) header or a previously unused value or unused bit in a field in a message header (used to indicate a security algorithm) is used to indicate that the present invention is used. Another previously unused bit in a message header is used for a message number bit pattern (as explained below).

[0022] The specification may specify which bit or bits are used for the message number bit pattern, how large the truncated MAC is, where it is located in the entire message, and which specific algorithm is used for the truncated MAC calculation, where the security indication indicates the use of the present invention. Any or all of these aspects may be indicated in the security indication itself, such as the size of the truncated MAC or the algorithm used to calculate the truncated MAC. These may also be known to higher layers in the communication system.

[0023] When calculating a truncated MAC or MIC over several messages, these messages should preferably all be from the same sender to the same receiver(s).

[0024] A typical way in which the present invention can be used with the previously mentioned indication of using the present invention in a message is as follows. In addition to the message number bit pattern, an embodiment can also use an indication of whether the MAC in the message is truncated. This indication can be called a MAC truncation bit pattern, which in the case of this example is a 1-bit pattern. This has the advantage that messages with truncated MACs and messages with normal-sized MACs can be used in the same communication system.

[0025] In addition to indicating whether a message uses a truncated MAC or as an alternative to a 1-bit indication that a message uses or does not use a truncated MAC, the MAC truncation bit pattern can also be used to indicate how many bits the MAC or MIC is truncated, for example to 8 bits. The MAC truncation bit pattern can also show how many bits are taken from a normal MAC or MIC, so an indication of 0 means that a normal, non-truncated MAC or MIC is used. Using a multi-bit MAC truncation bit pattern has the advantage of flexibility in reducing message size.

[0026] In a simple embodiment, a 1-bit MAC truncation bit pattern "T" bit and a 1-bit message number bit pattern "N" bit are used in the header of each message. When the "T" bit is equal to 1, the MAC or MIC of the message is truncated to, for example, 8 bits. When the "T" bit is equal to 0, the full MAC or MIC is used. When the message is the "first message", the value 0 is set to the "N" bit, and when the message is the "next message" (i.e., not the "first message"), the value 1 is set to the "N" bit'. Messages using the "T" bit and "N" bit combination of (1,0) and (1,1) have reduced overhead. Messages using the "T" bit and "N" bit combination of (0,0) use the full MAC or MIC and do not use the previous message for the MAC or MIC, so (0,0) is effectively a known integrity protection. The advantage of having this combination is that the message integrity protection of the present invention can be flexibly used in systems that also use known integrity protection. A series of messages with a "T" bit and "N" bit combination of (1,1) can end with a message with a "T" bit and "N" bit combination of (0,1), so the last (1,1) series of messages used to calculate the MAC or MIC for the message with the (0,1) combination now immediately obtains full MAC integrity protection. This is advantageous when the transmitter wants to switch to legacy integrity protection using the combination (0,0) and providing full integrity protection for all messages. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] These and other aspects of the invention will be apparent from and further elucidated with reference to the embodiments described by way of example in the following description and with reference to the accompanying drawings.

[0028] Figure 1 A communication system having a transmitter and a receiver in a network for transmitting and receiving messages and associated message authentication codes and for authenticating received messages according to an embodiment of the present invention is shown;

[0029] Figure 2 A method of transmitting a message and an associated message authentication code according to an embodiment of the present invention is shown;

[0030] Figure 3 A method for receiving a message and an associated message authentication code and for authenticating the received message according to an embodiment of the present invention is shown;

[0031] Figure 4a A computer readable medium is shown; and

[0032] Figure 4b A processor system is shown in a schematic representation.

[0033] The figures are purely diagrammatic and not drawn to scale.In the figures, elements corresponding to elements already described may have the same reference numerals. DETAILED DESCRIPTION

[0034] Figure 1 Two devices for communicating in a network are shown, one device adapted to transmit messages using a truncated MAC and the other device adapted to receive messages with a truncated MAC.

[0035] In the communication system 100, a network provides communication 130 between two devices 110 and 120 according to a communication protocol.

[0036] The communication protocol defines messages on the link between the two devices, or defines messages on the link between two applications running on the processors 113 and 123 of the devices, or defines messages on the link between an application running on the processor 123 and a processor (not shown) to which the device 110 forwards messages from the device 120. The message contains data that does not require integrity protection, data that requires integrity protection, and a short message authentication code (MAC).

[0037] The device 120 has a transceiver 121 arranged for transceiving according to a communication protocol, a truncated MAC generator 122 for generating a truncated MAC code for message integrity protection, and a processor 123 arranged to manage messages to the device 110 for transmission over the link.

[0038] The processor 123 is further arranged to provide the correct secret key to the truncated MAC generator 122 to calculate the truncated MAC and is further arranged to obtain the message content from the message content generator 124 , which may be a sensor measuring a physical property 126 , for example.

[0039] The truncated MAC generator 122 is further arranged to store previously sent messages in the message memory 125 and to retrieve previously sent messages from the message memory 125 for use in calculating the truncated MAC.

[0040] The transceiver 121 obtains a truncated MAC from the truncated MAC generator 122 for each message sent by the transceiver 121 .

[0041] Likewise, device 110 has a transceiver 111 arranged for transceiving according to a communication protocol, a truncated MAC generator 112 for generating a truncated MAC code for checking integrity protection of received messages, and a processor 113 arranged to manage messages to device 110 for transmission on a link.

[0042] The processor 113 is also arranged to provide the correct key to the truncated MAC generator 112 to calculate the truncated MAC, and may also be arranged to forward the received message to another device (not shown) or other application (not shown), where the message is further processed, the content of the message is displayed, etc.

[0043] The truncated MAC generator 112 is further arranged to store previously received messages in the message memory 115 and to retrieve previously received messages from the message memory 115 for calculating the truncated MAC.

[0044] The transceiver 111 obtains a truncated MAC for each message received by the transceiver 111 from the truncated MAC generator 112, and thus the transceiver 111 is able to perform the integrity protection provided by the truncated MAC by comparing the truncated MAC obtained from the truncated MAC from the truncated MAC generator 112 with the truncated MAC in the received message. Alternatively, the processor 113 or the truncated MAC generator 112 performs this comparison.

[0045] In practice, the communication protocol may be any wireless communication protocol, for example, any cellular network protocol defined by, for example, 3GPP, which may be Wi-Fi, Bluetooth, ZigBee, any IoT wireless communication protocol (e.g., LoRa, Narrowband IoT (NB-IoT), LTE Cat 1, LTE Cat 0, LTE Cat M1 (eMTC), LTE Cat NB1, etc.). The communication protocol may also be any wired communication protocol (e.g., Ethernet).

[0046] In practice, device 110 may be a cellular network base station (eNodeB, E-UTRAN Node B (also known as Evolved Node B)), a Wi-Fi access point (AP), a Wi-Fi point-to-point device, a Bluetooth device, a ZigBee device, an IoT device using an IoT wireless communication protocol, etc. Device 120 may be any device that sends a message to device 110, for example, any IoT device using the aforementioned communication protocol. Of course, device 120 may also be any device mentioned for device 110, and device 110 may then be any device mentioned for device 120, wherein device 120 sends a message to device 110.

[0047] In an embodiment, device 120 creates a first message for sending to device 110. The fact that this is the first message can be indicated in the message by a message number bit pattern. The message number bit pattern can be part of the message header, but can also be part of the message body. The bit pattern can be just 1 bit, where, for example, a "0" indicates that it is the first message, and a "1" indicates that it is the next message. The next message is any message that follows the first message that is not the first message.

[0048] The message number bit pattern can also indicate a number indicating how many previously sent messages have been used in calculating the truncated MAC for the message. For example, if the truncated MAC is 8 bits long, a 5-bit bit pattern can indicate that up to 31 previously sent messages have been included in calculating the truncated MAC for the current message. With these numbers, after 31 messages have been sent after the first message, the effective MAC size for the first message is 32*8=256 bits, which is equal to the protection strength of HMAC-SHA256. Preferably, the message number bit pattern is included in the message bits to be integrity protected.

[0049] Processor 123 creates a first message based on, for example, content from message content generator 124. Processor 123 also creates a message number bit pattern indicative of the first message as described above and sends it to transceiver 121. Alternatively, transceiver 121 creates the message number bit pattern itself.

[0050] The truncated MAC generator 122 collects all the bits of the first message to be integrity protected and uses these bits as input to a MAC algorithm (e.g., HMAC-SHA256). The complete first message or at least the bits of the first message to be used in the truncated MAC calculation for the next message are stored in the message memory 125, which may or may not include the truncated MAC for the message calculated by the truncated MAC generator. The key for MAC generation is provided to the truncated MAC generator 122 by the processor 123. Key distribution is well known and can be done, for example, during factory installation, or can be sent to the device 120 using a secure message on the communication 130.

[0051] The truncated MAC generator 122 truncates the calculated MAC into a truncated MAC by taking any N bits (e.g., the first N bits) from the MAC, where N is less than the size of the MAC. For example, N can be 8 bits, and for HMAC-SHA256, the size of the MAC is 256 bits.

[0052] The truncated MAC generator 122 provides the truncated MAC to the transceiver 121 so that the transceiver can include the truncated MAC in the message to be transmitted. After including the truncated MAC in the message, the transceiver 121 transmits the message to the device 110 using the communication 130.

[0053] In the case of a next message to be sent, the processor 123 creates a new message based on, for example, the content from the message content generator 124 and sends it to the transceiver 121 for transmission over the communication network. The processor 123 also creates a message number bit pattern indicating the next message as described above and sends it to the transceiver 121. Alternatively, the transceiver 121 creates the message number bit pattern itself. The truncated MAC generator 122 also needs to know this bit pattern.

[0054] For the next message, the truncated MAC generator 122 not only collects all the bits of the next message to be integrity protected, but also collects the bits of multiple previously sent messages that need to be integrity protected, which may or may not include the truncated MAC of the previously sent messages. All of these bits are now used as input to the MAC algorithm (e.g., HMAC-SHA256). This can be done by simply appending these bits one by one. Similar to what the truncated MAC generator 122 did for the first message, the truncated MAC generator 122 stores the complete next message or at least the bits of the next message to be integrity protected in the message memory 125, which may or may not include the truncated MAC.

[0055] The amount of previously stored messages used to calculate the truncated MAC can be indicated in the message number bit pattern. In this case, the amount of bits for the size of the message number bit pattern is preferably greater than 1, but only one bit may be used, in which case only the last sent message is included in the truncated MAC calculation.

[0056] Alternatively, the amount of previously stored messages to be used in the calculation of the truncated MAC can be all previously sent messages up to and including the first message of a specific number of previously sent messages having a maximum value. The maximum value can be specified in a standard, such as Bluetooth SIG (https: / / www.bluetooth.com / ), IEEE (https: / / www.ieee.org / ), Wi-Fi Alliance (https: / / www.wi-fi.org / ), or 3GPP (http: / / www.3gpp.org / ). For example, if the maximum value is 31 and the next message is the second message to be sent after the first message, the two previously sent messages (the first message and the first message after the first message) will be included in the truncated MAC calculation. For example, if this maximum value is 31 and the next message is the 32nd message to be sent after the first message, the 31 previously sent messages are included in the truncated MAC calculation, so all messages after the first message are included in the truncated MAC calculation. The message memory 125 does not need to store messages exceeding this maximum number. The maximum number of messages to be used may also be undefined, in which case all previously sent messages up to and including the first message are simply used for the truncated MAC calculation. In this case, the device 120 should from time to time decide to send a message as the first message, so that the amount of input for the MAC calculation and the amount to be stored in the message memory 125 does not become too large. In all these cases, the message number bit pattern can be just one bit, as explained above.

[0057] Deciding to send a message as the first message may be done, for example, as a reaction to a message from device 110. Device 110 may want to do that if device 110 lost or did not receive or erroneously received one or more previously sent messages.

[0058] The remaining process for the next message is similar to the process for the first message. The truncated MAC generator 122 truncates the calculated MAC into a truncated MAC by taking any N bits (e.g., the first N bits) from the MAC, where N is less than the size of the MAC. For example, N can be 8 bits, and for HMAC-SHA256, the size of the MAC is 256 bits. The truncated MAC generator 122 provides the truncated MAC to the transceiver 121 so that the transceiver can include the truncated MAC in the message to be sent. After including the truncated MAC in the message, the transceiver 121 sends the message to the device 110 using the communication 130.

[0059] In an embodiment, device 110 receives a message from device 120 in transceiver 111. Those skilled in the art will appreciate that the actions of device 110 are very similar to those of device 120. For example, if device 110 uses HMAC-SHA256 truncated to 8 bits as the truncated MAC, so does device 120. Both devices need to use the same maximum number of previously sent messages to be included in the calculation of the truncated MAC.

[0060] Transceiver 111 provides at least the bits from the message to be integrity protected, the truncated MAC from the received message, and the message number bit pattern in the received message to truncated MAC generator 112. Truncated MAC generator 112 stores the complete received message in message memory 115 or at least the bits of the received message to be used in the calculation of the truncated MAC for a subsequent message.

[0061] If the message number bit pattern indicates that it is the first message, then the truncated MAC generator 112 uses all of the bits to be integrity protected of this first message as input to the MAC algorithm (eg, HMAC-SHA256).

[0062] If the message number bit pattern indicates that the received message is the next message, the truncated MAC generator 112 collects not only all the bits to be integrity protected for the received message, but also the bits to be integrity protected for a number of previously received messages (as stored in the message memory 115), and the stored bits may or may not include the truncated MAC of the previously sent message. All of these bits are now used as input to the MAC algorithm (e.g., HMAC-SHA256). This can be done by simply appending the bits one by one.

[0063] As explained above, the number of previously received messages used in the truncated MAC calculation by the truncated MAC generator 112 may be indicated in the message number bit pattern, which may be all previously received messages up to and including the first message indicated as having a certain number of previously transmitted messages having a maximum value, wherein the maximum value is a maximum value as described above. The message memory 115 need not store more messages than this maximum value.

[0064] The key used for MAC generation is provided by processor 113 to truncated MAC generator 112. Key distribution is well known and can be done by factory installation or can be sent to device 110 using a secure message over any communication network (not shown).

[0065] The truncated MAC generator 112 truncates the calculated MAC into a truncated MAC by taking any N bits (e.g., the first N bits) from the MAC, where N is less than the size of the MAC. For example, N can be 8 bits, and for HMAC-SHA256, the size of the MAC is 256 bits.

[0066] The truncated MAC generator 112 compares the calculated truncated MAC with the truncated MAC from the received message. If the two values ​​are the same, the received message and all previously received messages used in the truncated MAC calculation are indicated as OK. The indication may include, for each received message, the amount of truncated MACs that have been found to be correct for that message, which serves as a measure of credibility. Other measures of credibility may also be used, for example, the probability that a message is forged in the event that an attacker uses a random truncated MAC. If the two values ​​are different, the received message and all previously received messages used in the truncated MAC calculation will always be indicated as problematic, overriding any previously set "OK" status.

[0067] Alternatively, the transceiver 111 or the processor 113 may perform the comparison and result processing of the truncated MAC.

[0068] Figure 2 A method of transmitting a message and an associated message authentication code according to an embodiment of the present invention is shown. The method begins with a link management step 503, which involves establishing a connection between a transmitter and a receiver. In step 504, keys or other secret information required for the authentication method are exchanged or determined by each of the transmitter and the receiver. In step 505, the necessary operations for calculating the message authentication code are performed. In step 506, truncation of the message authentication code as previously described is performed. In step 507, the truncated MAC code is attached to the message for transmission and the method moves to the next block / next message.

[0069] Figure 3A method of receiving a message and an associated message authentication code to authenticate the received message according to an embodiment of the present invention is shown. The method begins with a link management step 503, which involves establishing a connection between a transmitter and a receiver. In step 504, keys or other secret information required for the authentication method are exchanged or determined by each of the transmitter and the receiver. In step 505, the necessary operations for calculating the message authentication code are performed. In step 506, a truncation of the previously described message authentication code is performed. In steps 606 and 607, the calculated truncated code is compared with the received truncated code. If the two are the same, both the current message and the previous message are authenticated and the method moves to the next block 609. If the two are different, an error message 610 is generated and neither the message nor the previous message is authenticated.

[0070] Although various embodiments of the present invention are described above in terms of how to protect messages, below we will discuss details of how to use embodiments of the present invention in various data transmission standards (including, for example, 3GPP, WiFi, and Bluetooth).

[0071] With respect to Wi-Fi MAC frames, see [802.11], CTR with CBC-MAC protocol (CCMP, Section 12.5.3 in [802.11]) is widely used to protect Wi-Fi frames, including frames used in 802.11n, 802.11ac, 802.11ax, and 802.11ah. The commercial name for 802.11ah is HaLow. For example, by using reserved bits B0-B4 in the 8-bit CCMP header, the present invention can be used with CCMP. For example, B0 can be used instead of the 8-bit CCMP MIC, and according to the present invention, a truncated MIC is used. The MIC is calculated using the same algorithm and key as CCMP but using the contents of a MAC frame previously sent from the same source to the same destination, as explained below. For example, bit B1 can be used to indicate that the current frame is the first frame (message), as explained below. For example, bits B2 and B3 can indicate the length of the truncated MIC, for example, 1, 2, 3, or 4 octets. Since the original CCMP MIC is 8-16 octets in size, the present invention enables a considerable reduction. The size of the truncated MIC may also be specified in new versions of [802.11] as, for example, 1 octet. Bits B1-B2 may also be used, for example, as a 2-bit message number bit pattern, the value of which means "include N messages previously sent from the same sender to the same receiver(s) as for this message when calculating the truncated MIC for this message".

[0072] If the Wi-Fi MAC frame is the first message to use a truncated MIC, the MIC is calculated as specified in the CCMP specification in Section 12.5.3 of [802.11], and the normal MIC is truncated to, for example, 8 bits and appended to the payload of the Wi-Fi MAC frame. The message number bit pattern is set to indicate that this is the first message.

[0073] If a previously sent Wi-Fi MAC packet is needed for calculating a truncated MIC, all bits of the regular MIC used to calculate the previous Wi-Fi MAC packet are prepended (or appended) to the bits of the current Wi-Fi MAC packet used to calculate the regular MIC, and the regular algorithm for CCMP MIC calculation is used, but the algorithm now has a longer input. The MIC result is truncated to, for example, 8 bits and appended after the payload of the Wi-Fi MAC packet. The message number bit pattern is set to the correct number.

[0074] Wi-Fi frames used in 802.11ad (WiGig or 60GHz Wi-Fi, or Directional Multi-Gigabit (DMG), see [802.11]) typically use the GCM protocol (GCMP, Section 12.5.5 of [802.11]) to provide their protection. The present invention can be used in a manner similar to that described above for CCMP (using any of the reserved bits B0-B4 of the GCMP header and a truncated MIC). Since the size of the original GCMP MIC is 16 octets, the present invention can achieve a considerable reduction.

[0075] Cellular communication protocols are specified by 3GPP (http: / / www.3gpp.org / ) (eg, LTE, 4G, and 5G mobile communication specifications).

[0076] When a data packet (e.g., an IP packet) needs to be sent from a mobile base station (eNodeB in 3GPP terminology) to a mobile device (user equipment UE in 3GPP terminology) or vice versa, the packet is sent using the Packet Data Convergence Protocol (PDCP), which performs data header compression, ciphering, and integrity protection. The protocol uses PDCP packets with a PDCP header and payload to transport data packets, optionally with a compressed header. PDCP supports the transport of RTP / UDP / IP, UDP / IP, ESP / IP, IP, TCP / IP, RTP / UDP / IP, UDP / IP, ESP / IP packets, etc. Note that it is not only mobile phones' Internet access that use PDCP packets and PDCP packets, but also protocols defined by 3GPP for IoT purposes, such as Narrowband IoT (NB-IoT) categories NB1 and NB2, and LTE-M categories CAT-M1 and CAT-M2. PDCP is specified in [38.323].

[0077] Packet header compression technology can be based on IP header compression [RFC2507] or Robust Header Compression (RFC3095 or newer [RFC5795]).

[0078] Integrity protection of PDCP packets is configured by upper layers using the integrity protection methods specified in [33.501] as specified in [38.331].

[0079] Similar to the above, the present invention can be used for integrity protection of PDCP data packets. The purpose of the present invention and some general parameters (e.g., the algorithm for the truncated MIC and the size of the truncated MIC) can be configured by higher layers, similar to what has been specified for conventional MIC calculations. One or more reserved bits in the PDCP header can be used to carry a message number bit pattern. Section 6.2.2 of [38.323] specifies the PDCP header for data PDUs (protocol data units). There are at least three reserved bits in octet 1 of different types of data PDUs. The difference between them is the size of the PDCP sequence number (SN). In the current 3GPP specifications, control PDUs are not integrity protected. However, their PDCP headers have four reserved bits (see Section 6.2.3 of [38.323]), which can be used to indicate the purpose of the present invention and carry a message number bit pattern.

[0080] If the PDCP packet is the first message to use a truncated MIC, the MIC is calculated on the bits of the message as specified in Section 5.9 of [38.323] and configured by upper layers as specified in [38.331], and the normal MIC is truncated to, for example, 8 bits and appended after the payload of the PDCP packet. The message number bit pattern is set to indicate that this is the first message.

[0081] If a previously sent PDCP packet is required to calculate a truncated MIC, all bits used to calculate the conventional MIC for the previous PDCP packet are prepended (or appended) to the bits of the current PDCP packet used to calculate the conventional MIC, and the conventional algorithm for PDCP MIC calculation is used, but the algorithm now has a longer input. The MIC result is truncated to, for example, 8 bits and appended after the payload of the PDCP packet. The message number bit pattern is set to the correct number.

[0082] PDCP uses Radio Link Control (RLC) to transport PDCP packets. RLC is responsible for segmentation / concatenation, retransmission handling, duplicate detection and in-sequence delivery to higher layers. RLC uses RLC packets with an RLC header and a payload. The payload is used to transport (parts of) PDCP packets. Currently no encryption protection is specified for RLC packets. Nevertheless, the present invention can also be used as described above. The application of the present invention to RLC may imply the need to establish new keys between the transmitter and (one or more) receivers.

[0083] RLC uses medium access control (MAC) packets to transmit RLC packets. MAC packets also have a header and a payload, the latter being used to transmit RLC packets. The medium access control in the 3GPP system handles the multiplexing of logical channels, hybrid ARQ retransmissions, and scheduling of uplinks and downlinks. Currently, no encryption protection is specified for MAC packets. Nevertheless, the present invention can also be used as described above. The application of the present invention to the MAC layer may imply the need to establish new keys between the transmitter and (one or more) receivers.

[0084] Bluetooth LE is specified in the specification volume 6 of [BTv5.0].

[0085] Bluetooth LE packets at the link layer are called protocol data units (PDUs). Other Bluetooth variants are similar to what is described here. A Bluetooth (LE) PDU has a 16-bit header, a payload, and can have a MIC. A Bluetooth LE PDU is carried in a link layer packet. A link layer packet contains a 32-bit access address, which is used to specify an existing link between two specific devices. The same access address means a link between two devices of the same group. There are no reserved bits in the PDU header. The PDU header has a bit that indicates whether the payload contains data (data PDU) or control information (control PDU). The PDU header does not indicate whether the payload is encrypted and whether there is a MIC. Instead, this is indicated by a specific control PDU. The control PDU packet contains an opcode (a code indicating an operation), for example, "Start Encryption" (LL_START_ENC_REQ) and "Pause Encryption" (LL_PAUSE_ENC_REQ). The "Start Encryption" command starts encryption and integrity protection using a MIC, because the two are always used together or not at all. The present invention can be used for BLE by adding some new opcodes to the control PDU (e.g., one or more opcodes for sending a message number bit pattern, a signal opcode for starting encryption and using a truncated MIC, which can also be used to indicate that the next data PDU with the same access address is the first message to be used in calculating the truncated MIC). The conventional "pause encryption" (LL_PAUSE_ENC_REQ) can be used as an indication that the next data PDU with the same access address is no longer encrypted and no longer contains a truncated MIC.

[0086] If the data PDU is the first message to use a truncated MIC, the MIC is calculated as specified in the Bluetooth specification and the 32-bit normal MIC is truncated to, for example, 8 bits and appended after the payload of the data PDU. This means that each data PDU is reduced by 24 bits. The message number bit pattern is set to indicate that this is the first message.

[0087] If a previously sent Data PDU is needed for calculating a truncated MIC, all bits used to calculate the normal MIC of the previous message are prepended (or appended) to the bits of the current message used to calculate the normal MIC, and the normal algorithm for Bluetooth MIC calculation (CCM) is used, but now with a longer input. The MIC result is truncated to, for example, 8 bits and appended after the payload of the Data PDU. The message number bit pattern is set to the correct number.

[0088] The truncated MIC calculation can use the same MIC algorithm and the same keys as specified in the Bluetooth specification, but of course other MIC algorithms and other keys can also be defined.

[0089] Different versions of the Bluetooth specification use the same partitioning in data PDU and control PDU, but the addressing may be different, and the security algorithm may also be different. Nevertheless, the present invention can also be used for other Bluetooth versions in a similar manner.

[0090] LoRaWAN is specified in [LoRaWAN]. LoRaWAN is a network protocol optimized for battery-powered end devices that can be mobile or installed in fixed locations. LoRaWAN networks are typically laid out in a star-stack topology, where gateways relay messages between end devices and a central network server that routes packets from each device of the network to the associated application server. To protect radio transmissions, the LoRaWAN protocol relies on symmetric encryption using session keys derived from the device's root key. On the back end, storage of the device's root key and associated key derivation operations is ensured by the Join Server.

[0091] The lowest layer of communication in a LoRaWAN network is the radio PHY layer, where uplink messages and downlink messages carry PHY payloads. The PHY payload can carry a MAC packet consisting of a MAC header (MHDR), a MAC payload (MACPayload), and an encrypted 4-octet message integrity code (MIC). One way to apply the present invention in LoRaWAN is to use one of the three values ​​reserved for the value of the 2-bit main field of MHDR for future use to indicate that the present invention is used. If the main field indicates that the present invention is used, this also means extending the MHDR with one or more bits for the message number bit pattern, as explained below. In addition, the MHDR can be extended with one or two bits indicating the length of the truncated MIC. Alternatively, two of the three unused values ​​of the main field can be used; one value indicates that the present invention is used and the MAC packet is the first message, while the other value can be used to indicate that the present invention is used and the MAC packet is the next message.

[0092] Similar to the above, for example, for Bluetooth, when the MAC packet is indicated as the first message, the MIC can be calculated using the same key and algorithm as specified in the LoRaWAN specification. However, instead of appending the conventionally calculated MIC, the MIC is truncated to, for example, 8 bits and the truncated MIC is appended after the MACPayload.

[0093] Similar to the above, for example, for Bluetooth, if a previously sent MAC packet is needed to calculate a truncated MIC, all bits used to calculate the conventional MIC of the previous MAC message are prepended (or appended) to the bits of the current MAC message used to calculate the conventional MIC, and the conventional algorithm for LoRaWAN MIC calculation is used, but the algorithm now has a longer input. The MIC result is truncated to, for example, 8 bits and appended after the MACPayload.

[0094] Figure 4a A computer readable medium 1000 is shown having a writable portion 1010 including a computer program 1020 comprising instructions for causing a processor system to perform a Figure 1-3 The computer program 1020 may be a computer program that performs one or more of the methods and processes described above in the system described. The computer program 1020 may be embodied on the computer-readable medium 1000 as a physical mark or by means of magnetization of the computer-readable medium 1000. However, any other suitable embodiments are also conceivable. In addition, it will be appreciated that although the computer-readable medium 1000 is shown as an optical disk here, the computer-readable medium 1000 may be any suitable computer-readable medium (e.g., a hard disk, a solid-state memory, a flash memory, etc.) and may be non-recordable or recordable. The computer program 1020 includes instructions for causing the processor system to perform the method described.

[0095] Figure 4b The schematic diagram shows the Figure 1-3 The processor system 1100 of an embodiment of the described device or method. The processor system may include a circuit 1110 (e.g., one or more integrated circuits). The architecture of the circuit 1110 is schematically shown in the figure. The circuit 1110 includes a processing unit 1120 (e.g., a CPU) for running a computer program component to perform a method according to an embodiment and / or implement its module or unit. The circuit 1110 includes a memory 1122 for storing programmed code, data, etc. Part of the memory 1122 may be read-only. The circuit 1110 may include a communication element 1126 (e.g., an antenna, a transceiver, a connector, or both). The circuit 1110 may include a dedicated integrated circuit 1124 for performing some or all of the processing defined in the method. The processor 1120, the memory 1122, the dedicated IC 1124, and the communication element 1126 may be connected to each other via an interconnect 1130 (e.g., a bus). The processor system 1110 may be arranged for wired and / or wireless communication using a connector and / or an antenna, respectively.

[0096] Alternatively, the device may be implemented in whole or in part in the form of programmable logic, for example as a field programmable gate array (FPGA). The device and server may be implemented in whole or in part as a so-called application specific integrated circuit (ASIC), i.e., an integrated circuit (IC) customized for its specific purpose. For example, the circuit may be implemented in CMOS, for example using a hardware description language (e.g., Verilog, VHDL, etc.).

[0097] It will be appreciated that, for the sake of clarity, the above description describes embodiments of the present invention with reference to different functional units and processors. However, it will be appreciated that any suitable functional distribution between different functional units or processors may be used without departing from the present invention. For example, the function performed by a separate unit, processor or controller may be performed by the same processor or controller. Therefore, reference to a specific functional unit is only considered as a reference to a suitable unit for providing the described function, rather than indicating a strict logical or physical structure or organization. The present invention can be implemented in any suitable form including any combination of hardware, software, firmware or these items.

[0098] It should be noted that in this document, the verb "comprise" does not exclude the presence of elements or steps other than those listed, and the word "one" or "an" in front of an element does not exclude the presence of multiple such elements. When a statement such as "at least one of..." is in front of a list of elements, it means selecting all elements or any subset of elements from the list. For example, the statement "at least one of A, B, and C" should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all A, B, and C. Any figure mark does not limit the scope of the claim. The present invention can be implemented by any one or both of hardware and software. In addition, the present invention is not limited to these embodiments, and the present invention lies in each novel feature or combination of features described above or recorded in mutually different dependent claims.

[0099] In summary, this application relates to the following references:

[0100] [33.501] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for 5G Systems (Release 15); 3GPP TS 33.501 V15.2.0 (2018-09); http: / / www.3gpp.org / ftp / / Specs / archive / 33_series / 33.501 / 33501-f20.zip

[0101] [38.323] 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Packet Data Convergence Protocol (PDCP) Specification (Release 15); 3GPP TS 38.323 V15.3.0 (2018-09), http: / / www.3gpp.org / ftp / / Specs / archive / 38_series / 38.323 / 38323-f30.zip

[0102] [38.331] 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) Protocol Specification (Release 15); 3GPP TS 38.331 V15.3.0 (2018-09), http: / / www.3gpp.org / ftp / / Specs / archive / 38_series / 38.331 / 38331-f30.zip

[0103] [802.11] IEEE Computer Society, "IEEE Standard for Information Technology—Telecommunications and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific requirements Part 11: Wireless LAN MediumAccess Control (MAC) and Physical Layer (PHY) Specifications" (IEEE Standard 802.11-2016), December 2016

[0104] [BTv5.0] Bluetooth Core Specification, v5.0, https: / / www.bluetooth.org / DocMan / handlers / DownloadDoc.ashx?doc_id=421043&_ga=2.98314335.1543434637.1541687761-711838716871

[0105] [LoRaWAN]LoRaWAN TM 1.1 Specification, written by the LoRa Alliance Technical Committee, https: / / lora-alliance.org / resource-hub / lorawantm-specification-v11

[0106] [RFC2507] "IP Header Compression", February 1999, https: / / datatracker.ietf.org / doc / rfc2507 /

[0107] [RFC2104] "HMAC: Keyed-Hashing for Message Authentication", February 1997, https: / / datatracker.ietf.org / doc / rfc2104 /

[0108] [RFC4868] "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512withIPsec", May 2007, https: / / datatracker.ietf.org / doc / rfc4868 /

[0109] [RFC5795] “The RObust Header Compression (ROHC) Framework”, March 2010, https: / / datatracker.ietf.org / doc / rfc5795 /

Claims

1. A method of authenticating messages exchanged between a transmitter and a receiver over a network, The method comprises: On the transmitter side, in order to transmit the message, - generating a truncated MAC code by selecting or generating predetermined bits from a message authentication code (MAC) calculated on a concatenation of a predetermined portion of the message and at least one predetermined portion of a previously transmitted message; wherein the bit length of the truncated MAC code is less than the bit length of the message authentication code (MAC), - appending the truncated MAC code to the message for transmission; On the receiver side, to authenticate the message, - receiving a previously transmitted message, said message and said truncated MAC code; - generating an expected truncated MAC code by selecting or generating predetermined bits from a message authentication code (MAC) calculated on a concatenation of a predetermined portion of the message and at least one predetermined portion of a previously transmitted message; - If the received truncated MAC code is identical to the expected truncated MAC code, then authentication is given to the message and the previously transmitted message.

2. The method according to claim 1, wherein: For a first message transmitted, the message authentication code (MAC) is calculated over a predetermined portion of the first message without concatenation with at least one predetermined portion of a previously transmitted message.

3. The method according to claim 2, wherein: The message authentication code (MAC) is computed over either: concatenation of the predetermined portion of the message with a sequence of a second predetermined number of portions of previously transmitted messages; or A concatenation of the predetermined portion of the message with a sequence of predetermined portions of each preceding message starting with the first message transmitted.

4. The method according to claim 2 or 3, wherein: The message is provided with at least one of the following: - a first identifier identifying that the message authentication code (MAC) is calculated on a predetermined portion of the first message without concatenation with at least one predetermined portion of a previously transmitted message; - a second identifier identifying that said message authentication code (MAC) is calculated on the concatenation of a predetermined portion of said message and at least one predetermined portion of a previously transmitted message.

5. The method according to claims 1 to 4, wherein: The message is provided with at least one of the following: - a third identifier, which identifies that the message authentication code (MAC) is truncated; - a fourth identifier, which identifies that the message authentication code (MAC) is truncated to n bits.

6. The method according to claims 1 to 4, wherein: The message is provided with at least one of the following: - a third identifier, which identifies that the message authentication code (MAC) is truncated; - a fourth identifier, which identifies that the message authentication code (MAC) is not truncated.

7. The method according to claim 3, wherein: On the receiver side, to authenticate the message, - If the received truncated MAC code is different from the expected truncated MAC code, then no authentication is given to the message and the previously transmitted message, overwriting the authentication of the previously transmitted message.

8. The method according to claim 4, wherein: At least one of the first identifier or the second identifier has a bit length of 1 bit.

9. The method according to claim 8, wherein: At least one of the first identifier or the second identifier is either provided in a data packet header or concatenated with the truncated MAC code.

10. A method for transmitting a message and an authentication code over a network by a transmitter, the method comprising: - generating a truncated Message Authentication Code (MAC) code by selecting or generating predetermined bits from a MAC; The message authentication code is calculated on a concatenation of a predetermined portion of the message and at least one predetermined portion of a previously transmitted message; The bit length of the truncated MAC code is smaller than the bit length of the message authentication code (MAC), - appending the truncated MAC code to the message for transmission.

11. A method of authenticating a message received by a receiver over a network, The message includes a truncated MAC code, the truncated MAC code being calculated by selecting or generating predetermined bits from a message authentication code (MAC), the message authentication code being calculated on a concatenation of a predetermined portion of the message and at least one predetermined portion of a previously transmitted message, wherein, The bit length of the truncated MAC code is less than the bit length of the message authentication code (MAC), The method comprises: - receiving a previously transmitted message, said message and said truncated MAC code; - generating an expected truncated MAC code by selecting or generating predetermined bits from a message authentication code (MAC) calculated on a concatenation of a predetermined portion of the message and at least one predetermined portion of a previously transmitted message; - If the received truncated MAC code is identical to the expected truncated MAC code, then authentication is given to the message and the previously transmitted message.

12. The method according to claim 11, wherein: for a first message received as a first message transmitted, wherein the message authentication code (MAC) is calculated over a predetermined portion of the first message without concatenation with at least one predetermined portion of a previously transmitted message, The method comprises: An expected truncated MAC code is generated by selecting or generating predetermined bits from a message authentication code (MAC) that is computed on the first message without concatenation with at least a predetermined portion of a previously transmitted message.

13. The method according to claim 11 or 12, wherein: The message is provided with either: - a first identifier identifying that the message authentication code (MAC) is calculated on a predetermined portion of the first message without concatenation with at least one predetermined portion of a previously transmitted message; or - a second identifier identifying that the message authentication code (MAC) is calculated on a concatenation of a predetermined portion of the message and at least one predetermined portion of a previously transmitted message; The method comprises: The first identifier or the second identifier is used to determine a previously transmitted message to be used in generating an expected truncated MAC code.

14. A transmitter for transmitting a short message and a corresponding message authentication code over a network, The transmitter comprises: -Antenna and transceiver, which are used to transmit messages; - a processor coupled to the antenna and the transceiver, the processor being configured to control the transmission and generation of a message authentication code (MAC); The processor is adapted to perform the method according to claim 10.

15. A receiver for receiving a short message and a corresponding message authentication code on a network, The receiver comprises: - an antenna and a transceiver for receiving a message including a message authentication code (MAC); - a processor coupled to the antenna and the transceiver, the processor being configured to control the reception and generation of a message authentication code (MAC); The processor is adapted to perform the method according to claims 11 to 13.

Images