Method for authenticable data transmission

Abstract

A method for authenticable data transmission. In the method, a first key pair and one or more second key pairs are generated and stored, the first key pair comprising a first private key and a first public key and supporting bilinear pairing, each second key pair comprising a respective second private key and a respective second public key and supporting bilinear pairing. One of the second key pairs is selected. Messages of a first type are obtained and corresponding hashes are generated for them. An authentication message is constituted that includes the generated hash and a second public key of the selected second key pair or data deriving the public key. The constituted authentication message is signed with a first private key to generate a signed aggregate authentication message that is distributed to the recipient device. A first type of message is distributed to a recipient device. Messages of a second type are obtained and signed with a second private key in the selected second key pair to create associated signatures, each message of the second type being distributed to the recipient device along with a respective associated signature.

Description

Technical Field

[0001] The present disclosure relates to a method for authenticating data transmission and also relates to a provider device, a receiver device and a system thereof capable of implementing authenticating data transmission. Background Art

[0002] In many applications, when data is sent from a provider or sender to one or more recipients, the sent data needs to be authenticated. Various cryptographic schemes are generally known to be used for such authentication. For example, the provider or sender uses a private key to generate a cryptographic signature of the sent data, and the recipient verifies the signature using a corresponding public key, which must be known to the recipient. In addition or as an alternative, a cryptographic hash function or a keyed hash message authentication code (MAC) can be used, which also requires the presence of some key information at the recipient.

[0003] In applications with limited transmission bandwidth, it is challenging to convey the information required for authentication to the receiver. In addition, if the payload data to be sent is known in advance, the corresponding data (e.g., signature or MAC) for authentication can be generated and sent in advance (i.e., before the payload data to be authenticated is actually sent). This allows the receiver to perform authentication immediately once it receives the payload data to be authenticated.

[0004] However, if the payload data to be sent is not known in advance, conventional solutions generate and send corresponding data for authentication after sending the payload data. However, this may not always be possible if the transmission bandwidth is limited. Therefore, using conventional solutions, it is not always possible to authenticate immediately after receiving the payload data. Summary of the invention

[0005] The object to be achieved is to provide an improved cryptographic concept for authenticating data transmission with less effort (for example in positioning systems or generally in systems for distributing content with short-term validity to a large number of consumers).

[0006] In an application where authenticated data transmission is performed from a provider device to a recipient device via a one-to-many communication channel, at least two types of messages are to be sent from the provider device to the recipient device. For example, a defined set of at least two types of messages, typically having different short-term validity, may be sent during a time period called an epoch. For a first type of message, a corresponding hash, such as a keyed hash MAC, may be pre-generated, for example, at the beginning of the epoch in which the first type of message is generated, i.e., before the first type of message is sent. Messages of the second type are not fixed or defined in advance (e.g., at the beginning of the epoch), for example, because they depend on the moment at which they are sent (e.g., on data that is only available close to that moment).

[0007] A first key pair based on a first generator P selected from a first cyclic group G1 of a first order q and a second generator Q selected from a second cyclic group G2 of the first order q is stored in a provider device, the first key pair including a first private key and a first public key and supporting bilinear pairing (e.g., asymmetric bilinear pairing), wherein the first private key is based on a random number in the interval]0;q-1], and the first public key is calculated using the second generator Q and the first private key. For example, the first order q is a first prime order q. In addition, one or more second key pairs based on a second order q' that is smaller than the first order q are obtained by the provider device, each second key pair including a corresponding second private key and a corresponding second public key and supporting bilinear pairing (e.g., asymmetric bilinear pairing). For example, the second order q' is a second prime order q'. For example, multiple second key pairs are generated using the same cryptographic scheme as the first key pair but using other parameters (e.g., different cyclic groups and random numbers). A key pair supporting symmetric bilinear pairing can also be used, but it is not recommended because the size of the signature is larger in this case.

[0008] For example, the improved cryptographic concept is based on an asymmetric bilinear pairing, e.g., type III or higher. This allows, for example, to define a predefined security level by selecting a specific elliptic curve (e.g., one of a plurality of Barreto-Naehrig (BN) curves or Barreto-Lynn-Scott (BLS) curves), for example, the specific elliptic curve is parameterized to provide at least a predefined number of bits of security strength, such as 64 bits, 72 bits, 80 bits, 100 bits or higher, which can be adjusted according to, for example, available computing resources and / or bandwidth resources.

[0009] The improved cryptographic concept is based on the idea that before actually sending a message of the first type, a hash of the message of the first type and a second public key from a selected second key pair or data suitable for deriving the second public key from a selected second key pair are sent together with a signature generated using the first private key. Thus, as soon as the recipient device receives the message of the first type, the message of the first type can be authenticated immediately using the hash. Furthermore, the message of the second type can be signed using the second private key from the selected second key pair to create an associated signature. Since the corresponding second public key has been sent before sending the message of the second type, the associated signature can be authenticated, in particular immediately. This is particularly suitable for applications with limited transmission bandwidth.

[0010] The smaller second order q' used by the second key pair compared to the first order q used by the first key pair results in a reduced security level. However, the signature and the public key are also smaller, which is beneficial, for example, in situations where bandwidth is limited. Furthermore, since one or more second key pairs are available, another second key pair can be obtained and / or selected in case of repeated execution of the concept, such that each selected second key pair has an estimated maximum lifetime until it is concluded that the attacker has cracked the selected second key pair.

[0011] In an example implementation according to an improved cryptographic concept, for a method for authenticating data transmission from a provider device to a recipient device via a one-to-many communication channel, the method includes: obtaining, by the provider device, a first key pair based on a first generator P selected from a first cyclic group G1 of a first order q and a second generator Q selected from a second cyclic group G2 of the first order q different from the first cyclic group G1, the first key pair including a first private key and a first public key and supporting bilinear pairing (e.g., asymmetric bilinear pairing), wherein the first private key is based on a random number in the interval]0;q-1], and the first public key is calculated using the second generator Q and the first private key. Obtaining, by the provider device, one or more second key pairs based on a second order q' that is smaller than the first order q, each second key pair including a corresponding second private key and a corresponding second public key and supporting bilinear pairing (e.g., asymmetric bilinear pairing). Providing the first public key to the recipient device. The above steps can be regarded as some kind of preparation, for example, the first order q can be a first prime order q, and the second order q' can be a second prime order q'.

[0012] One or more messages of the first type are obtained or generated by a provider device. The provider device selects one of the one or more second key pairs. The provider device generates a corresponding hash for each of the one or more messages of the first type. Afterwards, the provider device constructs an authentication message, which includes the generated hash and the second public key in the selected second key pair or data suitable for deriving the second public key in the selected second key pair. The provider device signs the constructed authentication message using the first private key to generate a signed aggregate authentication message. The provider device distributes the signed aggregate authentication message to the recipient device via a one-to-many communication channel.

[0013] After distributing the signed aggregate authentication message, the provider device distributes one or more messages of the first type to the recipient device via the one-to-many communication channel. In addition, after distributing the signed aggregate authentication message, the provider device obtains or generates one or more messages of the second type and signs the one or more messages of the second type using the second private key of the selected second key pair to create an associated signature. The provider device then distributes the one or more messages of the second type together with the corresponding associated signature (particularly for each message) via the one-to-many communication channel.

[0014] After the signed aggregate authentication message is distributed, the order of sending the first type of message and the second type of message is not limited. For example, the second type of message is sent between the first type of messages.

[0015] For example, the time period from obtaining the first type of message until the end of distributing all messages via the one-to-many communication channel can be called an epoch. Such an epoch can have a predefined length, such as 10 seconds or 20 seconds or 30 seconds or 40 seconds or longer.

[0016] The above process allows the recipient device to authenticate immediately after receiving both the first type of message and the second type of message.

[0017] In the above description, sending to a single recipient device is only used as a non-limiting example. However, using the one-to-many communication network adopted, the same data can be sent to multiple recipient devices, and each recipient device can immediately authenticate after receiving both the first type of message and the second type of message.

[0018] For example, the recipient device authenticates the signed aggregate authentication message using the first public key, and then authenticates one or more messages of the first type using the corresponding hash distributed using the signed aggregate authentication message. The recipient device also derives the second public key of the selected second key pair from the signed aggregate authentication message, and authenticates one or more messages of the second type using the associated signature and the second public key of the selected second key pair.

[0019] Authenticating one or more messages of the first type may include performing corresponding hash operations on the received messages and comparing the results of these hash operations with the hashes contained in the signed aggregate authentication message. For example, the receiving device performs the same hash operation (e.g., hash function) on the first type of message as when the providing device generated the hash, so that if the messages are the same, the same hash as the hash contained in the signed aggregate authentication message will be produced. Therefore, comparing the sent hash with the hash generated by the receiving device can authenticate the corresponding message of interest.

[0020] In some implementations, each second public key in a subset of one or more second key pairs is encrypted using a dedicated symmetric security key. For example, two or more second key pairs are encrypted. For example, before generating a message of the second type, the encrypted second public key is provided to the recipient device, for example, via a secure communication channel. The authentication message selectively includes the second public key in the selected second key pair or data suitable for deriving the second public key in the selected second key pair, wherein the data includes a random number (nonce) and a dedicated symmetric security key for decrypting the encrypted second public key. Therefore, the recipient device can derive the second public key by simply extracting the second public key (if included) from the signed aggregate authentication message, or by decrypting one of the previously distributed encrypted second public keys using a dedicated symmetric security key.

[0021] In some implementations, the second key pair is generated by a trusted entity but provided to the provider device in plain text via a secure channel.In addition, the second public key is distributed to the recipient device within a signed aggregate authentication message.

[0022] In some implementations, the second key pair is generated by a trusted entity, which also generates a dedicated symmetric security key for each second key in the subset and encrypts the second public key using the symmetric security key. The second public key is distributed in encrypted form from the trusted entity to the recipient device. The second key pair is distributed from the trusted entity to the provider device along with the dedicated symmetric security key via a secure channel in plain text form.

[0023] In some implementations, each second public key encrypted using a dedicated symmetric security key is distributed together with a corresponding initialization vector, for example, the initialization vector includes information about the encryption type, such as AESGCM, CCM, CTR, CBC.

[0024] In some alternative implementations, the second key pair is generated by a trusted entity but provided to the provider device in plain text via a secure channel. The provider device generates a dedicated symmetric security key for each second public key in the subset and encrypts the second public key using the symmetric security key. The encrypted second public key is distributed to the recipient device.

[0025] The selection by the recipient device of one of the previously distributed encrypted second public keys to be decrypted may be accomplished, for example, using certain parameters available in the authentication message or via an automatic determination algorithm shared between the provider device and the recipient device. The automatic determination algorithm may, for example, use a UTC date time to select one of the previously distributed encrypted second public keys to be decrypted.

[0026] For example, a provider device or a trusted entity repeatedly generates a first key pair at a first repetition rate and subsequently stores it in the provider device, each generated first key pair being different from the first key pair of the previous copy, and selecting one of one or more second key pairs at a second repetition rate that is higher than the first repetition rate (e.g., at least 100 times higher), each selected second key pair being different from any selected second key pair of the previous copy.

[0027] For example, if a first key pair is generated at a first repetition rate and a second key pair is obtained and / or selected at a second repetition rate that is higher than the first repetition rate, the life cycle (also called crypto-period) of each second key pair can be limited without difficulty. Therefore, in order to save bandwidth, it can be tolerated that the second key pair has a smaller security level, because the smaller security level can mean smaller signatures to be distributed and smaller public keys.

[0028] If obtaining the one or more second key pairs includes obtaining a single second key pair, obtaining the one or more second key pairs and selecting one of the one or more second key pairs may be performed at a second repetition rate. This may apply, for example, if the selected second public key is directly included in the signed aggregate authentication message (i.e., in unencrypted form).

[0029] If obtaining the one or more second key pairs includes obtaining more than one second key pairs (e.g., a plurality of second key pairs), selecting one of the one or more second key pairs may be performed at the second repetition rate, and obtaining the one or more second key pairs may be performed at the first repetition rate or at a third repetition rate that is higher than the first repetition rate and lower than the second repetition rate. This may apply, for example, if data suitable for deriving a second public key in the selected second key pair (e.g., a dedicated symmetric security key) is included in the signed aggregate authentication message.

[0030] In some implementations, the provider device generates or obtains more than one first key pair that supports bilinear pairing (e.g., asymmetric bilinear pairing), which may have different cryptographic parameters (e.g., different curves, such as a BN curve on a 256-bit prime field or a BLS-12 curve on a 381-bit prime field). In such implementations, the corresponding first public key needs to be distributed to the recipient device before it can be used for signing / authentication purposes. At each epoch, one of the available first key pairs is selected for signing the composed authentication message. For example, the first key pairs have different security levels and produce different signature sizes. Therefore, the selection can be made based on the available bandwidth or the number of bits.

[0031] As a non-limiting example only, the provider device is provided with a set of first key pairs (e.g., on a BN curve over a 256-bit prime field) and a set of first key pairs with a higher security level (e.g., on a BLS-12 curve over a 381-bit prime field). On the other hand, the recipient device is provided with the corresponding first public key of the first key pair used.

[0032] For example, a hash of one or more messages of the first type is generated based on an intermediate key derived from at least part of the constructed authentication message (e.g., part of the second public key in the selected second key pair or part of the random number and the dedicated symmetric security key (if applicable)). As long as the intermediate key changes with each authentication message or epoch, respectively, the intermediate key is intermediate. The rules for which part is used for the intermediate key can be agreed in advance between the provider device and the recipient device, or corresponding parameters can be transmitted. For example, such parameters can be included in a control section within the constructed authentication message. Each hash can be a key-hashed message authentication code, an HMAC or a CMAC or a KMAC. For example, a hash function using a key (i.e., an intermediate key) can be used to generate a hash from the corresponding message.

[0033] The generation of the hash of one or more messages of the first type may include some truncation in order to reduce the number of bits to be sent. Thus, the level of truncation may depend, for example, on the available bandwidth or the number of bits.

[0034] For example, the constructed authentication message further includes a control section including information about at least one of the following items:

[0035] - the key to be used to generate the hash;

[0036] - the hash function to be used to generate the hash;

[0037] - the number of rounds to use to generate the hash;

[0038] - The truncation level to use for generating the hash.

[0039] In some implementations, signing the composed authentication message and / or signing one or more messages of the second type is based on a short signature scheme that produces a corresponding signature corresponding to a corresponding single elliptic curve point. For example, the signature is based on a pairing-friendly Barreto-Naehrig curve or a Barreto-Lynn-Scott curve. The short signature scheme is different from a traditional signature scheme (e.g., ECDSA) based on a non-pairing-friendly curve (e.g., secp256r1), which produces a larger signature.

[0040] The improved cryptographic concept further provides a provider device for a one-to-many communication network, wherein:

[0041] - generating, by a provider device or a trusted entity, a first key pair based on a first generator P selected from a first cyclic group G1 of first order q and a second generator Q selected from a second cyclic group G2 of first order q, the first key pair comprising a first private key and a first public key and supporting a bilinear pairing (e.g., an asymmetric bilinear pairing), wherein the first private key is based on a random number in the interval ]0;q-1], and the first public key is calculated using the second generator Q and the first private key;

[0042] - providing the first public key to the recipient device; and

[0043] - generating, by the provider device or the trusted entity, one or more second key pairs based on a second order q' smaller than the first order q, each second key pair comprising a corresponding second private key and a corresponding second public key and supporting a bilinear pairing (eg, an asymmetric bilinear pairing).

[0044] Under these prerequisites, the provider device is configured to obtain a first key pair and a plurality of second key pairs, obtain one or more messages of the first type, select one of the one or more second key pairs, generate a corresponding hash for each of the one or more messages of the first type, and construct an authentication message, the authentication message comprising the generated hash and the second public key of the selected second key pair or data suitable for deriving the second public key of the selected second key pair. The provider device is also configured to sign the constructed authentication message with the first private key to generate a signed aggregate authentication message, and distribute the signed aggregate authentication message to the recipient device via the one-to-many communication channel. After distributing the signed aggregate authentication message, the provider device also distributes one or more messages of the first type to the recipient device via the one-to-many communication channel.

[0045] The provider device is also configured to obtain one or more messages of the second type after distributing the signed aggregate authentication message, sign the one or more messages of the second type using the second private key of the selected second key pair to create associated signatures, and distribute the one or more messages of the second type together with the associated signatures to the recipient device via a one-to-many communication channel.

[0046] The improved cryptographic concept also provides a receiver device for a one-to-many communication network, wherein:

[0047] - generating, by a provider device or a trusted entity, a first key pair based on a first generator P selected from a first cyclic group G1 of first order q and a second generator Q selected from a second cyclic group G2 of first order q, the first key pair comprising a first private key and a first public key and supporting a bilinear pairing (e.g., an asymmetric bilinear pairing), wherein the first private key is based on a random number in the interval ]0;q-1], and the first public key is calculated using the second generator Q and the first private key;

[0048] - providing the first public key to the recipient device;

[0049] - generating, by the provider device or the trusted entity, one or more second key pairs based on a second order q′ that is smaller than the first order q, each second key pair comprising a corresponding second private key and a corresponding second public key and supporting a bilinear pairing (e.g., an asymmetric bilinear pairing);

[0050] - the provider device obtains one or more messages of the first type;

[0051] - the provider device selects one of the one or more second key pairs;

[0052] - generating, by the provider device, a respective hash for each of the one or more messages of the first type;

[0053] - forming, by the provider device, an authentication message comprising the generated hash and the second public key of the selected second key pair or data suitable for deriving the second public key of the selected second key pair;

[0054] - signing the composed authentication message by the provider device using the first private key to generate a signed aggregate authentication message;

[0055] - obtaining, by the provider device, one or more messages of the second type; and

[0056] - signing, by the provider device, one or more messages of the second type using the second private key of the selected second key pair to create an associated signature.

[0057] Under these prerequisites, the receiving device is configured to store a first public key, receive a signed aggregate authentication message from a provider device via a one-to-many communication channel, and authenticate the signed aggregate authentication message using the first public key. The receiving device is also configured to derive a second public key of a selected second key pair from the signed aggregate authentication message, derive a second public key of a selected second key pair from the signed aggregate authentication message, receive one or more messages of the first type from the provider device via the one-to-many communication channel, and authenticate the one or more messages of the first type using a corresponding hash distributed using the signed aggregate authentication message. The receiving device is also configured to receive one or more messages of the second type from the provider device via the one-to-many communication channel together with an associated signature, and authenticate the one or more messages of the second type using the associated signature and the second public key of the selected second key pair.

[0058] According to the improved cryptographic concept, a communication system of a one-to-many communication network may include a provider device as described above and a receiver device as described above.

[0059] According to various implementations described above or below, in combination with the method for authenticatable data transmission from a provider device to a recipient device via a one-to-many communication channel, further implementations and developments of the provider device, the recipient device and the communication system become apparent to the reader in the art. For example, the improved cryptographic concept can be applied in a positioning system such as a GNSS positioning system, where the payload data is, for example, correction data of a GNSS augmentation service such as PointPerfect provided by u-blox. In another example, the improved cryptographic concept can be applied in a system for distributing any type of high-value data with short-term validity to a large number of consumers.

[0060] The method according to one of the described implementations may be provided as a computer program product that may be stored on a non-volatile storage medium. The computer program product includes instructions that, when executed on at least two or more processors of a provider device and a recipient device, may cause the two or more processors to perform the method according to any one of the various implementations described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] The improved cryptographic concept will be explained in more detail below with the aid of the accompanying drawings. Elements and functional blocks having the same or similar functions have the same reference numerals throughout the accompanying drawings. Therefore, their description need not be repeated in the following drawings.

[0062] In the attached picture:

[0063] Figure 1 An example implementation of a one-to-many communication network is shown;

[0064] Figure 2 An example implementation for a verifiable data transfer method is shown;

[0065] Figure 3 An example of sending data in a one-to-many communication network is shown; and

[0066] Figure 4 Another example of sending data in a one-to-many communication network is shown.

[0067] Reference Symbols List

[0068] TE Trusted Entity

[0069] PD Provider Device

[0070] RX1, RX2, RXi, RXn Receiver Device

[0071] PL Payload Data

[0072] 400 Methods

[0073] 401-409 Methods and Steps

[0074] SAAM Signed Aggregate Authentication Message

[0075] HDR Control Section

[0076] M Hash

[0077] PR2 Second public key

[0078] SIG1 and SIG2 signatures

[0079] T1 Message of the first type

[0080] T2 The second type of message

[0081] NC Random Number

[0082] KDK Security Key DETAILED DESCRIPTION

[0083] Figure 1 An example implementation of a one-to-many communication network (e.g., implemented as a broadcast communication network or a multicast communication network using an IP or non-IP protocol) is shown. The main purpose of such a network is to allow authenticated data transmission of payload data PL from the server side to the client side through a one-to-many communication channel. In this example implementation, the server side includes a trusted entity TE and a provider device PD, which may or may not be implemented together in a single device or server instance. The trusted entity TE is more secure than the provider device PD in terms of key generation and storage because it can be based on hardware security module (HSM) technology with a true random generator (TRNG) and a trusted root (RoT) protected memory. The trusted entity TE and the provider device PD can communicate via a secure communication channel using, for example, standard TLS / DTLS / OSCORE or QUIC secure transport protocols and mutual authentication.

[0084] The payload data PL may have a short-term validity and originate, for example, from a backend system connected to the provider device PD or from the provider device PD itself. On the client side, there are multiple recipient devices RX1, RX2, RXi, RXn, so that, for example, n different devices are recipients of data sent via the one-to-many communication channel. In order to allow verifiable data transmission of the payload data PL, a key pair with a private key and a public key may be used to generate a signature with the private key to be sent with the data via the one-to-many communication channel, and the corresponding public key may then be used to authenticate the signature. Figure 2 Explain the details of the improved cryptographic concepts employed in one-to-many communication networks.

[0085] Figure 2 shows the use of Figure 1 An example implementation of a method 200 of verifiable data transmission from a provider device PD to one or more recipient devices over a one-to-many communication channel is shown.

[0086] In step 201, a first key pair is generated based on a first generator P selected from a first cyclic group G1 of a first order q and a second generator Q selected from a second cyclic group G2 of the first order q that is different from the first cyclic group G1, the first key pair includes a first private key and a first public key and supports bilinear pairing (e.g., asymmetric bilinear pairing). In the following, it is assumed that the first order q is a first prime order q. However, in an alternative implementation, the first order q may also be a non-prime order.

[0087] The first private key is based on a random number in the interval [0;q-1], and the first public key is calculated using the second generator Q and the first private key. The first key pair can be generated in the trusted entity TE or the provider device PD, and obtained by the provider device PD or stored in the provider device PD. In addition, the first public key is provided to one or more recipient devices. For example, the trusted entity TE or the provider device PD uses, for example, standard TLS / DTLS / OSCORE or QUIC secure transmission protocols and mutual authentication or server-side authentication only to distribute the first public key to one or more recipient devices separately in a one-to-one communication channel. In an alternative, this can be done, for example, using a one-to-many communication channel, since it is public content anyway. It may be beneficial if the recipient device can ensure that it is using a public key from a legitimate service provider.

[0088] In step 202, one or more second key pairs based on a second order q' that is smaller than the first order q are generated in the trusted entity TE or the provider device PD, each second key pair comprising a corresponding second private key and a corresponding second public key and supporting a bilinear pairing (e.g., an asymmetric bilinear pairing). The trusted entity TE can generate and store multiple second key pairs, which the provider device PD can then obtain together or one by one. As with the first order q, it is assumed in the following that the second order q' is a second prime order q'. However, in an alternative implementation, the second order q' may also be a non-prime order.

[0089] In step 203, the provider device PD selects one of the one or more second key pairs. In step 204, the provider device PD obtains one or more messages of the first type. For example, the one or more messages of the first type carry payload data PL to be sent from the provider device PD to one or more recipient devices.

[0090] In step 205, the provider device PD generates a corresponding hash for each of the one or more messages of the first type. Such a hash may be a keyed hash, a cryptographic hash, an HMAC, a cipher-based message authentication code (CMAC), or based on any other hash function. The generation of the hash may include some truncation to reduce the number of bits to be sent.

[0091] Still in step 205, the provider device PD then composes an authentication message comprising the generated hash and the second public key of the selected second key pair or data suitable for deriving the second public key of the selected second key pair. The provider device PD signs the composed authentication message using the first private key to produce a signed aggregate authentication message. The provider device PD then distributes the signed aggregate authentication message to one or more recipient devices via a one-to-many communication channel.

[0092] After distributing the signed aggregate authentication message, in step 206 the provider device PD distributes one or more messages of the first type to one or more recipient devices via the one-to-many communication channel.

[0093] Furthermore, after distributing the signed aggregate authentication message, the provider device PD generates or obtains one or more messages of the second type and signs the one or more messages of the second type using the second private key of the selected second key pair to create an associated signature in step 207. The provider device PD then distributes the one or more messages of the second type together with the corresponding associated signature (in particular for each message) to one or more recipient devices via a one-to-many communication channel.

[0094] It should be noted that after the signed aggregate authentication message is distributed, the order in which the first type of message and the second type of message are sent is not limited. For example, the second type of message is sent between the first type of messages. For example, step 206 and step 207 can be performed in parallel. More generally, the various actions in the above method steps can be performed in any order, unless causality requires a specific order for individual operations.

[0095] As described above, if no dedicated trusted entity TE is available or the provider device PD also performs the functions of the trusted entity TE, the generation of the key pair can be performed in the trusted entity TE or the provider device PD (e.g., in steps 201 and 202). The generation of various messages can be performed by the provider device PD or an external backend system. However, the distribution of various messages (e.g., in steps 206 and 207) is performed by the provider device PD.

[0096] It should also be noted that the process described in steps 201 to 207 above allows a recipient device of the one or more recipient devices to authenticate immediately after receiving both the first type of message and the second type of message.

[0097] For example, in optional step 208, the recipient device authenticates the signed aggregate authentication message using the first public key, and then authenticates one or more messages of the first type using corresponding hashes distributed using the signed aggregate authentication message. Authenticating the one or more messages of the first type may include performing corresponding hash operations on the received messages and comparing the results of the hash operations with the hashes contained in the signed aggregate authentication message.

[0098] In optional step 209, the recipient device also derives a second public key of the selected second key pair from the signed aggregate authentication message, and authenticates one or more messages of the second type using the associated signature and the second public key of the selected second key pair.

[0099] The message generation and distribution described in conjunction with steps 204 to 209 may be performed repeatedly, for example, in multiple epochs, such as Figure 2 204. An epoch may span the processing described in steps 204 to 208 or 209, respectively. For example, if additional payload data is to be sent (e.g., in a subsequent epoch), they can be verified using the corresponding new hash for the first type of message and the corresponding signature for the second type of message.

[0100] For example, the provider device may use the same selected second key pair across multiple epochs, and may also distribute one or more first public keys to the recipient device only once during the lifetime of the recipient device, or may distribute one or more first public keys to the recipient device every defined or random number of epochs.

[0101] However, due to the reduced security level of the second key pair caused by the smaller prime order q', the risk of the selected second key pair being cracked by an attacker increases over time, in particular from the first use or transmission of the second public key in the selected second key pair. Therefore, after a given time (mainly depending on the security level actually selected, and can be called a cryptographic cycle), the selected second key pair may no longer be considered safe. Therefore, instead of jumping back to step 204, a jump is made back to step 203 as shown by the dotted line in order to obtain and / or select another second key pair from one or more second key pairs, wherein each selected second key pair is different from any selected second key pair in the previous copy. For example, this newly selected second key pair starts a new cryptographic cycle.

[0102] Like the second key pair, the first key pair, although having a higher security level, may be deemed no longer secure after a period of time, for example, such that an attacker may be able to destroy the signature. Therefore, method 200 may return to step 201 ( Figure 2 Therefore, the key generation process of both the first key pair (step 201) and the second key pair can be started again.

[0103] For example, a first key pair is repeatedly generated at a first repetition rate and then stored in the provider device PD, each generated first key pair is different from the first key pair of the previous copy, and one of one or more second key pairs is selected at a second repetition rate that is higher than the first repetition rate (for example, at least 100 times higher), and each selected second key pair is different from any selected second key pair of the previous copy.

[0104] For example, if a first key pair is generated at a first repetition rate and a second key pair is selected at a second repetition rate higher than the first repetition rate, the life cycle (also called cryptoperiod) of each second key pair can be limited effortlessly.

[0105] If obtaining the one or more second key pairs includes obtaining a single second key pair, obtaining the one or more second key pairs and selecting one of the one or more second key pairs may be performed at a second repetition rate. This may apply, for example, if the selected second public key is directly included in the signed aggregate authentication message SAAM (i.e., in unencrypted form).

[0106] If obtaining the one or more second key pairs includes obtaining more than one second key pairs (e.g., multiple second key pairs), selecting one of the one or more second key pairs may be performed at the second repetition rate, and obtaining the one or more second key pairs may be performed at the first repetition rate or at a third repetition rate that is higher than the first repetition rate and lower than the second repetition rate. This may apply, for example, if data suitable for deriving the selected second public key (e.g., a dedicated symmetric security key) is included in the signed aggregate authentication message SAAM.

[0107] For example, the first repetition rate for generating the first key pair is 31 days, while the second repetition rate for selecting the second key pair is between 30 seconds and 18000 seconds, corresponding to 5 hours (non-limiting example). These numbers may result in a ratio between the first repetition rate and the second repetition rate of between 148.8 and 89280.

[0108] For example, the predefined security level of the asymmetric bilinear pairing is based on the selected elliptic curve. For example, a Barreto-Naehrig curve or a Barreto-Lynn-Scott curve can be used, which are parameterized to provide at least a given number of bits of security strength, such as 64 bits or more.

[0109] This is useful, for example, if the one-to-many communication channel is a unidirectional satellite channel with a low data rate (in the range of a few kilobits per second). Thus, resources can be saved by only providing a limited number of bits of keys and signatures over the communication channel. For example, the improved cryptographic concept can be applied in positioning systems such as GNSS positioning systems, where the payload data is, for example, correction data for GNSS augmentation services such as PointPerfect provided by u-blox.

[0110] For example, the first type of message may be a message in PointPerfect using the standardized SPARTN format, including messages related to OCB (Orbit, Clock, Bias), HPAC (High Precision Atmospheric Correction), GAD (Geographic Area Definition), to name a few. The second type of message may be an OCB-Clock-Only message in PointPerfect using the SPARTN format.

[0111] Reference now Figure 3 , showing an example of sending data in a one-to-many communication network. For example, the data corresponds to an epoch. As previously described, one or more messages T1 of the first type have been generated or obtained and are to be sent. For each of these first type messages, a hash M has been generated that is part of a signed aggregate authentication message SAAM. The signed aggregate authentication message SAAM also includes a second public key PR2 of the selected second key pair, followed by a signature SIG1 using the first private key, as described above.

[0112] It should be noted that all hashes choose the same reference symbol M, although they differ for the content or value of different messages. For example, the hash M can be an HMAC that is the result of a truncated HMAC-SHA256 or HMAC-SHA224 of the corresponding message, calculated using a key derived from some predefined fields of the aggregate authentication message SAAM (in particular the second public key PR2).

[0113] The signed aggregate authentication message SAAM may also contain an optional control section or header section HDR. The control section HDR may include information about at least one of the following items:

[0114] - the key to be used to generate the hash, e.g. which parts of the aggregate authentication message (like the public key PR2 or the random number NC and / or the dedicated symmetric security key KDK) should be used to define the key used in the keyed hash function;

[0115] - The hash function to be used to generate the hash, for example, HMAC-SHA256 or HMAC-SHA224;

[0116] - the number of rounds to use to generate the hash, i.e., how often to apply the hash function to generate the final hash;

[0117] - the truncation level to use for generating the hash, e.g., how many bits of the initial result of the hash function should be used;

[0118] - A curve used to generate the first key pair and / or the second key pair.

[0119] The selected hash function, number of rounds and truncation level may control the security level of the entire hash generation operation. If these are not included in the control section HDR, they may be predefined between the provider device PD and the recipient device.

[0120] When the signed aggregate authentication message SAAM is sent, the receiving device has all the information required to authenticate the subsequent first type of message and second type of message. Therefore, in this example, a first type of message T1, a second type of message T2 and an associated signature SIG2 and two further first type of messages T1 are sent. Those skilled in the art will appreciate that a greater number of first type of messages and second type of messages may be sent after the signed aggregate authentication message SAAM. For example, the signed aggregate authentication message SAAM together with the first type of message and the second type of message form an epoch.

[0121] Reference now Figure 4 , shows another example of sending data in a one-to-many communication network. Figure 3 The difference between the examples of is only the implementation of the signed aggregate authentication message SAAM. For example, the data corresponds to an epoch. As described above, the authentication message includes Figure 3 The second public key of the selected second key pair shown, or data suitable for deriving the second public key of the selected second key pair, and optionally a control section or a header section HDR. For example, each second public key in a subset of multiple second key pairs has been encrypted using a dedicated symmetric security key KDK, and the encrypted second public key is distributed separately to one or more recipient devices, for example, by the provider device PD or the trusted entity TE in a one-to-one communication channel, for example, using a standard TLS / DTLS / OSCORE or QUIC secure transport protocol and mutual authentication or only server-side authentication. In an alternative, this can be done, for example, using a one-to-many communication channel, because it is encrypted public content anyway. It may be beneficial if the recipient device can ensure that it is using a second public key from a legitimate service provider. Therefore, one or more recipient devices have a subset of the second public keys available in encrypted form.

[0122] The authentication message may optionally include a second public key of the selected second key pair (eg, Figure 3As shown) or data suitable for deriving the second public key in the selected second key pair, wherein the data includes a random number NC and a dedicated symmetric security key KDK (as shown) for decrypting the encrypted second public key Figure 4 In each case, the recipient device is able to authenticate messages of the first type and messages of the second type. It should be noted that deriving the second public key corresponds to decrypting the encrypted second public key. As with the unencrypted transmission of the second public key, the transmission of the symmetric security key KDK also results in a limited life cycle or cryptoperiod of the corresponding encrypted second public key, so it is recommended to select another second key pair after a given time.

[0123] and Figure 3 Similar to the example of , the hash M may be an HMAC that is the result of a truncated HMAC-SHA256 or HMAC-SHA224 of the corresponding message, computed using a key derived from some predefined fields of the aggregate authentication message SAAM, in particular the random number NC and the dedicated symmetric security key KDK. Such definitions may be predefined or included in the header section HDR.

[0124] The random number NC is a field with a defined bit length that the provider device changes at each epoch (i.e., with each new signed aggregate authentication message SAAM). This can prevent an attacker from trying to find the MAC preimage to forge a message of the first type using the entire period in which the same symmetric security key KDK is used in subsequent aggregate authentication messages.

[0125] In subsequent epochs, you can arbitrarily choose Figure 3 Examples or Figure 4 The selection can be identified by the receiving device and can also be included in the header section HDR. Figure 4 If one of the encrypted second public keys is used in the example, the index of the used second public key can be included in the header segment HDR.

[0126] Although the improved cryptographic concepts have been described in a general manner in the above description, a specific example implementation will be described below, in particular with regard to cryptographic schemes that can be used for a single operation. Furthermore, it may be assumed that a one-to-many communication channel with limited bandwidth is used, such as a satellite link.

[0127] In some implementations, signing the combined authentication message and / or signing one or more messages of the second type is based on a short signature scheme that produces a corresponding signature corresponding to a corresponding single elliptic curve point. This allows the recipient to authenticate the signature using only one bilinear pairing. For example, the signature is based on a pairing-friendly Barreto-Naehrig (BN) curve or a pairing-friendly Barreto-Lynn-Scott curve.

[0128] This cryptographic scheme can be based on a type III pairing scheme, which specifically defines an asymmetric pairing scheme in which the first group commutation group G1 and the second group commutation group G2 are different, i.e., one is smaller than the other. Using type III asymmetric bilinear pairing, we can get the bilinear pairing operator

[0129] Type III pairing schemes can be used for both the first key pair and the multiple second key pairs. However, bandwidth in the one-to-many communication channel can be further saved by adopting two authentication keys: a short-term authentication key, which has a moderately low security level and is therefore efficient in terms of bandwidth consumption; and a long-term authentication key, which has complete security. In the above disclosure, the key of the second key pair corresponds to this short-term authentication key, and the key of the first key pair corresponds to this long-term authentication key. The short-term authentication key is used to sign the second type of message and can be updated in a moderately short period (e.g., a few hours at most) to avoid active adversaries having enough time to crack it. It is distributed inside the aggregate authentication message (e.g., via a satellite link) or pre-distributed in encrypted form (as described in more detail above). The long-term authentication key is used to sign the aggregate authentication message and can be updated in a long period (e.g., once a month or once every few years). It can be distributed over a secure mutual authentication connection or a server-only authentication connection or using a one-to-many communication channel, as described in more detail above.

[0130] A Type III pairing scheme may have the following parameters:

[0131] {q, G1, G2, G T , e: G1×G2→G T , P∈G1, Q∈G2, H: {0, 1} * →Z q}

[0132] Where q is the prime order of the cyclic groups G1 and G2. P is the random generator for G1, and Q is the random generator for G2. H can be a classical hash function whose output modulo q to generate the value of Zq.

[0133] The scheme can include three algorithms:

[0134] Generate a key. Get a random number (private key); calculate P pub = x·Q∈G2(public key). Private key x and public key P pub A key pair is formed, such as a first key pair or one of a plurality of second key pairs.

[0135] Signature. Given a message m∈{0,1} * and private key Calculate the signature The message m may be a message of the first type or a message of the second type.

[0136] Verification / Authentication. Given a message m∈{0,1} * 、Public key P pub ∈G2 and signature S∈G1, check whether there is e(S, H(m)·Q+P pub )=e(P,Q). Note that, compare (in G T The second term in G2 can be precomputed to save processing power. If this is the case, the verification algorithm will: q ), (ii) perform multiplication in G2, (iii) perform summation in G2, and (iv) perform pairing.

[0137] The following is a proof of the correctness of the solution.

[0138]

[0139] The bit length of the BN elliptic curve coordinates used by the long-term authentication key can be fixed to 256, thereby obtaining a security level of approximately 100 bits. The following table shows possible long-term keys and possible short-term keys with Zq, G1, G2, G T Comparison of element sizes and security levels of the IETF standardized BN_P256 library (i.e., a BN curve over a 256-bit prime field) and the non-standardized BN_P128 (i.e., a BN curve over a 128-bit prime field).

[0140]

[0141] In G T In the calculation, the same embedding degree is used for both long-term and short-term keys, but in practice the embedding degree of the short-term key can be reduced from 12 to 10 without affecting the security level. In this case, the G of the short-term key is T The elements will have a size of 1280 bits (16.67% less than 1536 bits).

[0142] As another bandwidth saving technique, the provider device may pre-distribute some short-term authentication keys, i.e., the public keys of a subset of the plurality of second keys, to avoid sending them over the one-to-many communication channel (e.g., a satellite link). To prevent an attacker from starting to try to crack the short-term authentication key immediately after it is pre-distributed, the short-term authentication key may be encrypted (e.g., using a 128-bit AES key). The relative decryption key (key decryption key) is a symmetric key that must be sent by the provider device over the one-to-many communication channel just before it starts signing messages using the short-term authentication key. This corresponds, for example, to Figure 4 The example implementation shown in . The provider device PD may provide the recipient device with means to select a pre-distributed set of encrypted short-term authentication keys from the aggregate authentication message for decryption (key index or automatic determination) using a dedicated symmetric key KDK. Such information may be contained in the header section HDR.

[0143] To actually save bandwidth, the key decryption key must be shorter than the short-term authentication key. The operation of sending the key decryption key for the first time is called a key unwrap. After a key unwrap, the short-term authentication key can be used to sign messages for at most a short-term crypto period, so as not to give an attacker too much time to crack it. For each epoch, e.g., a 30-second time frame, the provider device can decide to send a new short-term authentication key on the one-to-many communication channel or use a pre-distributed key. The more pre-distributed keys it uses, the more bandwidth it saves in the one-to-many communication channel, but the more storage capacity it requires on the recipient device.

[0144] In some implementations, the receiving device may reject messages where a short-term key has been authenticated after exceeding its cryptoperiod. Such cryptoperiod may be predefined or included in the header section HDR.

[0145] It should be clear to a person skilled in the art that the devices involved in the operation of the improved cryptographic concept (such as the trusted entity, the provider device and the recipient device) may each be equipped with some kind of processor and associated volatile and / or non-volatile memory for storing instructions for performing the corresponding method steps and for storing keys, payload data, etc. as required. The improved cryptographic concept in particular allows to keep the processor and memory requirements on the client side (i.e. the recipient device) as small as possible, while keeping memory intensive operations on the server side. Furthermore, it should be obvious to a person skilled in the art which steps in the method according to the improved cryptographic concept are to be performed by which entity, so that in this part of the present disclosure, it is referred to as the invention content.

[0146] Various embodiments of the improved cryptographic concept can be implemented in the form of software logic or hardware logic or a combination of the two. The logic can be stored in a computer-readable storage medium or a machine-readable storage medium as a set of instructions, which are suitable for instructing one or more processors of a (distributed) computer system to perform a set of steps disclosed in an embodiment of the improved cryptographic concept. The logic can form part of a computer program product, which is suitable for instructing an information processing device to automatically perform a set of steps disclosed in an embodiment of the improved cryptographic concept.

[0147] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the scope of the invention as set forth in the claims.

Claims

1. A method for authenticatable data transmission from a provider device to a recipient device via a one-to-many communication channel, the method comprising: - obtaining, by the provider device PD, a first key pair based on a first generator P selected from a first group exchange group G1 of a first order q and a second generator Q selected from a second group exchange group G2 of the first order q, the first key pair comprising a first private key and a first public key and supporting a bilinear pairing, in particular an asymmetric bilinear pairing, wherein the first private key is based on a random number in the interval]0;q-1], and the first public key is calculated using the second generator Q and the first private key; - obtaining, by said provider device PD, one or more second key pairs based on a second order q′ smaller than said first order q, each second key pair comprising a respective second private key and a respective second public key and supporting a bilinear pairing, in particular an asymmetric bilinear pairing, - providing the first public key to the recipient device; - selecting, by the provider device PD, one of the one or more second key pairs; - obtaining, by said provider device PD, one or more messages of a first type; - generating, by the provider device PD, for each of the one or more messages of the first type a respective hash; - composing, by said provider device PD, an authentication message comprising said generated hash and said second public key of said selected second key pair or data suitable for deriving said second public key of said selected second key pair; - the provider device PD signs the composed authentication message using the first private key to generate a signed aggregate authentication message; - distributing, by the provider device via the one-to-many communication channel, the signed aggregate authentication message to the recipient device; - after distributing the signed aggregate authentication message, distributing by the provider device PD to the recipient device via the one-to-many communication channel the one or more messages of the first type; - obtaining, by said provider device PD, one or more messages of a second type after distributing said signed aggregate authentication message; - signing, by the provider device PD, the one or more messages of the second type using the second private key of the selected second key pair to create an associated signature; and - distributing, by the provider device via the one-to-many communication channel, the one or more messages of the second type together with the associated signature to the recipient device.

2. The method according to claim 1, further comprising: - authenticating the signed aggregate authentication message by the recipient device using the first public key; - authenticating, by the recipient device, the one or more messages of the first type using a corresponding hash distributed with the signed aggregate authentication message; - deriving, by the recipient device, the second public key of the selected second key pair from the signed aggregate authentication message; as well as - authenticating, by the recipient device, the one or more messages of the second type using the associated signature and the derived second public key of the selected second key pair.

3. The method according to claim 1, further comprising: - encrypting each second public key in the subset of the one or more second key pairs using a dedicated symmetric security key KDK; as well as - providing the encrypted second public key to the recipient device, in particular providing the encrypted second public key to the recipient device before generating the second type of message; wherein, - said authentication message selectively comprises said second public key of said selected second key pair or said data suitable for deriving said second public key of said selected second key pair; and - said data comprises a random number and said dedicated symmetric security key KDK for decrypting the encrypted second public key.

4. The method according to any one of claims 1 to 3, wherein - the first key pair is repeatedly generated by the provider device PD or a trusted entity at a first repetition rate and subsequently stored in the provider device PD, each generated first key pair being different from the first key pair of a previous copy; and -Selection of said one of said one or more second key pairs is performed at a second repetition rate higher than said first repetition rate, in particular at a second repetition rate at least 100 times higher than said first repetition rate, each selected second key pair being distinguishable from any selected second key pair of a previous copy.

5. The method according to claim 4, wherein - if obtaining the one or more second key pairs comprises obtaining a single second key pair, performing obtaining the one or more second key pairs and selecting the one of the one or more second key pairs at the second repetition rate; and -If obtaining the one or more second key pairs includes obtaining more than one second key pairs, selecting one of the one or more second key pairs is performed at the second repetition rate, and obtaining the one or more second key pairs is performed at the first repetition rate or at a third repetition rate that is higher than the first repetition rate and lower than the second repetition rate.

6. The method according to any one of claims 1 to 3, wherein: Signing the composed authentication message and / or signing the one or more messages of the second type is based on a short signature scheme, in particular using a pairing-friendly Barreto-Naehrig curve or a Barreto-Lynn-Scott curve, which produces a corresponding signature corresponding to a corresponding single elliptic curve point.

7. The method according to claim 6, wherein: Signing the composed authentication message and / or signing the one or more messages of the second type is based on a Type III pairing scheme, which is defined as: {q,G1,G2,G T ,e:G1×G2→G T ,P∈G1,Q∈G2,H:{0,1} * →Z q } Among them, G T is a multiplication pairing group, H is defined to generate the field Z q The cryptographic hash function, x is the number of cells from the field Z q A randomly selected private key, and where the signature S of a message m is calculated according to:

8. The method according to claim 1, wherein: The hash is generated based on an intermediate key derived from at least a portion of the composed authentication message.

9. The method according to claim 1, wherein: Each hash is a keyed-hash message authentication code.

10. The method according to claim 8 or 9, wherein: The constructed authentication message also includes a control section, the control section including information about at least one of the following: - the key to be used to generate said hash; - the hash function to be used to generate said hash; - the number of rounds to be used to generate said hash; - The truncation level to use to generate the hash.

11. A computer program product, comprising instructions, which, when executed on two or more processors of at least a provider device and a recipient device, cause the two or more processors to perform the method according to any one of claims 1 to 10.

12. A provider device PD for a one-to-many communication network, wherein - generating, by the provider device PD or a trusted entity, a first key pair based on a first generator P selected from a first group swizzling group G1 of a first order q and a second generator Q selected from a second group swizzling group G2 of the first order q, the first key pair comprising a first private key and a first public key and supporting a bilinear pairing, in particular an asymmetric bilinear pairing, wherein, The first private key is based on a random number in the interval]0;q-1], and the first public key is calculated using the second generator Q and the first private key; - providing the first public key to the recipient device; - generating, by the provider device PD or the trusted entity, one or more second key pairs based on a second order q′ smaller than the first order q, each second key pair comprising a respective second private key and a respective second public key and supporting a bilinear pairing, in particular an asymmetric bilinear pairing; The provider device is configured to: - obtaining the first key pair and the one or more second key pairs; - obtaining one or more messages of a first type; - selecting one of the one or more second key pairs; - generating a respective hash for each of the one or more messages of the first type; - forming an authentication message comprising the generated hash and the second public key of the selected second key pair or data suitable for deriving the second public key of the selected second key pair; - using the first private key to sign the composed authentication message to generate a signed aggregate authentication message; - distributing the signed aggregate authentication message to the recipient device via a one-to-many communication channel; - after distributing the signed aggregate authentication message, distributing the one or more messages of the first type to the recipient devices via the one-to-many communication channel; - after distributing said signed aggregate authentication message, obtaining one or more messages of a second type; - signing the one or more messages of the second type using the second private key of the selected second key pair to create an associated signature; as well as - distributing said one or more messages of the second type together with said associated signature to said recipient devices via said one-to-many communication channel.

13. The provider device PD according to claim 12, wherein - Each second public key in the subset of the plurality of second key pairs is encrypted using a dedicated symmetric security key KDK and distributed to the recipient device, in particular before generating the second type of message; - the authentication message selectively comprises the second public key of the selected second key pair or data suitable for deriving the second public key of the selected second key pair; and - said data comprises a random number and said dedicated symmetric security key KDK for said second public key.

14. A receiving device for a one-to-many communication network, wherein - generating, by a provider device PD or a trusted entity, a first key pair based on a first generator P selected from a first group swizzled group G1 of a first order q and a second generator Q selected from a second group swizzled group G2 of said first order q, said first key pair comprising a first private key and a first public key and supporting a bilinear pairing, in particular an asymmetric bilinear pairing, wherein, The first private key is based on a random number in the interval]0;q-1], and the first public key is calculated using the second generator Q and the first private key; - providing the first public key to the recipient device; - generating, by the provider device PD or the trusted entity, one or more second key pairs based on a second order q′ smaller than the first order q, each second key pair comprising a respective second private key and a respective second public key and supporting a bilinear pairing, in particular an asymmetric bilinear pairing; - obtaining, by said provider device PD, one or more messages of a first type; - selecting, by the provider device PD, one of the one or more second key pairs; - generating, by the provider device PD, for each of the one or more messages of the first type a respective hash; - composing, by said provider device PD, an authentication message comprising said generated hash and said second public key of said selected second key pair or data suitable for deriving said second public key of said selected second key pair; - the provider device PD signs the composed authentication message using the first private key to generate a signed aggregate authentication message; - obtaining, by the provider device PD, one or more messages of a second type; - signing, by the provider device PD, the one or more messages of the second type using the second private key of the selected second key pair to create an associated signature; The receiving device is configured as follows: - storing the first public key; - receiving said signed aggregate authentication message from said provider device PD via a one-to-many communication channel; - authenticating the signed aggregate authentication message using the first public key; - deriving the second public key of the selected second key pair from the signed aggregate authentication message; - receiving said one or more messages of the first type from said provider device PD via said one-to-many communication channel; - authenticating said one or more messages of the first type using a corresponding hash distributed with said signed aggregate authentication message; - receiving said one or more messages of the second type together with said associated signature from said provider device PD via said one-to-many communication channel; and - authenticating said one or more messages of the second type using said associated signature and the derived second public key of said selected second key pair.

15. A communication system for a one-to-many communication network, the communication system comprising a provider device according to claim 12 or 13 and a receiver device according to claim 14.

Images