Patent Description:
Protecting the integrity and confidentiality of data transmission may be desired in communication systems. For example, different authentication methods may be applied to ensure that data has been received from an authenticated user. Furthermore, encryption may be applied to prevent third parties from reading data intended to a particular user. Data packets may indicate an identifier of the data source. In cryptography, a message authentication code (MAC) may refer to a field of information, which may be used at a receiver to ensure that the received data packet has really originated from the indicated data source.

<CIT> discloses a method for determining a terminal ID from a message received from a terminal in a communication system that avoids sending the terminal ID in the clear. In this system each terminal ID has an associated encryption key. A transmitted message comprises at least a Message Authentication Code (MAC), a n-bit hash, and encrypted message text. At least the terminal key and a nonce is used to generate the MAC, and neither the terminal ID nor the terminal key are included in the transmitted message. An authentication broker stores the set of all (terminal ID, terminal key) pairs for the plurality of terminals in the communication system. The set of all terminal keys is grouped into at least two partitions, and on receipt of a message the authentication broker identifies the partition that includes the terminal key of the terminal that transmitted the received message using the n-bit hash (the search partition). The authentication broker then searches the search partition for the terminal key that authenticates the MAC to identify the terminal ID. In some examples, this involves testing each terminal key in the search partition to determine if it authenticates the MAC, and if a terminal key is found that authenticates the MAC, then the terminal ID can be identified using knowledge of the (terminal key, terminal ID) pairings.

<NPL>) discloses in section <NUM> considerations and improvements regarding the usage of temporary RAN identifiers for user equipment.

<CIT> discloses techniques to improve secure user authentications in Bluetooth Low Energy communications.

It is an objective of the present disclosure to provide joint identification and authentication of data sources with reduced transmission overhead. The foregoing and other objectives may be achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description, and the drawings.

According to a first aspect, a device for generating a data packet is disclosed. The device is configured to: obtain payload data associated with a data source; compute a message authentication code based on a unique key of the data source and the payload data, wherein the unique key of the data source is unique within a plurality of data sources; obtain an auxiliary identifier for the data source, wherein a size of the auxiliary identifier is smaller than a size of an identifier of the data source, wherein the auxiliary identifier is ambiguous within the plurality of data sources and the identifier of the data source is unambiguous within the plurality of data sources; determine a checksum based on the payload data, the message authentication code, and the auxiliary identifier, wherein determining the checksum based on the payload data, the message authentication code, and the auxiliary identifier comprises performing an exclusive-or operation for the checksum with the auxiliary identifier; and generate the data packet, wherein the data packet comprises the payload data, the message authentication code, and the checksum and wherein the data packet does not include an explicit identifier of the data source. This solution enables identification and authentication of data sources with reduced transmission overhead.

According to an implementation form of the first aspect, the device is configured to perform an exclusive-or operation for the checksum with the auxiliary identifier. This solution enables to scramble the auxiliary identifier, thereby improving security. According to an implementation form of the first aspect, the device may be further configured to determine the auxiliary identifier as a function of the identifier of the data source. This solution enables auxiliary identifiers to be determined locally at a transmitter and thereby to reduce the required amount of memory, since preconfiguration of auxiliary identifiers at the transmitter may be avoided.

According to an implementation form of the first aspect, the auxiliary identifier may comprise a subset of bits of the identifier of the data source. This solution enables to determine the auxiliary identifier with low complexity. According to an implementation form of the first aspect, the identifier of the data source is unambiguous within a plurality of data sources. This solution enables each data source to be unambiguously identified.

According to an implementation form of the first aspect, the auxiliary identifier is ambiguous within the plurality of data sources. This solution enables reduced transmission overhead with moderate complexity at a receiver. According to an implementation form of the first aspect, the device may be further configured to compute the message authentication code further based on the identifier of the data source. This solution improves security of data source identification and authentication.

According to an implementation form of the first aspect, the device may be further configured to receive a cryptographic nonce. The device may be configured to compute the message authentication code further based on the cryptographic nonce. This solution improves security of data source identification and authentication.

According to a second aspect, a device for identifying a data source is provided. The device is configured to: receive a data packet associated with a data source, wherein the data packet comprises payload data, a message authentication code and a checksum; determine an auxiliary identifier for the data source based on the checksum of the data packet, wherein a size of the auxiliary identifier is smaller than a size of an identifier of the data source, wherein the auxiliary identifier is ambiguous within a plurality of data sources and the identifier of the data source is unambiguous within the plurality of data sources; determine a plurality of candidate data sources as a subset of a plurality of data sources, wherein the subset of the plurality of data sources is associated with the auxiliary identifier; compute a plurality of candidate message authentication codes based on the payload data and a plurality of unique keys associated with the plurality of candidate data sources; and determine the identifier of the data source based on detecting a match between the message authentication code and one candidate message authentication code of the plurality of candidate message authentication codes. This solution enables identification and authentication of the data source with reduced transmission overhead.

According to an implementation form of the second aspect, the data packet further comprises a checksum and the device may be further configured to determine the auxiliary identifier for the data source based on the checksum of the data packet, wherein a size of the auxiliary identifier is smaller than a size of the identifier of the data source; and determine the plurality of candidate data sources as a subset of a plurality of data sources, wherein the subset of the plurality of data sources is associated with the auxiliary identifier. This solution enables identification and authentication of the data source with reduced transmission overhead and moderate complexity at a receiver due to a limited subset of candidate data sources.

According to an implementation form of the second aspect, the device may be further configured to compute an auxiliary checksum based on the payload data and the message authentication code; and determine the auxiliary identifier based on an exclusive-or operation between the checksum of the data packet and the auxiliary checksum. This solution enables a receiver to determine the subset of candidate data sources and thereby to reduce complexity at the receiver.

According to an implementation form of the second aspect, the auxiliary identifier may comprise a subset of bits of the identifier of the data source. This solution enables to determine the auxiliary identifier with low complexity. According to an implementation form of the second aspect, the identifier of the data source is unambiguous within the plurality of data sources. This solution enables each data source to be unambiguously identified.

According to an implementation form of the second aspect, the auxiliary identifier is ambiguous within the plurality of data sources. This solution enables reduced transmission overhead with moderate complexity at a receiver, since the auxiliary identifier identifies a subset of data sources.

According to an implementation form of the second aspect, the device may be further configured to determine a plurality of auxiliary identifiers for the plurality of data sources as a function of identifiers of the plurality of data sources. This solution enables auxiliary identifiers to be determined locally at a receiver and thereby to reduce the required amount of memory, since preconfiguration of auxiliary identifiers at the receiver may be avoided. According to an implementation form of the second aspect, the device may be further configured to compute the plurality of candidate message authentication codes further based on identifiers of the plurality of candidate data sources. This solution improves security of data source identification and authentication.

According to an implementation form of the second aspect, the device may be further configured to compute the plurality of candidate message authentication codes further based on a cryptographic nonce. This solution improves security of data source identification and authentication.

According to a third aspect, a method for generating a data packet is provided. The method comprises obtaining payload data associated with a data source; computing a message authentication code based on a unique key of the data source and the payload data, wherein the unique key of the data source is unique within a plurality of data sources; obtaining an auxiliary identifier for the data source, wherein a size of the auxiliary identifier is smaller than a size of an identifier of the data source, wherein the auxiliary identifier is ambiguous within the plurality of data sources and the identifier of the data source is unambiguous within the plurality of data sources; determining a checksum based on the payload data, the message authentication code, and the auxiliary identifier, wherein determining the checksum based on the payload data, the message authentication code, and the auxiliary identifier comprises performing an exclusive-or operation for the checksum with the auxiliary identifier; and generating the data packet, wherein the data packet comprises the payload data, the message authentication code, and the checksum and wherein the data packet does not include an explicit identifier of the data source. This solution enables identification and authentication of the data source with reduced transmission overhead.

According to a fourth aspect, a method for identifying a data source is provided. The method comprises receiving a data packet associated with a data source, wherein the data packet comprises payload data, a message authentication code and a checksum; determining an auxiliary identifier for the data source based on the checksum of the data packet, wherein a size of the auxiliary identifier is smaller than a size of an identifier of the data source, wherein the auxiliary identifier is ambiguous within a plurality of data sources and the identifier of the data source is unambiguous within the plurality of data sources; determining a plurality of candidate data sources as a subset of a plurality of data sources, wherein the subset of the plurality of data sources is associated with the auxiliary identifier; computing a plurality of candidate message authentication codes based on the payload data and a plurality of unique keys associated with the plurality of candidate data sources; and determining the identifier of the data source based on detecting a match between the message authentication code and one candidate message authentication code of the plurality of candidate message authentication codes. This solution enables identification and authentication of the data source with reduced transmission overhead.

According to a fifth aspect, a computer program is provided. The computer program may comprise program code configured to cause performance of any implementation form of the method of the third aspect, when the computer program is executed on a computer.

According to a sixth aspect, a computer program is provided. The computer program may comprise program code configured to cause performance of any implementation form of the method of the fourth aspect, when the computer program is executed on a computer.

Implementation forms of the present disclosure can thus provide devices, methods, and computer programs for generating or receiving a chirp waveform. These and other aspects of the present disclosure will be apparent from the example embodiment(s) described below.

The accompanying drawings, which are included to provide a further understanding of the example embodiments and constitute a part of this specification, illustrate example embodiments and, together with the description, help to explain the example embodiments. In the drawings:.

Reference will now be made in detail to example embodiments, examples of which are illustrated in the accompanying drawings. The detailed description provided below in connection with the appended drawings is intended as a description of the present embodiments and is not intended to represent the only forms in which the present examples may be constructed or utilized. The description sets forth the functions of the examples and the sequence of operations for constructing and operating the examples. However, the same or equivalent functions and sequences may be accomplished by different examples.

Unsourced random access provides a framework for modelling and analyzing massive and uncoordinated random access technologies as applied for example in massive internet-of-things (IoT) communications. In an unsourced random access framework, users may use the same modulation codebook, which may cover both pilot and data symbols. Therefore, it may not be possible to distinguish one user from another at the physical (PHY) layer. This is in contrast to systems where users use the same constellation, for example a quadrature amplitude modulation (QAM) constellation, but can be distinguished via their user-specific pilot sequences. In some systems, a multi-user decoder may output the received data packets up to a permutation between active users and a user identifier (ID) may be included in the data payload to resolve the lack of ID at the PHY layer.

Accordingly, unsourced random access schemes may lack the possibility of identifying the transmitting users. Embodiments disclosed herein provide several methods for identifying and authenticating data sources, for example users or nodes. The disclosed embodiments provide joint identification and authentication protocols, which are based on the message authentication code (MAC) field instead of an explicit data source identifier field, for example an explicit address field. The MAC field may be unique for each data source, since it may be generated from a unique private key. As a result, an address field that includes an explicit identifier for the data source is not required anymore. Additionally, the disclosed methods provide the advantage of decreasing the overhead caused by explicit data source identifiers in packet headers. This advantage can be obtained without a need for protocols designed specifically for the unsourced random access scenario. Furthermore, the disclosed methods can provide better performance for short data packets also in a point-to-point scenario.

According to an embodiment, payload data may be obtained for transmission. The payload data may be associated with a data source. A message authentication code may be computed based on a unique key of the data source and the payload data. Furthermore, an auxiliary identifier for the data source may be obtained. The auxiliary identifier may be of shorter size than an identifier of the data source. Upon receipt, a set of candidate message authentication codes may be computed based on the payload data and unique keys associated with a set of candidate data sources and the data source may be identified based on a match between the received message authentication code and one of the candidate message authentication codes. Furthermore, the match may be detected based on searching within a subset of candidate data sources identified by the auxiliary identifier.

<FIG> illustrates an example of a communication system <NUM> comprising a node <NUM> and a base station <NUM>. The communication system <NUM> may further comprise one or more other nodes <NUM>, <NUM>. Base station <NUM> may therefore communicate with a plurality of nodes. Node <NUM> is provided as an example of a device that generates authenticated data packets. Node <NUM> may operate as a data source. Node <NUM> may comprise a transmitter for transmitting the authenticated data packets to base station <NUM>. Node <NUM> may comprise an internet-of-things (IoT) device such as, for example, a tag, a sensor, a tracker, a wearable device, a smart home appliance, an autonomous vehicle, or the like. Alternatively, or additionally, node <NUM> may comprise a user equipment (UE) such as, for example, a mobile phone, a smart phone, a smart watch, a tablet, a laptop, or the like.

Base station <NUM> is provided as an example of a receiver that identifies the data source. The base station <NUM> may also confirm authenticity of the received data packets. Base station <NUM> may comprise an access point of a radio access network (RAN) such as, for example, a <NUM>, <NUM>, or <NUM> cellular communication network or a wireless local are network (WLAN). Nodes <NUM>, <NUM>, <NUM> and base station <NUM> may be configured to operate based on a standard, for example, one or more machine type communication (MTC) functions of the <NUM>rd Generation Partnership Project (3GPP) <NUM> New Radio (NR) standard. Base station <NUM> may therefore comprise a <NUM>th generation base station (gNB). It is however noted that the embodiments of the present disclosure may be applied in data communications between various type of devices, for example, over a direct radio interface between nodes <NUM>, <NUM>, <NUM>, or other devices. Embodiments may be applied also in wired data communications.

In a massive multiple access scenario, a large number of nodes may transmit small packets to the base station <NUM>. In general, a receiver may perform data source identification, authentication, and/or encryption. While encryption may not introduce additional overhead, identification and authentication may involve transmission of additional bits together with information bits (payload data). This may result in an enormous overhead in case of short packets with small data payloads, as envisioned in the considered massive multiple access scenario. Therefore, it may be desirable to reduce the overhead caused by data source identification and/or authentication.

Even though some embodiments have been described using a node as an example of a data source, it is appreciated that embodiments may be generalized to communication systems, where a node comprises more than one data source or is associated with one or more external data sources. For example, a node could provide packet generation services for a plurality of data sources. A data source may comprise a device, an application, a software or hardware component, or the like. A data source may be identifiable by an identifier that is unique within a plurality of data sources, for example by an address of the data source.

<FIG> illustrates an example of a device <NUM> configured to practice one or more embodiments. Device <NUM> may be, for example, configured to generate authenticated data packets and/or authenticate received data packets. Device <NUM> may comprise at least one processor <NUM>. The at least one processor <NUM> may comprise, for example, one or more of various processing devices, such as, for example, a co-processor, a microprocessor, a controller, a digital signal processor (DSP), a processing circuitry with or without an accompanying DSP, or various other processing devices including joint circuits such as, for example, an application specific joint circuit (ASIC), a field programmable gate array (FPGA), a microcontroller unit (MCU), a hardware accelerator, a special-purpose computer chip, or the like.

The device <NUM> may further comprise at least one memory <NUM>. The memory <NUM> may be configured to store, for example, computer program code or the like, for example, operating system software and application software. The memory <NUM> may comprise one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination thereof. For example, the memory may be embodied as magnetic storage devices (such as hard disk drives, magnetic tapes, etc.), optical magnetic storage devices, or semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash ROM, RAM (random access memory), etc.).

Device <NUM> may further comprise a communication interface <NUM> configured to enable the device <NUM> to transmit and/or receive information. The communication interface <NUM> may comprise an internal communication interface within a data source, a transmitter, a receiver, or a transceiver device. Alternatively, or additionally, the communication interface <NUM> may be configured to provide at least one external wireless radio connection, such as, for example, a 3GPP mobile broadband connection (e.g. <NUM>, <NUM>, <NUM>), a wireless local area network (WLAN) connection such as, for example, standardized by IEEE <NUM> series or Wi-Fi alliance, a short-range wireless network connection such as, for example, a Bluetooth connection. The communication interface <NUM> may hence comprise one or more antennas to enable transmission and/or reception of radio frequency signals over the air.

The device <NUM> may further comprise other components and/or functions such as, for example, a user interface (not shown) comprising at least one input device and/or at least one output device. The input device may take various forms such a keyboard, a touch screen, or one or more embedded control buttons. The output device may for example comprise a display, a speaker, a vibration motor, or the like.

When the device <NUM> is configured to implement some functionality, some component and/or components of the device, such as, for example, the at least one processor <NUM> and/or the at least one memory <NUM>, may be configured to implement this functionality. Furthermore, when the at least one processor <NUM> is configured to implement some functionality, this functionality may be implemented using program code <NUM> comprised, for example, in the at least one memory <NUM>.

The functionality described herein may be performed, at least in part, by one or more computer program product components such as software components. According to an embodiment, the device <NUM> comprises a processor or processor circuitry, such as, for example, a microcontroller, configured by the program code <NUM>, when executed, to execute the embodiments of the operations and functionality described herein. For example, and without limitation, illustrative types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific joint circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), complex programmable logic devices (CPLDs), graphics processing units (GPUs), or the like.

The device <NUM> may be configured to perform method(s) described herein or comprise means for performing method(s) described herein. In one example, the means comprises the at least one processor <NUM>, the at least one memory <NUM> including program code <NUM> configured to, when executed by the at least one processor <NUM>, cause the device <NUM> to perform the method(s).

The device <NUM> may comprise, for example, a node, a base station, a transmitter, a receiver, a transceiver, an authentication module, authentication circuitry, or the like. Although the device <NUM> is illustrated as a single device, it is appreciated that, wherever applicable, functions of the device <NUM> may be distributed to a plurality of devices, for example between components of a device.

<FIG> illustrates an example of a data packet <NUM> for identification and authentication of a node. A data packet may be also called a message. The data packet <NUM> may be applied in a communication system comprising K nodes that transmit data packets containing D information bits, for example to the base station <NUM> using uplink (UL) transmission. The K nodes are provided as examples of data sources. The data packet <NUM> sent by the i-th node may comprise a header hi, an address field ai, information bits (payload data) di, and a message authentication code (MAC) mi. The header hi, where hi ∈ {<NUM>,<NUM>}H, may comprise a physical-layer packet header of size H. The header may be encoded separately from the rest of the data packet <NUM> and it may include information for decoding the remaining parts of the data packet <NUM>. It is however possible that the data packet <NUM> does not include a header. For example, information included in the header may be provided to the base station <NUM> by other means.

The address field ai, where ai e {<NUM>,<NUM>}A, may comprise an address of the i-th node. The address may be unambiguous, i.e. unique, within the K nodes. The address field is provided as an example of an explicit data source identifier. The address field may not carry other information and it may serve for the sole purpose of identifying the node <NUM>. The size of the address field may be A. The address field may comprise a layer two (L2) address, where layer two may refer to the link layer according to the OSI (Open Systems Interconnection) model or a layer structure of a particular standard. The information bits di, where di ∈ {<NUM>,<NUM>}D, may comprise payload data of size D. The payload data may comprise encrypted data. It is however noted that embodiments described herein may be also applied to non-encrypted data. The MAC mi, where mi e {<NUM>,<NUM>}M, may be of size M.

The data fields hi, ai, di, mi may be binary data fields comprising a set of bits. A size of a data field may indicate a length of the data field, for example, as the number of bits, or some other measure of transmission resources needed for transmitting the data field. The size of the data packet <NUM> may be therefore equal to H + A + D + M. The data fields of data packet <NUM> may be in any suitable order. This also applies to any data packet disclosed herein. The data packet <NUM> may, for example, have the following structure: <MAT>.

An unambiguous identification of the K different nodes may be achieved by an address field comprising A = log<NUM>(K) bits. Here, K represents the maximum number of supported nodes in the system, which may be larger than the number of simultaneously active nodes. An authentication of a transmitting node based on data packet <NUM> may be performed, for example, based on symmetric key cryptography and the use of a cryptographic nonce b. The nonce may comprise an arbitrarily selected number or a bit sequence, which may change from time to time, for example between consecutive transmissions. Each of the K nodes may be associated with a private (secret) key ki. The private key may be unique within the K nodes and therefore each of the K nodes may be associated with a different private key. The private key may comprise a sequence of bits. The private key may be specific to a particular node, or in general specific to a particular data source. The private keys ki of the K nodes (i = <NUM>. K) may be known to the base station <NUM>. Prior to data transmission, the base station <NUM> may select the nonce, for example, randomly and, for example, from a uniform key space and distribute it to the K nodes. A transmitting node may then perform a signing algorithm to generate the MAC field based on the nonce and its private key. The MAC may be computed from the encrypted data di (encode-then-sign) using a predefined function fauth(·), for example based on <MAT>.

It is however noted that the MAC may be also computed further based on the address ai and/or without the nonce b, for example based on mi = fauth(ki, b, ai, di).

The base station <NUM> may verify the authenticity of the MAC of a received packet, for example, based on the following pseudocode:
<IMG>.

The base station <NUM> may provide as an input to the above pseudocode the received data packet denoted by [ĥi, âi, d̂i, m̂l]. In response to receiving a data packet <NUM>, the base station <NUM> may decode the received address field âi indicating the i-th node. The base station <NUM> may determine the private key of the i-th node ki based on the indicated address âi. This may be done, for example, by retrieving the private key of the i-th node from a look-up table based on the received address field. The base station <NUM> may then compute a reference MAC <MAT> based on the determined private key of the i-th node and the received data d̂i, and optionally based on the decoded address field. For example, the reference MAC may be computed based on the private key of the i-th node and a concatenation of the received address field and the received data. Computing the reference MAC may be further based on the nonce b.

The base station <NUM> may compare the computed reference MAC to the received MAC m̂i. If the reference MAC is equal to the received MAC, the base station <NUM> may declare the node associated with the received address to be an authentic data source. For example, the base station <NUM> may set a Boolean value valid = true. The base station <NUM> may then return valid = true as an output of the authentication procedure. If the computed reference MAC is not equal to the received MAC, the base station <NUM> may determine that the node associated with the received address is not an authentic data source. The base station <NUM> may then return a Boolean value valid = false.

<FIG> illustrates an example of a data packet <NUM> with a joint MAC and address field. The data packet <NUM> may comprise data fields hi, di, and mi similar to data packet <NUM>. However, the data packet <NUM> may not include the explicit address field ai. Instead, the address of the transmitting node (i-th node), or in general an identifier of a data source, may be implicitly indicated in the MAC field mi. The size of the data packet <NUM> [hi, di, mi] may be hence equal to H + D + M. The node <NUM> may determine the MAC as described above, for example based on mi = fauth(ki, b, di ) (cf. Equation (<NUM>)). Alternatively, the MAC may be determined further based on the address of the i-th node, for example based on mi = fauth(ki, b, ai, di ). It is further noted that the use of the nonce b may be optional and therefore the MAC computation may be also performed based on mi = fauth(ki, di ). Since the MAC is generated based on the private key of the i-th node, the MAC implicitly carries also information about the identity of the i-th node. The data packet <NUM> therefore provides a joint identification and authentication protocol. Instead of including the explicit address field in the data packet, the i-th node may be identified through the MAC, which is dependent on the private (unique) key of the i-th node.

A device, for example, node <NUM>, may generate the data packet <NUM> without the explicit address field for example as follows. The device may first obtain payload data subject to transmission. The payload data may be associated with a data source. For example, the payload data may have been received from a particular data source or the device may itself act as the data source. The device may determine a MAC based on the payload data and a unique key of the data source, for example the private key. As discussed above, determining the MAC may be further based on a cryptographic nonce, which may be received prior to data transmission. The generated data packet <NUM> may comprise the payload data and the MAC, but the data packet <NUM> may not comprise the explicit address field.

<FIG> illustrates an example of a procedure <NUM> for data source identification on a joint MAC and address field. This procedure may be performed at base station <NUM>, as described below, but it may be alternatively performed by any device or application that authenticates data packets having a joint MAC and address field. The procedure <NUM> may be used to implement for example the following pseudocode:
<IMG>
<IMG>.

At operation <NUM>, the procedure <NUM> may be started at base station <NUM> by receiving the data packet <NUM>. The received data fields of the data packet <NUM> are denoted by [ĥ, d̂, m̂], and the data packet comprising these fields may be provided as an input to the above pseudocode.

At operation <NUM>, the base station <NUM> may initialize a set of valid addresses. For example, the base station <NUM> may initialize an empty set of valid addresses (cf. line <NUM> of the above pseudocode). The base station <NUM> may further set a node index i equal to <NUM>.

At operation <NUM>, the base station <NUM> may select key ki associated with address ai of the i-th node, which may be referred to as an i-th candidate node. For example, at the first iteration (i=<NUM>) the base station <NUM> may select key k<NUM> associated with address a<NUM> of the first candidate node. The key ki may be determined for example by retrieving a corresponding key from a look-up table based on address ai (cf. line <NUM>). Key ki is an example of a unique key of a data source.

At operation <NUM>, the base station <NUM> may compute an i-th candidate MAC <MAT> of the i-th candidate node based on the received payload data d̂ and key ki. As illustrated in the above pseudocode, determining the i-th candidate MAC may be further based on nonce b and/or the i-th address ai and the received data d̂ (cf. line <NUM>).

At operation <NUM>, the base station <NUM> may compare the i-th candidate MAC to the received MAC m̂. The base station <NUM> may determine whether the candidate MAC is equal to the received MAC. The base station may set a value of Boolean parameter valid based on whether a match is detected between the i-the candidate MAC and the received MAC (cf. line <NUM>). In response to detecting a match (valid = true), the base station <NUM> may move to operation <NUM> to update the set of valid addresses with the address of the i-th node (cf. line <NUM>).

If no match is detected at <NUM>, the base station <NUM> may set the parameter valid to value false. The base station <NUM> may further move to operation <NUM> to determine whether i = K, i.e., whether the K candidate nodes have been already processed. If i < K, the base station <NUM> may increase the value of the node index i by one at operation <NUM> and move <NUM> to continue with another iteration. As a result, a plurality of candidate MACs may be determined for a plurality of candidate nodes based on a corresponding plurality of unique keys of the nodes and the received payload data. If i = K, the base station <NUM> may return the set of valid addresses at <NUM>.

As a summary, decoding the received data packet <NUM>, [ĥ, d̂, m̂], may comprise computing, for the plurality of K nodes, the candidate MACs <IMG> = {m̂<NUM>, m̂<NUM>,. , m̂K} based on the unique keys ki of the nodes and the received payload data d̂, optionally using the addresses of the nodes ai, and/or a current nonce b. The candidate MACs may be computed for example based on: <MAT>.

In order to identify the transmitting node, and thereby also authenticate the transmitting node and validate the integrity of the data packet <NUM>, the base station <NUM> may compare each candidate MAC m̂i to the MAC m̂ contained in the received packet <NUM>. If the codes match, the base station <NUM> may determine that the data packet <NUM> was correctly decoded and that it was transmitted by user î, with î such that mî = m̂. The base station <NUM> may therefore determine an identifier of the transmitting node based on detecting the match. This also provides authentication of the transmitting node.

This scheme provides the advantage of avoiding the overhead caused by an explicit address field. Another benefit of not having the explicit address field in the data packet is that the data packets are independent and identically distributed across transmitting nodes, and thus the schemes from unsourced random access framework can be applied even though the data sources can in fact be identified.

It is noted that, due to a non-zero hash collision probability, which will be further analyzed in relation to <FIG>, it is possible that the returned set of valid addresses comprises more than one address. Even though in that occasion it is not possible to unambiguously determine the identity of the data source, the above procedure enables to detect such identification failures. Therefore, according to an embodiment, base station <NUM> may provide a declaration of identification success in response to determining that the cardinality of the set of valid addresses is equal to one, i.e., when the number of data sources or data source identifiers in the valid set is equal to one. An identification failure may be declared otherwise.

As discussed above, computing the MAC at the node <NUM> or the candidate MAC at the base station <NUM> may be done based on the address field or without the address field. Using the address field improves security. For example, assuming that an attacker knows of some key ki, the attacker may create a valid MAC by mi = fauth(ki, b, di) and send the message [h, di, mi]. Since there is no address included, the base station <NUM> goes through the list of keys and finds that the key ki is a match, since it produces a matching MAC mi. Based on that the base station concludes that the message is valid and that it has been sent by a data source with address ai. However, if the MAC computation is further based on the address ai, the attacker would have to guess the address in order to perform a successful attack. Similar benefit may be achieved also when using the address field in computation of the MAC in other embodiments described herein.

<FIG> illustrates an example of a data packet <NUM> with a joint MAC and address field and a checksum field. As will be further described below, the checksum field may be determined based on an (ambiguous) auxiliary identifier of the data source and therefore the checksum field may be used by a receiver to assist in identifying the data source. The data packet <NUM> may comprise data fields hi, di, and mi similar to data packet <NUM>. Similar to data packet <NUM>, the data packet <NUM> may not include an explicit address identifier, or any other explicit identifier of a data source.

However, the data packet <NUM> may comprise a checksum field <MAT>. The checksum field may be of size C (e.g. bits). The checksum field may be located at any suitable position within data packet <NUM>, for example after the joint MAC and address field mi, in the order of transmission. The data packet <NUM> may therefore comprise fields [hi, di, mi, <MAT>] and be of size H + D + M + C. The auxiliary identifier may be also called an auxiliary node identifier, an auxiliary data source identifier, a fixed-length identifier, a short digest, a digest, a short identifier, an ambiguous identifier, or a non-unique identifier.

<FIG> illustrates an example of a procedure for generating data packets with a joint MAC and address field and a checksum field. The procedure <NUM> may be performed by node <NUM>, as described below, but it is understood that a similar procedure may be performed by any type of device or application that provides a packeting service for any data source. The procedure <NUM> may be used to generate the data packet <NUM> comprising the fields hi, di, mi and <MAT>.

At operation <NUM>, the node <NUM> may start the procedure.

At operation <NUM>, the node <NUM> may obtain payload data di. The payload data may be associated with address ai of the node <NUM> (i-th node), or in general payload data associated with a data source or an identifier of the data source. As discussed above, the node <NUM> may operate as a data source itself or it may generate data packets based on payload data received from one or more data sources. Obtaining the payload data may therefore comprise retrieving the payload data from a memory, from an internal data source of node <NUM> such as a component or an application of the node <NUM>, or receiving the payload data over a communication interface from an external data source.

At operation <NUM>, the node <NUM> may obtain an auxiliary identifier ji for the node based on its address ai. The size of the auxiliary identifier ji may be smaller than a size of the address ai. Hence, the auxiliary identifier ji may be ambiguous within the K nodes unambiguously identifiable by the address. For example, some nodes may share the same auxiliary identifier ji. The auxiliary identifier ji may be computed based on the address ai, for example as a function fj of the address: <MAT>.

The function fj(ai) may or may not be a cryptographic function. For example, the function may comprise selecting a subset of bits of ai, for example the C less significant bits of ai. The auxiliary identifier ji or the function for determining it based on the address, may be known to the base station <NUM>. The auxiliary identifier ji may be static or semi-static and therefore it may not need to change between consecutive transmissions.

At operation <NUM>, the node <NUM> may select a key ki based on address ai, for example using a look-up table of addresses mapped to corresponding keys.

At operation <NUM>, the node <NUM> may compute the MAC mi based on the payload data di, and the key ki. Node <NUM> may be configured to compute the MAC further based on the nonce &, and/or the address ai. The MAC may be therefore computed for example based on mi = fauth(ki, b, ai, di ).

At operation <NUM>, the node <NUM> may compute a checksum <MAT> based on the payload data and the MAC computed at <NUM>. The checksum <MAT> may be computed, for example, based on <MAT>, where fc(·) may be any suitable faction for calculating a checksum and where [·] denotes concatenation. However, the computation of the checksum <MAT> may be additionally based on further data fields of the data packet <NUM>, such as, for example, the header hi.

At operation <NUM>, the node <NUM> may perform an exclusive-or (XOR) operation for the checksum <MAT> with the auxiliary identifier ji: <MAT>. The XOR operation may comprise a bit-wise XOR operation between the checksum <MAT> and the auxiliary identifier ji. Hence, a second checksum <MAT> may be obtained by: <MAT>.

The computation of the second checksum <MAT> may be therefore based on the payload data, the MAC, and the auxiliary identifier.

At operation <NUM>, the node <NUM> may insert the resulting second (XOR'ed) checksum <MAT> in the data packet <NUM> to construct a data packet comprising the payload data, di, the MAC, mi, and the second checksum <MAT>.

At operation <NUM>, the node <NUM> may output the data packet <NUM>, for example for transmission to base station <NUM>.

<FIG> illustrates an example of a procedure <NUM> for data source identification based on a joint MAC and address field and a checksum field. This procedure may be performed at base station <NUM>, as described below, but it may be alternatively performed by any device or application that authenticates data packets having a joint MAC and address field and a checksum field. The procedure <NUM> may be used to implement, for example, the following pseudocode:
<IMG>
<IMG>.

At operation <NUM>, the procedure <NUM> may be started at base station <NUM> by receiving the data packet <NUM>. The received data fields of the data packet <NUM> are denoted by [ĥ, d̂, m̂, ĉ"]. These data fields may be provided as an input to the above pseudocode.

At operation <NUM>, the base station <NUM> may initiate a set of valid addresses, similar to operation <NUM>.

At operation <NUM>, the base station <NUM> may compute a checksum ĉ' (auxiliary checksum) based on the received payload data d̂, and the received MAC m̂,, for example based on the same checksum function fc(·) used for generating the data packet <NUM>: <MAT>.

At operation <NUM>, the base station <NUM> may perform an XOR operation between the checksum ĉ" received in the data packet and the computed auxiliary checksum ĉ', to obtain an estimate of the auxiliary identifier ji. The auxiliary identifier may be therefore estimated based on: <MAT>.

At operation <NUM>, the base station <NUM> may determine a subset of nodes Cv based on the auxiliary identifier. For example, the base station <NUM> may select the subset of nodes Cv from the plurality of K nodes of the system such that the subset of nodes Cv includes only nodes associated with the determined auxiliary identifier. The determined subset may be then used as a set of candidate nodes for searching for a match for the received MAC m̂.

At operation <NUM>, the base station <NUM> may select key ki associated with address ai of the i-th node of the subset of nodes. The i-th node of the subset may be again referred to as an i-th candidate node.

At operation <NUM>, the base station <NUM> may compute an i-th candidate MAC <MAT> of the i-th candidate node, similar to operation <NUM>.

At operation <NUM>, the base station <NUM> may compare the i-th candidate MAC to the received MAC similar to operation <NUM>, and move to operation <NUM> to update the set of valid addresses with the address of the i-th node in response to detecting a match (valid = true). If no match is detected at <NUM> (valid = false), the base station <NUM> may move to operation <NUM> to determine whether i = |Cv|, where |Cv| denotes the cardinality of the subset of nodes Cv, i.e. the number of nodes in the subset. Hence, at <NUM>, the base station <NUM> may determine whether the |Cv | candidate nodes have been already processed. If i <| Cv,| the base station <NUM> may increase the value of the node index i by one at operation <NUM> and move to <NUM> to initiate another iteration for the next node within the subset of nodes. As a result, a plurality of candidate MACs may be determined for a subset of a plurality of nodes based on a corresponding plurality of node specific keys and the received payload data. In this embodiment, the base station <NUM> may therefore consider the subset of nodes as a plurality of candidate nodes. If i = |Cv|, the base station <NUM> may return the set of valid addresses at <NUM>.

In general, decoding the received data packet <NUM> [ĥ, d̂, m̂, ĉ"] may comprise determining the subset of nodes Cv, based on the checksum field ĉ", and computing, for the |Cv |nodes of the subset, the candidate MACs <IMG> = {m̂<NUM>, m̂<NUM>,. , m̂|Cv|), based on the received payload data d̂, optionally using the current nonce b, and/or the address ai. For example, based on <MAT>.

In order to identify the transmitting node, and thereby also to authenticate the transmitting node and validate the integrity of the data packet <NUM>, the base station <NUM> may compare each computed candidate MAC m̂i to the MAC m̂ contained in the received packet <NUM>. If the codes match, the base station <NUM> may determine that the message is correctly decoded and that it was transmitted by node î, with î such that m̂î = m̂. The base station <NUM> may therefore determine an identifier of the node based on detecting the match. This also provides authentication of the node. This procedure provides similar benefits as procedure <NUM> of <FIG>. However, since the checksum field enables to reduce the number of candidate nodes, the complexity at the base station <NUM> is reduced. Furthermore, the hash collision probability is reduced, as will be further described below.

<FIG> illustrate performance of different data packet identification and authentication schemes. In the following, the data packet identification and authentication scheme based on a data packet <NUM> comprising an explicit address identifier is referred to as the Reference scheme. Procedure <NUM>, which is based on data packet <NUM> comprising the joint MAC and address field is referred to as Scheme <NUM>. Procedure <NUM>, which is based on data packet <NUM> comprising the joint MAC and address field and the checksum field is referred to as Scheme <NUM>.

Radio access may implemented in three steps: (i) Contention-based random access in the uplink, (ii) broadcast of a scheduling decision in the downlink, and (iii) contention-free uplink data transmission. Since phases (i) and (ii) may not use any user identification, they are not considered in the analysis, and the focus is therefore in phase (iii). Furthermore, since the header may be in many cases encoded separately from the payload data, it provides a constant contribution to the spectral efficiency and is therefore omitted in the analysis. Unless otherwise specified, the sizes of the packet elements are equal to A=<NUM> (in the Reference scheme only), M=<NUM>, and C=<NUM> (in Scheme <NUM>).

<FIG> illustrates performance analysis results for different data source identification and authentication schemes. The rows of the table indicate the overhead reduction as an overhead reduction percentage, the spectral efficiency as the number of channel uses, the complexity as the number of MAC computations, the identification failure rate as the hash collision probability and the authentication security as the MAC attack probability, as will be further described in relation to the following figures.

<FIG> illustrates an example of overhead reduction for a data source identification and authentication scheme based on a joint MAC and address field (Scheme <NUM>). The reduction in the data packet size (in bits) for Scheme <NUM> compared to the data packet of the Reference scheme is given by: <MAT> where the denominator A + D + M is the size of data packet <NUM> and the numerator D + M is the size of data packet <NUM> (without headers). The overhead reduction has been plotted for different combinations of address field size A, and data field size D. It can be observed that, for small data payloads, which is expected in unsourced random access systems, Scheme <NUM> provides a substantial overhead reduction.

<FIG> illustrates an example of overhead reduction for a data source identification and authentication scheme based on a joint MAC and address field and a checksum field (Scheme <NUM>). The reduction in the data packet size (in bits) for Scheme <NUM> compared to the data packet of the Reference scheme is given by <MAT> where the numerator D + M + C is now the size of data packet <NUM> (without the header). The overhead reduction has been plotted for different combinations of address field size A, payload data field size D, and checksum field size C. It can be observed that Scheme <NUM> provides a substantial overhead reduction for small data payloads as well. However, the overhead reduction is slightly lower due to the bits allocated to the checksum field.

<FIG> illustrates an example of spectral efficiency for a reference scheme and a data source identification and authentication scheme based on a joint MAC and address field (Scheme <NUM>). The spectral efficiency is characterized by considering the number of channel uses required to provide a fixed reliability target of ε = <NUM>-<NUM> in a point-to-point scenario, which may be used as a basis for estimating performance for unsourced random access schemes. A Rayleigh block-fading channel with an average channel gain of <NUM> is assumed so that the required rate can be calculated as: <MAT> where SNR denotes the signal-to-noise ratio and N denotes the number of channel uses. The number of channel uses Nref and N<NUM> for the Reference scheme and Scheme <NUM> are: <MAT> <MAT>.

It can be observed that, at low SNRs, as expected in case of unsourced random access, Scheme <NUM> requires a significantly smaller number of channel uses compared to the Reference scheme with different sizes of payload data D.

<FIG> illustrates an example of spectral efficiency for a reference scheme and a data source identification and authentication scheme based on a joint MAC and address field and a checksum field (Scheme <NUM>). Under the above assumptions, the number of channel uses N<NUM> for Scheme <NUM> is: <MAT>.

It can be observed that, at low SNR, also Scheme <NUM> requires a smaller number of channel uses compared to the reference scheme with different sizes of payload data D.

<FIG> illustrates an example of signal-to-noise ratio (SNR) gain for a data source identification and authentication scheme based on a joint MAC and address field. The gain provided by the disclosed data packets may be also expressed as an equivalent increase in the SNR. Specifically, for a fixed number of channel uses N, a fixed data size D, and a fixed reliability target of ε = <NUM>-<NUM>, the SNR gain for Scheme <NUM> is given by: <MAT>.

The SNR gain has been plotted for different payload data sizes D, up to D = <NUM>. It can be observed that Scheme <NUM> provides a significant SNR gain over the Reference scheme for a fixed reliability target. This SNR gain is particularly high for the small data payloads, as expected in unsourced random access schemes.

<FIG> illustrates an example of signal-to-noise ratio (SNR) gain for a data source identification and authentication scheme based on a joint MAC and address field and a checksum field (Scheme <NUM>). Under similar assumptions, the SNR gain for Scheme <NUM> is given by: <MAT>.

The SNR gain has been plotted again for different payload data sizes D, up to D = <NUM>. It can be observed that also Scheme <NUM> provides a significant SNR gain over the Reference scheme for a fixed reliability target. Again, the SNR gain is higher for the small data payloads, which is beneficial in case of unsourced random access schemes.

<FIG> illustrates examples of complexities of data source identification and authentication schemes based on a joint MAC and address field, with and without a checksum field. A precise comparison of the complexities of the different schemes is not straightforward. However, the disclosed methods use only few different operations such as: XORs, comparisons (simple bitwise operation), table lookups (fast on sorted lists), CRC (cyclic redundancy check) computation and MAC computations. Out of those, the MAC computation may be the most complex operation. Hence, focusing solely on the number of MAC computations provides a relatively good indication of the overall complexity.

<FIG> provides both the exact complexities (solid lines) as well as the approximated complexities (crosses overlaid on respective solid lines).

In the reference scheme, users may be identified by their addresses, and, hence, only one MAC address needs to be computed. The complexity for the reference scheme complexity is therefore <MAT>.

The worst case scenario, where the total populations of nodes is K = <NUM>A, is assumed for estimating the complexity for Schemes <NUM> and <NUM>. Under Scheme <NUM>, the base station <NUM> may compare the MAC for the K potential users and, hence, the number of MAC computations is <MAT>.

In Scheme <NUM>, the auxiliary identifier j has C bits, and hence the probability of having any particular one is <NUM>/<NUM>C. From the perspective of an arbitrary node, the probability that ℓ among the remaining K - <NUM> nodes have the same auxiliary identifier is given by the binomial distribution. Then, the average number of MAC computations for Scheme <NUM> is: <MAT>.

The number of operations for Schemes <NUM> and <NUM> has been plotted as a function of the total number of nodes K. It is observed that the complexity of Scheme <NUM> scales linearly with the number of nodes K. In contrast, Scheme <NUM> reduces the complexity of Scheme <NUM> by a factor of <NUM>C.

<FIG> illustrates an example of complexity with respect to overhead reduction for a data source identification and authentication scheme based on a joint MAC and address field and a checksum field (Scheme <NUM>). Based on the above calculations, the number of MAC computations has been plotted with respect to the overhead reduction percentage for different sizes of the payload data D, and with the total number of users being equal to K = <NUM>. It is observed that the resulting complexity is manageable even for high overhead reductions.

<FIG> illustrates an example of MAC collision probability with respect to a number of nodes for data source identification and authentication schemes based on a joint MAC and address field, with and without a checksum field.

According to embodiments of the present disclosure, the base station <NUM> may determine the identity of the node <NUM> by checking which key produces the matching MAC, and hence it is possible that ambiguity occurs. In other words, it may happen that for a particular message mi and nonce b, there exists aj ≠ ai such that: <MAT>.

As discussed above, identification success may be declared when equation (<NUM>) does not occur, that is, when there is exactly one matching MAC-key pair, corresponding to the originator of the message. Assuming that the MACs produced by the hashing function fauth(·) are uniformly distributed, the following analysis holds: For Scheme <NUM>, the identification success occurs when all the other K - <NUM> keys produce a MAC which is different from the received MAC mi. The probability of the collision, i.e., the probability of an identification failure, is therefore: <MAT>.

For Scheme <NUM>, the auxiliary identifier restricts the number of potentially colliding devices, and hence the probability of collision is: <MAT>.

Both exact and approximated collision probabilities have been plotted. It is observed that besides reducing complexity, Scheme <NUM> also provides a reduced probability of identification failure. This highlights the benefit of the hierarchical decoding included in the procedure <NUM>, since a corresponding increase in the length of the MAC in Scheme <NUM> to have the same identification failure as with Scheme <NUM>, would not reduce the decoding complexity.

Since the disclosed protocols do not alter the encryption scheme, the level of confidentiality may be maintained. However, the decoding procedure of the disclosed protocols changes the authenticity of the protocol. For example, an attacker may construct a random packet (or is able to alter the bits in a packet transmitted by a user). Since the data is assumed to be encrypted, the attacker is not able to extract or inject specific information into the data. However, the attacker may "hope" that the constructed packet has a valid MAC for some of the users. This may lead to the situation in which the receiver erroneously believes that the packet is authentic. In the reference scheme, the probability that the attacker constructs a valid MAC is <NUM>/<NUM>M.

On the other hand, under the disclosed protocol with Scheme <NUM>, a MAC is declared valid if it coincides with the MAC obtained from any of the user's keys, which happens approximately with probability K/<NUM>M. Even when K is much smaller than <NUM>M, this probability cannot be neglected. As an example, suppose K = <NUM><NUM> and M = <NUM>, the probability that the attacker guesses correctly is in the order of <NUM>-<NUM>, which means that an attacker would have to send a large number of packets to perform a successful attack. Under Scheme <NUM>, the CRC decreases the attack success probability by a factor of <NUM>C. In particular, if C = log<NUM> K, then the scheme provides the same level of security as the reference scheme.

Although authentication may be desired in many applications, there may be situations in which it is less important, e.g., because additional authenticity can be obtained using non-cryptographic methods. This may for instance be the case in a control system, where the transmitted data represent sensor readings that can be expected to follow some predictable process. Since the protocol still provides confidentiality, an application-level error detection mechanism may be applied to provide additional confidentiality. Another scenario could be that the transmitter has access to a more secure side-channel that it can use occasionally to batch-verify the packets transmitted over the primary channel.

<FIG> illustrates an example of a method <NUM> for generating authenticated data packets.

At <NUM>, the method may comprise obtaining payload data associated with a data source.

At <NUM>, the method may comprise computing a message authentication code based on a unique key of the data source and the payload data.

At <NUM>, the method may comprise obtaining an auxiliary identifier for the data source. A size of the auxiliary identifier may be smaller than a size of an identifier of the data source.

At <NUM>, the method may comprise determining a checksum based on the payload data, the message authentication code, and the auxiliary identifier.

<FIG> illustrates an example of a method <NUM> for authenticating data packets.

At <NUM>, the method may comprise receiving a data packet associated with a data source, wherein the data packet comprises payload data and a message authentication code.

At <NUM>, the method may comprise computing a plurality of candidate message authentication codes based on the payload data and a plurality of unique keys associated with a plurality of candidate data sources.

At <NUM>, the method may comprise determining an identifier of the data source based on detecting a match between the message authentication code and one candidate message authentication code of the plurality of candidate message authentication codes.

Further features of the methods directly result from the functionalities and parameters of the methods and devices, for example node <NUM> or base station <NUM>, as described in the appended claims and throughout the specification and are therefore not repeated here.

A device or a system may be configured to perform or cause performance of any aspect of the method(s) described herein. Further, a computer program may comprise program code configured to cause performance of an aspect of the method(s) described herein, when the computer program is executed on a computer. Further, the computer program product may comprise a computer readable storage medium storing program code thereon, the program code comprising instruction for performing any aspect of the method(s) described herein. Further, a device may comprise means for performing any aspect of the method(s) described herein. According to an example embodiment, the means comprises at least one processor, and at least one memory including program code, the at least one processor, and program code configured to, when executed by the at least one processor, cause performance of any aspect of the method(s).

Furthermore, references to 'at least one' item or 'one or more' items may refer to one or a plurality of those items.

Aspects of any of the embodiments described above may be combined with aspects of any of the other embodiments described to form further embodiments without losing the effect sought. The term 'comprising' is used herein to mean including the method, blocks, or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or device may contain additional blocks or elements.

It will be understood that the above description is given by way of example only and that various modifications may be made by those skilled in the art. The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from scope of this specification. station <NUM> is reduced. Furthermore, the hash collision probability is reduced, as will be further described below.

<FIG> illustrates an example of spectral efficiency for a reference scheme and a data source identification and authentication scheme based on a joint MAC and address field (Scheme <NUM>).

The spectral efficiency is characterized by considering the number of channel uses required to provide a fixed reliability target of ε = <NUM>-<NUM> in a point-to-point scenario, which may be used as a basis for estimating performance for unsourced random access schemes. A Rayleigh block-fading channel with an average channel gain of <NUM> is assumed so that the required rate can be calculated as: <MAT> where SNR denotes the signal-to-noise ratio and N denotes the number of channel uses. The number of channel uses Nref and N<NUM> for the Reference scheme and Scheme <NUM> are: <MAT> <MAT>.

<FIG> illustrates examples of complexities of data source identification and authentication schemes based on a joint MAC and address field, with and without a checksum field. A precise comparison of the complexities of the different schemes is not straightforward. However, the disclosed methods use only few different operations such as: XORs, comparisons (simple bitwise operation), table lookups (fast on sorted lists), CRC (cyclic redundancy check) computation and MAC computations. Out of those, the MAC computation may be the most complex operation. Hence, focusing solely on the number of MAC computations provides a relatively good indication of the overall complexity. <FIG> provides both the exact complexities (solid lines) as well as the approximated complexities (crosses overlaid on respective solid lines).

<FIG> illustrates an example of MAC collision probability with respect to a number of nodes for data source identification and authentication schemes based on a joint MAC and address field, with and without a checksum field. According to embodiments of the present disclosure, the base station <NUM> may determine the identity of the node <NUM> by checking which key produces the matching MAC, and hence it is possible that ambiguity occurs. In other words, it may happen that for a particular message mi and nonce b, there exists aj ≠ ai such that: <MAT>.

Aspects of any of the embodiments described above may be combined with aspects of any of the other embodiments described to form further embodiments without losing the effect sought.

The term 'comprising' is used herein to mean including the method, blocks, or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or device may contain additional blocks or elements.

It will be understood that the above description is given by way of example only and that various modifications may be made by those skilled in the art. The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments.

Claim 1:
A device (<NUM>) for generating a data packet (<NUM>), the device (<NUM>) configured to:
obtain payload data associated with a data source;
compute a message authentication code based on a unique key of the data source and the payload data, wherein the unique key of the data source is unique within a plurality of data sources;
obtain an auxiliary identifier for the data source, wherein a size of the auxiliary identifier is smaller than a size of an identifier of the data source, wherein the auxiliary identifier is ambiguous within the plurality of data sources and the identifier of the data source is unambiguous within the plurality of data sources;
determine a checksum based on the payload data, the message authentication code, and the auxiliary identifier, wherein determining the checksum based on the payload data, the message authentication code, and the auxiliary identifier comprises performing an exclusive-or operation for the checksum with the auxiliary identifier; and
generate the data packet (<NUM>), wherein the data packet (<NUM>) comprises the payload data, the message authentication code, and the checksum and wherein the data packet (<NUM>) does not include an explicit identifier of the data source.