CN113302877B

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

Info

Publication number: CN113302877B
Application number: CN201980088729.XA
Authority: CN
Inventors: J·A·C·伯恩森
Original assignee: Koninklijke Philips NV
Current assignee: Koninklijke Philips NV
Priority date: 2018-11-13
Filing date: 2019-11-13
Publication date: 2024-12-20
Anticipated expiration: 2039-11-13
Also published as: CN113302877A; US20220006644A1; WO2020099446A1; EP3881490B1; JP2022507141A; JP7300506B2; US12010243B2; EP3881490A1; EP3881490C0

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

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

Technical Field

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

The present invention relates to the field of authentication of messages transmitted over a network (e.g., mobile network, wi-Fi network, bluetooth network).

Background

The field of internet of things (IoT) devices has become ubiquitous. Many of these devices (e.g., sensor devices) are expected to send very short messages, such as a 32-bit user or sensor ID, a 32-bit timestamp, and an 8-bit sensor value, on a regular basis. A known problem with all these inexpensive devices is the relatively weak security associated therewith. One of the related security issues is that malicious messages are inserted into the network, thus requiring integrity protection of transmissions from such IoT devices. A well-known technique for doing this is to add a Message Authentication Code (MAC) to the message. The input to the MAC calculation is the 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 appear random. If only one bit in the message changes, the output of the MAC calculation will vary widely in an unpredictable manner for someone who does not know the key. For good MAC, just as for good cryptographic hashing, if only one bit in the input changes, about half of the output bits will change. One class of example functions that can be used to calculate the MAC is the HMAC algorithm class (key hash message authentication code or hash-based message authentication code, see e.g., [ RFC2104 ]). An example of an HMAC is HMAC-SHA256, see [ RFC 4868].

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 too low to be practically correct. However, 256 bits must be added to protect a 72 bit message, which adds significant overhead to the message, as shown in the example above.

The number of bits of the MAC can of course be reduced, but so that an attacker can more easily guess the correct MAC of the message, making it easier for the attacker to forge the message. Thus, to enhance protection, longer MAC sizes are desired.

A potential solution to avoid large overhead is to concatenate several messages together, thereby expanding the size of one message, and to provide message authentication for the concatenated message using a conventional size 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 concatenation may affect the functionality of the system.

Disclosure of Invention

It is an object of the present invention to provide a method for providing a message authentication code suitable for short messages, which method alleviates at least one of the above problems. This object is achieved by a method according to claim 1. Basically, this solution exploits the fact that a transmitter (e.g., ioT device) will typically send more than one message.

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 for input of MAC computation 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 to the MAC calculation. The resulting MAC is truncated to N bits to produce a truncated MAC for the second message. For example, N may be one byte, i.e., 8 bits. After the second message is transmitted, the attacker has a probability of 2 (2*N) times that of the previous message and a probability of 1 times that of 2 times that of the next message. Thus, when using the method according to the invention, the MAC protection for the latter message increases the confidence level in the earlier message. When combining a predetermined number of messages (M), the probability of an attacker forging the earliest message will be reduced to 1 of 2 (M N) fraction.

A system may be considered in which the first M-1 messages are sent without any MAC protection, and then the message number M is sent with the MAC protection and message number M of the normal length (i.e. length M x N) calculated on the previous M messages. There are two advantages of the claimed method compared to this system. First, 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 truncated MACs of the same size. For many systems, it is advantageous to have a fixed message length.

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

In embodiments of the invention, the transmitter (e.g., ioT device) adds a truncated MAC to the first message it sends, independent of previous messages. Advantageously, such a first message may be tagged with a specific identifier to allow the receiver to know that the MAC must be calculated on that single message.

In an embodiment of the invention, the number of messages to be included in the integrity protection of the 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 0 for the first message to be sent ("truncated MAC for this message is calculated using 0 previously sent messages"). The value can also be predetermined or specified in a standard.

In a further embodiment of the invention, in order to save message bit length, it is possible to indicate with only one bit whether this is the first message for integrity protection or whether all previously sent messages up to and including the first message have an indication that the first message must be included in calculating the truncated MAC for the current message.

It is noted that a hash function with strong encryption properties requires mixing all input bits such that the probability of one bit toggling when any change occurs in an input bit is 0.5 and the toggling of any one of the output bits is uncorrelated with the toggling of any of the other output bits. Thus, if the desired protection strength is N-bit integrity protection (i.e., the guess probability is 2-N by using N/L shorter hashes), then a large hash of the input mix attribute is required, e.g., in SHA256, the message is broken into 512 bit blocks, the bit processing algorithm is applied 64 times ("rounds") to obtain an output for the block values, internally, 2048 bit states are used per round, the outputs of the different blocks are combined to calculate the hash over the entire message, the combination is simple exor, so here one point of the number of calculations can be reduced, only the first 8 bits of the final result are calculated, thus by selecting or generating a pre-determined bit from the Message Authentication Code (MAC) calculated on a concatenation of a pre-determined portion of the message with at least one pre-determined portion of the previously sent message, which means that all the required calculations are performed according to the corresponding algorithm to obtain the desired bits, independent of the final operation required to calculate the unused bits.

Regarding the input from the message to the authentication method, the complete message or its pre-determined bits (e.g. excluding header bits that may have a known structure/value) should be used.

For some unknown reason, the number of messages to be included in the integrity protection of the 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 0 for the first message to be sent ("truncated MAC for this message is calculated using 0 previously sent messages"). This value can also be specified in the standard. To save space, it is possible to indicate with only one bit whether this is the first message for integrity protection or whether all previously sent messages up to and including the first message have an indication that the first message must be included in calculating a truncated MAC for the current message.

In this application, the term message indicates any set of bits sent from a party to one (unicast) or more (multicast, broadcast) receivers at any level in the communication stack. Examples of lower level messages may be PHY layer packets or MAC packets (medium access control; due to the fact that MAC may represent both medium 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 is enabled. 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 security may extend over several links. Other examples of messages are MPEG transport stream packets, MPEG program stream packets, elementary stream packets multiplexed in the payloads of MPEG TS packets or MPEG PS packets, etc. An application can also define its own messages, where security is typically end-to-end.

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 be appended with a CRC, but this is not a cryptographically protected value. CRCs are typically used to quickly determine transmission errors and require retransmission when an error occurs.

The payload of the message (or data packet) may also be appended with a Message Authentication Code (MAC) or message integrity code. Both the creation of a MAC and a MIC requires knowledge of the secret key, and thus neither MAC nor MIC is easily counterfeited. This is often, but not always, the case where the header of the 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.

A typical way of using the invention is as follows. Note that the use of the present invention for message types that have been assigned some form of encryption protection is the simplest, but is not necessary to be able to use the present invention for a particular message type.

The previously reserved bits in the message (or data packet) header or the previously unused values or unused bits in the fields in the message header (used to indicate the security algorithm) are used to indicate that the invention is used. Another previously unused bit in the message header is used for the message numbering bit pattern (as explained below).

The specification may specify which bit or bits are used for the message numbering bit pattern, how large the truncated MAC is, its position in the entire message and which particular algorithm is used for the truncated MAC calculation in the case where the security indication indicates that the present invention is used. Any or all of these aspects may be indicated in the security indication itself, for example, the size of the truncated MAC or an algorithm for calculating the truncated MAC. These may also be known to higher layers in the communication system.

When calculating truncated MACs or MICs over several messages, these messages should preferably all be destined for the same receiver(s) from the same sender.

The exemplary manner in which the invention may be used with the previously mentioned indications of the use of the invention in messages is as follows. In addition to the message numbering bit pattern, embodiments may use an indication of whether the MAC in the message is truncated. This indication may be referred to as a MAC truncated bit pattern, in this example a 1 bit pattern. This has the advantage that messages with truncated MACs and messages with normal size MACs can be used in the same communication system.

In addition to indicating whether a message uses a truncated MAC or as an alternative to a 1-bit indication of a message with or without a truncated MAC, a MAC truncated bit pattern can be used to indicate how many bits the MAC or MIC is truncated, e.g., to 8 bits. The MAC truncated bit pattern may also show how many bits were obtained from a normal MAC or MIC, so an indication of 0 means that a normal, untruncated MAC or MIC is used. The use of a multi-bit MAC puncturing pattern has the advantage of flexibility in reducing the size of the message.

In a simple embodiment, a 1-bit MAC truncated bit pattern "T" bit and a 1-bit message numbering 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 a combination of "T" bits and "N" bits of (1, 0) and (1, 1) have reduced overhead. Messages using the "T" bit and "N" bit combination of (0, 0) use the complete MAC or MIC and do not use previous messages for the MAC or MIC, so (0, 0) is effectively a known integrity protection. The advantage of having such a 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 combination of "T" bits and "N" bits of (1, 1) can end with a message with a combination of "T" bits and "N" bits of (0, 1), so the last (1, 1) series of messages used to calculate the MAC or MIC of a message with a combination of (0, 1) now immediately gets complete MAC integrity protection. This is advantageous when the transmitter wants to switch to legacy integrity protection using the combination (0, 0) and providing complete integrity protection for all messages.

Drawings

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

Fig. 1 shows a communication system with 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 invention;

FIG. 2 illustrates a method of transmitting a message and an associated message authentication code according to an embodiment of the invention;

FIG. 3 illustrates a method for receiving a message and an associated message authentication code and for authenticating the received message according to an embodiment of the invention;

FIG. 4a shows a computer-readable medium, and

Fig. 4b shows a processor system in a schematic representation.

The figures are purely diagrammatic and not drawn to scale. In the drawings, elements corresponding to elements already described may have the same reference numerals.

Detailed Description

Fig. 1 shows two devices for communication in a network, one device being adapted to transmit a message using a truncated MAC and the other device being adapted to receive a message having a truncated MAC.

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

The communication protocol defines messages on a link between the two devices, or between two applications running on the processors 113, 123 of the devices, or between an application running on the processor 123 and the processor (not shown in the figures) 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).

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 transmitted over a link to device 110.

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

Truncated MAC generator 122 is further arranged to store the previously sent message in message memory 125 and retrieve the previously sent message from message memory 125 for use in calculating the truncated MAC.

Transceiver 121 obtains a truncated MAC for each message sent by transceiver 121 from truncated MAC generator 122.

Also, the 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 for managing messages transmitted over a link to the device 110.

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

Truncated MAC generator 112 is further arranged to store previously received messages in message memory 115 and to retrieve previously received messages from message memory 115 for use in calculating a truncated MAC.

Transceiver 111 obtains a truncated MAC for each message received by transceiver 111 from truncated MAC generator 112 so that transceiver 111 can perform the integrity protection provided by the truncated MAC by comparing the truncated MAC obtained from the truncated MAC from truncated MAC generator 112 with the truncated MAC in the received message. Alternatively, the processor 113 or truncated MAC generator 112 performs such comparison.

In practice, the communication protocol may be any wireless communication protocol, e.g., any cellular network protocol defined by, e.g., 3GPP, which may be Wi-Fi, bluetooth, zigBee, any IoT wireless communication protocol (e.g., loRa, narrowband IoT (NB-IoT), LTECat1, LTECat0, LTECatM1 (eMTC), LTECatNB1, etc.). The communication protocol may also be any wired communication protocol (e.g., ethernet).

In practice, the device 110 may be a cellular network base station (eNodeB, E-UTRAN node B (also referred to as evolved node B)), wi-Fi Access Point (AP), wi-Fi point-to-point device, bluetooth device, zigBee device, ioT device using IoT wireless communication protocols, and so on. The device 120 may be any device that sends a message to the device 110, e.g., any IoT device that uses the aforementioned communication protocols. Of course, device 120 may also be any of the devices mentioned for device 110, and device 110 may then be any of the devices mentioned for device 120, wherein device 120 sends a message to device 110.

In an embodiment, device 120 creates a first message for transmission 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 numbering bit pattern may be part of the message header but may also be part of the message body. The bit pattern can be only 1 bit, where, for example, "0" indicates that it is the first message and "1" indicates that it is the next message. The next message is any message that is not the first message after the first message.

The message numbering bit pattern can also indicate a number indicating how much of the previously sent message has been used in calculating the truncated MAC for that message. For example, if the truncated MAC is 8 bits in length, a bit pattern of 5 bits can indicate that a maximum of 31 previously sent messages have been included in calculating the truncated MAC for the current message. With these numbers, after 31 messages are sent again after the first message, the effective MAC size for the first message is 32×8=256 bits, which is equivalent to the protection strength of HMAC-SHA 256. Preferably, the message numbering bit pattern is included in the message bits to be integrity protected.

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

Truncated MAC generator 122 gathers all bits of the first message to be integrity protected and uses those bits as input to a MAC algorithm (e.g., HMAC-SHA 256). The entire 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 message memory 125, which may or may not include the truncated MAC calculated for that message by the truncated MAC generator. The key for MAC generation is provided by processor 123 to truncated MAC generator 122. Key distribution is well known and can be done, for example, during factory installation, or can be sent to the device 120 using secure messages over the communication 130.

Truncated MAC generator 122 truncates the calculated MAC to 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, while for HMAC-SHA256, the size of the MAC is 256 bits.

Truncated MAC generator 122 provides the truncated MAC to 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, transceiver 121 sends the message to device 110 using communication 130.

In case the next message is to be sent, the processor 123 creates a new message based on content, e.g. from the message content generator 124, and sends it to the transceiver 121 for transmission over the communication network. Processor 123 also creates and sends to transceiver 121 a message number bit pattern as described above that indicates the next message. Alternatively, the transceiver 121 creates the message number bit pattern itself. The truncated MAC generator 122 also needs to know this bit pattern.

For the next message, truncated MAC generator 122 gathers not only all bits of the next message to be integrity protected, but also gathers bits of a plurality of previously sent messages that need to be integrity protected, which may or may not include truncated MACs of previously sent messages. All of these bits are now used as inputs for the MAC algorithm (e.g., HMAC-SHA 256). This can be done by simply appending the bits one after the other. Similar to what the truncated MAC generator 122 did for the first message, the truncated MAC generator 122 stores the next message in its entirety or at least the bits of the next message to be integrity protected, which may or may not include the truncated MAC, in the message memory 125.

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 numbering bit pattern is preferably greater than 1, but only one bit may be used, in which case only the last transmitted message is included in the truncated MAC calculation.

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 certain number of previously sent messages having the maximum value. This maximum 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 (https:// 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, then the two messages previously sent (the first message and the first message after the first message) will be included in the truncated MAC calculation. For example, if this maximum is 31 and the next message is the 32 nd message to be sent after the first message, then the previously sent 31 messages are included in the truncated MAC calculation, so all messages after the first message are included in the truncated MAC calculation. The message store 125 need not store more than this maximum number of messages. 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 truncated MAC calculation. In this case, the device 120 should decide to send the message as the first message from time to time, whereby the amount of input for MAC calculation and the amount to be stored in the message memory 125 do not become too large. In all these cases, the message numbering bit pattern can be just one bit, as explained above.

The decision to send the message as the first message may be done, for example, as a reaction to the message from the device 110. If device 110 loses or does not receive or erroneously receives one or more previously sent messages, device 110 may want to do so.

The rest of the flow for the next message is similar to the flow for the first message. Truncated MAC generator 122 truncates the calculated MAC to 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, while for HMAC-SHA256, the size of the MAC is 256 bits. Truncated MAC generator 122 provides the truncated MAC to 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, transceiver 121 sends the message to device 110 using communication 130

In an embodiment, device 110 receives a message from device 110 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, then device 120 also does. Both devices need to use the same maximum of the number of previously sent messages to be included in the calculation of the truncated MAC.

Transceiver 111 provides at least the bits to be integrity protected from the message, the truncated MAC from the received message, and the message numbering bit pattern in the received message to truncated MAC generator 112. Truncated MAC generator 112 stores the complete received message, or at least the bits of the received message, in message memory 115 to be used in truncated MAC calculations for subsequent messages.

If the message number bit pattern indicates that it is the first message, truncated MAC generator 112 uses all bits of the first message to be integrity protected as input to a MAC algorithm (e.g., HMAC-SHA 256).

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

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 numbering bit pattern, which may be up to and including all previously received messages of the first message of a certain number of previously transmitted messages indicated as having a maximum value, wherein the maximum value is the maximum value as described above. The message memory 115 need not store more messages than this maximum.

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

Truncated MAC generator 112 truncates the calculated MAC to 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, while for HMAC-SHA256, the size of the MAC is 256 bits.

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 truncated MAC calculations 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 the message, which serves as a measure of trustworthiness. Other measures of trustworthiness may also be used, such as the probability that a message is forged if an attacker uses a random truncated MAC. If the two values are different, the received message, and all previously received messages used in truncated MAC calculations, will always be indicated as problematic, which will override any previously set "OK" states.

Alternatively, transceiver 111 or processor 113 may perform comparison and result processing on truncated MACs.

Fig. 2 illustrates a method of transmitting a message and an associated message authentication code according to an embodiment of the present invention. The method starts 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 message authentication code as previously described is performed. In step 507, a truncated MAC code is appended to the message for transmission and the method moves to the next block/next message.

Fig. 3 illustrates a method of receiving a message and an associated message authentication code to authenticate the received message according to an embodiment of the invention. The method starts 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 message authentication code previously described is performed. In steps 606 and 607, the calculated truncated code is compared to the received truncated code. If both are the same, authentication is given to both the current message and the previous message 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 last piece of information is authenticated.

While various embodiments of the present invention are described above in terms of how messages are protected, we will hereinafter discuss details of how embodiments of the present invention are used in various data transfer standards, including, for example, 3GPP, wiFi, and bluetooth.

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

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

If the previously sent Wi-Fi MAC packet needs to be used to calculate a truncated MIC, then all bits used to calculate the conventional MIC of the previous Wi-Fi MAC packet are prepended (or appended) to those bits of the current Wi-Fi MAC packet used to calculate the conventional MIC, and the conventional algorithm of CCMP MIC calculation is used, but now with longer inputs. 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.

Wi-Fi frames used in 802.11ad (Wigig or 60GHz Wi-Fi, or directed Multi-gigabits (DMG), see [802.11 ]) typically use the GCM protocol (GCMP, [ 12.5.5 th section 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 the truncated MIC). Since the original GCMP MIC is 16 octets in size, the present invention enables a substantial reduction.

The cellular communication protocol is specified by 3GPP (http:// www.3gpp.org /) (e.g., LTE, 4g, and 5g Mobile communication Specifications).

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

The packet header compression technique can be based on IP header compression [ RFC2507] or Robust header compression (RFC 3095 or updated [ RFC5795 ]).

The integrity protection of PDCP packets is configured by upper layers using the integrity protection method specified in [33.501], as specified in [38.331 ].

Similar to the above, the present invention can be used for integrity protection of PDCP packets. The use of the present invention and some general parameters (e.g., the algorithm used 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 numbering bit pattern. Section 6.2.2 of [38.323] specifies a PDCP header for a data PDU (protocol data unit). There are at least three reserved bits in octet 1 of the different types of data PDUs. The difference between them is the size of the PDCP Sequence Number (SN). In current 3GPP specifications, the control PDU is not integrity protected. However, their PDCP headers have four reserved bits (see section 6.2.3 of [38.323 ]) that can be used to indicate the purpose of the present invention and carry a message numbering bit pattern.

If the PDCP packet is the first message to use a truncated MIC, then the MIC is calculated on the bits of the message as specified in section 5.9 of [38.323] and is configured by the upper layer 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.

If it is desired to calculate a truncated MIC using a previously transmitted PDCP packet, all bits of the conventional MIC for conventionally calculating the previous PDCP packet are prepended (or appended) to the bits of the current PDCP packet for conventionally calculating the conventional MIC, and a conventional algorithm of DPCP MIC calculation is used, but now has a longer input. MIC results are 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.

PDCP uses Radio Link Control (RLC) to transmit PDCP packets. RLC is responsible for segmentation/concatenation, retransmission processing, duplicate detection and sequential delivery to higher layers. RLC uses RLC packets with RLC header and payload. The payload is used for (part of) transmitting PDCP packets. No ciphering protection is currently specified for RLC packets. Nevertheless, the invention can also be used as described above. The application of the present invention to RLC may imply that a new key needs to be established between the sender and the receiver(s).

RLC uses Medium Access Control (MAC) packets to transmit RLC packets. The MAC packet also has a header and a payload, which is used to transmit the RLC packet. Multiplexing of media access control processing logic channels, hybrid ARQ retransmissions, and scheduling for uplink and downlink in 3GPP systems. No encryption protection is currently specified for the MAC packet. Nevertheless, the invention can also be used as described above. The application of the present invention to the MAC layer may imply that a new key needs to be established between the sender and the receiver(s).

Bluetooth LE is specified in specification volume 6 of btv 5.0.

Bluetooth LE packets on the link layer are called Protocol Data Units (PDUs). Other bluetooth variants are similar to those described herein. Bluetooth (LE) PDUs have a 16-bit header, payload, and may have a MIC. Bluetooth LE PDUs are carried in link layer packets. The link layer packet contains a 32-bit access address that is used to specify the existing link between two particular 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 indicating whether the payload contains data (data PDU) or control information (control PDU). The PDU header does not indicate whether the payload is encrypted or whether there is a MIC. But is now indicated by a particular control PDU. The control PDU packet contains an operation code (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 the MIC, as both are always used together or not used 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 numbering bit pattern, a signal opcode for starting encryption and using a truncated MIC, which signal opcode 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). Conventional "PAUSE ciphering" (ll_pause_enc_req) may be used as an indication that the next data PDU with the same access address is no longer ciphered and no longer contains a truncated MIC.

If the data PDU is the first message to use a truncated MIC, the MIC is calculated as specified by the Bluetooth specification, and the normal MIC of 32 bits 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.

If a previously transmitted data PDU is required for calculating a truncated MIC, all bits for calculating a conventional MIC of the previous message are prepended (or appended) to the bits for calculating a conventional MIC of the current message, and a conventional algorithm of bluetooth MIC calculation (CCM) is used, but now has a longer input. MIC results are 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.

The truncated MIC computation can use the same MIC algorithm and the same key as specified in the bluetooth specification, but of course other MIC algorithms and other keys can be defined as well.

Different versions of the bluetooth specification use the same partitioning in the data PDU and the control PDU, but the addressing may be different and the security algorithm may be different. However, the invention can be used in a similar manner for other bluetooth versions as well.

LoRaWAN has been specified in [ LoRaWAN ]. LoRaWAN is a network protocol that is optimized for battery-powered terminal devices that may be mobile or installed at a fixed location. LoRaWAN networks are typically laid out in a star-pile topology, where a gateway relays messages between terminal devices and a central network server, which routes data packets from each device of the network to an associated application server. To protect the radio transmissions, the lorewan protocol relies on symmetric encryption using a session key derived from the root key of the device. At the backend, the storage of the root key of the device and the associated key derivation operations is guaranteed by the joining server.

The lowest layer of communication in the LoRaWAN network is the radio PHY layer, where uplink 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 a LoRaWAN is to use one of three values reserved for future use of the value of the 2-bit main field of the MHDR to indicate that the present invention is used. If the primary field indicates that the present invention is used, this also means that the MHDR is extended with one or more bits for the message numbering bit pattern, as explained below. In addition, the MHDR may be extended with one or two bits indicating the length of the truncated MIC. Alternatively, two of the three unused values of the primary field can be used, one value indicating use of the invention and the MAC packet is the first message and another value can be used to indicate use of the invention and the MAC packet is the next message.

Similar to what is described above, e.g., for bluetooth, when a MAC packet is indicated as the first message, the MIC can be calculated as specified by the lorewan specification using the same key and algorithm. However, instead of appending a conventionally calculated MIC, the MIC is truncated to, for example, 8 bits and the truncated MIC is appended after MACPayload.

Similar to what is described above, for example for bluetooth, if a previously sent MAC packet is needed to calculate a truncated MIC, then all bits of the conventional MIC for conventionally calculating the previous MAC message are prepended (or appended) to the bits of the current MAC message for conventionally calculating the conventional MIC, and the conventional algorithm of the lorewan MIC calculation is used, but now with longer inputs. MIC results are truncated to, for example, 8 bits and appended after MACPayload.

Fig. 4a shows a computer-readable medium 1000 having a writable portion 1010 including a computer program 1020, the computer program 1020 including instructions for causing a processor system to perform one or more of the methods and processes described above in the system described with reference to fig. 1-3. The computer program 1020 may be embodied on the computer readable medium 1000 as physical markers or by means of magnetization of the computer readable medium 1000. However, any other suitable embodiment is also conceivable. Furthermore, it will be appreciated that although computer-readable medium 1000 is illustrated herein as an optical disk, computer-readable medium 1000 may be any suitable computer-readable medium (e.g., hard disk, solid state memory, flash memory, etc.) and may be non-recordable or recordable. The computer program 1020 includes instructions for causing a processor system to perform the method.

Fig. 4b shows in schematic representation a processor system 1100 according to an embodiment of the apparatus or method described with reference to fig. 1-3. The processor system may include circuitry 1110 (e.g., one or more integrated circuits). The architecture of the circuit 1110 is schematically shown in this figure. The circuit 1110 comprises a processing unit 1120 (e.g. a CPU) for running computer program means to perform the methods according to the embodiments and/or to implement modules or units thereof. The circuit 1110 includes a memory 1122 for storing programmed code, data, etc. Portions of 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, etc.). Circuitry 1110 may include application specific integrated circuit 1124 for performing some or all of the processing defined in the method. The processor 1120, the memory 1122, the application-specific IC 1124 and the communication element 1126 may be connected to each other via an interconnect 1130 (e.g., bus). The processor system 1110 may be arranged for wired and/or wireless communication using connectors and/or antennas, respectively.

Alternatively, a device may be implemented in whole or in part in the form of programmable logic, e.g., as a Field Programmable Gate Array (FPGA). The devices and servers may be implemented in whole or in part as so-called Application Specific Integrated Circuits (ASICs), i.e., integrated Circuits (ICs) tailored for their specific use. For example, the circuitry may be implemented in CMOS, e.g., using hardware description language (e.g., verilog, VHDL, etc.).

It will be appreciated that for clarity, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be appreciated that any suitable distribution of functionality between different functional units or processors may be used without detracting from the invention. For example, functions illustrated as being performed by separate units, processors, or controllers may be performed by the same processor or controller. Thus, references to specific functional units are only to be seen as references to suitable units for providing the described functionality rather than indicative of a strict logical or physical structure or organization. The invention can be implemented in any suitable form including hardware, software, firmware or any combination of these.

It should be noted that in this document the verb "to comprise" does not exclude the presence of elements or steps other than those listed and the word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Expressions such as "at least one of the elements" when in front of a list of elements mean that all elements or any subset of elements is selected from the list. For example, the expression "at least one of A, B and C" should be understood to include a only, B only, C only, both a and B, both a and C, both B and C, or all A, B and C. Any reference signs do not limit the scope of the claims. The present invention may be implemented by either or both of hardware and software. Furthermore, the invention is not limited to the embodiments, and the invention lies in each and every novel feature or combination of features described above or in mutually different dependent claims.

In summary, the present application relates to the following references:

[33.501] third Generation partnership project, technical Specification group services and System aspects, security architecture and flow for 5G systems (15 th edition) );3GPP TS 33.501V15.2.0(2018-09);http://www.3gpp.org/ftp//Specs/archive/33_series/33.501/33501-f20.zip

[38.323] Third Generation partnership project, technical Specification group radio Access network, NR, packet Data Convergence Protocol (PDCP) Specification (15 th edition );3GPP TS 38.323V15.3.0(2018-09),http://www.3gpp.org/ftp//Specs/archive/38_series/38.323/38323-f30.zip

[38.331] Third Generation partnership project, technical Specification group radio Access network, NR, radio Resource Control (RRC) protocol Specification (15 th edition );3GPP TS 38.331V15.3.0(2018-09),http://www.3gpp.org/ftp//Specs/archive/38_series/38.331/38331-f30.zip

[802.11] IEEE computer Association ,"IEEE Standard for Information Technology–Telecommunications and Information Exchange Between Systems–Local and Metropolitan Area Networks–Specific requirements Part 11:Wireless LAN Medium Access Control(MAC)and Physical Layer(PHY)Specifications"(IEEE Standard 802.11-2016), month 12 of 2016

[ BTv5.0] Bluetooth core Specification ,v5.0,https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashxdoc_id＝421043&_ga＝2.98314335.1543434637.1541687761-711838716871

[ LoRaWAN ] LoRaWAN ^TM 1.1.1 Specification, written by the LoRa alliance technical Committee, https:// LoRa-alliance. Org/resource-hub/lorawantm-specification-v11

[ RFC2507] "IP Header Compression",1999, month 2, https:// datatracker.ietf org/doc/RFC2507 ]

[ RFC2104] "HMAC: keyed-Hashing for Message Authentication", month 2 1997, https:// datatracker.ietf.org/doc/RFC2104 ]

[ RFC4868] "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512with IPsec", month 5 of 2007, https:// datatracker:// ietf org/doc/RFC4868 ]

[ RFC5795] "The RObust Header Compression (ROHC) Framework", month 3 2010, https:// datatracker.ietf org/doc/RFC5795 ]

Claims

1. A method of authenticating messages exchanged over a network between a transmitter and a receiver,

The method comprises the following steps:

On the transmitter side, in order to transmit a message,

-Generating a truncated Message Authentication Code (MAC) by selecting or generating a predetermined bit from a MAC, the MAC being calculated on a concatenation of a predetermined portion of the message with at least one predetermined portion of a previously transmitted message;

Wherein the bit length of the truncated MAC code is smaller than the bit length of the Message Authentication Code (MAC), -attaching the truncated MAC code to the message for transmission;

At the receiver side, in order to authenticate the message,

-Receiving a previously transmitted message, said message and said truncated MAC code;

-generating an expected truncated Message Authentication Code (MAC) by selecting or generating a predetermined bit from a MAC, the MAC being calculated on a concatenation of a predetermined portion of the message with 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 of claim 1, wherein, for a transmitted first message, the Message Authentication Code (MAC) is calculated on a predetermined portion of the first message without concatenating with at least one predetermined portion of a previously transmitted message.

3. The method of claim 2, wherein the Message Authentication Code (MAC) is calculated on either of two following depending on which sequence is shorter:

Concatenation of a predetermined portion of said message with a sequence of a second predetermined number of portions of a previously transmitted message, or

A concatenation of the predetermined portion of the message with a sequence of predetermined portions of each preceding message starting from the transmitted first message.

4. A method according to claim 2 or 3, wherein the message is provided with at least one of:

-a first identifier identifying that the Message Authentication Code (MAC) is calculated on a predetermined portion of a first message without concatenating with at least one predetermined portion of a previously transmitted message;

-a second identifier identifying that the Message Authentication Code (MAC) is calculated on a concatenation of a predetermined portion of the message with at least one predetermined portion of a previously transmitted message.

5. The method of claims 1 to 4, wherein the message is provided with at least one of:

-a third identifier identifying that the Message Authentication Code (MAC) is truncated;

-a fourth identifier identifying that the Message Authentication Code (MAC) is truncated to n bits.

6. The method of claims 1 to 4, wherein the message is provided with at least one of:

-a fourth identifier identifying that the Message Authentication Code (MAC) is not truncated.

7. A method according to claim 3, wherein, at the receiver side, for authenticating the message,

-If the received truncated MAC code is different from the expected truncated MAC code, not giving authentication to the message and the previously transmitted message, overriding authentication to the previously transmitted message.

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

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

10. A method of transmitting a message and an authentication code by a transmitter over a network, the method comprising:

wherein the truncated MAC code has a bit length less than a 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 comprising a truncated MAC code calculated by selecting or generating a predetermined bit 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 transmitted message, wherein the bit length of the truncated MAC code is smaller than the bit length of the Message Authentication Code (MAC),

The method comprises the following steps:

12. The method of claim 11, wherein for a received first message that is a transmitted first message, wherein the Message Authentication Code (MAC) is calculated over a predetermined portion of the first message without concatenating with at least one predetermined portion of a previously transmitted message,

The method comprises the following steps:

An expected truncated Message Authentication Code (MAC) is generated by selecting or generating a pre-determined bit from a MAC, the MAC being calculated on the first message without concatenating with at least one predetermined portion of a previously transmitted message.

13. The method according to claim 11 or 12, wherein the message is provided with either of:

a first identifier identifying that the Message Authentication Code (MAC) is calculated on a predetermined portion of the first message without concatenating 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 with at least one predetermined portion of a previously transmitted message;

The method comprises the following steps:

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 conveyor includes:

-an antenna and a transceiver for transmitting a message;

-a processor coupled to the antenna and the transceiver, the processor for controlling the transmission and generation of a Message Authentication Code (MAC);

the processor is adapted to perform the method of claim 10.

15. A receiver for receiving a short message and a corresponding message authentication code over a network,

The receiver includes:

-an antenna and a transceiver for receiving a message comprising a Message Authentication Code (MAC);

-a processor coupled to the antenna and the transceiver, the processor for controlling the reception and generation of a Message Authentication Code (MAC);

The processor is adapted to perform the method according to claims 11 to 13.