Method and apparatus for authenticating master station

Abstract

The present invention relates to a method, device and system for secure communication wherein a terminal device is adapted to receive a first system information message from or by a first master station, decode said first system information message and obtain a "protection field", determine a location of "security information" using said "protection field", and transmit the "security information" to the terminal device. And validating the received message and / or the first master station and / or sending a subsequent secure message to the first master station or a third master station using the "security information".

Description

Technical Field

[0001] The present invention relates to the field of wireless communications, and in particular to security aspects of communications between a primary station (eg a base station) and a secondary station (eg a terminal or a mobile station forming a network).Other entities may be present in such a network, such as a security entity. Background Art

[0002] In a wireless network, terminals connect to the network to exchange data. Security is especially important for wireless devices that do not require physical interaction to access the network. Therefore, wireless networks must take some measures to be able to exclude unauthorized devices from the network.

[0003] Traditional attacks involve an attacker impersonating an entity in a wireless network, particularly a master or base station. Therefore, many countermeasures are aimed at verifying the identities of various entities in the network.

[0004] exist Figure 1 In these telecommunication systems shown, the secondary station 100 acts as a terminal or terminal device (also referred to as user equipment, UE in 5G or terminal device (ED) in the present invention). The secondary station can access different types of services, including voice and data services, through the primary station 110, which is a base station deployed on site (also referred to as gNB in ​​5G). Each primary station 110 serves and communicates with the secondary stations 100 present in an area also referred to as a cell 111. The primary station is connected to a core network (CN) 120 managed by a network operator, which controls the telecommunication system and coordinates the delivery of services.

[0005] As mentioned above, attackers can impersonate network entities such as primary stations by attacking secondary stations in a variety of ways using a "fake" base station (FBS). FBS, as a proper primary station managed by the network operator, is designed to attract UEs with different goals, 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, etc.).

[0006] 3GPP defines a system comprising a secondary station or terminal equipment ED (100) and a primary station or base station (110) used in a wireless telecommunication system such as 2G or 3G or 4G or 5G. The ED is connected to a core network via the primary equipment. The connection process between the ED and the primary station includes a number of steps:

[0007] The master station broadcasts system information, especially MIB and SIB1;

[0008] ED receives system information from one or more master stations;

[0009] ED selects the master station based on various conditions such as signal strength and preference;

[0010] ED obtains random access parameters from SIB1 of the selected master station;

[0011] ED sends a first random access message to the primary station;

[0012] The primary station replies a second random access message to the ED.

[0013] The above process may be a 2-message RACH or a 4-message random access process.

[0014] The broadcast security of system information needs to be ensured, for example, ensuring that EDs only join trusted master stations, or ensuring that EDs can verify information broadcast by master stations, such as public warning messages or coverage information in non-terrestrial networks. It is also necessary to ensure that EDs do not join old generation FBSs when old generation base stations (e.g. 2G) have been decommissioned.

[0015] One option is to append some security information in the SIB itself, which can be used to verify the integrity and freshness of the SIB. However, the size of the SIB at the physical layer is limited to about 3000 bits. In addition, the SIB already contains a lot of data, so there is limited space left for the security information. The typical size of security information may be between 260 bits and several thousand bits, so in many cases, the security information does not fit in the same SIB that needs to be protected.

[0016] Options also include broadcasting the security information in a SIB, for example, a new SIB whose periodicity and timing are closely aligned with the periodicity and timing of the existing system information, for example, the same period of the MIB or SIB1 that is regularly broadcast every 80ms or 160ms and can be repeated multiple times in this time period. A specific option includes broadcasting the security information with the same frequency within the time slot. However, this results in a large use of communication resources (spectrum usage) and energy.

[0017] Another problem refers to the fact that legacy master devices, such as in 3G or 4G, may not support the broadcasting of system information. Therefore, such systems relying on legacy technology are still vulnerable to attacks.

[0018] Another problem stems from the fact that low-cost ambient IoT tags, small, low-power devices, can be requested to provide certain data, such as sensing data or identification data. However, they may only be willing to be trusted devices. Summary of the invention

[0019] It is an object of the present invention to alleviate the above mentioned problems.

[0020] Another aspect of the present invention proposes that the master device broadcasts security information used to verify its system information on demand (ie, based on a request from the ED).

[0021] Another aspect of the present invention proposes that the second master device broadcasts security information for verifying system information broadcasted by the first legacy master device as needed (ie, based on a request from the ED).

[0022] The detailed embodiments illustrate further aspects of the invention, wherein different embodiments can be combined with each other as appropriate.

[0023] Another object of the invention is to provide a method that allows increasing the difficulty for an attacker to access or impersonate a network entity.

[0024] Yet another object of the present invention is a secondary station capable of detecting a pseudo base station to ignore its messages.

[0025] Therefore, according to a first aspect of the present invention, a device according to claim 1 is proposed. Therefore, a device is proposed, comprising:

[0026] Controller;

[0027] receiver, and

[0028] transmitter;

[0029] wherein the receiver is adapted to receive a first system information message sent from or via the first master station,

[0030] wherein the controller is adapted to decode the first system information message and obtain a protection field, the controller is adapted to use the protection field to determine the location of "security information", and

[0031] The controller is configured to use the "security information" in order to

[0032] Verify the received message and / or the first master station and / or

[0033] The transmitter is caused to send a subsequent safety message to the first master station or a third master station.

[0034] In a first variant of the first aspect of the invention, the device is adapted to:

[0035] Sending a "security information request" to the first master station or the third master station,

[0036] receiving a "security message" from said first master station,

[0037] 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 master station.

[0038] Optionally, the apparatus may be adapted to send a safety information request based on the determined location of the safety information.

[0039] First variant Further, the apparatus may be adapted to send a "security information request" to the first master station or the third master station, wherein the security information request requires security information for verifying the system information message, and the request is sent if at least one of the following conditions is met:

[0040] - the device is of a given type

[0041] - said system information message is sent by a master station with a given identity,

[0042] - said system information message is sent at a given time or time frame,

[0043] - The system information message is sent in a given area.

[0044] In a second variation of the first aspect, the "security information" of the first master station is retrieved from the distributed ledger.

[0045] In another example of the above variation, a "security information request" may be sent in an initial PRACH message.

[0046] In a third variant of the first aspect which may be combined with the previous variants or options, 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 correction with the timing advance indicated by the master station, whereby the timing advance is securely protected by means of the security information.

[0047] In a fourth variation of the first aspect, which may be combined with the previous variations of the options, the device is capable of:

[0048] receiving a second system information message, and

[0049] The second system information message is verified based on the received security information to verify the first system information message.

[0050] Optionally, the device uses a Merkle tree structure to verify the second system information message.

[0051] In a fifth variation of the first aspect which may be combined with any of the preceding variations and options, the "protected field" in the first system information message comprises a challenge used by the device to authenticate the master station by means of the first function P() and the secret internal state variable.

[0052] Optionally or alternatively, the "guard field" includes one or more identities used by the device to determine whether the device needs to further process the received first system information message.

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

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

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

[0056] Further, in the fifth to seventh variations, the first, second, third and fourth functions may be one or more of the following:

[0057] Physical unclonable functions,

[0058] a list of challenge-response values ​​stored in memory,

[0059] Secret replacement,

[0060] Hash functions, such as ASCON-HASH,

[0061] Expandable output functions such as ASCON-XOF,

[0062] Authenticated encryption algorithms such as ASCON-AE.

[0063] According to a second aspect of the present invention, a device is proposed in claim 16, comprising:

[0064] Controller,

[0065] receiver, and

[0066] transmitter;

[0067] wherein the controller is adapted to cause the transmitter to broadcast a first system information message including a "guard field",

[0068] And the receiver is adapted to receive a "security information request" and / or a security message from the terminal equipment ED.

[0069] In a first variation of the second aspect, the controller may be adapted to:

[0070] securely processing the secure message by extracting data included in the secure message based on the information in the "protected field", the secret internal state information of the ED,

[0071] and / or

[0072] Determine security information for the first system information message and send the security information.

[0073] Optionally, the receiver is adapted to receive the second safety message and to securely process the second safety message.

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

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

[0076] According to a third aspect of the present invention, a method for securely communicating with a master station is proposed in claim 21, wherein the method comprises:

[0077] receiving a first system information message from or through the first master station,

[0078] Decoding the first system information message and obtaining the "protection field",

[0079] Use the "Protection Field" to determine the location of the "Security Information", and

[0080] Use Security Messages to

[0081] Verify the received message and / or the first master and / or

[0082] A subsequent safety message is sent to the first primary station.

[0083] According to a fourth aspect of the present invention, a method for securely communicating with a terminal device is proposed in claim 22, wherein the method comprises:

[0084] broadcasting a first system information message including a "protection field",

[0085] A "security information request" and / or security message is received from a terminal device.

[0086] In a fifth aspect of the present invention, a system is proposed, which comprises an apparatus according to the first aspect or its variations and an apparatus according to the second aspect or its variations.

[0087] In a sixth aspect of the present invention, a computer program for secure communication is proposed, wherein the program includes instructions for implementing the apparatus of the first aspect or the second aspect.

[0088] It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or the above-described embodiments with the respective independent claim.

[0089] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0090] - Already described Figure 1 is a block diagram representing a cellular network in which the present invention may be implemented;

[0091] - Figure 2 is a flow chart representing a method according to different aspects of the present invention;

[0092] - Figure 3 is a flow chart representing a method focusing on a security protocol for communicating with a terminal device according to different aspects of the present invention;

[0093] - Figure 4 Represents the centralized and distributed deployment scenarios of the present invention;

[0094] - Figure 5 is a block diagram showing a secondary station according to a first embodiment of the present invention; and

[0095] - Figure 6 is a flow chart representing a method focusing on secure distribution of content in a SIB according to different aspects of the present invention. DETAILED DESCRIPTION

[0096] As described above, the present invention can be implemented in a cellular network such as a 5G network. Figure 1 As seen, such a cellular network comprises a plurality of terminals or secondary stations 100, which are mobile devices (or UEs) that can travel from a network cell to another network cell 111. Each cell 111 is served by a primary station 110 (or gNodeB), which forms an interface between the secondary stations 100 and a core network 120.

[0097] Thus, the secondary station 100 communicates with the primary station 110 on various radio channels, uplink (from the secondary station to the primary station) and downlink (from the primary station to the secondary station). There are other radio channels, such as between secondary stations (e.g., sidelink channels) and between primary stations (e.g., X2 interfaces), but for simplicity, only one radio channel is used. Figure 1 Embodiments of the present invention may also be applied to these interfaces, however, the following part of the description will focus on the link between the secondary station and the primary station.

[0098] In order to allow secondary stations to connect to the network, primary station 110 may broadcast some configuration information on cell 111. The configuration information includes a master information block (MIB) and a system information block. First, MIB is a message that is broadcast periodically (e.g., every 80ms) and includes all the required information to allow decoding of subsequent SIBs.

[0099]

[0100] Once a secondary station obtains the MIB, it can decode several system information blocks that can also be sent periodically (e.g., every 80ms, 160ms) or upon request from the secondary station. These SIBs describe the operation and parameters of the network. In order to increase the security of the entire network, it is recommended to add digital signatures to these SIBs to prevent anyone from impersonating the primary station. A digital signature is a technique that binds an entity to digital data. This binding can be independently verified by the recipient as well as any third party. Therefore, a digital signature is a cryptographic value calculated from the data and a key known only to the signer. In this case, the data corresponds to the payload carried by the SIB itself. The signature allows the secondary station to guarantee that the message belongs to the primary station.

[0101] In the example of 5G, one of the available options is that the digital signature generator of the core network 120 generates a signature based on the request of these master stations for each message and provides the signature to the master station 110. Another option is to include a digital signature generator in each master station. This solution can be used for at least some of the messages, which will reduce the load on the digital signature generator of the core network.

[0102] Figure 5 is a block diagram representing a secondary station 500 according to an embodiment of the present invention. The secondary station comprises a communication unit 501 comprising a receiver 502 and a transmitter 503 suitable for communicating in a network, for example in a 5G cellular network.

[0103] The receiver 502 includes at least one antenna or an antenna array having multiple antennas. The receiver may be adapted to receive messages sent from multiple master stations. Such messages may be system information SI messages for configuring the secondary station communication unit 501 in the communication network. These SI messages each include corresponding time reference information related to its corresponding primary station. The secondary station 500 also includes a controller 504 to control the operation of the secondary station. The controller may be a computer programming unit or other combinations of hardware and software. The controller 504 is configured to check the validity of the received signature for each of the primary stations in the primary station, and check at least the cell identifier for each primary station with a valid signature in the primary station, and then the controller 504 ignores the time reference information from the primary station, wherein the cell identifier is the same as another primary station and has an earlier value than the value from the other primary station. Finally, the controller 504 infers the local time reference from one or more time reference information in the time reference information of the primary station with a valid signature.

[0104] In a first general embodiment that solves multiple problems, the connection process between the ED and the master station involves the following steps:

[0105] 1. The master station broadcasts system information, especially MIB and SIB1, which includes the "protection field";

[0106] 2. The ED receives system information from one or more master stations using the “protection field” to determine the location of the “security information”;

[0107] 3. ED sends an "on-demand instruction" or "safety information request" message;

[0108] 4. The master station calculates / obtains the "security information" associated with the system information and sends it;

[0109] 5. ED receives “safety information” and

[0110] 6.ED verifies the "System Information".

[0111] This is through Figure 2 , where 200 refers to ED and 201 refers to the master station. Messages are represented by arrows, where the arrow direction indicates to which entity the message is sent. Arrows / messages exchanged at the top are exchanged before arrows / messages exchanged further downward. Message 202 represents a message including a "protected field". Message 203 represents a message including an "on-demand indication" or a "security information request". Message 204 represents "security information". Finally, message 205 indicates the final response of 200 after verifying the security information. The advantage of this construction is that the ED can receive system information such as MIB / SIB1 as usual without communication overhead, and if requested by the ED, security information can be provided to the ED during, for example, a random access procedure.

[0112] In an aspect of the embodiment, step 3 is performed when a PRACH message is sent, and step 4 is performed before receiving a RAR message (message 2 of the random access procedure). This allows for simple integration in existing telecommunication systems.

[0113] In one aspect of the embodiment, the ED may cache in local storage, for example, in the USIM, the "security information" received in a previous message. This has the advantage of reducing resource consumption, as it eliminates the need for the ED to request the "security information" again.

[0114] In one aspect of the embodiment, the ED may have local access to the "security information" determined in the "protection field" so that the ED may not need to send an "on-demand indication" message and may directly verify the "system information". For example, the ED may be pre-configured with such information, and the ED may have retrieved / received it in a previous interaction.

[0115] In one embodiment, the master station broadcasts system information including MIB and SIB1 with existing periodicity, and SIB1 and / or MIB include a "protection field" indicating whether the system information (e.g., MIB and / or SIB1) is protected. If protected, the ED can decide to conduct a network access procedure with the master station and retrieve "security information" for authenticating them.

[0116] In an embodiment, the "protection field" indicating whether the system information block is protected is a flag, such as a single bit set to 1 or 0.

[0117] In one embodiment, the "protection field" indicating whether the system information is protected is a structure containing one or more fields, such as:

[0118] Protected system information, e.g., SIB1 and / or (MIB and SIB1) and / or (PCI and MIB and SIB1) and / or (PBCH field and PCI and MIB and SIB1) and / or any other SIB (e.g., SIB19 as used in non-terrestrial networks);

[0119] System information that can be protected, such as PBCH field and / or PCI and / or MIB and / or SIB1 and / or time value and / or other SIBs, etc.

[0120] Physical identity of the cell, e.g., in the same area, security information can be requested as needed (e.g., a UE may wish to join a 4G cell without available security information, but a nearby 5G cell may broadcast the cell ID of the 4G cell, so that the UE can obtain the security information required to authenticate the 4G cell through / from the nearby 5G cell);

[0121] · Structure / parts of "safety information", e.g.

[0122] o Digital signature;

[0123] o Certificates;

[0124] o Current time value;

[0125] o Time values ​​in the past;

[0126] o Signature algorithm.

[0127] The location of all or part of the security information sent in a different SIB, e.g. appended to the same SIB;

[0128] The frequency band / timing resources used to send the security information when sent in different SIBs;

[0129] The identity of the master station from which security information can be retrieved on demand;

[0130] Algorithms used to protect system information, such as ECDSA;

[0131] A security solution or process that can be used to protect system information, such as a hash-based solution and / or a signature / certificate-based solution (as in the embodiments below or as shown in TR 33.809);

[0132] "On-demand indication" of all or part of the security information, e.g. digital signatures are appended to received system information and certificates can be received on demand;

[0133] A distributed ledger or a location in a distributed ledger storing security information used to verify the cell's system information.

[0134] In one aspect of the present invention, a "protected field" may determine whether a digital signature is appended to a received SIB and whether a certificate may be received on demand.

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

[0136] In another aspect of the present invention, a "protected field" determines whether the signature can be received in a different SIB that is periodically transmitted, and the certificate can be received on demand in a different second SIB.

[0137] In another aspect of the present invention, "security information" may be broadcast in a first SIB to support verification of system information distributed in another SIB.

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

[0139] In another aspect of the present invention, the digital signature is based on one of ECDSA, RSA or ECCSI.

[0140] In another aspect of the invention, the digital signature refers to a message integrity code calculated using an undisclosed hash chain value, such as in TESLA.

[0141] In another aspect of the present invention, "security information" includes a digital certificate or a subset of a digital certificate used to verify a public key required to verify a digital signature.

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

[0143] In another aspect of the invention, the ED is configured with a trust anchor, e.g., a public key associated with a private key owned, e.g., by a network operator. 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 a master device (master station) to sign system information broadcast by the master device.

[0144] In another aspect of the present invention, the public key pair used by the master device (master station) to sign the system information refers to the hash chain used in the TESLA scheme.

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

[0146] In another aspect of the present invention, "security information" includes an indication of which system information it protects when broadcasting SIB1 from an initial time to an end time.

[0147] In another aspect of the invention, the "security information" comprises 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 a SFN.

[0148] In another aspect of the present invention, a digital signature is calculated on system information (eg, SIB).

[0149] In another aspect of the present invention, a digital signature is calculated over the MIB and / or SIB and / or fields (such as PCI) in the PBCH channel that broadcasts the MIB.

[0150] In another aspect of the invention, a digital signature is calculated over a time value (eg, a UTC-based value, such as a UTC-based counter or the least significant bits of a UTC-based counter, or a SFN value).

[0151] In another aspect of the invention, a digital signature distributed on demand covers / signs a timing advance value that is specific to the distance between the ED and the master station. The reason for signing the TA value is that it is related to the propagation delay from the master station to the ED. Assuming that the clocks of the ED and the master station are perfectly synchronized, a MitM attacker may want to manipulate the TA value (to a higher value) in order to be able to intercept, modify, inject messages, because in this case the ED believes that the later reception of the message is not due to the presence of the MitM, but due to the propagation delay. In this context, if the ED receives security information during a random access procedure, for example, it is received together with message B in a 2-message random access procedure, then the same message also includes an estimate of the TA parameter estimated by the master station. Therefore, this TA parameter can be signed to prevent MitM from manipulating the communication.

[0152] In another aspect of the present invention, the digital signature distributed on demand covers / signs other communication parameters specific to the communication link used by the ED, such as the beam used to perform the random access procedure.

[0153] In another aspect of the invention, a digital signature distributed over the required coverage / signature / is calculated using other parameters or fields included in the message used to distribute the digital signature (e.g., fields of message B in a two-message random access procedure (RAR message) used to distribute security information. In other words, the signature is calculated taking as input at least one field in the system information and the message carrying the security information.

[0154] In another aspect of the present invention,

[0155] a) the primary station sends (e.g., in message B of a 2-message random access procedure) security information including signature information about, for example, (1) the time Ts_sig of the primary station when security information was sent, (2) the timing advance TA observed / calculated by the primary station, and / or (3) the time Ts_SI when system information (e.g., SIB1, MIB) was sent; and / or

[0156] b) the terminal device, upon receiving the security information, determines whether the security information is fresh / recent by comparing ABS((ED_time-TA)-Ts_sig) with the T_w parameter,

[0157] where ED_time is the local ED time and ABS(x) returns the absolute value of x; and / or

[0158] c) the terminal device, upon receiving the security information, verifies that the system information is fresh by checking that the system information is received at time Ts_SI, where Ts_SI may be an absolute value or relative to the receipt of the security information; and / or

[0159] d) When the terminal device receives the security information, it verifies the system information by using the information received in the security information.

[0160] In another aspect of the invention, the master station signs only the static fields of the system information, ie, leaving variable fields such as SFN value, so that the security information can be used to authenticate multiple system information sets, such as MIB or SIB1 sent in different time slots.

[0161] In another aspect of the invention, the master station signs static and dynamic fields of the system information, ie including variable fields such as SFN values, so that the security information is specific to a given system information (eg MIB or SIB1 transmitted in a given time slot).

[0162] In another aspect of the invention, the master indicates whether only static fields are signed or both static and dynamic fields are signed. This can be indicated in the security information itself or in a "protection field".

[0163] In another aspect of the present invention, an ED that needs to verify system information (e.g., MIB / SIB1) sent in time slot k and receives security information from a master station that can verify the system information sent in time slot k' (e.g., k'=k-1) can:

[0164] · No new request for new security information for time slot k is sent;

[0165] Verify the system information for time slot k' by replacing k with k';

[0166] Check that the time difference between time slots k and k' is consistent with the signature time of the master (related to k') and the local time of the ED (related to the time linked to time slot k when acquiring the system information).

[0167] In another aspect of the invention, the ED verifies the system information by using information received in a secure message (eg, a digital signature such as ECDSA or ECCSI or a message integrity code used in a TESLA-like scheme).

[0168] In another aspect of the invention, the ED determines whether the security information is new / recent based on at least one of the following: absolute comparison, for example, whether ABS((ED_time-TA)-Ts_sig) <T_w,

[0169] ●Relative comparison, such as ABS((ED_time-TA)-Ts_sig) / T_w,

[0170] ●The strategy for determining the value of T_w configured in ED,

[0171] ● A policy configured in ED that determines how much larger ABS ((ED_time-TA)-Ts_sig) can be compared to T_w, ● A policy configured in ED that determines which absolute / relative comparisons are acceptable in different contextual situations, e.g., normal access to a cell versus emergency situations. For example, in normal access, it is acceptable only if ABS ((ED_time-TA)-Ts_sig) / T_w<1, but in emergency access, it may be acceptable if ABS ((ED_time-TA)-Ts_sig) / T_w>1;

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

[0173] In another aspect of the present invention, the master station is configured with at least one of the following by a network function in the core network (e.g., a digital signature network function (DSnF)) or by an OAM (operation, administration and maintenance entity):

[0174] ● key material, such as signing keys,

[0175] ●Digital certificates,

[0176] ●Security policy,

[0177] • Scheduling for the broadcast or on-demand delivery of safety information.

[0178] In another aspect of the invention, the master station configures its own security information, e.g., key material such as signing keys, digital certificates, security policies, schedules for broadcast or on-demand delivery of security information, and uploads the public information (e.g., public keys) to a distributed ledger (e.g., blockchain) so that the information is publicly available and can be retried by other UEs.

[0179] In another aspect of the invention, the master station may be configured with a policy, e.g., through an OAM or NF in the CN, determining which security procedures / countermeasures (e.g., hash-based solutions (e.g., as described above or in solutions #14 or #19 in TR 33.809), signature / certificate-based (e.g., as described above or in solutions #20 or #27 in TR 33.809), none, etc.) are:

[0180] - be allowed to use, enable or disable and / or

[0181] - under what conditions (e.g., time-based, location-based) and / or

[0182] -Through which devices.

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

[0184] In another aspect of the invention, the ED is configured with a policy, which may be hard-coded in the technical specifications of the telecommunication standard, according to which the ED / UE may not request security information if the ED is in certain circumstances (eg, emergency access).

[0185] In another aspect of the present invention, the master station may also include an indication (security mechanism indication) which indicates which security mechanism the master station allows to be used, enabled and / or disabled in, for example, SIB1.

[0186] In another aspect of the invention, the master station includes said indication (security mechanism indication) in a "protection field" which determines how the system information is protected.

[0187] In another aspect of the present invention, the previous indication may be specific to the ED or the type of ED (e.g., the ED may be a standard UE, or an IoT UE, or a law enforcement UE, or an environmental IoT tag). For example, the indication may indicate:

[0188] - IoT UEs need to use signature / certificate based solutions (e.g., on-demand), but should not use hash-based solutions.

[0189] - Standard UEs may use a signature / certificate based solution (e.g. on demand) or a hash based solution based on their local UE / ED policies,

[0190] -Environmental IoT tags can request security information of a given type.

[0191] In another aspect of the present invention, the security mechanism indication may be a bit flag that specifies which countermeasures are enabled / disabled / supported.

[0192] In another aspect of the invention, the master station and / or ED may support multiple countermeasures and negotiate which countermeasure to apply.

[0193] In another aspect of the invention, if both the ED and the master station support multiple countermeasures, the selection of the security mechanism can be determined on demand (eg, by the ED).

[0194] In another aspect of the present invention, in certain situations (eg, emergency situations), the ED may request the use of "None" as a safety countermeasure. "None" may be expressed by simply not sending an "on-demand indication."

[0195] In another aspect of the present invention, the master station may choose to accept / reject the use of "None" as a security mechanism, depending on its security policy and / or the type of ED.

[0196] In another aspect of the present invention, the ED may be configured with a policy that determines which type of network the ED is allowed to join and / or the ED prefers to join based on the security countermeasures supported by the ED and the security countermeasures provided / supported / used by the network. For example, the ED may only be allowed to join a given type of network / cell, such as a 3G cell / master station, if the ED has (retrieved / received) security information that allows authentication of the network / cell.

[0197] In another aspect of the present invention, the ED may include a device and / or a method for receiving an indication (security mechanism indication) from a primary base station, and determining a security mechanism for verification (e.g., system information verification) based on the indication and / or security countermeasures supported by the ED and / or configured policies.

[0198] In another aspect of the present invention, the network operator configures the ED with the policy by means of standard signaling (eg, using NFs in the CN) when communicating with the core network.

[0199] In another aspect of the invention, the ED is configured with the policy prior to deployment.

[0200] In another aspect of the present invention, ED is configured by a network function in 5GS having the above-mentioned strategy.

[0201] In another aspect of the invention, the ED comprises a USIM including the above-mentioned policy.

[0202] In another aspect of the invention, the MIB or SIB1 includes "on-demand indications" related to the procedures required to retrieve the security information required to authenticate the MIB and / or SIB1.

[0203] In another aspect of the invention, an ED that needs some security information that may be broadcast on demand first scans the time / frequency resources specified in the "Guard Field" and only if no SIB is detected does the ED send a "Security Information Request". Figure 2 The distribution of the message 204 in has been scheduled for the first ED (which has previously sent a security information request ( Figure 2 message 203)) in, then it is advantageous to then Figure 2 The broadcast of such information is signaled in a message 202 in , which may be broadcast / distributed in a conventional manner. Thus, when a second ED receives such a message 202 including time / frequency resources for distributing safety information, the second ED may directly access such safety information.

[0204] In another aspect of the invention, the master uses a combined approach between periodic broadcasts of security information and on-demand delivery of security information. This allows the ED to monitor the channel for regular updates, such as certificates, without having to explicitly send requests; but it also allows security information to be retrieved when needed. The master configuration is conveyed via a "protection field".

[0205] In another aspect of the present invention, a "Guard Field" specifies that security information can be retrieved by sending an initial PRACH message.

[0206] In another aspect of the present invention, a "guard field" refers to a specific frequency / time domain where the ED must send an "on-demand indication" or "safety information request" to trigger the distribution of safety information.

[0207] In another aspect of the present invention, the "Safety Information Request" is sent by the ED via a unicast or multicast message.

[0208] In another aspect of the present invention, the "safety information request" sent by the ED to the master station may be a message including one or more of the following:

[0209] An anonymous signal common to all EDs indicating a “security information request”;

[0210] System information that needs to be verified (e.g., SIB1, MIB, ...);

[0211] The time when the system information has been read, is being read, or will be read;

[0212] · Required security information, such as digital signatures and / or certificates and / or

[0213] · PCI of the cell that needs security information,

[0214] ·wait

[0215] In another aspect of the invention, the above fields may be explicit or implicit for an "indication on demand" / "security information request" message, e.g., receipt of an "indication on demand" at a given frequency band indicates that the UE requires a signature for the current SFN or for some security information (e.g., SIB1) for the current SFN and MASK (mask), where the MASK may be, for example, 0x3F0, such that the SFN and MASK return the 6 most significant bits of the SFN.

[0216] In another aspect of the invention, the "Protection Field" may include a first NONCE (random number), and the "Protection on Demand" / "Security Information Request" may include a second NONCE, and the "Security Information" is calculated taking 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 the second NONCE, and the digital signature in the "Security Information" is calculated using the second NONCE, the ED can verify the freshness of the message.

[0217] In another aspect of the present invention, upon receiving a "security information request" from an ED at a master station, the master station calculates and / or collects the required security information and sends the security information to the ED.

[0218] In another aspect of the present invention, the master station calculates the security information by signing the system information together with the current time value (e.g., the current UTC time or the current SFN value). This can allow the UE to verify the freshness of the security information if the UE is time synchronized, or this can allow the UE to learn the current time of the master station if the security information also includes a signed second NONCE and the UE trusts the master station as in the above embodiments.

[0219] In another aspect of the invention, when requested by the ED or when the ED receives the system information, the master station calculates the security information by signing the system information with a past time value (eg, past UTC time and / or a partial SFN value).

[0220] In another aspect of the invention, the master station may calculate security information by signing the system information together with past and current time values.

[0221] In another aspect of the present invention, the master station may calculate the security information by including the time value used or a portion thereof (the least significant bit (LSB)). Specifically, if a message including a "protection field" ( Figure 2 If the message 202 in the UE includes a time value such as a UTC-based counter or SFN, the security information may include only a portion of the current time value (e.g., the least significant bits) so that the ED / UE can reconstruct the time value when calculating the security information. This is possible because the ED / UE knows that the time value of T0 is included / received in the message including the "protection field" and knows that the message including the "protection field" ( Figure 2 message 202) and a message including "security information" ( Figure 2The time DeltaT that has passed between the two messages (in the message 204) is calculated, and the message 204 includes the LSB of the time when the security information is calculated. The number of LSBs required is equal to log2(DeltaT / Time_Accuracy_Of_A_Bit) rounded up multiplied by the time accuracy of the bit. For example, DeltaT=9ms, and Time_Accuracy_Of_A_Bit is equal to 1ms, then log2(DeltaT / Time_Accuracy_Of_A_Bit)>3 but less than 4. Therefore, the number of LSBs required is 4.

[0222] In a related aspect of the invention, the master station may calculate security information (signature) by including a time value or time difference depending on the beam (SSB) used by the ED to connect to the master station. This is necessary because, for example, the same SIB1 is broadcast multiple times on different beams with a given time delay, as described in the above embodiments.

[0223] 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 depending on the beam (SSB) that the ED uses to connect to the master station. The ED takes this into account by knowing the specific timing of the SIB broadcast in a given SSB when verifying the freshness of the message.

[0224] In a related aspect of the invention,

[0225] The CN or AF sends a message requiring verification to one or more master devices (eg, the message may be, for example, a Public Warning message or other SIB), causing the master devices to broadcast the message as needed.

[0226] The CN or AF may optionally send a signature signing the message using a trust anchor linked to the CN or AF.

[0227] • The master device broadcasts the message in a SIB (eg SIB5) enhanced with a "guard field".

[0228] • If the CN or AF has not provided a signature, the master device optionally calculates a signature over the SIB.

[0229] • The master device broadcasts the "Security Information" as determined in the "Protection Field".

[0230] In a related aspect of the invention, the master station sends security information to the ED via a broadcast channel in the SIB.

[0231] In related aspects of the present invention, security information may be distributed on the DL-SCH in the following manner:

[0232] Unicast

[0233] ●On-demand unicast

[0234] ●Periodic broadcast

[0235] ●On-demand broadcasting

[0236] In a related aspect of the invention, the master station may compute and distribute security information comprising a Merkle tree, the root of the Merkle tree being computed from a hash of the SIBs (e.g., SIB1, SIB2, ...), (e.g., clause 7.3.1 in TS38.300), and the signature being computed on the root of the Merkle tree. This has the advantage of the signing party (e.g., the master station only needs to compute the signature). This has the advantage that the receiving party (e.g., ED) only needs to verify the signature. This embodiment is of particular interest when the ED may request multiple SIBs, and those different SIBs may need to be verified independently.

[0237] In a related aspect of the invention, at least one of the Merkle tree leaves is a hash of a time value or a time value difference, for example:

[0238] ●The time at which a given SIB (e.g. SIB1) is sent

[0239] • The time difference between the sending of a given SIB and the time of sending the security information.

[0240] ● etc.

[0241] This allows the freshness of the single authentication information to be verified independently of the SIB.

[0242] In a related aspect of the invention, the sending of the security information may be accomplished in a random access message such as message 2 of a random access procedure.

[0243] In a related aspect of the invention, the master station for delivering security information is a UE-to-network relay, which has received the security information from an access device such as a base station. It is noted that the UE-to-network relay can act as an ED when receiving security information from a base station, and can act as a master station when forwarding security information to a remote UE.

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

[0245] In a related aspect of the invention, an ED receiving "security information" from a master station uses a signaled algorithm (eg, a digital signature algorithm) to verify the security information, eg, a received digital signature.

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

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

[0248] In a related aspect of the invention, the ED receives the MIB and observes certain fields that may give an indication, for example, that the cell is barred, the ED may still proceed to retrieve SIB1, retrieve security information (e.g., from the network or local storage), and verify that the MIB / SIB1 is correct. This prevents an attacker from performing a DoS attack by giving the UE / ED the ability / configuration to verify the received information.

[0249] In a related aspect of the invention, the ED receives the MIB and observes certain fields that may give an indication, for example, that the cell is barred, which the ED may verify using locally stored security information. As described in other embodiments, the security information may have been received from a different master device.

[0250] In a related aspect of the present invention, the ED can verify the freshness of a message (e.g., a SIB having "system information" including a "protection field" or a subsequent SIB) by checking whether the reception time value in the "security information" is within a time window of the ED's local time (e.g., whether the reception time value of the security information and the local time value are not far from the time window).

[0251] In a related aspect of the present invention, the ED can verify the freshness of the "system information" by checking whether the time difference between the current (for example, when the master station is signed and sends the security information) and past time values ​​(for example, when the master station sends the system information) in the received "security information" is equal to the time difference between the "system information" and the "security information" received by the ED within a time window.

[0252] In a related aspect of the present invention, the ED receiving the "security information" verifies the public key included in the digital certificate included in the "security information" with the help of a trust anchor (e.g., the operator's public key) pre-installed in the ED or USIM or distributed through another "security information" message.

[0253] In a related aspect of the invention, the ED receiving the "security information" verifies the hash chain anchor (TESLA anchor) included in the digital certificate with the help of a trust anchor (e.g., the operator's public key) pre-installed in the ED or USIM or distributed through another "security information" message.

[0254] In a related aspect of the present invention, a first legacy master device (e.g., a 4G eNB) does not support the distribution of "security information". However, the "security information" of the legacy master device is available on demand by a second master device (e.g., a 5G master station) located, for example, in close proximity or within communication range.

[0255] In a related aspect of the present invention, the second master device can link the system information (including timing) broadcast by the first (legacy) master device from the core network or from the first master device (for example, via a wireless / wired Uu interface or an Xn interface), and the second master device will provide corresponding "security information" associated with the system information on demand.

[0256] In a related aspect of the invention, ED

[0257] · receiving system information from the first (legacy) master station and the second master station,

[0258] determining that the second master device provides on-demand security information associated with the first (legacy) master station,

[0259] Request the second master station security information of the first master station,

[0260] receiving said security information from the first master station,

[0261] - Using the security information to verify the system information broadcast by the first master station.

[0262] For example, the first master station may be an NTN satellite or a base station, and the second master station may be a ground base station or another UE / ED, respectively. For example, when the NTN satellite distributes SIBs (e.g., SIB19), the UE connected to the ground base station may request / receive security information of the SIB19 of the NTN satellite from the ground base station. For example, when a base station distributes SIBs (e.g., SIB1), a UE that needs to connect to the base station may request / receive security information of the base station from the UE to which it is connected (via the sidelink / PC5 interface).

[0263] In a related aspect of the present invention, the first master station requests at least one of the following from the second master station via the Xn interface: (a) its system information (e.g., SIB1), (b) its security information (e.g., a signature to sign SIB1), (c) other parameters.

[0264] In a related aspect of the invention, the first master station may request the second master station to deliver its security information (eg, a signature signing SIB1) for a given SIB (eg, SIB1 broadcasted over a given SSB at a given time) over an Xn interface.

[0265] In a related aspect of the present invention, the first master station may request the second master station to deliver its security information (eg, a signature to sign SIB1) upon receiving a security information request from the ED via the Xn interface.

[0266] In a related aspect of the invention, a security message calculated by a master station signs the system messages of multiple masters. This has the advantage that the ED has to retrieve a single security message, for example on demand.

[0267] In a related aspect of the invention, security information calculated by a master station signs system information of multiple masters, where the signature is calculated on the root of a Merkle tree, where leaves correspond to system information (eg, MIB / SIB1) of different masters.

[0268] In a related aspect of the invention, the ED sends a "security information request" to the first master station, which requests "security information" related to at least the first master station and other master stations. This has the advantage that the ED must send fewer requests to retrieve the security information needed to verify the system information of the surrounding cells. The "security information request" may include the PCI of the cell for which the ED needs security information.

[0269] In a related aspect of the invention, the ED searches for a master station that provides good link quality (e.g., a master station that sends a synchronization signal with the strongest signal). The ED can then retrieve the SIB1 of one or more of those "selected" master stations and use the "protected field" to determine whether one of those master stations provides delivery of security information for one or more of the "selected" master stations. The ED can then select one of the master stations and send a request to the "selected" master station to receive not only security information linked to its own system information, but also security information linked to system information of other master stations. Delivery of security information can occur at the "selected" master station or at all "selected" master stations. In the second case, the "selected" master station sends a request to distribute security information to the "selected" master station via the Xn interface.

[0270] In a related aspect of the invention, when the ED is connected to a master station, the ED may receive security information from the master station. The security information may be received on request from the ED (e.g., via an RRC message) or triggered by the master station itself. The ED may then use the security information when performing a handover procedure, whereby the ED needs to receive a synchronization signal of a new, second master station, determine a station identity (PCI), and may only perform the handover if the received security information allows for successful verification and / or freshness verification of the system information received from the second master station.

[0271] Distributed Ledger

[0272] In related aspects of the invention, verification of the authenticity and legitimacy of the master station may be based on records of a ledger, e.g., a distributed ledger such as a blockchain, which may be owned, operated and / or maintained, for example, by a management entity (e.g., a 3GPP body, member, operator, NPN owner).

[0273] A ledger can include one or more of the following modes:

[0274] Operator mode, which includes, for example, 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.) mode, which includes, for example, id, Operator_id, type, operating status, compliance status, certificates, movement trajectory (location over time), etc.

[0275] Trusted certificate authority mode, which includes, for example, the certificate subject name, root certificate, status, etc.

[0276] In related aspects of the invention, the ledger can be a blockchain, or a transparent tree as in RFC9162, or just a central trusted repository.

[0277] In a related aspect of the invention, the ledger may allow permissioned write access so that only authorized manufacturers and / or operators can write to it. In this way, when an operator decides to deploy a base station, an entry including all or part of the information about the base station is entered / submitted into the ledger. When only part of the information about the base station is entered, it may only include, for example, a statement that there are 4G base stations in a given area. This may allow certain parameters that the network operator may not want to share to be kept confidential.

[0278] In a related aspect of the invention, the base station may initially set the operational state to "None" and update to "Operational" only when all checks and / or criteria defined by the management entity are met, e.g., the base station is tested and certified (e.g., compliance certified), deployed, and ready for operation. Other states, such as "Testing" or "Faulty", may also be defined and assigned to the base station based on its state. The state may be included in the ledger or updated in the ledger so that the ED / UE can use it for verification.

[0279] In a related aspect of the invention, an access device may initially have a compliance status set to none, and only be updated to, for example, "compliant" or "non-compliant" based on the reported results of conformance testing conducted by a trusted, independent test lab and / or an operational network and / or ED / UE. Future continuous evaluation / testing of the compliance of the station by a trusted test lab and / or network may result in an update of the compliance status of the access device (e.g., from "compliant" to "non-compliant"). For public verification, the compliance status update may include the conditions under which the status is updated.

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

[0281] In a related aspect of the invention, a monitoring party may monitor for inconsistencies in the information stored in the ledger, for example, if there are two entries that are inconsistent with each other indicating a potential attack (e.g., FBS). This may be, for example, two sets of security information signed by apparently the same access device at two (slightly) different locations. This may be, for example, a set of security information signed by an access device (e.g., a mobile base station mounted on a vehicle) that deviates from the route of a vehicle (e.g., a bus). The monitoring party may be an independent entity / device that monitors the correctness / compliance of the data in the ledger.

[0282] In related aspects of the present invention, the operator may be issued a certificate by a trusted certificate authority. A standardization body (such as ETSI or 3GPP or GSMA) may be / become a trusted certificate authority. These certificates may be used to issue certificates for base stations. Base stations (typically, access devices) may use these certificates to derive security information. The ED may verify a trusted certificate chain to establish the authenticity of the base station before, during, or after connecting to the network, but preferably before connecting to the network. For example, the ED may send an on-demand indication (e.g., a challenge, a random number) as part of a message 1, such as a random access procedure. The base station may sign the random number with its signing key and include it, for example, in a random access response (i.e., a random access procedure message 2), together with other required parameters (e.g., access device id, operator id, certificate authority id, signature, and / or signature digest).

[0283] In a related aspect of the invention, the randomly selected preamble or a portion thereof, or the resources (time / frequency) used by the ED to send, for example, the preamble, may play the role of an on-demand indication (i.e., random number / challenge) sent to the access device (e.g., gNB). In this case, no further data is added to the random access procedure, such as Message 1.

[0284] In related aspects of the invention, the on-demand indication may include additional parameters and / or conditions, such as a time-based counter and / or a time limit.

[0285] In a related aspect of the invention, the ED may store records from a (public / private) ledger (e.g., a schema of a base station, operator, and / or trusted certificate authority) used to verify the authenticity of the station, for example in a local storage device. Such records may be partially or completely changed (e.g., deleted, updated) when the ED is connected to the network and accesses the public ledger, taking into account the capabilities of the ED (e.g., storage capabilities, roaming support, mobility status, etc.); they may be based on an on-demand request by the ED or based on a pull and push mechanism.

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

[0287] In a related aspect of the invention, the ledger is private, e.g. private to a non-public network or private to an operator of a PLMN. Thus, an ED can only access the ledger if authenticated. For example, authenticated as a member of a PLMN or NPN during primary authentication. For example, authenticated with an OAM. This is intended to ensure that the contents of the ledger remain private. Authentication may be based on pre-configured credentials in the ED / UE, e.g., a digital certificate or ownership of an authorization token or private key, which may be used to prove the identity of the ED / UE through the ledger or identity and access management functions around the ledger, and authorize requests for information contained in the ledger.

[0288] In a related aspect of the invention, the ED may retrieve (or configure) and store relevant information from the ledger, such as public keys, access devices, etc., about the area where the ED is currently located or may be located in the future. For example, when the ED is located in a given tracking area, it may retrieve this information. For example, this may be implemented based on a policy. For example, a user may choose to retrieve information for a given location.

[0289] In a related aspect of the invention, depending on the user consent settings of the ED, the network can process / analyze the data of the ED (e.g., location data, cyclic access devices used, etc.) and curate information from the ledger related to the ED. Based on the (continuous) analysis, the network can update (e.g., add, edit, delete) records stored on the ED, for example, periodically and / or based on policies and / or based on on-demand requests from the ED.

[0290] In a related aspect of the invention, the ED can use the stored relevant information to verify the security information received from the access device / master station, for example, after sending an on-demand indication or challenge. For example, if the master station returns security information (including a digital signature), the ED can use the public key retrieved from the ledger to verify the digital signature.

[0291] In a related aspect of the invention, the ledger (i.e., all potential modes, such as devices, access devices, trusted certificate authorities, etc.) can be kept private and / or privately owned by, for example, a non-public network (NPN). The ledger, such as the architecture and access rights, can be personalized according to the needs and requirements of the NPN.

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

[0293] In a related aspect of the invention, the ED may temporarily store information provided by the master / base station (e.g., id, operator id, signature) and then transmit it to the home network (e.g., UDM) for verification together with or as part of the SUCI. In a related aspect of the invention, the ED may have a policy that allows / does not allow (temporary) storage of information provided by the master / base station (e.g., id, operator id, signature) and then performs the necessary verifications itself (e.g., trust certificate chain, operability and compliance checks) once the ED obtains network access rights (including access to the ledger). The policy may also determine the conditions under which the storage of information is allowed / disallowed. The policy may be configurable or hard-coded and always allow / disallow it.

[0294] In a related aspect of the invention, the ED may send a challenge / security information request that may include a reference to the Home Network Identifier (HNI) or Mobile Network Code (MNC) of the ED's home network, where the master station / base station is required to provide its signature, id, operator id, and the ED's random number to be verified by the ED's home network. Upon verification, the ED's HN sends a verification result in a protected message containing other parameters to be delivered to the ED (e.g., Home Network Public Key Identifier). This allows the ED to access / verify the master station even if they have not been configured with a trust anchor to verify them.

[0295] 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) that references the ED's home network, which allows the master station to determine if the ED has been configured with the relevant trust anchor. This allows the master station (e.g., a gNB in ​​a serving network) to request the home network (e.g., a signing NF) with the required security information through the ED. This may be, for example, a digital signature so that the ED can verify that the home network allows the ED to use the master station / gNB / access device.

[0296] In related aspects of the invention, the signature and authenticity checks performed on the information provided by the master station may also include operational and compliance checks, i.e., checks to verify that the master station is a trusted device to be accessed and that it performs well with the ED. In general, or in the specific embodiments mentioned, trust verification and / or verified certificate chain may refer to and / or include, but are not limited to, a process of verifying the validity period of an entity (e.g., a base station) certificate (e.g., Certificate_A) and the signature of the authority (e.g., an operator) that issued and signed Certificate_A, and then recursively repeating the process (i.e., verifying the validity period of an authority (e.g., an operator) certificate (e.g., Certificate_B), and the signature of a higher authority (e.g., a trusted certificate authority) that issued and signed Certificate_B, until a trusted certificate authority is reached, thereby establishing the authenticity and trustworthiness of the entity.

[0297] In another aspect of the present invention, verification may also refer to and / or include one or more of the following:

[0298] - Operational check: whereby a local check (e.g., a locally stored copy of the ledger record) corresponds to the operational state of the device id (e.g., PCI of the master / access device) or checks the records of the ledger.

[0299] - Compliance check: whereby the compliance status of the id corresponding to the primary site / device (e.g., NCR) is checked locally (e.g., a locally stored copy of the ledger record) or the records of the ledger are checked.

[0300] In another aspect of the present invention, the PCI may be broadcast in the PBCH as part of the synchronization signal of the master station next to the MIB. However, the PCI is too short an identifier to allow unique identification of the master station. Therefore, the system information (e.g., SIB1) includes a unique master station identifier that can be used by the ED to identify the master station. Additionally or alternatively, a unique master station identifier may be constructed based on the location of the master station and the PCI identifier to ensure that the PCI is unique in a given area. "Protected information" and / or "security information" and / or SIB may include such a unique master station identifier.

[0301] In some cases, a network may include cells of multiple cellular generations, such as 2G, 3G, 4G, and 5G. Over time, some cells of the oldest generation are deactivated. However, an attacker may still place (fake) base stations of those older generations because the attack surface is larger. The ED cannot determine whether the cell of one of those old cellular generations is operated correctly by the operator or a fake base station. In this context, in one aspect of the present invention, a distributed ledger can be used to enhance the cellular system, which is used by the operator to include a statement of cellular technology (e.g., 2G, 3G) of the base station or base station type that is retired or available in a certain area (e.g., in a tracking area). The ED / user device can look up such a blockchain infrastructure to determine whether the base station is fake or deactivated. When the ED is already connected or is connecting to the network (e.g., sending a "security information request"), the ED or user device can request / retrieve / download a statement from the blockchain. The ED can perform local verification based on the locally stored statement before connecting to the base station. The ED may be able to retrieve, request, or receive a statement for a given geographic area (e.g., the area where the UE is currently located or the area where the UE will be located). For example, an ED / UE in a given tracking area may receive declarations related to that tracking area by default or if subscribed to the declarations. For example, an ED in a given tracking area may send a request to a distributed ledger or a network function interacting with it to download declarations for the tracking area. For example, a master station may receive a "security information request" and retrieve declarations from the distributed ledger. These requests may be for a specific PLMN or for a specific NPN or for multiple PLMNs. The network function may verify the location of the ED or the authorization to access the data before authorizing the distribution of the declaration. If the network function verifies that the ED is connected to a plane flying to Boston, an ED heading for a given location / tracking area (e.g., an ED flying from Amsterdam to Boston) may request / retrieve declarations for the target area (in this case, Boston).

[0302] In another aspect of the present invention, the master station / access device (e.g., base station) can broadcast (e.g., in SIB) a signed statement from the ledger, which confirms their status, so that the ED / UE can verify whether the oldest generation of the master cell / serving cell is still entrusted to operate. Alternatively, or if the ED / UE fails to retrieve the statement, the ED / UE can request such a statement from the master station / access device, for example, when transmitting PRACH, whereby the ED / UE establishes an RRC connection upon successful verification of the access device authenticity and / or commissioning status.

[0303] In another embodiment, when the UE enters the RRC_INACTIVE state while being served by a master / base station (e.g., source gNB), and then later, after retrieving a security context from the source master / gNB, attempts to transition to RRC_CONNECTED under another master / base station (e.g., target gNB), the latter may verify (e.g., via a ledger) that the target master / gNB is legitimate and still in a commissioned state, and only process (e.g., decrypt, integrity verify, and / or provide keys) the target master / gNB's request if the verification is successful. In addition, the source master / gNB may provide a signed statement of successful verification to the target master / gNB, which the target master / gNB may forward to the UE. Such a statement from the source master / gNB is equivalent to a ledger check, and the UE may be exempted from the ledger check. After verifying the statement from the source master / gNB, and if successful, the UE may establish an RRC connection with the target master / gNB and transition to RRC_CONNECTED.

[0304] In some cases, such as inter-gNB handover scenarios, the UE may access the target master station / cell without reading system information because this information is provided by the source master station / cell (e.g., source gNB) together with at least the cell ID in the RRCReconfiguration message, which is received as part of the handover request confirmation sent by the target master station / gNB to the source master station / gNB. In this case, in another aspect of the present invention, the target master station / gNB may also include a signed statement of the confirmation status from the ledger, which may be verified by one or both of the source master station / gNB and the ED / UE. Alternatively, the source master station / gNB may check and verify the status of the target master station / cell before initiating a handover procedure with the target cell; the source master station / gNB may then provide the statement to the ED / UE for further verification as part of the RRCReconfiguration configuration message.

[0305] According to the above-mentioned embodiment, a method for checking / verifying the legitimacy and authenticity of a master station based on a ledger is proposed, wherein the method can be implemented on a validator (e.g., ED) and involves verifying security information of an access device (e.g., signature, trust certificate chain, and other criteria (e.g., operation and compliance status) based on records in the ledger, whereby once the validator has access to the network, the verification may or may not rely on network assistance, such as being completed by the validator itself, or based on a locally stored copy of the latest record corresponding to the ledger.

[0306] The method may rely on a different process to obtain security information. For example, the process may be the same as in other embodiments:

[0307] - The terminal device (e.g., UE) sends an on-demand indication (e.g., a challenge) to the primary station during a random access procedure (e.g., random access procedure message 1);

[0308] -The master station signs and calculates the signature digest indicated on demand, adds the parameters required to perform the check / verification (e.g., master station ID, certificate authority ID) to the response message (e.g., random access response), and sends the response message to the verifier (e.g., terminal device).

[0309] The present invention is applied to non-terrestrial networks

[0310] The application of the present invention may refer to a non-terrestrial network, in which a non-terrestrial access device (such as a satellite or an unmanned aerial vehicle) provides a connection to the ED / UE. The important information that needs to be verified refers to the data of the non-terrestrial device, such as ephemeris data. SIB19 was introduced by 3GPP Release 17. The SIB provides NTN-specific parameters for the serving master station and / or the master station. Specifically, SIB19 includes auxiliary information of non-terrestrial access devices, such as ephemeris data, common timing advance parameters, koffset, validity duration of UL synchronization epoch time, cell reference position, timing advance report during initial access, and cell stop time as described in TS38.331. If false information is distributed or the information is modified, it may seriously affect the communication of UE / ED because they will not be able to communicate correctly. Therefore, the content of SIB19 should be protected. To this end, the present invention and variations of the present invention may be applicable. Examples of applications may include:

[0311] In applications, the content of SIB19 can be stored in a distributed ledger that can be accessed by the ED or another master station / NF on behalf of the ED so that the ED can verify the received parameters. When a new non-ground master station becomes available, for example, when a new satellite enters orbit, the satellite operator uploads the information of the non-ground master station to the distributed ledger. The information of the satellite can be retrieved by, for example, the UE / ED when connected, or by the ground master station / NF on behalf of the UE / ED. The ground master station / NF can then distribute the security information to the UE / ED.

[0312] Figure 3 It is shown how some aspects described in this invention can be applied to the protection of SIB19. Figure 3 The entities and messages 300-305 in are equivalent to Figure 2 306 represents a request from ED 300 to retrieve security information for SIB19 of a given non-terrestrial master station. The request may also request security information to verify the SIB19 non-terrestrial master stations available in a given area at a given time (e.g., for the current hour in the location where the ED is located). Entity 311 may then return one or more security information messages to entity 300. Entity 300 may then use the received security information to verify SIB19 (if it has been received). Additionally or alternatively, entity 300 may send a request to retrieve SIB19. The 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 retrieve SIB19. The request may not include a request for security information related to SIB19. Entity 301 then delivers SIB19 in message 309. In this case, the SIB may include an indication of protection so that entity 300 may send a subsequent security information request in message 310. Entity 301 delivers security information for SIB19 in message 312.

[0313] Additionally or alternatively, the management entity of the non-terrestrial master station may not want the information of SIB19 to be public and accessible to all EDs. Therefore, the management entity may select a key K for a given period of time and use K to protect the data in SIB19 confidentially. An ED interested in the use of a non-terrestrial master station may send a request to the network (e.g., NF) or AF (e.g., AF representing the management entity of the non-terrestrial master station) to obtain authorization to use the service. This request may be authenticated via AKMA (TS33.535) or GBA. After authentication, the NF or AF may further check whether the ED is authorized, for example, whether the ED has subscribed to the services of the non-terrestrial access device. This may require sending a request to an authentication function such as AUSF or UDM where the ED profile is located. After authentication, the AF / NF may securely pass the key K to the ED.

[0314] Figure 6This overall approach is shown, where entities 600, 601, 602, 603, and 604 represent an ED, a first master station (e.g., a non-terrestrial master station), a second master station (e.g., a terrestrial master station), an NF or AF in the core network of a 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 process) for accessing the first master station, including a registration request. During this process, message 605 may indicate that certain SIBs are protected by confidentiality, in this case SIB19, and authentication / authorization is required to access them. During this process, the ED may send a security information request to the first master station. The returned security information may indicate that certain SIBs are protected by confidentiality, in this case SIB19, and authentication / authorization is required to access them. Message 609 represents a message or process toward the NF in the CN / AF to obtain authentication / authorization to use the first master station. This may be part of a network access message or primary authentication. The request may be sent via the second master station (e.g. if it involves an AKMA procedure, or may be sent via the first master station, where the first master station may only allow such messages / procedures, such as primary authentication. Once entity 603 has authenticated 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 may provide entity 600 (i.e. ED) with the key K for protecting SIB19. Additionally or alternatively, the ED may receive a key K in this message. Receive the contents of SIB19. In step 613, the ED may request further SIB19. In step 614, entity 603 may provide the first master station with SIB19 information and / or key K to protect the SIB19 information, and / or the protected data to be carried in SIB19. Finally, in step 615, the protected information of SIB19 is distributed via SIB19. It should be noted that, beside K, the ED receives other auxiliary data, such as a protection algorithm (e.g., NEA and / or NIA algorithm) used to protect the SIB information. Protection may mean confidentiality and / or integrity protection.

[0315] The present invention is applied to environmental IoT

[0316] One aspect disclosed by the present invention is how the ED / UE can receive security information on demand, such as during a random access procedure. Therefore, the present invention helps to protect the random access procedures used by the ED / UE in cellular technologies such as 4G or 5G. The next generation of cellular technologies will also handle and support resource-constrained IoT devices. These devices, also known as environmental IoT tags, will be very simple. The reader, such as a base station / master station, may be able to send a read signal, while the environmental IoT tag may only be able to send a reply, an answer, such as its identity, location, or sensing data. From this perspective, it makes sense if such a read signal can be distributed similarly to system information such as MIB or SIB1 so that the tag can reply to it when it is receiving / receiving such a signal. Therefore, it makes sense to further align the procedures in the above-mentioned invention variants with security procedures to protect communications with surrounding IoT devices. Therefore:

[0317] In one aspect of the present invention, Figure 2 The first message 202 in may refer to a message including system information and requesting an IoT device (e.g., an environmental IoT tag) to provide a response with certain information that the IoT device may have (e.g., its identity or sensor data); Figure 2 The second message 203 in may refer to a potential response of the device, which may include protected data of the master station or another entity behind the master station (e.g., NF or AF); Figure 2 The third message 204 in may refer to security information provided by the master station to the ED so that the ED can authenticate the requesting entity. The data may be associated with the master station or the requesting entity; Figure 2 The fourth message 205 in may refer to a further potential response of the device, which may include protected data for the master station or another requesting entity (eg, NF or AF) when authenticating the master station or another requesting entity behind the master station.

[0318] In such ambient IoT scenarios, ambient IoT tags may be very resource-constrained, so they may not be able to perform heavy computations. Therefore, the following aspects of the present invention may apply.

[0319] In one aspect of the present invention, a master may send a challenge to an ED (such as an ambient IoT device) to retrieve certain data from the ED. The ED may have a policy that only allows data to be disclosed to trusted devices, even if it is encrypted. Therefore, the received IoT may include a "protection field" that provides system / identification information about the requesting master and an indication that security information is available. The ED may then reply with an "indication on demand" / "security information request" message. Upon receipt, the requesting master sends the requested security information to the ED, which authenticates it, and if the authentication is successful, sends the previously requested data. This requires two round trips to securely retrieve data from the ED.

[0320] In another aspect, the ED may include a function such as a one-function, a physically unclonable function (PUF), or an HMAC that can Figure 2 The function takes as input one or more parameters (challenges) in the "protected field" received in the first message 202 in the first message 202 and generates a response. The function may make it difficult to calculate one or more input parameters (challenges) given the response. For example, if the function is based on a physically unclonable function or an HMAC with a device-specific key as input, it may be device-specific. For example, the parameter in the "protected field" may be a first random number.

[0321] In another aspect, the ED may reply in message 203 with a response that depends on the challenge in the "Protection Field". The master station (or a requesting entity behind the master station) may use the response to identify the ED. For example, the master station (or a requesting entity behind the master station) may have a mapping:

[0322] Challenge, Response_i, Device_ID_i

[0323] Such that for a given response_i, the challenge can be used to identify the device_ID_i.

[0324] In another aspect, the ED may have a function that generates a response R_j given an input challenge. The response R_j may be viewed as the concatenation of two responses R_j1 and R_j2, such that R_j1 has a length L1 and R_j2 has a length L2. R_j1 may be sent in message 203 as in the previous embodiment. And R_j2 may be used to encrypt data to be sent by encrypting the data as an XOR with R_j2. This allows R_j1 to be used to identify the device and generate the output, and once the device is identified, the master may use the (then known R_j2) to access the data.

[0325] In another aspect of the present invention, the ED / environmental IoT tag can be configured to determine whether it needs to authenticate the master / requesting entity behind the master. This configuration can be policy-based or pre-configured. If authentication of the master is required, the ED / environmental IoT tag can determine whether it needs to authenticate the master / requesting entity behind the master. Figure 2 A "Security Information Request" message is sent 203. The message may include a second random number. Additionally or alternatively, the ED may use other embodiments as described below which are directly aimed at verifying the authenticity of the master station given an initial message including a "protection field".

[0326] In another aspect of the invention, since generating random data may be difficult in a resource-constrained device, the device may store the random data in a read-only memory and use the random data as a source of randomness.

[0327] In another aspect of the present invention, it may be desirable that the IoT device 200 may act on the 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 it to be verified by the device 200. For example, a method may include including a random number / counter and a MIC in the message 202, wherein the MIC is calculated using a key and a random number / counter specific to the device 200, wherein the device tracks the last random number / counter used. If the message 202 includes a counter and a MIC, the device 200 may recalculate the MIC (e.g., assuming that HMAC-SHA256 is used to calculate the MIC, e.g., as the last 32 bits of the HMAC output), then the device 200 may verify that the received MIC is correct and that the counter included in the message 202 is higher than the counter stored locally. This approach provides strong security, but may be too demanding for small IoT devices. Another approach may include sending a challenge Ch to the device 200 in the message 202. When Ch is applied to P(), the device 200 is configured with a secret / device-specific function P() (e.g., a secret permutation) and a current internal state IS. A requesting device (e.g., a master station 201) that knows the tag may select Ch such that P(Ch)=IS. The device may also be configured with a second secret device-specific function PP(), which is applied to the received challenge Ch and a function G() of the old IS, such that a new internal state IS' is calculated as IS'=PP(G(Ch, IS)) and, if the check P(Ch)=IS succeeds, is stored in the device. Furthermore, if the check P(Ch)=IS succeeds, the device 200 may send a message 203 to the requesting device 201 (e.g., a master station). If the message 203 includes any private data D, such private data may be confidentiality protected by XORing it with a pseudo-random sequence derived by a third function PPP() having as input the received challenge Ch and the internal state IS. The message 203 may also include some bits related to the new internal state IS' and / or the data sent. For example, if PP(Ch, S)=TRUNC(PP'(G(Ch, IS))) and TRUNC(A) returns the b least significant bits of the k-bit long input A=PP'(G(Ch, IS)), then the message 203 may return the kb most significant bits of A. This is typically the fourth function PPPP(), which takes as input the new internal state IS' and the sent data, and whose output serves as a proof to the requesting device 201 that the new internal state IS' is correct and / or that the received data is correct.

[0328] In one aspect of the invention, the device 200 may include four functions P(), PP(), PPP() and PPPP():

[0329] P() is intended to verify the request in message 202,

[0330] • PP() aims to update the internal state of the tag given the request in message 202 and / or the last internal state, • PPP() aims to generate a pseudo-random sequence to protect data to be sent in, for example, message 203.

[0331] • PPPP() is intended to provide proof to the requesting device about the currently received data (eg in message 203) and the (new) secret internal state.

[0332] In one aspect of the present invention, a potential choice of the above function is a lightweight hash function, for example, P() in the above design can be a one-way hash function. The master or requesting entity can calculate the hash chain given an initial seed S. The master station can calculate S^n=Hash(Hash(…n times…(Hash(S))…), that is, S^n is obtained by applying the hash function n times. The initial state of the device is set to S^n. The first challenge sent by the master station / requesting device is S^{n-1}, so that the device 200 needs to check whether S^n is equal to Hash(S^{n-1}). In this case, the function PP() simply replaces the old internal state with the newly received challenge. PPP() and PPPP() can also be based on the same hash function. For example, PPP() can be a hash function that takes IS and / or a received challenge or another secret / internal state as input to derive a pseudo-random bit sequence for data encryption by XORing the data with the pseudo-random bit sequence. For example, PPPP() may be a hash function that takes IS and / or a received challenge or another secret / internal state and / or data as input to calculate a MIC.

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

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

[0335] In another aspect of the present invention, the one-way hash function may be based on ASCON Hash or ASCON XOF.

[0336] In another aspect of the present invention, some of the above functions may also be based on ASCON authentication encryption, for example, functions PPP() and PPPP() may be based on ASCON authentication encryption.

[0337] In another aspect of the present invention, ED 200, i.e., an ambient IoT tag, may be configured with one or more identities, such as a master station, a requesting entity, a lookup service, a type of ED addressed by the message, an IoT group, etc., which is authorized to retrieve data / send request 202. The one or more identities may be included in the message 202 (e.g., as part of "system information"). The type of ED addressed by the message may refer to the capabilities of the addressed ED, such as an ED with more or less resource capabilities. The ED / tag 200 may only further process the message if one or more identities included in the message 202 matches a preconfigured identity or set of identities. This aspect of the present invention acts as a first filter for the ED 200 to reply only to those messages sent to it. This is useful, for example, to reduce the amount of replies to broadcast messages 202.

[0338] In another aspect of the present invention, the initial message 202 including the "protection field" may include a flag indicating the master mode, where the mode may be, for example, "identifying" or "identified". In the "identifying" mode, the master identifies the ED / IoT tag by requesting the ED / IoT to only reply to the input message, for example, by providing an identifier or a response to a challenge at one or more frequencies. The returned response may be a message 203, which also includes a "security information request". The master may then profile the ED / IoT device's answer to identify it by sending multiple messages 202 and receiving multiple messages 203. The analysis may be based on, for example, the radio frequency (RF) properties of the ED's wireless transmitter (Tx), because the device-specific aspects of the Tx make it identifiable. Therefore, the RF characteristics of the Tx act as a PUF. Once the ED is identified by the master (or a requesting entity behind the master), the ED is sent a message 202 including the "identified" mode. The message may also be a message 204 with the requested security information. Sending this message may implicitly mean that the device ED has been identified. Since it has been identified, the security information may be specific to that device, for example, a challenge may be being used against the ED PUF whose response is known to the master, or it may be using a challenge so that the ED can calculate a MIC by using a key K known to the master. Additionally or alternatively, the master may send the MIC itself, which is calculated using the key known to the ED and uses as input a random number received in a message from the ED during the identification phase. Upon receiving this message indicating that the master has identified the ED, the ED may proceed to provide the master with requested data (e.g., its protected identity or protected sensed data), etc., if, for example, the master has been authenticated by the ED based on the security information provided by the master.

[0339] In another aspect of the present invention, since it may be difficult to generate random data in a resource-constrained device, the device may generate random data by passing the currently received wireless signal to a function such as a hash function, HMAC, PUF, etc. and using the output as random data. In order to ensure that an attacker cannot easily manipulate the input and thus the output, the tag may retain the secret original value R (e.g., in memory) and XOR / pre-add / append / insert it with the received wireless 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 wireless signal. In addition, the secret original value R can be updated after each iteration. For example, if the function outputs a value W, b bits of W can be used as a second random number, and k different bits of W can be used to update the secret original value R, for example, by replacing the old value R or obtaining a new value R as a third function of the old value R and k selected bits of W, for example, R_new=R_old XOR W_k, where R_new is the new secret original value R, W_k is the selected k bits of W, and R_old is the old secret original value R.

[0340] In another aspect of the invention, the ED may receive information in message 204 along with the security information that it may use in subsequent interactions. For example, the ED may retain a pseudonym in memory. The ED may use the pseudonym to identify itself, for example, when sending a "security information request" in message 203. When the ED receives message 204 and the ED verifies the security information, the ED may also update the pseudonym currently in memory with the new pseudonym. This operation can only be applied when the ED successfully verifies the security information. The newly received pseudonym can be protected by XORing it with a random bit string, which can be the output of a function (such as a PUF) described in other aspects of the invention. Message 204 may also include a challenge known to the host or requesting entity, which, when applied to the function, generates a random bit string used to encrypt the pseudonym.

[0341] Figure 4Another potential deployment option of the present invention is described, in which entities 401 and 402 refer to master stations, for example, they can both be base stations, or 401 can be a UE, 402 can be a base station, etc., and entity 400 represents an ED or environmental IoT device. Message 403 represents the distribution of a system information message including a protected field. Upon receiving 403, entity 400 can reply to entity 401 with message 404, such as a security message or a message with a security information request. This reply is similar to many of the variants discussed so far. In addition or alternatively, entity 400 can send / forward message 405 to entity 402. This message 405 can be a backscatter message of the ED / environmental IoT device. It should be noted that since entity 402 is the entity that receives message 405 in this alternative, this may require entity 402 to send an initial message 406 before message 403 is sent with the security configuration. Alternatively, entity 401 may generate some random parameters, such as random numbers or RF communication parameters, and send them to entity 402 in message 406 so that entity 402 takes them into account when identifying / authenticating ED 400, i.e., in this alternative, message 406 goes from 401 to 402. In general, message 406 represents a secure information exchange between master stations 401 and 402 to achieve identification and / or authentication of ED 400.

[0342] therefore, Figure 4 Explained Figure 2 How the message flow is applied to a distributed environment, where an entity 400 may receive a first message (a system information message with a protection field) from a first master station, and the entity 400 may send another message 404 or 405 to the first master station or the second master station. Figure 4 The need for coordination between the first master station and the second master station regarding exchanged safety data is described.

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

[0344] Thus, as seen in the foregoing description, a whole system is proposed to reduce the possibility of attacks based on pseudo base stations or middlemen and to allow verification of system information distributed by access devices / main stations. The components of the system include secondary stations and main stations that implement one or more of the described embodiments. The device can be implemented by program code units of a computer program and / or dedicated hardware of related devices, respectively. The computer program can be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with other hardware or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

[0345] Other variations to the disclosed embodiments may be understood and implemented by those skilled in the art in practicing the claimed invention by studying the drawings, the present disclosure and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may implement the functions of several items described in the claims. The fact that certain measures are cited in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage. The above description describes certain embodiments of the invention in detail. However, it should be understood that no matter how detailed the above is in the text, the present invention can be practiced in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of specific terms in describing certain features or aspects of the present invention should not be taken as implying that the term is redefined herein to be limited to including any specific features of the features or aspects of the invention associated with the term.

[0346] Furthermore, where a convention similar to “at least one of A, B, and C, etc.” is used, generally speaking, such construction is in the sense that a person skilled in the art understands the convention, for example, “a system having at least one of A, B, and C” will include but is not limited to systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Where a convention similar to “at least one of A, B, or C, etc.” is used, generally speaking, such construction is in the sense that a person skilled in the art understands the convention, for example, “a system having at least one of A, B, and C” will include but is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Those skilled in the art will further understand that almost any disjunctive word and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”.

Claims

1. A device comprising: Controller; Receiver, and transmitter; The receiver is adapted to receive a first system information message sent from or through the first primary station, wherein the controller is adapted to decode the first system information message and obtain a protection field, the controller is adapted to use the protection field to determine the location of "security information", and The controller is configured to use the "security information" in order to Verify the received message and / or the first master station and / or The transmitter is caused to send a subsequent safety message to the first master station or a third master station.

2. The device according to claim 1, wherein: The device is suitable for: Sending a "security information request" to the first master station or the third master station, Receive "security information" from the first master station, The received “security information” is used to verify the previously received first system information message or the second system information message received from the second master station.

3. The device according to claim 2, wherein: The apparatus is adapted to send the safety information request based on the determined location of the safety information.

4. The device according to claim 2 or 3, wherein: The apparatus is adapted to send a "security information request" to the first master station or the third master station, wherein the security information request requires security information for authentication of a system information message, and the request is sent if at least one of the following conditions is met: - the device is of a given type - said system information message is sent by a master station with a given identity, - said system information message is sent at a given time or time frame, - The system information message is sent in a given area.

5. A device according to any one of the preceding claims, wherein: The "security information" of the first master station is retrieved from a distributed ledger.

6. The device according to claim 2 or 3, wherein: The "safety information request" is sent in the initial PRACH message.

7. A device according to any one of the preceding claims, 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 correction with the timing advance indicated by the master station, whereby the timing advance is securely protected by means of the security information.

8. A device according to any one of the preceding claims, wherein: The device is capable of: receiving a second system information message, and The second system information message is verified based on the received security information to verify the first system information message.

9. The device according to claim 8, wherein: The device verifies the second system information message using a Merkle tree structure.

10. The device according to claim 1, wherein: The “protected field” in the first system information message comprises a challenge used by the device to authenticate the master station by means of a first function P() and a secret internal state variable.

11. The device according to claim 1 or 10, wherein: The “protection field” includes one or more identities used by the device to determine whether the device needs to further process the received first system information message.

12. The device according to 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. The device according to claim 1, 10, 11 or 12, wherein: The subsequent secure message includes data that is confidentiality protected based on the "protection field", the secret internal state information and the information in the third variable PPP().

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

15. The device according to any one of the preceding claims 10 to 14, wherein: The first function, the second function, the third function and the fourth function may be one or more of the following: Physical unclonable functions, a list of challenge-response values ​​stored in memory, Secret replacement, Hash functions, such as ASCON-HASH, Expandable output functions such as ASCON-XOF, Authenticated encryption algorithms such as ASCON-AE.

16. An apparatus comprising: Controller, Receiver, and transmitter; wherein the controller is adapted to cause the transmitter to broadcast a first system information message including a “guard field”, And the receiver is adapted to receive a "security information request" and / or a security message from the terminal equipment ED.

17. The device according to claim 16, wherein: The controller is suitable for: securely processing the secure message by extracting data included in the secure message based on the information in the "protected field", the secret internal state information of the ED, and / or Determining security information for the first system information message and sending the security information.

18. The device according to claim 17, wherein: The receiver is adapted to receive a second safety message and to securely process the second safety message.

19. The device according to claim 17, wherein: The security information is included in the random access response message.

20. The device according to claim 17 or 19, wherein: The “security information” integrity protects fields in the random access response message, such as the timing advance, and / or properties of the security information request message, such as the beam used to receive the message.

21. A method for securely communicating with a master station, wherein: The method comprises: receiving a first system information message from or through the first master station, Decoding the first system information message and obtaining a "protection field", Use the "Protection Field" to determine the location of the "Security Information", and Use Security Messages to Verify the received message and / or the first master and / or A subsequent safety message is sent to the first primary station.

22. A method for securely communicating with a terminal device, wherein: The method comprises: broadcasting a first system information message including a "protection field", Receive a "security information request" and / or security message from a terminal device.

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

24. A computer program for secure communication, wherein: The program includes instructions for implementing the apparatus according to any one of claims 1 to 15 and 16 to 20.

Images