Method and device for authenticating a primary station

Abstract

The present invention relates to a method, apparatus, and system for secure communications in which an end device receives a first system information message from or via a first primary station, decodes the first system information message to obtain a “protected field,” uses the “protected field” to locate “security information,” and uses the “security information” to verify the received message and / or the first primary station and / or send a subsequent secure message to the first or third primary station.

Description

[Technical Field]

[0001] The present invention relates to the field of wireless communications, and in particular to security aspects of communications between primary stations (e.g. base stations) and secondary stations (e.g. terminals or mobile stations) forming a network in which other entities, such as security entities, may be present. [Background technology]

[0002] In wireless networks, terminals connect to the network to exchange data. Security is especially important for wireless devices, which do not require physical interaction to access the network. Therefore, wireless networks must implement measures that allow them to exclude devices that are not authorized on the network.

[0003] One conventional attack involves an attacker impersonating an entity in a wireless network, particularly a primary or base station. Consequently, many countermeasures aim to authenticate the identity of various entities in the network.

[0004] In these communication systems shown in FIG. 1, secondary stations 100 operate as terminals or end devices (also called user equipment (UE) in 5G, or end devices (ED) in the present invention). The secondary stations can access various types of services, such as voice and data services, via primary stations 110 operating as deployed base stations (also called gNB in ​​5G). Each primary station 110 provides service and communication to secondary stations 100 located within its area, also called cell 111. The primary stations are connected to a core network (CN) 120 managed by a network operator that controls the communication system and coordinates the delivery of services.

[0005] As mentioned above, an attacker can use a "fake" base station (FBS) to impersonate a network entity, such as a primary station, and attack secondary stations in a variety of ways. The FBS acts as a proper primary station controlled by the network operator and attempts to attract UEs for various purposes, such as performing DoS attacks, obtaining private user data, performing Man-in-the-Middle (MitM) attacks, and subsequent attacks (e.g., aLTEr, imp4gt, network misconfiguration).

[0006] 3GPP (registered trademark) defines a system including a secondary station or end device ED (100) and a primary station or base station (110) used in a wireless communication system such as 2G, 3G, 4G, or 5G. The ED connects to a core network through the primary device. The connection procedure between the ED and the primary station includes the following steps: The primary station broadcasts system information, especially MIB and SIB1; The ED receives system information from one or more primary stations; · The ED selects the primary station based on various criteria such as signal strength and preference, The ED obtains random access parameters from the SIB1 of the selected primary station; the ED transmitting a first random access message to the primary station; The primary station responds to the ED with a second random access message.

[0007] The above procedure can be a two-message RACH or a four-message random access procedure.

[0008] For example, the broadcast of system information needs to be protected to ensure that EDs only join trusted primary stations or to allow EDs to verify information broadcast by primary stations (e.g., public warning messages or coverage information in non-terrestrial networks). Also, it needs to be prevented that EDs join older generation FBSs if those older generation base stations (e.g., 2G) have already been decommissioned.

[0009] One option is to attach security information used to verify the integrity and freshness of the SIB to the SIB itself. However, SIBs are limited in size at the physical layer to approximately 3000 bits. Furthermore, since SIBs already contain a significant amount of data, the space left for security information is limited. Typical sizes of security information range from 260 bits to several thousand bits, so in many cases the security information will not fit within the SIB itself that needs protection.

[0010] One option consists of broadcasting the security information in a SIB as well, for example a new SIB whose periodicity and timing are precisely aligned with those of the existing system information (for example, the same periodicity as MIB or SIB1, broadcast periodically every 80 ms or 160 ms and potentially repeated multiple times within that period). One specific option consists of broadcasting the security information on the same frequency and in the same time slot. However, this consumes a considerable amount of communication resources (spectrum) and energy.

[0011] Another issue is that legacy primary devices, such as 3G or 4G, may not support system information broadcasting, so systems relying on legacy technology are still vulnerable to attacks.

[0012] Another issue arises from the fact that low-cost ambient IoT tags (small, low-power devices) may be required to provide some data, such as sensing or identification data, but they may only want to provide such data to trusted devices. Summary of the Invention

[0013] One object of the present invention is to alleviate the above problems.

[0014] Another aspect of the invention proposes that the primary device broadcasts security information used to verify the system information of the primary device on demand, i.e., upon request from the ED.

[0015] Another aspect of the present invention proposes that the second primary device broadcasts, on demand, i.e., upon request from the ED, security information used to verify the system information broadcast by the first legacy primary device.

[0016] The detailed embodiments show other aspects of the present invention that may be realized by appropriately combining a number of different embodiments.

[0017] Another object of the present invention is to provide a method that makes it difficult for an attacker to access or impersonate an entity on a network.

[0018] It is yet another object of the present invention to provide a secondary station that is able to detect a false base station and ignore its messages.

[0019] Therefore, according to a first aspect of the present invention, an apparatus as claimed in claim 1 is proposed. A controller; a receiver; a transmitter, the receiver receives a first system information message transmitted from or via the first primary station; The controller decodes the first system information message to obtain a protection field, and determines a location of the "security information" using the protection field; The controller uses "security information" to Verifying the received message and / or the first primary station; and / or An apparatus is proposed that causes the transmitter to transmit a subsequent secure message to the first primary station or to a third primary station.

[0020] In a first variant of the first aspect of the present invention, an apparatus comprises: sending a "security information request" to the first primary station or the third primary station; Receive "security information" from the first primary station, The received "security information" is used to verify a previously received first system information message or a second system information message received from a second primary station. Optionally, the device may transmit a security information request based on the determined location of the security information.

[0021] Further, in the first variant, the device sends a "security information request" to the first primary station or the third primary station, and the security information request requests security information for verification of the system information message, and the request satisfies the following conditions: - the device belongs to a certain type, - a system information message is being sent by a primary station with a specific ID, - System information messages are sent at specific times or time frames; - System information messages are being sent within a specific area may be transmitted if at least one of the following is satisfied:

[0022] In a second variation of the first aspect, the "security information" of the first primary station is obtained from a distributed ledger.

[0023] In another example of the above variation, a "Security Information Request" may be sent in the initial PRACH message.

[0024] In a third variation of the first aspect, which may be combined with the above variations or options, the freshness of the first system information message is verified by comparing the device's local time with a signature time of the security information after modification using a timing advance indicated by the primary station, the timing advance being secured by the security information.

[0025] In a fourth variation of the first aspect, which may be combined with any of the variations or options described above, the apparatus comprises: receiving a second system information message; The second system information message may be validated based on the security information received to validate the first system information message.

[0026] Optionally, the device validates the second system information message using the Merkle tree structure.

[0027] In a fifth variation of the first aspect, which may be combined with any of the above variations or options, a “protected field” in the first system information message includes a challenge used by the device to verify the primary station using the first function P() and the secret internal state variable.

[0028] Optionally, or alternatively, a "protected field" contains one or more IDs that the device uses to determine whether it needs to further process the first system information message it receives.

[0029] Additionally, the secret internal state variable may be updated based on at least the received challenge, the previous value of the secret internal state variable, and the second function PP( ).

[0030] In a sixth variant, which may be combined with the fifth variant or options thereof, the subsequent secure message includes information in a "protected field", secret internal state information, and data whose confidentiality is protected based on the third variable PPP().

[0031] In a seventh variant, which may be combined with the fifth or sixth variant or options thereof, the integrity of a subsequent secure message is protected and / or a new proof of the secret internal state is obtained based on the information in the "protected field", the secret internal state information and the fourth function PPPP().

[0032] In the fifth to seventh modifications, the first, second, third, and fourth functions are further defined as follows: Physically unclonable functions, A list of challenge-response values ​​stored in memory, Secret sorting, hash functions such as ASCON-HASH, Extensible output functions such as ASCON-XOF, Authenticated encryption algorithms such as ASCON-AE It can be one or more of:

[0033] According to a second aspect of the present invention, in claim 16, A controller; A receiver; a transmitter, the controller causes the transmitter to broadcast a first system information message including a "protected field"; An apparatus is proposed in which the receiver receives a "security information request" and / or a secure message from the end device ED.

[0034] In a first variation of the second aspect of the present invention, the controller: securely processing the secure message by extracting data contained in the secure message based on information in the "protected field", the ED's secret internal state information; and / or Security information for the first system information message may be determined and the security information may be transmitted.

[0035] Optionally, a receiver receives the second secure message and securely processes the second secure message.

[0036] Alternatively, the security information is included in the random access response message.

[0037] In a second variant, which may be combined with the first variant or its options, the "security information" may be: fields in the random access response message, such as timing advance, and / or Protect the integrity of the properties of the security information request message, such as the beam used to receive the security information request message.

[0038] According to a third aspect of the present invention, in claim 21 there is proposed a method for secure communication with a primary station, the method comprising: receiving a first system information message from or via a first primary station; decoding the first system information message to obtain a "protected field"; locating "security information" using a "protected field"; Use "Security Information" to Verifying the received message and / or the first primary station; and / or and transmitting a subsequent secure message to the first primary station.

[0039] According to a fourth aspect of the present invention, in claim 22 there is proposed a method for secure communication with an end device, the method comprising: broadcasting a first system information message including a "protected field"; receiving a "security information request" and / or a secure message from the end device.

[0040] A fifth aspect of the present invention provides a system comprising the device of the first aspect or a variant thereof and the device of the second aspect or a variant thereof.

[0041] In a sixth aspect of the present invention, a computer program for secure communications is proposed, the program comprising instructions for implementing the apparatus of the first or second aspect.

[0042] It is to be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or the above embodiments with the independent claims.

[0043] These and other aspects of the invention will be elucidated with reference to the embodiment(s) described hereinafter. [Brief explanation of the drawings]

[0044] [Figure 1] FIG. 1, discussed above, is a block diagram representing a cellular network in which the present invention may be implemented. [Figure 2] FIG. 2 is a flow chart illustrating a method according to various aspects of the present invention. [Figure 3] FIG. 3 is a flowchart illustrating a method according to various aspects of the present invention, focusing on security protocols for communication with end devices. [Figure 4] FIG. 4 depicts centralized and distributed deployment scenarios of the present invention. [Figure 5] FIG. 5 is a block diagram showing a secondary station according to the first embodiment of the present invention. [Figure 6]FIG. 6 is a flowchart illustrating a method according to various aspects of the present invention, focusing on secure delivery of SIB content. DETAILED DESCRIPTION OF THE INVENTION

[0045] As noted above, the present invention may be implemented as a cellular network, such as a 5G network. As shown in Figure 1, such a cellular network includes a number of terminals or secondary stations 100, which are mobile devices (or UEs) that may move from one network cell to another. Each cell 111 is served by a primary station 110 (or gNodeB), which interfaces between the secondary stations 100 and a core network 120.

[0046] Thus, the secondary station 100 communicates with the primary station 110 over various uplink (secondary to primary) and downlink (primary to secondary) wireless channels. Other wireless channels exist (e.g., between secondary stations (e.g., sidelink channels) and between primary stations (e.g., the X2 interface)) but are not shown in FIG. 1 for simplicity. While embodiments of the present invention are applicable to these interfaces as well, the following discussion focuses on the link between the secondary and primary stations.

[0047] To allow secondary stations to connect to the network, the primary station 110 may broadcast some configuration information over the cell 111. This configuration information includes a Master Information Block (MIB) and a System Information Block. First, the MIB is a message broadcast periodically (e.g., every 80 ms) that contains all the information necessary to enable decoding of subsequent SIBs. MIB::=SEQUENCE systemFrameNumber BIT STRING(SIZE(6)), subCarrierSpacingCommon ENUMERATED {scs15or60,scs30or120}, ssb-SubcarrierOffset INTEGER(0..15), dmrs-TypeA-Position ENUMERATED{pos2,pos3}, pdcch-ConfigSIB1 INTEGER(0..255), cellBarred ENUMERATED{barred,notBarred}, intraFreqReselection ENUMERATED{allowed,notAllowed}, spare BIT STRING(SIZE(1)) }

[0048] After acquiring the MIB, the secondary station can decode several System Information Blocks (SIBs), which may be sent periodically (e.g., every 80 ms, every 160 ms) or upon request from the secondary station. These SIBs describe the network's operation and parameters. To improve the overall network security, it is proposed to add digital signatures to these SIBs to prevent anyone from impersonating the primary station. Digital signatures are a technique for binding an entity to digital data. This binding is independently verifiable not only by the receiver but also by a third party. A digital signature is therefore a cryptographic value calculated from the data and a private key known only to the signer. In this case, the data corresponds to the payload carried within the SIB itself. The signature provides the secondary station with assurance that the message belongs to the primary station.

[0049] In the 5G example, one option is for the digital signature generator in the core network 120 to generate a signature for each message upon request from the primary stations 110 and provide it to these primary stations. Another option is for each primary station to have a digital signature generator. This solution may be used for at least some messages and can reduce the load on the digital signature generator in the core network.

[0050] 5 is a block diagram illustrating a secondary station 500 according to one embodiment of the present disclosure. The secondary station comprises a communication unit 501 including a receiver 502 and a transmitter 503 configured to communicate within a network, such as a 5G cellular network.

[0051] The receiver 502 includes at least one antenna or an antenna array having multiple antennas. The receiver may be configured to receive messages transmitted from multiple primary stations. The messages may be system information (SI) messages for configuring the secondary station communication unit 501 in the communication network. Each SI message includes a respective time reference associated with a respective primary station. The secondary station 500 further includes a controller 504 for controlling the operation of the secondary stations. The controller may be a computer programming unit or other combination of hardware and software. The controller 504 is configured to check the validity of the received signature for each primary station and, for at least each primary station having a valid signature, check a cell identifier. The controller 504 then ignores time reference information from a primary station whose cell identifier is identical to that of another primary station and has an earlier value than the time reference information from the other primary station. Finally, the controller 504 infers a local time reference from one or more of the time reference information derived from the primary stations having valid signatures.

[0052] In a first general embodiment that addresses multiple issues, the connection procedure between an ED and a primary station includes the following steps: 1. The primary station broadcasts system information, especially MIB and SIB1, including "protected fields"; 2. An ED receiving system information from one or more primary stations uses the "protection field" to determine the location of the "security information"; 3. The ED sends a "View on Demand" or "Security Information Request" message; 4. The primary station calculates / obtains and transmits "security information" associated with the system information; 5. ED receives "security information"; 6. ED will verify the "System Information."

[0053] This is shown in Figure 2, where 200 refers to the ED and 201 refers to the primary station. Messages are represented by arrows, and the direction of the arrow indicates the entity to which the message is sent. Arrows / messages exchanged on the upper side are exchanged before arrows / messages exchanged on the lower side. Message 202 represents a message containing a "protected field". Message 203 represents a message containing a "display on demand" or a "security information request". Message 204 represents "security information". Finally, message 205 indicates the final response by 200 after verification of the security information. The advantage of this configuration is that the ED can receive system information such as MIB / SIB1 as usual without communication overhead, and can provide security information to the ED if requested by the ED (e.g., during a random access procedure).

[0054] In one embodiment, step 3 is performed upon transmission of the PRACH message and step 4 is performed before receiving the RAR message (message 2 of the random access procedure), which allows for easy integration into existing communication systems.

[0055] In one aspect of the embodiment, the ED may cache the "security information" received in the previous message in a local storage, for example in the USIM, which has the advantage of reducing resource consumption since the ED does not need to request the "security information" again.

[0056] In one aspect of the embodiment, the ED may have local access to the "security information" determined within the "protected field", and thus the ED may be able to verify the "system information" directly without having to send a "display on demand" message. For example, such information may have been pre-configured in the ED and it may have been acquired / received in a previous interaction.

[0057] In one embodiment, the primary station broadcasts system information including MIB and SIB1 at an existing periodicity, and SIB1 and / or MIB includes a "protection field" indicating whether the system information (e.g., MIB and / or SIB1) is protected. If protected, the ED may decide to continue the network access procedure with the primary station and obtain "security information" used for verification.

[0058] In one embodiment, the "protection field" that indicates whether the system information block is protected is a flag, such as a single bit set to 1 or 0.

[0059] In one embodiment, the "protection field" that indicates whether the system information is protected is a structure that includes one or more fields such as: Protected system information, e.g. SIB1 and / or (MIB and SIB1) and / or (PCI and MIB and SIB1) and / or (PBCH fields and PCI and MIB and SIB1) and / or other SIBs (e.g. SIB19 used in non-terrestrial networks), Protectable system information (e.g., PBCH fields and / or PCI and / or MIB and / or SIB1 and / or time values ​​and / or other SIBs, etc.), Cell physical IDs (e.g., in the same area) that allow security information to be requested on demand (e.g., a UE may not have security information available but wants to join a 4G cell, and a nearby 5G cell broadcasts the cell ID of the 4G cell, allowing the UE to obtain the security information needed to validate the 4G cell via / from the nearby 5G cell), · The structure / parts of the "security information", e.g. - digital signature, - certificate, - the current time value, - past time values, - Signature algorithm. Location of all or part of the security information (e.g., attached to the same SIB, sent in a different SIB), If security information is transmitted in different SIBs, the frequency band / timing resources used to transmit the security information; - Primary station ID for on-demand security information retrieval; The algorithm used to protect system information (e.g., ECDSA), Security solutions or procedures that can be used to protect system information, for example, hash-based solutions and / or signature / certificate-based solutions (as described in the following embodiments or in TR33.809); "On-demand viewing" for all or part of security information (e.g., system information received is digitally signed and certificates can be received on demand); A distributed ledger or location within a distributed ledger that stores security information used to verify a cell's system information.

[0060] In one aspect of the invention, the "protected field" may determine whether a received SIB is digitally signed and whether a certificate can be received on demand.

[0061] In a further aspect of the invention, the "protected field" determines whether the signature and certificate can be received on demand in a single SIB.

[0062] In a further aspect of the invention, the "protected field" determines whether a signature can be received in a different SIB sent periodically and whether a certificate can be received on demand in a different second SIB.

[0063] In a further aspect of the invention, "security information" may be broadcast in a first SIB to accommodate verification of system information delivered in another SIB.

[0064] In a further aspect of the invention, the "security information" includes a digital signature.

[0065] In a further aspect of the invention, the digital signature is based on either ECDSA, RSA, or ECCSI.

[0066] In a further aspect of the invention, the digital signature refers to a message integrity code calculated using a hash chain value that has not yet been disclosed, as in TESLA.

[0067] In a further aspect of the invention, "security information" includes a digital certificate, or a subset of a digital certificate, used to verify a public key needed to verify a digital signature.

[0068] In a further aspect of the invention, the "security information" includes a digital signature and / or a digital certificate.

[0069] In a further aspect of the invention, the ED is configured with a public key associated with a private key owned by a trust anchor, e.g., a network operator, etc. The private key associated with the trust anchor can be used to sign (create a certificate) the public key of a public key pair used by the primary device (primary station) to sign system information broadcast by the primary device.

[0070] In a further aspect of the invention, the public key pair used by the primary device (primary station) to sign the system information refers to the hash chain used in the TESLA scheme.

[0071] In a further aspect of the present invention, the public key pair used by the primary device (primary station) to sign the system information refers to the public key pair and hash chain used in the TESLA scheme.

[0072] In a further aspect of the invention, the "security information" includes an indication of what system information the security information protects, for example, when SIB1 is broadcast from the initial time to the end time.

[0073] In a further aspect of the invention, the "security information" includes an indication of when the signature was created, for example with reference to a global time such as UTC time or a local time such as SFN.

[0074] In a further aspect of the invention, the digital signature is calculated based on system information, eg, the SIB.

[0075] In a further aspect of the invention, the digital signature is calculated based on a field (eg, PCI) in the MIB and / or SIB and / or the PBCH channel over which the MIB is broadcast.

[0076] In a further aspect of the invention, the digital signature is calculated based on a time value, such as a UTC-based value, eg a UTC-based counter or the least significant bits of a UTC-based counter, or an SFN value.

[0077] In a further aspect of the invention, the digital signature delivered on demand covers or signs a timing advance value specific to the distance between the ED and the primary station. The reason for signing the TA value is that it is related to the propagation delay from the primary station to the ED. Assuming that the clocks of the ED and the primary station are perfectly synchronized, a MitM attacker could manipulate the TA value (to a higher value) to intercept, modify, or insert messages, because doing so would cause the ED to attribute the delayed reception of the message to propagation delays and not to the presence of a MitM. In this context, when the ED receives security information during a random access procedure (e.g., together with message B in a two-message random access procedure), the same message also contains an estimate of the TA parameter estimated by the primary station. Therefore, this TA parameter may be signed to prevent MitM manipulation of communications.

[0078] In a further aspect of the invention, the digital signature delivered on demand covers or signs other communication parameters specific to the communication link used by the ED (e.g., the beam used to perform the random access procedure).

[0079] In a further aspect of the invention, the digital signature delivered on demand covers, signs, or is computed using as input other parameters or fields contained in the message used to deliver the digital signature (e.g., fields of message B in a two-message random access procedure (RAR message) used to deliver security information). In other words, the signature is computed using system information and at least fields in the message carrying security information as input.

[0080] In a further aspect of the invention, a) the primary station transmits security information (e.g., in message B of a two-message random access procedure) that includes signed information regarding, for example, (1) the primary station's time Ts_sig at the time of transmission of the security information, (2) the timing advance TA observed / calculated by the primary station, and / or (3) the time Ts_SI at the time of transmission of system information (e.g., SIB1, MIB); and / or b) when the end device receives the security information, it determines whether the security information is up-to-date / new by comparing ABS((ED_time-TA)-Ts_sig) with the T_w parameter; where ED_time is the local ED time and ABS(x) returns the absolute value of x; and / or c) when the end device receives the security information, verifying that the system information is up to date by checking whether the system information was received at time Ts_SI, where Ts_SI may be an absolute value or a value relative to the receipt of the security information; and / or d) When the end device receives the security information, it verifies the system information using the information received in the security information.

[0081] In a further aspect of the invention, the primary station signs only static fields of the system information, i.e., excludes variable fields such as SFN values, so that the security information can be used to verify multiple sets of system information (e.g., MIB or SIB1) transmitted in different time slots.

[0082] In a further aspect of the invention, the primary station signs both static and dynamic fields of the system information, i.e., fields including variable fields such as SFN values, so that the security information is specific to the particular system information, e.g., MIB or SIB1, transmitted in a particular timeslot.

[0083] In a further aspect of the invention, the primary station indicates whether only static fields are signed or whether dynamic fields are also signed, which may be indicated in the security information itself or within a "protected field."

[0084] In a further aspect of the present invention, an ED that requests verification of system information (e.g., MIB / SIB1) transmitted in time slot k and receives security information from a primary station that can verify the system information transmitted in time slot k' (e.g., k'=k-1) comprises: without sending a new request for new security information for time slot k, Verify the system information for time slot k' by replacing k with k'; · There is a possibility to verify that the time difference between time slots k and k' is consistent with the primary station's signing time (associated with k') and the ED's local time (associated with the time linked to time slot k when the system information was acquired).

[0085] In a further aspect of the invention, the ED verifies the system information using information received in the security information, for example, a digital signature such as ECDSA or ECCSI, or a message integrity code used in schemes such as TESLA.

[0086] In a further aspect of the present invention, the ED determines whether security information is up-to-date / new based on at least one of the following. · Absolute comparison, for example, whether ABS((ED_time - TA) - Ts_sig) < T_w · Relative comparison, for example, ABS((ED_time - TA) - Ts_sig) / T_w · A policy set in the ED that determines the T_w value · A policy set in the ED that determines how large ABS((ED_time - TA) - Ts_sig) may be compared to T_w · A policy set in the ED that determines which absolute / relative comparison is permitted in different context situations (e.g., normal access to the cell, emergency situation). For example, in normal access, it is only permitted when ABS((ED_time - TA) - Ts_sig) / T_w < 1, while in emergency access, it may be permitted when ABS((ED_time - TA) - Ts_sig) / T_w > 1.

[0087] In a further aspect of the present invention, the ED may have a configuration or policy such that when the ED accesses the cell / network in emergency mode, even if the cell provides security information, the ED does not need to request / verify the security information of the cell.

[0088] In a further aspect of the present invention, in the primary station, at least one of the following is set by a network function in the core network (e.g., DSnF (Digital Signature Network Function)) or by an OAM (Operations, Administration, and Maintenance entity). · Key materials such as signature keys · Digital certificates · Security policies · Schedule broadcast or on-demand delivery of security information.

[0089] In a further aspect of the invention, the primary station schedules its own security information, e.g., keying material such as a signature key, digital certificates, security policies, broadcast or on-demand delivery of security information, and uploads the public information (e.g., public key) to a distributed ledger (e.g., blockchain) to make this information public and allow other UEs to retry.

[0090] In a further aspect of the invention, the primary station may be notified, for example by the OAM or the NF in the CN, of which security procedures / measures (e.g., hash-based solutions (e.g., those described above or in solutions #14 or #19 of TR33.809), signature / certificate-based solutions (e.g., those described above or in solutions #20 or #27 of TR33.809), none, etc.) are being used to - Can be used, enabled or disabled; and / or - Conditions for doing so (e.g., time-based, location-based conditions), and / or -Policies may be set that determine which devices can run it.

[0091] This aspect of the invention, as well as other aspects of the present application (e.g., those described below), has the advantage of being able to support and / or negotiate and / or select different types of solutions (e.g., hash-based, signature / certificate-based, etc.), as different solutions may be (more or less) appropriate depending on the use case, network, or type of device.

[0092] In a further aspect of the present invention, the ED is configured with a policy, which may be hard-coded into the technical specifications of the communication standard, that specifies that the ED / UE cannot request security information when the ED is in a particular situation (e.g., emergency access).

[0093] In a further aspect of the invention, the primary station may also include, for example in SIB1, an indication of the security mechanisms that the primary station has authorized for use, enabled, and / or disabled (security mechanism indication).

[0094] In a further aspect of the invention, the primary station includes the indication (security mechanism indication) in a "protection field" that determines how system information is protected.

[0095] In a further aspect of the invention, the indication may be specific to the ED or type of ED (e.g., the ED may be a standard UE, an IoT UE, a law enforcement UE, or an ambient IoT tag). For example, the indication may be: - IoT UEs must use signature / certificate-based solutions (e.g., on-demand) and must not use hash-based solutions; - A standard UE may use either a signature / certificate-based solution (e.g., on-demand) or a hash-based solution, based on local UE / ED policy; - Ambient IoT tags can request security information for specific types This may indicate:

[0096] In a further aspect of the invention, the security mechanism indication may be a bit flag indicating which countermeasures are enabled / disabled / supported.

[0097] In a further aspect of the invention, the primary station and / or ED may support multiple countermeasures and negotiate which ones to apply.

[0098] In a further aspect of the invention, if both the ED and the primary station support multiple countermeasures, the selection of the security mechanism may be determined according to the requirements of either (eg, the ED).

[0099] In a further aspect of the invention, the ED may require the use of "none" as a security measure in certain cases, such as emergency situations. "none" may be expressed simply by not transmitting an "on-demand presentation."

[0100] In a further aspect of the invention, the primary station may choose to accept or reject the use of "none" as a security mechanism depending on its security policy and / or the type of ED.

[0101] In a further aspect of the invention, an ED may be configured with policies that determine the types of networks the ED can join and / or prefers to join based on the security measures the ED supports and the security measures the network provides / supports / uses. For example, an ED may only be able to join a particular type of network / cell (e.g., a 3G cell / primary station) if it has (obtains / receives) security information that allows verification of that network / cell.

[0102] In a further aspect of the invention, the ED may include an apparatus and / or employ a method for receiving an indication (security mechanism indication) from the primary base station and determining the security mechanism to use for verification (e.g., system information verification) based on the indication and / or security measures supported by the ED and / or configured policies.

[0103] In a further aspect of the invention, the EDs are configured with the above policies by the network operator through standard signaling when communicating with the core network (eg, with the NFs in the CN).

[0104] In a further aspect of the invention, the above policies are set in the ED before deployment.

[0105] In a further aspect of the present invention, the above policy is set in the ED by a network function within 5GS.

[0106] In a further aspect of the invention, the ED has a USIM that includes the policy.

[0107] In a further aspect of the invention, the MIB or SIB1 includes an "on-demand display" that relates to the procedures necessary to obtain the security information necessary to validate the MIB and / or SIB1.

[0108] In a further aspect of the invention, an ED that requires certain security information to be (potentially) broadcast on demand first scans the time / frequency resources specified in the "protected field" and only sends a "security information request" if no SIB is detected. This is advantageous, for example, when the delivery of security information (message 204 in FIG. 2) has already been scheduled for a first ED (which previously sent a security information request (message 203 in FIG. 2)), in which case the broadcast of such information may be announced in message 202 in FIG. 2, which may be broadcast / delivered periodically. Thus, when a second ED receives message 202 containing the time / frequency resources on which the security information is to be delivered, the second ED has direct access to such security information.

[0109] In a further aspect of the invention, the primary station uses a combined approach of periodic broadcast of security information and on-demand delivery of security information, allowing the ED to monitor the channel for periodic updates (e.g., certificate updates) without having to explicitly request them, and also to obtain security information as needed. This primary station configuration is conveyed by a "protected field."

[0110] In a further aspect of the invention, the "protected field" indicates that security information can be obtained by transmitting an initial PRACH message.

[0111] In a further aspect of the invention, a "protected field" relates to a specific frequency / time region in which an ED must transmit an "on-demand presentation" or "security information request" to trigger the delivery of security information.

[0112] In a further aspect of the invention, the "security information request" is sent by the ED via a unicast or multicast message.

[0113] In a further aspect of the invention, the "security information request" sent from the ED to the primary station may be a message that includes one or more of the following: An anonymous signal common to all EDs indicating a "security information request"; System information that needs to be verified (e.g., SIB1, MIB, etc.), the time when system information was read, is being read, or is scheduled to be read; Required security information (e.g., digital signatures and / or certificates), and / or PCI of the cell whose security information is required; ·others.

[0114] In a further aspect of the invention, the above fields may be explicit or implicit for the "Indication on Demand" / "Security Information Request" message, for example, reception of an "Indication on Demand" on a particular frequency band indicates that the UE requires a signature of security information (e.g., SIB1) for the current SFN or the current SFN and MASK, where MASK is, for example, 0x3F0, and SFN and MASK returns the most significant 6 bits of the SFN.

[0115] In a further aspect of the present invention, the "protection field" may include a first nonce (random number), the "on-demand protection" / "security information request" may include a second nonce, and the "security information" is calculated using the first nonce and / or the second nonce as input. This allows the ED to verify the freshness of the security information. For example, if the ED sends a second nonce and the digital signature of the "security information" is calculated using the second nonce, the ED can verify the freshness of the message.

[0116] In a further aspect of the invention, when a "security information request" is received at the primary station from the ED, the primary station calculates and / or collects the necessary security information and transmits the security information to the ED.

[0117] In a further aspect of the invention, the primary station calculates security information by signing the system information with a current time value, e.g., the current UTC time or the current SFN value, so that if the UE is time synchronized, the UE can verify the currency of the security information, or if the security information also includes a signed second NONCE and the UE trusts the primary station as in the above embodiment, the UE can know the current time of the primary station.

[0118] In a further aspect of the invention, the primary station, when requested by the ED or when the ED receives the system information, calculates security information by signing the system information with a past time value, e.g., a past UTC time and / or a partial SFN value.

[0119] In a further aspect of the invention, the primary station may calculate security information by signing system information along with past and current time values.

[0120] In a further aspect of the invention, the primary station may calculate the security information by including the time value used or a portion thereof (the least significant bits (LSBs)). In particular, if the message containing the "protected field" (message 202 in FIG. 2) contains a time value such as a UTC-based counter or SFN, the security information may include only a portion (e.g., the least significant bits) of the current time value, allowing the ED / UE to reconstruct the time value at the time the security information was calculated. This is possible because the ED / UE knows the time value T0 contained / received in the message containing the "protected field," knows the elapsed time DeltaT between receiving the message containing the "protected field" (message 202 in FIG. 2) and receiving the message containing the "security information" (message 204 in FIG. 2), and message 204 includes the LSBs of the time at the time the security information was calculated. The number of LSBs required is the result of rounding up log2(DeltaT / Time_Accuracy_Of_A_Bit) multiplied by the time accuracy in bits. For example, when DeltaT=9 ms and Time_Accuracy_Of_A_Bit=1 ms, log2(DeltaT / Time_Accuracy_Of_A_Bit)>3 and is less than 4. Therefore, the number of LSBs required is 4.

[0121] In a related aspect of the invention, the primary station may calculate security information (signature) by including a time value or time difference that depends on the beam (SSB) used by the ED to connect to the primary station. This is necessary, for example, because the same SIB1 is broadcast multiple times via multiple different beams with specific time delays, as described in the above embodiment.

[0122] In a related aspect of the invention, the ED takes into account that the security information (signature) is calculated including a time value or time difference that depends on the beam (SSB) used by the ED to connect to the primary station. The ED takes this into account when verifying the freshness of the message by knowing the specific timing of the SIB broadcast on a particular SSB.

[0123] In a related aspect of the invention, · The CN or AF sends a message requiring verification (e.g., a public alert message or other SIB) to one or more primary devices, which then broadcast the message on demand. Optionally, the CN or AF may send a signature to sign the message using a trust anchor linked to the CN or AF. The primary device broadcasts a message in a SIB (e.g., SIB5) extended with a "protected field". If a signature is not provided by the CN or AF, the primary device optionally calculates a signature based on the SIB. ·The primary device broadcasts the "security information" determined within the "protection field".

[0124] In a related aspect of the invention, the primary station transmits "security information" to the ED over a broadcast channel in a SIB.

[0125] In a related aspect of the invention, security information may be delivered over the DL-SCH by: Unicast Unicast on demand Regular broadcasts Broadcast on Demand

[0126] In a related aspect of the invention, a primary station can compute and distribute security information that includes a Merkle tree whose root is computed from hashes of the SIBs (e.g., SIB1, SIB2, ...), and a signature is computed based on the root of the Merkle tree (as described in Section 7.3.1 of TS38.300). This has the advantage that the signing party (e.g., the primary station) only needs to compute the signature. This also has the advantage that the receiving party (e.g., the ED) only needs to verify the signature. This embodiment is particularly suitable when an ED may request multiple SIBs, and these different SIBs may need to be verified individually.

[0127] In a related aspect of the invention, at least one of the leaves of the Merkle tree is a hash of a time value or a difference of time values, for example: The transmission time of a particular SIB (e.g., SIB1) The time difference between the transmission of a particular SIB and the transmission of security information ·others.

[0128] This allows the recency of information to be verified once, independently of SIB verification.

[0129] In a related aspect of the invention, the transmission of security information may be performed within a random access message, such as message 2 of the random access procedure.

[0130] In a related aspect of the invention, the primary station that sends the security information is a UE-to-network relay that receives the security information from an access device such as a base station. Note that the UE-to-network relay may act as an ED when receiving the security information from a base station, and may act as a primary station when forwarding the security information to a remote UE.

[0131] In a related aspect of the invention, the primary station that signs the security information may be a relay from the UE to the network.

[0132] In a related aspect of the invention, an ED receiving "security information" from a primary station verifies the security information (e.g., a received digital signature) using a notified algorithm (e.g., a digital signature algorithm).

[0133] In a related aspect of the invention, the signature algorithm is signaled in a "protected field" in the received system information or in the received "security information."

[0134] In a related aspect of the invention, the default signature algorithm (eg, ECDSA) is not advertised; only non-default signature algorithms (eg, RSA) are indicated.

[0135] In a related aspect of the invention, the ED may receive the MIB and observe certain fields that may indicate, for example, that the cell is barred, and the ED may still proceed to obtain SIB1, obtain security information (e.g., from the network or local storage), and verify whether the MIB / SIB1 is correct. This prevents an attacker from performing a DoS attack by providing the UE / ED with the capability / configuration to verify the received information.

[0136] In a related aspect of the invention, the ED receives the MIB and observes certain fields that may indicate, for example, that the cell is barred, and the ED may validate it using locally stored security information, which may have been received from a different primary device, as described in other embodiments.

[0137] In a related aspect of the invention, the ED can verify the freshness of a message (e.g., a SIB or subsequent SIB having "System Information" containing a "Protected Field") by verifying that the received time value in the "Security Information" is within a time window of the ED's local time, e.g., that the difference between the received time value of the security information and the local time value is not greater than the time window.

[0138] In a related aspect of the invention, the ED can verify the currency of the "System Information" by verifying that the time difference between the current (e.g., when the primary station signed and transmitted the security information) and past (e.g., when the primary station transmitted the system information) time value in the received "Security Information" is equal to the time difference between receipt of the "System Information" and the "Security Information" at the ED within a time window.

[0139] In a related aspect of the invention, an ED receiving the "Security Information" verifies the public key contained in the digital certificate included in the "Security Information" using a trust anchor (e.g., the operator's public key) that is pre-installed in the ED or USIM or delivered in a separate "Security Information" message.

[0140] In a related aspect of the invention, upon receiving the "Security Info" message, the ED verifies the hash chain anchor (TESLA anchor) included in the digital certificate using a trust anchor (e.g., the operator's public key) that is pre-installed in the ED or USIM or delivered in a separate "Security Info" message.

[0141] In a related aspect of the invention, a first legacy primary device, e.g., a 4G eNB, does not support distribution of “security information.” However, the “security information” of the legacy primary device is made available on demand, e.g., by a second primary station (e.g., a 5G primary station) located nearby or within communication range.

[0142] In a related aspect of the invention, a second primary device can receive system information (including timing) broadcast by a first (legacy) primary device from the core network or a link to the first primary device (e.g., via a wireless / wired Uu interface or Xn interface), and make available to the second primary device, on demand, corresponding "security information" associated with that system information.

[0143] In a related aspect of the invention, ED is receiving system information from a first (legacy) primary station and a second primary station; determining that the second primary device provides on-demand security information associated with the first (legacy) primary station; requesting security information of the first primary station from the second primary station; receiving security information from a first primary station; · The security information is used to verify the system information broadcast by the first primary station.

[0144] For example, the first primary station may be an NTN satellite or a base station, and the second primary station may be a terrestrial base station or another UE / ED. For example, if an NTN satellite broadcasts an SIB (e.g., SIB19), a UE connected to a terrestrial base station may request / receive security information for SIB19 of the NTN satellite from the terrestrial base station. For example, if a base station broadcasts an SIB, e.g., SIB1, a UE that needs to connect to that base station may request / receive the base station's security information from the UE to which it is connected (via the sidelink / PC5 interface).

[0145] In a related aspect of the invention, a first primary station requests at least one of (a) system information (e.g., SIB1), (b) security information (e.g., a signature for signing SIB1), and (c) other parameters from a second primary station via the Xn interface.

[0146] In a related aspect of the invention, a first primary station can request a second primary station via the Xn interface to deliver its security information (e.g., a signature for signing SIB1) for a particular SIB (e.g., SIB1 broadcast over a particular SSB at a particular time).

[0147] In a related aspect of the invention, upon receiving a security information request from the ED, the first primary station may request that the second primary station deliver the security information (e.g., a signature to sign SIB1) via the Xn interface.

[0148] In a related aspect of the invention, security information calculated by a primary station signs the system information of multiple primary stations, which has the advantage that the ED only needs to obtain a single piece of security information (e.g., on demand).

[0149] In a related aspect of the invention, the security information computed by the primary station signs the system information of multiple primary stations, and the signature is computed based on the root of a Merkle tree whose leaves correspond to the system information (e.g., MIB / SIB1) of different primary stations.

[0150] In a related aspect of the invention, the ED sends a "security information request" to the first primary station requesting "security information" relating to at least the first primary station and other primary stations. This has the advantage of reducing the number of requests the ED must send to obtain security information needed to verify the system information of surrounding cells. The "security information request" may include the PCI of the cell for which the ED requires security information.

[0151] In a related aspect of the invention, the ED searches for primary stations that offer good link quality, e.g., those that transmit synchronization signals with the strongest signal. The ED then obtains the SIB1s of one or more of these "selected" primary stations and uses the "protection field" to determine whether one of these primary stations offers to distribute security information for one or more of these "selected" primary stations. The ED then selects one of the primary stations and sends a request to the "selected" primary station to receive not only the security information linked to its own system information but also the security information linked to the system information of the other primary stations. Distribution of security information can occur via the "selected" primary station or all "selected" primary stations. In the latter case, the "selected" primary station sends a request to distribute security information to the "selected" primary station via the Xn interface.

[0152] In a related aspect of the invention, when an ED is connected to a primary station, the ED may receive security information from the primary station. This security information may be received in response to a request from the ED (e.g., via an RRC message) or may be triggered by the primary station itself. This security information may be used when the ED performs a handover procedure. In this procedure, the ED must receive a synchronization signal and identify the station ID (PCI) of a new second primary station, and may perform the handover only if the received security information successfully verifies and / or validates the currency of the system information received from the second primary station.

[0153] Distributed Ledger In a related aspect of the invention, verification of the authenticity and legitimacy of the primary station may be based on records in a ledger (e.g., a distributed ledger such as a blockchain) that may be owned, operated, and / or managed, for example, by an administrative entity (e.g., a 3GPP® organization, member, operator, NPN owner).

[0154] A ledger can include one or more of the following schemas: Operator schema including e.g. ID, license status, service type (e.g. terrestrial and / or non-terrestrial), region, certificates etc. Access device (e.g. base station, NCR, smart repeater, satellite, etc.) schema including e.g. ID, Operator_id, type, operational status, compliance status, certificates, movement trajectory (location over time), etc. Trusted Certificate Authority schema, including, for example, the certificate authority name, root certificate, status, etc.

[0155] In a related aspect of the invention, the ledger may be a blockchain, or a transparency tree like RFC9162, or simply a trusted central repository.

[0156] In a related aspect of the invention, the ledger may allow permissioned write access so that only authorized manufacturers and / or operators may make writes. Thus, when an operator decides to deploy a base station, an entry containing all or part of the information about that base station is entered / submitted to the ledger. Entering only part of the information about the base station might include, for example, only a statement such as the presence of a 4G base station in a particular area. This allows certain parameters that the network operator does not want shared to be kept private.

[0157] In a related aspect of the invention, the operational status of a base station may be initially set to "none" and updated to, e.g., "operational" only once all checks and / or criteria defined by one or more management entities have been met (e.g., the base station has been tested, certified (e.g., compliance certified), deployed, and is ready for operation). Other statuses, such as "in testing" or "down," may also be defined and assigned to a base station based on its state. This status may be included or updated in a ledger so that it is available to the ED / UE for verification.

[0158] In a related aspect of the invention, the compliance status of the access device may be initially set to "none" and only updated, e.g., to "compliant" or "non-compliant," based on the reported results of conformance tests performed by a trusted independent test lab and / or an operational network and / or ED / UE. Future ongoing evaluation / testing of the station's compliance by the trusted test lab and / or network may result in an update to the compliance status of the access device (e.g., from "compliant" to "non-compliant"). In the case of public validation, the compliance status update may include the conditions under which the status was updated.

[0159] In a related aspect of the invention, the UE may report information about the access device to the ledger, for example, the information may be security information (e.g., a signature) distributed by the access device.

[0160] In a related aspect of the invention, a watchdog may monitor for inconsistencies in the information stored in the ledger, such as two entries that contradict each other, indicating a potential attack (e.g., FBS). This could be, for example, two sets of security information that appear to have been signed by the same access device in two (slightly) different locations. This could be, for example, a set of security information signed by an access device (e.g., a mobile base station on board a vehicle) that is off the route of the vehicle (e.g., a bus). This watchdog could be an independent entity / device that monitors the correctness / compliance of the data in the ledger.

[0161] In a related aspect of the invention, certificates may be issued to operators by a trusted certificate authority. A standardization body such as ETSI, 3GPP, or GSMA may be / be the trusted certificate authority. These certificates may be used to issue certificates for base stations. The base station (generally, the access device) may use these certificates to derive security information. The ED may verify the certificate trust chain to establish the authenticity of the base station before, during, or after connecting to the network, but preferably before connecting. For example, the ED may send an on-demand indication (e.g., challenge, nonce) as part of Message 1 of the random access procedure. The base station may sign the nonce using a signing key and include it, for example, in a random access response (i.e., Random Access Procedure Message 2) along with other required parameters (e.g., Access Device ID, Operator ID, Certificate Authority ID, Signature, and / or Signature Digest).

[0162] In a related aspect of the invention, the randomly chosen preamble, or a portion thereof, or the resources (time / frequency) used by the ED to transmit such a preamble, may serve as an on-demand indication (i.e., nonce / challenge) sent to the access device (e.g., gNB), in which case no further data is added to the random access procedure (e.g., message 1).

[0163] In a related aspect of the invention, on-demand viewing may include additional parameters and / or conditions, such as time-based counters and / or time limits.

[0164] In a related aspect of the invention, the ED may store, e.g., in local storage, records from (public / private) ledgers (e.g., base station, operator, and / or trusted certificate authority schemas) used to verify station authenticity. Such records may be partially or entirely modified (e.g., deleted, updated) when the ED connects to the network and accesses the public ledger. They may also be modified on-demand request by the ED or based on a pull-and-push mechanism, taking into account the ED's capabilities (e.g., storage capabilities, roaming support, mobility status, etc.).

[0165] In a related aspect of the invention, the ledger is a public ledger.

[0166] In a related aspect of the invention, the ledger is a private ledger, e.g., open only to private networks or to the operator of a PLMN. Thus, an ED may only access the ledger if it is authenticated, e.g., authenticated as a member of a PLMN or NPN during primary authentication, e.g., by an OAM. This is intended to ensure that the contents of the ledger remain private. Authentication may be based on credentials pre-configured in the ED / UE (e.g., possession of a digital certificate, authentication token, or private key that can be used by an identity and access management function in or around the ledger to prove the identity of the ED / UE and authorize requests for information contained in the ledger).

[0167] In a related aspect of the invention, the ED can retrieve (or have such information configured in) relevant information from the ledger (e.g., relevant information regarding public keys, access devices, etc. for areas where the ED is currently located or may be located in the future) and store it. For example, the ED may retrieve this information when located within a particular tracking area. For example, this may be done based on policy. For example, a user may select to retrieve information about a particular location.

[0168] In a related aspect of the invention, depending on the user consent settings of the ED, the network may process / analyze the ED's data (e.g., location data, recurrent access devices used, etc.) and curate information from the ledger related to the ED. Based on the (continuous) analysis, the network may update (e.g., add, edit, delete) records stored in the ED, e.g., periodically and / or based on policy and / or based on on-demand request by the ED.

[0169] In a related aspect of the invention, the ED may verify security information received from the access device / primary station, e.g., after sending an on-demand indication or challenge, using the stored relevant information. For example, if the primary station returns security information (including a digital signature), the ED may verify the digital signature using a public key obtained from the ledger.

[0170] In a related aspect of the invention, the ledger (i.e., all potential schemas, e.g., devices, access devices, trusted certificate authorities, etc.) may be kept private and / or privately owned by a non-public network (NPN). The ledger may be personalized based on the needs and requirements of the NPN, e.g., with respect to architecture and access rights.

[0171] In a related aspect of the invention, the ED may temporarily store information provided by the primary / base station (e.g., ID, operator ID, signature, signature fingerprint) and then forward it for verification to the network (e.g., AMF), e.g., as part of a registration request. The network can use the provided information to identify potential FBSs, for example. In this case, the network may implement a monitoring entity as mentioned in other embodiments.

[0172] In a related aspect of the invention, the ED may temporarily store information (e.g., ID, operator ID, signature) provided by the primary station / base station and then forward it to the home network (e.g., UDF) for validation, e.g., using or as part of the SUCI. In a related aspect of the invention, the ED may have a policy that allows / disallows the ED to (temporarily) store information (e.g., ID, operator ID, signature) provided by the primary station / base station and perform the necessary validations (e.g., certificate trust chain, action readiness, compliance checks) itself after gaining access to the network, including ledger access. The policy may also determine the conditions under which the storage of information is allowed / disallowed. The policy may be configurable or hard-coded to always allow / disallow.

[0173] In a related aspect of the invention, the ED may send a challenge / security information request that may include a Home Network Identifier (HNI) or Mobile Network Code (MNC) referencing the ED's home network, and the primary station / base station must provide its signature, ID, operator ID, and the ED's nonce for verification by the ED's home network. After verification, the ED's HN sends the verification result in a protected message that includes other parameters (e.g., the home network's public key identifier) ​​to be sent to the ED. This allows the ED to access / verify the primary station even if no trust anchor for verification is configured.

[0174] In a related aspect of the invention, the ED may send a challenge / security information request that may include a Home Network Identifier (HNI) or Mobile Network Code (MNC) referencing the ED's home network, allowing the primary station to determine whether an associated trust anchor has been configured for the ED. This allows the primary station (e.g., a gNB in ​​a serving network) to request from the home network (e.g., a signing NF) that it has the security information the ED needs. This may be, for example, a digital signature so that the ED can verify that the home network has authorized the ED to use the primary station / gNB / access device.

[0175] In related aspects of the invention, signature and authenticity checks performed on information provided by the primary station may also include operational and compliance checks (i.e., checks to verify that the primary station is a trusted device to access and that it functions well with the ED). Generally, or in the specific embodiments mentioned, certificate chain of trust verification and / or validation may refer to and / or include, but is not limited to, the process of verifying the validity period of an entity's (e.g., base station's) certificate (e.g., Certificate_A) and the signature of the authority (e.g., operator) that issued and signed Certificate_A, and the process may be repeated recursively (i.e., verifying the validity period of the authority's (e.g., operator's) certificate (e.g., Certificate_B) and the signature of the superior authority (e.g., trusted certificate authority) that issued and signed Certificate_B) until a trusted certificate authority is reached, i.e., the authenticity and trustworthiness of the entity are established.

[0176] In another aspect of the invention, validation may refer to and / or include one or more of the following: - Operational check: The operational status corresponding to the device's ID (e.g., PCI of the primary station / access device) is checked locally (e.g., a locally stored copy of the ledger record) or matched against the ledger record. - Compliance check: The compliance status corresponding to the ID of the primary station / device (e.g., NCR) is checked locally (e.g., a locally stored copy of the ledger record) or matched against the ledger record.

[0177] In another aspect of the present invention, the PCI may be broadcast next to the MIB in the PBCH as part of the synchronization signal of the primary station. However, the PCI is an identifier that is too short to uniquely identify the primary station. Therefore, the system information (e.g., SIB1) includes a unique primary station identifier that the ED can use to identify the primary station. Additionally or alternatively, the unique primary station identifier may be constructed based on the location of the primary station and the PCI identifier, keeping in mind that the PCI is unique within a particular area. The "protected information" and / or "security information" and / or SIB may include such a unique primary station identifier.

[0178] In some situations, a network may include cells of multiple cellular generations, such as 2G, 3G, 4G, and 5G. Over time, some of the older generation cells will be decommissioned. However, due to the large attack surface, an attacker may still install older generation (fake) base stations. The ED cannot determine whether the older cellular generation cells are properly operated by the operator or are fake base stations. In this regard, in one aspect of the present invention, the cellular system may be extended by a distributed ledger that the operator uses to include statements regarding decommissioned or available base stations or the cellular technology types (e.g., 2G, 3G) of base stations in a specific area (e.g., a tracking area). The ED / user equipment can search such a blockchain infrastructure to determine whether a base station is a fake or decommissioned base station. The ED or user equipment can request / retrieve / download the statement from the blockchain (e.g., send a "security information request") when the ED is connected to the network or is attempting to connect to the network. The ED may perform local verification based on the locally stored statement before connecting to the base station. An ED may be able to obtain, request, or receive statements for a particular geographic area (e.g., an area where a UE is currently located or an area where the UE will be located). For example, an ED / UE within a particular tracking area may receive statements related to that tracking area by default or if it subscribes to such statements. For example, an ED within a particular tracking area may send a request to the distributed ledger or a network function that interacts with the distributed ledger to download a statement for that tracking area. For example, a primary station may receive a "security information request" and obtain a statement from the distributed ledger. These requests may be for a specific PLMN, a specific NPN, or multiple PLMNs.The network function may verify the ED's location or data access authorization before authorizing delivery of the statement. An ED heading to a particular location / tracking area (e.g., an ED carried on a flight from Amsterdam to Boston) may request / obtain a statement about the target area (Boston in this case) if the network function determines that the ED is connected to a flight heading to Boston.

[0179] In another aspect of the invention, the primary station / access device (e.g., base station) may broadcast (e.g., in a SIB) a signed statement from the ledger confirming its status, allowing the ED / UE to verify whether the older generation primary cell / serving cell is still authorized to operate in. Alternatively, or if the ED / UE is unable to obtain said statement, the ED / UE may request such a statement from the primary station / access device, e.g., when transmitting a PRACH, in which the ED / UE establishes an RRC connection upon successful verification of the access device's authenticity and / or authorization status.

[0180] In another embodiment, if a UE is in RRC_INACTIVE state while being served by one primary station / base station (e.g., a source gNB) and then attempts to transition to RRC_CONNECTED under another primary station / base station (e.g., a target gNB), upon obtaining the security context from the source primary station / gNB, the latter verifies (e.g., via a ledger) whether the target primary station / gNB is legitimate and still authorized, and processes the target primary station / gNB's request (e.g., decrypts, verifies integrity, and / or provides keys) only if the verification is successful. The source primary station / gNB may also provide a signed statement indicating successful verification to the target primary station / gNB, which the target primary station / gNB may forward to the UE. Such a statement by the source primary station / gNB amounts to a ledger check that is omitted by the UE. If the UE verifies the statement from the source primary station / gNB and is successful, it may establish an RRC connection with the target primary station / gNB and transition to RRC_CONNECTED.

[0181] In certain cases, such as inter-gNB handover, the UE can access the target primary station / cell without reading the system information because the source primary station / cell (e.g., source gNB) provides at least the cell ID along with the cell ID in the RRC Reconfiguration message received as part of the HANDOVER REQUEST ACKNOWLEDGE sent by the target primary station / gNB to the source primary station / gNB. In such cases, and in a further aspect of the invention, the target primary station / gNB may also include a signed statement from the ledger verifying the status, which may be verified by either or both the source primary station / gNB and the ED / UE. Alternatively, the source primary station / gNB may check and verify the status of the target cell before initiating the handover procedure with the target primary station / cell. The source primary station / gNB may then provide the statement to the ED / UE for further verification as part of the RRC Reconfiguration message.

[0182] According to the above embodiment, a method is proposed for checking / verifying the legitimacy and authenticity of a primary station against a ledger, the method being implemented on a verifier (e.g., ED) and comprising verifying the security information of the access device (e.g., signatures, certificate trust chains, and other criteria (e.g., behavior and compliance status)) based on records in the ledger, the verification may or may not rely on network assistance and may be performed, for example, by the verifier itself after the verifier has accessed the network or against a locally stored copy of the latest records corresponding to said ledger.

[0183] This method may rely on different processes to obtain security information, for example, the process may be performed as follows, as in other embodiments. - an end device (e.g., UE) sends an on-demand indication (e.g., a challenge) to a primary station during a random access procedure (e.g., random access procedure message 1); - The primary station signs the on-demand indication and calculates the signature digest, adds the necessary parameters (e.g., primary station ID, certificate authority ID) to perform the check / verification to a response message (e.g., random access response), and sends the response message to the verifier (e.g., end device).

[0184] Application of the invention to non-terrestrial networks The application of the present invention may refer to non-terrestrial networks in which non-terrestrial access devices, such as satellites or unmanned aerial vehicles, provide connectivity to EDs / UEs. The critical information that needs to be verified refers to non-terrestrial device data, such as ephemeris data. SIB19 was introduced in 3GPP Release 17. This SIB provides NTN-specific parameters of the serving primary station and / or nearby primary stations. In particular, SIB19 includes assistance information for non-terrestrial access devices, such as ephemeris data, common timing advance parameters, Koffset, validity period of UL synchronization epoch time, cell reference location, timing advance report during initial access, and cell outage time as described in TS38.331. If false information is distributed or this information is tampered with, it may significantly affect UE / ED communications, as the UE / ED will no longer be able to communicate properly. Therefore, the contents of SIB19 should be protected. For this purpose, the present invention and its variants can be applied. Application examples may include the following:

[0185] In one application, the contents of SIB19 may be stored in a distributed ledger accessible by the ED or another primary station / NF on behalf of the ED, so that the ED can verify the received parameters. When a new non-terrestrial primary station becomes available, for example, when a new satellite is launched into orbit, the information about that non-terrestrial primary station is uploaded to the distributed ledger by the satellite operator. The satellite information may be obtained by the UE / ED upon connection, or by the terrestrial primary station / NF on behalf of the UE / ED. The terrestrial primary station / NF may then distribute the security information to the UE / ED.

[0186] FIG. 3 illustrates how some aspects described herein can be applied to SIB19 protection. Entities and messages 300-305 in FIG. 3 are equivalent to entities and messages 200-205 in FIG. 2. Entity 311 also represents a second primary station (e.g., a terrestrial primary station) or an NF or AF. Message 306 represents a request from ED 300 to obtain SIB19 security information for a specific non-terrestrial primary station. The request may also request security information to identify SIB19 non-terrestrial primary stations available in a specific area at a specific time (e.g., the current hour at the location where the ED is located). Entity 311 may return one or more security information messages to entity 300. Entity 300 can use the received security information to validate SIB19 (if already received). Additionally or alternatively, entity 300 may send a request to obtain SIB19. This request may also include a request for security information related to SIB19. Entity 301 then delivers SIB19 in message 309 and security information for SIB19 in message 312. Additionally or alternatively, entity 300 may send a request to obtain SIB19. This request may not include a request for security information related to SIB19. Entity 301 then delivers SIB19 in message 309. The SIB (SIB19 in this case) may include an indication of protection so that entity 300 can send a subsequent security information request in message 310. Entity 301 sends the security information for SIB19 in message 312.

[0187] Additionally or alternatively, the management entity of the non-terrestrial primary station may not want to expose the information in SIB19 to all EDs. Therefore, the management entity may select a key K for a specific period of time and use K to protect the confidentiality of the data in SIB19. An ED interested in using a non-terrestrial primary station may send a request to the network (e.g., NF) or AF (e.g., acting on behalf of the management entity of the non-terrestrial primary station) to obtain authorization to use the service. This request may be authenticated by the AKMA (TS33.535) or GBA. After authentication, the NF or AF may further verify whether the ED is authorized, e.g., whether the ED subscribes to the non-terrestrial access device service. This may require sending a request to an authentication function, such as an AUSF or UDM, where an ED profile may be located. After authentication, the AF / NF can securely send key K to the ED.

[0188] This overall approach is illustrated in Figure 6. In Figure 6, entities 600, 601, 602, 603, and 604 represent an ED, a first primary station (e.g., a non-terrestrial primary station), a second primary station (e.g., a terrestrial primary station), an NF or AF in the core network of the cellular system, and an authentication function, respectively. Message 605 represents the initial distribution of system information such as MIB / SIB1. Messages 606 / 607 represent the initial process (random access procedure) for accessing the first primary station, including a registration request. In this procedure, message 605 may indicate that a specific SIB (SIB19 in this case) is confidentiality protected and requires authentication / authorization for access. In this procedure, a security information request may be sent by the ED to the first primary station. The returned security information may indicate that a specific SIB (SIB19 in this case) is confidentiality protected and requires authentication / authorization for access. Message 609 represents a message or procedure directed to an NF in the CN / AF to receive authentication / authorization to use the first primary station. This could be part of a network access message or primary authentication. This request could be sent via a second primary station (e.g., referring to the AKMA procedure) or via the first primary station, in which case the primary station may only allow such messages / procedures (e.g., primary authentication). Once entity 603 authenticates the ED, entity 604 may send a request to entity 604 (e.g., AUSF, UDM, or an external database) to verify whether the ED has a valid subscription. The answer is provided in message 611. Based on this, entity 603 can provide entity 600 (i.e., the ED) with key K, which is used to protect SIB19. Additionally or alternatively, the ED may receive the contents of SIB19 in this message. In step 613, the ED may request a further SIB19.In step 614, entity 603 may provide the SIB19 information, and / or a key K for protecting the SIB19 information, and / or the protected data carried by SIB19 to the first primary station. Finally, in step 615, the protected information of SIB19 is distributed by SIB19. Note that next to K, the ED receives other auxiliary data, such as a protection algorithm (e.g., the NEA algorithm and / or the NIA algorithm) used to protect the SIB information. Protection may mean confidentiality and / or integrity protection.

[0189] Application of this invention to ambient IoT One aspect disclosed by the present invention is a method for an ED / UE to receive security information on demand, for example, during a random access procedure. Therefore, the present invention helps protect random access procedures used by EDs / UEs in cellular technologies such as 4G or 5G. Future generations of cellular technologies will also accommodate and support resource-constrained IoT devices. These devices, also known as ambient IoT tags, are very simple. A reader (e.g., a base station / primary station) can transmit a read signal, and the ambient IoT tag may be able to transmit a response or reply containing its ID, location, or sensing data. From this perspective, it makes sense for such a read signal to be similar to the distribution of system information such as MIB or SIB1, allowing the tag to respond when it receives such a signal. Therefore, it is meaningful to further align procedures such as those in the above-described variant of the invention with security procedures for protecting communications with ambient IoT devices. Thus, in one aspect of the invention, the first message 202 in FIG. 2 may refer to a message containing system information requesting an IoT device (e.g., an ambient IoT tag) to provide a response containing certain information the IoT device may have (e.g., its ID or sensor data); the second message 203 in FIG. 2 may refer to a potential response from the device that may include protected data about the primary station or another entity (e.g., NF or AF) behind the primary station; and the third message 204 in FIG. 2 may refer to security information provided from the primary station to the ED so that the ED can verify the requesting entity. This data may be associated with the primary station or the requesting entity. The fourth message 205 in FIG. 2 may refer to a further potential response from the device that may include protected data about the primary station or another requesting entity after verification of the primary station or another requesting entity (e.g., NF or AF) behind the primary station.

[0190] In such an ambient IoT scenario, the ambient IoT tags may be very resource constrained and may not be able to perform extensive computations, and therefore the following aspects of the present invention may be applicable.

[0191] In one aspect of the present invention, a primary station may send a challenge to an ED, such as an ambient IoT device, to obtain specific data from the ED. The ED may have a policy that allows disclosure of data only to trusted devices, even if the data is encrypted. Thus, the received challenge may include a "protected field" indicating that security information is available and providing system / identification information about the requesting primary station. The ED may then respond with a message containing a "display on demand" / "security information request." After receiving this, the requesting primary station sends the requested security information to the ED, which verifies it and, if the verification is successful, transmits the previously requested data. This requires two round trips to securely obtain the data from the ED.

[0192] In a further aspect, the ED may include a function, such as a physical unclonable function (PUF) or HMAC, that can generate a response using one or more parameters (challenges) in the "protected field" received in the first message 202 of FIG. 2 as input. The function may be such that it is difficult to calculate one or more input parameters (challenges) based on the response. The function may be device-specific, for example, if it is based on a PUF or HMAC that uses a device-specific key as input. For example, the parameter in the "protected field" may be a first NONCE.

[0193] In a further aspect, the ED may reply with a response to the challenge in a "protected field" in message 203. The primary station (or a requesting entity behind the primary station) may use this response to identify the ED. For example, the primary station (or a requesting entity behind the primary station) may have a mapping such as: challenge,response_i,device_ID_i Thus, a particular response_i to a challenge can be used to identify device_ID_i.

[0194] In a further aspect, the ED may have a function that generates a response R_j based on the input challenge. Response R_j can be viewed as the concatenation of two responses R_j1 and R_j2, where R_j1 has length L1 and R_j2 has length L2. R_j1 may be transmitted in message 203 as in the above embodiment, while R_j2 may be used to encrypt the data to be transmitted as an XOR with R_j2. R_j1 can then be used to identify the device and the generated output, and once the device is identified, the primary station can access the data using (the now known R_j2).

[0195] In a further aspect of the invention, the ED / Ambient IoT tag may be configured to determine whether verification of the primary station / requesting entity behind the primary station is required. This configuration may be based on policy or pre-configuration. If verification of the primary station is required, the ED / Ambient IoT may send a "Security Information Request" message 203 as shown in FIG. 2. This message may include a second NONCE. Additionally or alternatively, the ED may use other embodiments described below that aim to directly verify the authenticity of the primary station based on an initial message including a "protected field."

[0196] In a further aspect of the invention, because generating random data on resource-limited devices can be difficult, such devices may store random data in read-only memory and use that random data as a source of randomness.

[0197] In a further aspect of the present invention, it may be desirable for the IoT device 200 to act on a received message 202 only if the message is deemed authorized. Thus, in one aspect of the present invention, the message may be crafted to allow verification by the device 200. For example, one approach is to include a nonce / counter and a MIC in the message 202, where the MIC is calculated using a key and nonce / counter unique to the device 200, and the device keeps track of the last nonce / counter used. If the message 202 includes a counter and a MIC, the device 200 can recalculate the MIC (e.g., consider calculating the MIC using HMAC-SHA256 (e.g., as the last 32 bits of the HMAC output)), and the device 200 can verify whether the received MIC is correct and whether the counter included in the message 202 is higher than the counter stored locally. While this approach provides strong security, it may be too demanding for small IoT devices. Another approach is to send a challenge Ch to the device 200 within the message 202. The device 200 is configured with a secret / device-specific function P() (e.g., a secret permutation) and its current internal state IS when Ch is applied to P(). A requesting device (e.g., primary station 201) knowing its tag can choose Ch so that P(Ch) = IS. The device may also be configured with a second secret, device-specific function PP() which, if the check P(Ch) = IS is successful, is applied to a function G() of the received challenge Ch and old IS to calculate a new internal state IS' as IS' = PP(G(Ch, IS)), which may be stored in the device. Furthermore, if the check P(Ch) = IS is successful, the device 200 may send a message 203 to the requesting device 201 (e.g., primary station).If this message 203 contains secret data D, it may protect the confidentiality of such secret data by XORing it with a pseudorandom sequence generated by a third function PPP() that uses the received challenge Ch and the internal state IS as inputs. The message 203 may also include bits related to the new internal state IS′ and / or the transmitted data. For example, if PP(Ch, IS) = TRUNC(PP′(G(Ch, IS))) and TRUNC(A) returns the b least significant bits of a k-bit long input A = PP′(G(Ch, IS)), then the message 203 may return the kb most significant bits of A. This is generally a fourth function PPPP() that uses the new internal state IS′ and the transmitted data as inputs, and its output may serve to prove to the requesting device 201 that the new internal state IS′ is correct and / or that the received data is correct.

[0198] In one aspect of the invention, device 200 may include the following four functions: P(), PP(), PPP(), and PPPP(). P() is intended to validate the request in message 202, PP() is intended to update the internal state of the tag based on the request in message 202 and / or the last internal state, PPP() is intended to generate a pseudo-random number sequence to protect transmitted data (e.g., message 203), · PPPP() is intended to provide the requesting device with proof of the currently received data (e.g., message 203) and the (new) secret internal state.

[0199] In one aspect of the invention, a potential choice for the above function is a lightweight hash function, for example, P() in the above design can be a one-way hash function. The primary station or requesting entity may calculate the hash chain based on an initial seed S. The primary station may calculate Ŝn=Hash(Hash( n times (Hash(S)) ), i.e., Ŝn is obtained by applying the hash function n times. The initial state of the device is set to Ŝn. Since the first challenge sent by the primary station / requesting device is Ŝn-1}, device 200 needs to check whether Ŝn=Hash(Ŝn-1}). In this case, function PP() simply replaces the old internal state with the newly received challenge. PPP() and PPPP() may also be based on the same hash function. For example, PPP() is a hash function that takes IS and / or the received challenge or another secret / internal state as input and derives a pseudo-random bit string that is XORed with the data to encrypt the data. For example, PPPP() is a hash function that takes IS and / or the received challenge or another secret / internal state and / or data as input and calculates some MIC.

[0200] In one aspect of the invention, the one-way hash function may be based on ASCON.

[0201] In a further aspect of the invention, one or more PUFs may serve as one-way functions P(), PP(), PPP(), PPP(). For example, a first PUF() is used as P() and a second PUF() is used as PPP().

[0202] In a further aspect of the invention, the one-way hash function may be based on an ASCON hash or an ASCON XOF.

[0203] In a further aspect of the invention, some of the above functions may be based on ASCON authenticated encryption, for example the functions PPP() and PPPP() may be based on ASCON authenticated encryption.

[0204] In a further aspect of the present invention, the ED 200, i.e., the ambient IoT tag, may be configured with one or more IDs, such as an ID of a primary station, a requesting entity, a search service, the type of ED addressed by the message, an IoT group, or the like, that has the authority to retrieve data / send the request 202. This ID may be included in the message 202 (e.g., as part of the "System Information"). The type of ED addressed by the message may refer to the capabilities of the addressed ED (e.g., an ED with more or less resource capabilities). The ED / tag 200 may further process the message 202 only if the ID included in the message 202 matches a pre-configured ID or set of IDs. This aspect of the present invention acts as a first filter, ensuring that the ED 200 only responds to messages intended for it. This can be useful, for example, to reduce the volume of responses to a broadcast message 202.

[0205] In a further aspect of the present invention, the initial message 202 containing the “protected field” may include a flag indicating the mode of the primary station, which may be, for example, “identifying” or “identified.” In the “identifying” mode, the primary station is identifying the ED / IoT tag by simply requesting the ED / IoT tag to respond to the input message (e.g., by sending back an identifier on one or more frequencies or by providing a response to a challenge). The returned response may be a message 203 that also contains a “security information request.” The primary station may then identify the ED / IoT device by sending multiple messages 202 and receiving multiple messages 203 to profile the ED / IoT device's answers. This profiling may be based, for example, on the radio frequency (RF) properties of the ED's radio transmitter (Tx), because device-specific aspects of the Tx make the ED identifiable. Thus, the RF properties of the Tx function as a PUF. Once the ED is identified by the primary station (or a requesting entity residing behind the primary station), a message 202 containing the “identified” mode is sent to the ED. This message may be message 204 with the requested security information. Transmission of this message may implicitly indicate that the device ED has been identified. Because the device ED has been identified, the security information may be device-specific, e.g., using a challenge of the ED PUF whose response is known to the primary station, or using a challenge that allows the ED to calculate a MIC using a key K known to the primary station. Additionally or alternatively, the primary station may send a MIC calculated using a key known to the ED, using as input a NONCE received in a message from the ED during the identification phase. Upon receiving this message indicating that the ED has been identified by the primary station, the ED may provide the primary station with the requested data (e.g., protected ID or protected sensing data), for example, if the ED validates the primary station based on the security information provided by the primary station.

[0206] In a further aspect of the invention, because generating random data can be difficult in resource-constrained devices, the device may generate random data by passing the currently received radio signal through a function such as a hash function, HMAC, or PUF, and using the output as the random data. To prevent an attacker from easily manipulating the input and therefore the output, the tag may maintain a secret raw value R (e.g., in memory) and XOR / prepend / append / insert it to the received radio signal before passing it to the function. Typically, the input to the function is a second function of the secret value R and the measured radio signal. Additionally, the secret raw value R may be updated with each iteration. For example, if the function outputs a value W, then b bits of W may be used as a second NONCE, and k different bits of W may be used to update the secret raw value R (e.g., by replacing the old value R, or by obtaining a new value R as a third function of the old value R and k selected bits of W (e.g., R_new = R_old XOR W_k, where R_new is the new secret raw value R, W_k is the selected k bits of W, and R_old is the old secret raw value R)).

[0207] In a further aspect of the invention, the ED may receive, along with the security information, information in message 204 that can be used in subsequent interactions. For example, the ED may maintain a pseudonym in memory. The ED may use this pseudonym to identify itself, for example, when sending a "Security Information Request" in message 203. When the ED receives message 204 and verifies the security information, the ED may also update the pseudonym currently in memory with the new pseudonym. This action should only be applied if the ED successfully verifies the security information. The newly received pseudonym may be protected by XORing it with a random bit string, which may be the output of a function, such as a PUF, as described in other aspects of the invention. Message 204 may also include a challenge known to the primary station or requesting entity. When this challenge is applied to a function, it generates a random bit string used to encrypt the pseudonym.

[0208] FIG. 4 illustrates another deployment option of the present invention, where entities 401 and 402 refer to primary stations, e.g., they may both be base stations, or 401 may be a UE and 402 a base station, and entity 400 represents an ED or ambient IoT device. Message 403 represents the delivery of a system information message containing a protected field. Upon receiving 403, entity 400 may respond with message 404 (e.g., a secure message or a message containing a security information request) toward entity 401. This reply may be similar to many of the variations discussed above. Additionally or alternatively, entity 400 may send / forward message 405 to entity 402. This message 405 may be a message backscattered by the ED / ambient IoT device. Note that in this alternative, since entity 402 is the entity that receives message 405, it may be necessary for entity 402 to send initial message 406 before message 403 with security settings is sent. Alternatively, entity 401 may generate random parameters, such as NONCE or RF communication parameters, and send them to entity 402 in message 406, so that entity 402 can take them into account when identifying / authenticating ED 400. That is, in this alternative message, message 406 travels from 401 to 402. Generally, message 406 represents an exchange of security information between primary stations 401 and 402 to enable identification and / or authentication of ED 400.

[0209] Figure 4 therefore shows how the message flow of Figure 2 is applied in a distributed environment where entity 400 receives a first message (a system information message including a protection field) from a first primary station and entity 400 may send a further message 404 or 405 to the first or second primary station. Figure 4 shows the need for coordination between the first and second primary stations regarding the security data exchanged.

[0210] The different aspects of the invention may be combined with each other as required.

[0211] Thus, as can be seen from the above, an overall system is proposed that reduces the likelihood of attacks based on fake base stations or man-in-the-middle attacks and enables verification of system information distributed by access devices / primary stations. Components of this system include secondary stations and primary stations that implement one or more of the above embodiments. The apparatuses may each be implemented as program code means of a computer program and / or as dedicated hardware in the associated device. The computer program may be stored and / or distributed on a suitable medium, such as an optical or solid-state storage medium, supplied with or as part of other hardware, or in other forms, such as via the Internet or other wired or wireless communication systems.

[0212] Other variations of the disclosed embodiments can be understood and realized by those skilled in the art in practicing the claimed invention from the drawings, the disclosure, and the appended claims. In the claims, the term "comprises" does not exclude other elements or steps, and the singular form of an element does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that several means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage. The above description details specific embodiments of the present invention. However, it will be understood that, regardless of how detailed the above content appears, the invention can be embodied in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of certain terms in describing particular features or aspects of the present invention should not be interpreted as meaning that the terms are redefined to be limited to include the specific features of the feature or aspect of the invention with which they are associated.

[0213] Furthermore, when idiomatic expressions similar to "at least one of A, B, and C, etc." are used, such syntax is generally intended in the sense that one of ordinary skill in the art would understand the idiomatic expression, e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. When idiomatic expressions similar to "at least one of A, B, or C, etc." are used, such syntax is generally intended in the sense that one of ordinary skill in the art would understand the idiomatic expression, e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Additionally, those skilled in the art will understand that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, contemplates the possibility of including one of the terms, either term, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B."

Claims

1. A controller; a receiver; a transmitter, the receiver receives a first system information message transmitted from or via a first primary station; the controller decodes the first system information message to obtain a protection field and uses the protection field to determine a location of "security information"; The controller uses the "security information" to verifying the received first system information message and / or the first primary station; and / or causing the transmitter to transmit a subsequent secure message to the first primary station or a third primary station.

2. The device comprises: Sending a "security information request" to the first primary station or the third primary station; receiving "security information" from the first primary station; 2. The apparatus of claim 1, wherein the received "security information" is used to verify the previously received first system information message or a second system information message received from a second primary station.

3. The device of claim 2 , wherein the device transmits the security information request based on the determined location of the security information.

4. The device sends a "security information request" to the first primary station or the third primary station, the security information request requests security information for verification of the system information message, and the request satisfies the following conditions: the device belongs to a particular type, the system information message is transmitted by a primary station having a specific ID; the system information message is transmitted at a specific time or time frame; The system information message is transmitted within a specific area.

4. The device according to claim 2, wherein the device transmits if at least one of the following conditions is satisfied:

5. 5. The apparatus of claim 1, wherein the "security information" of the first primary station is obtained from a distributed ledger.

6. The apparatus of claim 2 or 3, wherein the "security information request" is transmitted within an initial PRACH message.

7. 7. The device according to claim 1, wherein the freshness of the first system information message is verified by comparing the local time of the device with the signature time of the security information after modification with a timing advance indicated by the primary station, the timing advance being secured by the security information.

8. The device, receiving a second system information message; 8. The device according to claim 1, wherein the device is capable of validating the second system information message based on the security information received for validating the first system information message.

9. 10. The apparatus of claim 8, wherein the apparatus validates the second system information message using a Merkle tree structure.

10. 2. The apparatus of claim 1, wherein the "protected field" in the first system information message includes a challenge used by the apparatus to verify the primary station using a first function P() and a secret internal state variable.

11. 11. The device of claim 1 or 10, wherein the "protected field" includes one or more IDs that the device uses to determine whether the device needs to further process the received first system information message.

12. 12. The apparatus of claim 10 or 11, wherein the secret internal state variable is updated based on at least the received challenge, a previous value of the secret internal state variable, and a second function PP( ).

13. 13. The apparatus of claim 1, 10, 11, or 12, wherein the subsequent secure message includes data whose confidentiality is protected based on information in the "protected field," the private internal state information, and a third variable, PPP().

14. 14. The apparatus of claim 1, 10, 11, 12, or 13, wherein the integrity of the subsequent secure message is protected and / or a new proof of secret internal state is obtained based on information in the "protected field", the secret internal state information, and a fourth function PPPP().

15. The first, second, third, and fourth functions are: Physically unclonable functions, a list of challenge-response values ​​stored in memory; Secret sorting, hash functions such as ASCON-HASH, Extensible output functions such as ASCON-XOF; Authenticated encryption algorithms such as ASCON-AE 15. The device according to any one of claims 10 to 14, wherein the device may be one or more of:

16. A controller; A receiver; a transmitter, the controller causes the transmitter to broadcast a first system information message including a "protected field"; The receiver receives a "security information request" and / or a secure message from an end device.

17. The controller: securely processing the secure message by extracting data contained in the secure message based on information in the "protected field", private internal state information of the end device; and / or 17. The apparatus of claim 16, further comprising: determining security information for the first system information message; and transmitting the security information.

18. 20. The apparatus of claim 17, wherein the receiver receives a second secure message and securely processes the second secure message.

19. The apparatus of claim 17 , wherein the security information is included in a random access response message.

20. The "security information" is a field in the random access response message, such as a timing advance, and / or 20. An apparatus according to claim 17 or 19, adapted to protect the integrity of a property of the security information request message, such as a beam used to receive the security information request message.

21. 1. A method for secure communication with a primary station, said method comprising: receiving a first system information message from or via a first primary station; decoding the first system information message to obtain a "protected field"; using said "protected field" to locate "security information"; Use the "Security Information" above, verifying the received message and / or the first primary station; and / or transmitting a subsequent secure message to the first primary station; A method comprising:

22. 1. A method for securely communicating with an end device, the method comprising: broadcasting a first system information message including a "protected field"; receiving a "security information request" and / or a secure message from the end device; A method comprising:

23. A system comprising an apparatus according to any one of claims 16 to 20 and an apparatus according to any one of claims 1 to 15.

24. A computer program for secure communications, said computer program comprising instructions for implementing the apparatus of any one of claims 1 to 15 and 16 to 20.

Images