Authenticating system information blocks

Abstract

This disclosure describes techniques and systems for authenticating a system information block (SIB). These techniques enable a base station (120) to schedule a signed SIB for transmission and generate a signed SIB (805). The base station packs (810) the signed SIB for transmission, transmits (815) SIB1, and transmits the signed SIB (820). Further aspects describe techniques for a user equipment (UE) (110) to verify (830) a signed SIB, authenticate the content of the signed SIB, and then use some of the content of the signed SIB to verify other received SIBs (835) and use the verified SIBs for network attachment.

Description

Authentication system information block Background Technology

[0001] User equipment (UE) connected to cellular networks is vulnerable to spoofed base station (FBS) attacks. This vulnerability is present across multiple generations of wireless mobility technologies and is a systemic security threat, not specific to any particular device manufacturer or wireless operator. Therefore, UEs are susceptible to protocol vulnerabilities such as International Mobile Subscriber Identity (IMSI) capture devices, surveillance and tracking, spoofed radio emergency alerts, and other exploits. Standard security features used by UEs, such as end-to-end encryption and virtual private networks, neither prevent nor mitigate any of these threats.

[0002] The fundamental vulnerability in all these attacks lies in the fact that the UE cannot verify the legitimacy of the cellular network before performing security- and privacy-sensitive operations. Specifically, the UE cannot verify the integrity of the System Information Block (SIB) broadcast by the base station. The SIB contains critical connection establishment information and is broadcast without integrity protection so that it can be decoded by a UE that has not established an integrity protection key with the network. There is an opportunity to use authentication technologies to improve the security of the wireless network and the UE without hindering existing UEs that have not implemented authentication technologies. Summary of the Invention

[0003] The present invention is provided to introduce a simplified concept for coordinating user equipment selection. This simplified concept is further described below in the detailed description. The present invention is not intended to identify key features of the claimed subject matter, nor is it intended to determine the scope of the claimed subject matter.

[0004] In various aspects, methods, apparatuses, systems, and components for authenticating System Information Blocks (SIBs) by a base station are described, wherein a base station schedules signed SIBs for transmission and generates signed SIBs. The base station packages the signed SIBs for transmission, transmits SIB1 and SIB2, and transmits the signed SIBs, wherein the scheduling information contains an indication of the signed SIBs.

[0005] In other aspects, methods, apparatus, systems, and components for authenticating System Information Blocks (SIBs) by a User Equipment (UE) are described, wherein the UE receives an SIB1 including scheduling information from a base station. If a signed SIB is scheduled, the UE obtains the signed SIB and compares the Public Land Mobile Network (PLMN) identifier in the signed SIB with the primary PLMN identifier in SIB1. If the compared PLMN identifiers match, the UE verifies the signature of the signed SIB to verify its contents. If the signature of the signed SIB is valid, the UE verifies the basic SIB group. If the basic SIB group is valid, the UE uses the SIBs in the basic SIB group to perform actions and continues the attachment process to attach to the cell provided by the base station transmitting SIB1.

[0006] In a further aspect, methods, apparatus, systems, and components for authenticating System Information Blocks (SIBs) by a Certification Authority (CA) server are described, wherein the CA server generates a home network root certificate and signs the home network root certificate using a home network private key. The CA server generates one or more serving network certificates and signs one or more serving network certificates using a home network private key, the one or more serving network certificates being used to authenticate SIBs for cells in a Radio Access Network (RAN). Attached Figure Description

[0007] The details of one or more aspects of the authentication system information block are described below. The same reference numerals are used to indicate similar elements in different instances in the specification and figures: Figure 1 shows an example wireless network system in which various aspects of the authentication system information block can be implemented.

[0008] Figure 2 shows an example device diagram that can implement various aspects of the authentication system information block.

[0009] Figure 3 shows an example diagram of the 4G LTE core network architecture.

[0010] Figure 4 shows an example diagram of the 5G core network architecture.

[0011] Figure 5 shows an example device diagram that can implement various aspects of the authentication system information block.

[0012] Figure 6 shows an example implementation of a signature SIB used for authentication system information blocks.

[0013] Figure 7 shows another example certificate trust chain used for authentication system information blocks.

[0014] Figure 8 shows example data and control transactions between the base station and user equipment for implementing authentication system information blocks.

[0015] Figure 9 illustrates an example process for SIB packaging of a base station according to various aspects of the technology described herein.

[0016] Figures 10a and 10b illustrate example procedures for SIB unpacking and verification by a UE according to various aspects of the techniques described herein.

[0017] Figure 11 illustrates an example method of a system information block in an authentication user device according to various aspects of the techniques described herein.

[0018] Figure 12 illustrates an example method for system information blocks in an authentication network based on various aspects of the techniques described herein.

[0019] Figure 13 illustrates an example method for system information blocks in an authentication network based on various aspects of the techniques described herein. Detailed Implementation

[0020] This document describes techniques and systems for authenticating System Information Blocks (SIBs). Currently, attackers can broadcast malicious SIBs to force UEs to display false warning messages, trick UEs into connecting to rogue base stations to perform UE surveillance in the local area, or carry out other cellular network attacks. The techniques described herein introduce a new signature broadcast and certificate trust chain to the cellular standard, which allows UEs to verify the integrity and authenticity of one or more System Information Blocks (SIBs) broadcast by the Radio Access Network (RAN) in a combined manner. By adding new SIBs containing signatures for other SIBs, the described techniques maintain backward compatibility with older UEs while providing SIB authentication to UEs that support the authentication techniques described herein. Furthermore, these techniques have lower overhead because signatures for multiple SIBs are contained in a single signature, rather than each SIB having its own signature.

[0021] The certificate trust chain consists of a single root certificate and one or more serving network certificates. Each home network operator (NLO) acts as its own certification authority, with the long-term root certificate serving as the root of trust (RoT) within the operator's network. The NLO is expected to protect this long-term RoT key via contemporary mechanisms, including but not limited to Hardware Security Modules (HSMs). This NLO root certificate is used to sign one or more serving network certificates (other NLOs providing wireless services, such as roaming partners). The NLO is also considered a serving network operator; therefore, the NLO also possesses a serving network certificate. Serving network certificates are generated for the NLO and for each NLO with which the NLO has established a roaming agreement, allowing roaming on authorized networks. The NLO can choose to generate short-term serving network certificates—countersigned by the long-term RoT certificate—thus reducing the operational burden of potentially revoking serving network certificates. One or more NLO root certificates can be pre-loaded onto the UE by the operator or OEM. Alternatively, the operator can choose to have a third-party Internet CA sign their NLO root certificates. In this case, one or more Internet root CAs can be pre-loaded onto the UE or Subscriber Identity Module (SIM) by the operator or OEM. The SIM can be a SIM card or an eSIM. The same public key used in the serving network certificate will be shared among all serving network certificates used by a specific serving mobile network operator, thus allowing a single serving network operator to have roaming agreements with multiple home network operators, including itself. Home network operators can also generate certificates for other networks that lack the resources to do so, such as mobile virtual network operators (MVNOs) using the home network operator's RAN.

[0022] In all aspects, the root of trust (RoT) public key used to verify signatures is included in the SIM card or embedded SIM (eSIM) used by the UE. Using a single long-term root of trust key, the serving network can use short-term signing keys, each of which is countersigned by the root of trust key. The UE will only need the RoT public key to verify the signature generated by the network. Each certificate is identified using either the serving network's Public Land Mobile Network (PLMN) code for the serving network certificate or the home network PLMN code for the root certificate.

[0023] The signed broadcast is transmitted via a new System Information Block (SIB). This SIB contains space for the network's primary PLMN code (primary PLMN identifier), a basic hash providing integrity protection for all basic SIBs (e.g., SIB1, SIB2) periodically broadcast by the network, an optional primary hash for attaching SIBs, optional secondary hashes, and a signature providing integrity protection for the SIB itself. For example, secondary hashes can be added whenever the network needs to temporarily broadcast one or more SIBs (e.g., an emergency alarm transmitted on SIB type 12). Dividing SIBs into basic, primary, and secondary groups allows the UE to attach to the cell faster than if all involved SIBs were packaged into a single hash, because only the basic SIB group must be verified before the attachment process can begin. Furthermore, the sets of SIBs included in the basic, primary, and secondary SIB groups can be mutually exclusive or partially overlapping.

[0024] For each hash, the SIBs included in that hash are concatenated in ascending order of SIB numbers and hashed using a cryptographically secure hash algorithm (e.g., hash = SHA256{SIB1 || SIB2 || … || SIBn}). The SIBs included in each hash are explicitly signaled using the same structure as the list of SIB mapping information in SIB1. The basic hash is required to contain SIB1 and SIB2, and if either is missing, the mobile device should reject the signed SIB. All three hashes are transmitted in plaintext but are protected for integrity through signatures.

[0025] As an example, a network entity (e.g., a base station) uses the private key of the serving network (e.g., signature = Sign{sk, Hash(Time || SignSIB)}, where sk is the private key of the serving network) to sign the entire Signature SIB (excluding the signature) and the current time rounded down to the time interval (e.g., every 10 minutes). In an alternative, the time source used for signature generation can be provided by a Global Navigation Satellite System (GNSS). To provide protection against GNSS time spoofing attacks coupled with replay attacks, the UE can monitor for sudden, unexpected changes in time and refuse to complete the network attachment process, as such a time change might indicate an ongoing attack using GNSS time spoofing.

[0026] The UE can verify the integrity of all SIBs broadcast by the network by first decoding the received signed SIB and recovering the PLMN and the list of SIB mapping information for basic SIB blocks, main SIB blocks, and auxiliary SIB blocks. The UE then obtains the RoT key corresponding to the PLMN (e.g., via SIM, eSIM, or CarrierConfig) and verifies the validity of the serving network public key by checking if the serving network certificate is chained back to the home network root certificate known to the UE. Failure to verify this signature results in the SIB being discarded, and the UE should not continue with further connection to the PLMN. After the signature is verified, the UE then calculates the hash for the corresponding SIB group (basic SIB group, main SIB group, auxiliary SIB group) included in each signature and compares this hash with the signed hash included in the signed SIB. If the signatures match, the UE accepts the signed SIB as valid. If the hash for the SIB group (basic group, main group, or auxiliary group) does not match, or if the SIB is not included in any of the signatures, the SIB is considered invalid and discarded. Optionally or additionally, to account for the possibility of bit errors during wireless transmission, a number of retries for receiving and verifying the signed SIB is envisioned. Optionally or additionally, the UE may refuse to attach to the network and warn the user that a fake base station may be operating in the area. If the UE attempts to attach to a network that does not support the signed SIB, the UE may display a warning indicating that the network cannot be authenticated and ask the user if they still want to connect.

[0027] The techniques used for authenticating System Information Messages (e.g., multiple SIBs) maintain backward compatibility with older UEs that do not support these authentication techniques for SIBs. Existing standards-compliant UEs will not be negatively affected by the techniques described herein. For example, LTE is designed to be upgradable when new features are added to the network and SIBs have already been added in previous LTE versions. Older UEs will simply ignore the signed SIB and connect to networks previously defined by 3GPP standards, while newer UEs will check for the presence of the signed SIB before attempting to attach to the network.

[0028] The technology used to authenticate the System Information Block (SIB) establishes a certificate trust chain that can be used to verify whether the UE is connected to a valid base station. For example, the content of the signed SIB is signed using an Elliptic Curve Digital Signature Algorithm (ECDSA) key pair. Any suitable signature algorithm and key pair can be used to provide the best available cryptographic techniques and can evolve over time (e.g., to incorporate post-quantum cryptography). The network retains the private key, while the public key is distributed to the UE as an X.509 certificate. Using the public key, the UE can simultaneously check the integrity of the signed SIB and verify the identity of the serving network base station.

[0029] For UEs implementing this technology, attackers will no longer be able to use fake base stations, message masking, or man-in-the-middle attacks that alter System Information Blocks (SIBs). UEs inspecting signed broadcast messages will reject altered SIBs and may optionally display warning messages indicating that an attacker may be operating in the local area.

[0030] The technology used for the authentication system information block also supports roaming and can be used to implement operator roaming agreements. Intermediate service network intermediate certificates are installed on the device and signed by the home network's root certificate. These intermediate certificates can be updated over the air via the operator's app on the UE or future 3GPP standard enhancements. The UE can optionally refuse to connect to any network that does not present a valid signed broadcast or does not have the intermediate certificate required for that network.

[0031] Operating environment

[0032] Figure 1 illustrates an example environment 100 including a user equipment 110 (UE 110) that can communicate with a base station 120 (shown as base stations 121 and 122) via one or more wireless communication links 130 (wireless links 130) (shown as wireless links 131 and 132). For simplicity, the UE 110 is implemented as a smartphone, but can be implemented as any suitable computing or electronic device, such as a mobile communication device, modem, cellular phone, gaming device, navigation device, media device, laptop computer, desktop computer, tablet computer, smart appliance, vehicle-based communication system, or Internet of Things (IoT) device (such as a sensor or actuator). The base station 120 (e.g., an evolved universal terrestrial radio access network node B (E-UTRAN node B), evolved node B, eNodeB, eNB, next-generation node B, gNode B, gNB, ng-eNB, etc.) can be implemented in macro cells, micro cells, small cells, pico cells, distributed base stations, etc., or any combination thereof or future evolution thereof. Although the base station icon represents a terrestrial network (TN), base station 120 can be implemented using non-terrestrial network (NTN) components such as satellite gateways, satellites, aircraft, drones, and other high-altitude platforms (HAPS). Nothing in this document should be construed as limiting oneself to current wireless standards and associated network components. The techniques described herein can be used in any wireless environment where strong (encrypted) authentication of the corresponding network component to which a user's device is connecting is required.

[0033] Base station 120 uses radio links 131 and 132 to communicate with user equipment 110, which can be implemented as any suitable type of radio link. Radio links 131 and 132 include control and data communications, such as downlinks transmitting data and control information from base station 120 to user equipment 110, uplinks transmitting other data and control information from user equipment 110 to base station 120, or both. Radio link 130 may include one or more radio links (e.g., radio links) or bearers implemented using any suitable communication protocol or standard or combination of communication protocols or standards (such as 3GPP LTE, 5G NR, etc.). Multiple radio links 130 can be aggregated in carrier aggregation or multi-connectivity to provide higher data rates for UE 110. Multiple radio links 130 from multiple base stations 120 can be configured for Coordinated Multipoint (CoMP) communication with UE 110.

[0034] Base station 120 collectively serves as radio access network 140 (e.g., RAN, Evolved Universal Terrestrial Radio Access Network E-UTRAN, 5G NR RAN, or NR RAN). Base stations 121 and 122 in RAN 140 are connected to core network 150. When connected to a 5G core network, base stations 121 and 122 connect to core network 150 at 102 and 104 respectively via an NG2 interface for control plane signaling and an NG3 interface for user plane data communication; or when connected to an evolved packet core (EPC) network, they connect to the core network using an S1 interface for control plane signaling and user plane data communication. At 106, base stations 121 and 122 can communicate via an Xn interface using the Xn Application Protocol (XnAP) or via an X2 interface using the X2 Application Protocol (X2AP) to exchange user plane and control plane data. User equipment 110 can connect to a public network, such as the Internet 160, via core network 150 to interact with remote services 170. The core network 150 includes a certificate authority 118 (CA 118) for generating network certificates for serving networks and for networks of operators with roaming agreements with the core network 150 and its associated RAN.

[0035] Example device

[0036] Figure 2 illustrates an example arrangement 200 of one of the base stations, UE 110 and base station 120, which can implement various aspects of the authentication system information block in a wireless communication system. UE 110 and / or base station 120 may include additional functions and interfaces omitted from Figure 2 for clarity.

[0037] UE 110 includes an antenna 202, a radio frequency front-end 204 (RF front-end 204), and a radio transceiver (e.g., LTE transceiver 206 and / or 5G NR transceiver 208) for communicating with a base station 120 in RAN 140. The RF front-end 204 of UE 110 can couple or connect the LTE transceiver 206 and the 5G NR transceiver 208 to the antenna 202 to facilitate various types of wireless communication. The antenna 202 of UE 110 may include an array of multiple antennas configured in similar or different ways. The antenna 202 and the RF front-end 204 can be tuned to and / or are capable of being tuned to one or more frequency bands defined by the 3GPP LTE and 5G NR communication standards and implemented by the LTE transceiver 206 and / or the 5G NR transceiver 208. Additionally, antenna 202, RF front-end 204, LTE transceiver 206, and / or 5G NR transceiver 208 can be configured to support beamforming for transmission and reception of communications with UE 120. By way of example, and not limitation, antenna 202 and RF front-end 204 can be implemented for operation in sub-gigahertz (GHz) bands, sub-6 GHz bands, and / or above 6 GHz bands as defined by the 3GPP LTE and 5G NR communication standards.

[0038] UE 110 also includes a processor 210 and a computer-readable storage medium 212 (CRM 212). The processor 210 can be a single-core or multi-core processor composed of various materials such as silicon, polysilicon, high-k dielectrics, copper, etc. The computer-readable storage medium described herein excludes propagating signals. CRM 212 can include any suitable memory or storage device that can be used to store device data 214 of UE 110, such as random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or flash memory. Device data 214 includes user data, multimedia data, beamforming codebooks, applications, and / or the operating system of UE 110, some of which can be executed by the processor 210 to implement user plane data, control plane information, and user interaction with UE 110.

[0039] The CRM 212 of UE 110 includes an authentication manager 216. Alternatively or additionally, the authentication manager 216 may be implemented, in whole or in part, as a hardware logic or circuit system integrated or separate from other components of UE 110. In various aspects, the authentication manager 216 of UE 110 implements authentication of various aspects of system information blocks received from base station 120, as described above and below.

[0040] The device diagram of base station 120 shown in Figure 2 includes a single network node (e.g., gNode B). The functionality of base station 120 can be distributed across multiple network nodes or devices and can be distributed in any manner suitable for performing the functions described herein. This split-type base station functionality uses a different nomenclature and includes terms such as Central Unit (CU), Distributed Unit (DU), Baseband Unit (BBU), Remote Radio Header End (RRH), and / or Remote Radio Unit (RRU). Base station 120 includes antenna 252, radio frequency front-end 254 (RF front-end 254), and one or more radio transceivers (e.g., one or more LTE transceivers 256 and / or one or more 5G NR transceivers 258) for communicating with UE 110. The RF front-end 254 of base station 120 can couple or connect the LTE transceivers 256 and 5G NR transceivers 258 to antenna 252 to facilitate various types of wireless communication. Antenna 252 of base station 120 may include an array of multiple antennas configured in similar or different ways. Antenna 252 and RF front-end 254 can be tuned to and / or are capable of being tuned to one or more frequency bands defined by the 3GPP LTE and 5G NR communication standards and implemented by LTE transceiver 256 and / or 5G NR transceiver 258. Additionally, antenna 252, RF front-end 254, LTE transceiver 256, and / or 5G NR transceiver 258 can be configured to support beamforming, such as massive MIMO, for transmission and reception of communications with UE 110.

[0041] Base station 120 also includes processor 260 and computer-readable storage medium 262 (CRM 262). Processor 260 may be a single-core or multi-core processor composed of various materials such as silicon, polysilicon, high-k dielectric, copper, etc. CRM 262 may include any suitable memory or storage device that can be used to store device data 264 of base station 120, such as random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or flash memory. Device data 264 includes network scheduling data, radio resource management data, beamforming codebooks, applications, and / or the operating system of base station 120, which can be executed by processor 260 to enable communication with UE 110.

[0042] CRM 262 also includes a base station manager 266. Alternatively or additionally, the base station manager 266 may be implemented, wholly or partially, as a hardware logic or circuit system integrated or separate from other components of the base station 120. In at least some aspects, the base station manager 266 configures the LTE transceiver 256 and the 5G NR transceiver 258 for communication with the UE 110, communication with a core network such as the core network 150, and communication with certified SIBs, as described above and below. In various aspects, the base station manager 266 of the base station 120 implements aspects of authenticating system information blocks transmitted by the base station 120, as described above and below.

[0043] Base station 120 also includes an inter-base station interface 268, such as an Xn and / or X2 interface, which base station manager 266 configures to exchange user plane data, control plane information, and / or other data / information with other base stations to manage communication between base station 120 and UE 110. Base station 120 includes a core network interface 270, which base station manager 266 configures to exchange user plane data, control plane information, and / or other data / information with core network functions and / or entities.

[0044] Figure 3 illustrates an example 4G LTE network architecture 300 for a service provider network. Components in the example network architecture communicate with each other via various non-roaming interfaces. The example network includes a user equipment 110 communicating with an eNB 321 (e.g., using a well-known LTE-Uu interface). The eNB communicates with a Mobility Management Entity (MME) 306 in an evolved packet core network 350 (EPC 350) via an interface (e.g., a well-known S1-MME interface). The MME 306 communicates with a Home Subscriber Server (HSS) 308 via an interface (such as a well-known S6a interface). The eNB 321 can also communicate with a Serving Gateway (SGW) 310, such as by using a well-known S1-U interface. The SGW 310 can interface with the MME 306 (e.g., via a well-known S11 interface) and a Packet Gateway (PGW) 312 (e.g., via a well-known S5 interface). PGW 312 is configured to interface with Internet Protocol Multimedia Subsystem (IMS) 314 (e.g., via the well-known SGi interface) and the Internet 360.

[0045] In all aspects, the EPC 350 includes a Certificate Authority 318 (CA 318) for generating network certificates for the serving network and for networks with roaming agreements with operators of the EPC 350 and its associated RAN. In one option, the CA 318 generates certificates based on root certificates from a root CA (such as a root CA operated by a third-party company, government organization, standards body, etc.). In another option, the CA 318 can act as a root CA and generate and self-sign root certificates for RoT. The CA 318 is configured to connect to the MME 306 using interface 322. Optionally, the CA 318 can connect to the MME 306 via firewall 320 to protect the CA 318 from potential core network intrusion. The CA 318 generates certificates for SIB authentication on a RAN-wide, tracking area-wide, or individual base station (eNB) basis.

[0046] Figure 4 illustrates an example architecture 400 of a 5G core network. In the example 400 shown, the control plane and user plane are separate. Here, network functions within the 5G core control plane (5GC-CP) 450 use service-based interfaces to interact with each other. In various aspects, control plane network functions can provide one or more network function services.

[0047] Example network functions within the 5GC-CP 450 include Network Slice Selection Function (NSSF) 404, Access and Mobility Management Function (AMF) 406, Session Management Function (SMF) 408, Authentication Server Function (AUSF) 410, and Policy Control Function (PCF) 412. Additional network functions can be implemented within the 5GC-CP 450 to provide any suitable functionality to the network. UE 110 communicates with AMF 406 via reference point N1. AMF 406 communicates with base stations in RAN 140 via reference point N2. Control plane signaling for session management is communicated between SMF 408 and UPF 424 using reference point N4. Policy control for session management is communicated between SMF 408 and PCF 412 via reference point N7. SMF 408 uses reference point N11 to subscribe to information related to UE 110 from AMF 406. AMF 406 uses the N12 interface for UE 110 authentication by AFS 410. Network slicing assistance information is provided between AMF 406 and NSSF 404 via the N22 reference point.

[0048] The 5GC-CP 450 is configured to communicate with User Data Management (UDM) 414 and Application Function (AF) 416. Additionally, the 5GC-CP 450 communicates with the Radio Access Network (RAN) 140 and User Plane Function (UPF) 424. UPF 424 communicates with the Data Network (DN) 422. User plane data for UE 110 is transmitted to and from RAN 140 via the Uu interface, between RAN 140 and UPF 424 via reference point N3, and to and from DN 422 via reference point N6. SMS subscription data retrieval between AMF 406 and UDM 414 occurs via reference point N8. Application function requests are sent to PCF 412 using reference point N5.

[0049] In various aspects, the 5GC-CP 450 includes a Certificate Authority 418 (CA 418) for generating network certificates for the serving network and for networks with roaming agreements with operators of the 5GC-CP 450 and its associated RAN. In one option, the CA 418 generates certificates based on root certificates from root CAs such as those operated by third-party companies, government organizations, standards bodies, etc. In another option, the CA 418 can act as a root CA and generate and self-sign root certificates for RoT. The CA 418 is configured to connect to the AMF 406 using a reference point 428. Optionally, the CA 418 can connect to the AMF 406 via a firewall 420 to protect the CA 418 from potential core network intrusion. The CA 418 generates certificates for SIB authentication on a RAN-wide, tracking area-wide, or gNB-based basis.

[0050] Figure 5 shows an example device diagram 500 of the core network server 502. The core network server 502 may include additional functions and interfaces omitted from Figure 5 for clarity.

[0051] Core network server 502 can provide all or part of the functions, entities, services, and / or gateways in core network 150. Each function, entity, service, and / or gateway in core network 150 can be provided as a service in core network 150, distributed across multiple servers, or embodied on a dedicated server. For example, core network server 502 can provide all or part of the services or functions of MME 306, HSS 308, SGW 310, PGW 312, CA 118, 318, 418, NSSF 404, AMF 406, SMF 408, AUSF 410, PCF 412, or firewalls 320, 420. Core network server 502 is shown as being embodied in a single server including processor 504 and computer-readable storage medium 506 (CRM 506). Processor 504 can be a single-core processor or a multi-core processor made of various materials such as silicon, polysilicon, high-K dielectric, copper, etc. CRM 506 may include any suitable memory or storage device that is useful for storing the device data 508 of the core network server 502, such as random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), hard disk drive, or flash memory. Device data 508 includes data and / or the operating system for supporting core network functions or entities and the core network server 502, which may be executed by processor 504. For example, root certificates used by CA 318 or CA 418 to generate certificates may be stored in device data 508.

[0052] CRM 506 also includes one or more core network applications 510, which, in one implementation, are embodied in CRM 506 (as shown in the figure). The one or more core network applications 510 may implement the functionality of MME 306, HSS 308, SGW 310, PGW 312, CA 318, firewall 320, NSSF 404, AMF 406, SMF 408, AUSF 410, PCF 412, CA 418, or firewall 420. Alternatively or additionally, the one or more core network applications 510 may be implemented, wholly or partially, as hardware logic or circuitry integrated with or separate from other components of the core network server 502. The core network server 502 also includes a core network interface 512 for communication of user plane data and control plane data with other functions or entities in the core network 150 or base station 120.

[0053] Signature SIB structure

[0054] Figure 6 illustrates an example implementation 600 of the signature SIB 602. The signature SIB 602 includes the primary PLMN identifier (ID) 604 (PLMN code) of the radio network from which the signature SIB 602 was generated, a basic SIB hash 606, a primary SIB hash presence flag 608, (optionally included) a primary SIB hash 610, a secondary SIB hash presence flag 612, (optionally included) a secondary SIB hash 614, and a signature 616. The basic SIB 606 includes the SIBs (e.g., SIB1 and SIB2) required for the UE to connect to the RAN.

[0055] In an embodiment, each SIB hash (e.g., basic SIB hash 606, main SIB hash 610, auxiliary SIB hash 614) includes an SIB list 618 of the SIBs in the hash (where each list item is an SIB type indicator 620) and a hash algorithm indicator 622 indicating the algorithm used to generate hash data 624. The list of SIBs in each hash (e.g., basic SIB hash 606, main SIB hash 610, auxiliary SIB hash 614) is arranged in numerical order by default. Alternatively, the order of the SIBs in each SIB hash can be specified in the SIB list 618. The signature 616 includes a signature algorithm indicator 626 of the algorithm used to generate signature data 630, a hash algorithm indicator 628, and signature data 630. In another embodiment of the invention, the combination of hash algorithm, signature algorithm, and signature scheme can be indicated by a single "signature version" identifier—in order to reduce the size of the signature SIB. Accordingly, newer wireless standards and evolving encryption standards can indicate a higher (or newer) "signature version".

[0056] Certificate Trust Chain

[0057] Figure 7 illustrates an example certificate trust chain 700 including an X.509 certificate and a signing SIB. The certificate trust chain consists of a single root certificate (e.g., a home network root certificate 702) and one or more serving network certificates (serving network intermediate certificates 704, RAN certificate 704). The home network root certificate 702 is used to sign one or more serving network intermediate certificates 704. The home network operator is also considered a serving network operator; therefore, the home network also possesses a short-lived serving network intermediate certificate 704. Serving network intermediate certificates 704 are generated for the home network operator and for each network operator with which the home network operator has established a roaming agreement, thereby allowing roaming only on authorized networks. The same public key pair used in the serving network intermediate certificates 704 is shared among all serving network intermediate certificates 704 used for a specific serving mobile network operator, thereby allowing a single serving network operator to have roaming agreements with multiple home network operators, including itself.

[0058] The Home Network Root Certificate 702 includes a Publisher field, a Subject field, a Subject pubkey (public key) field, and a Signature field. The Publisher field includes a unique Public Land Mobile Network (PLMN) code assigned to the home network. The Subject field identifies the public key used by the home network PLMN in the Home Network Root Certificate 702. The Subject pubkey includes the home network root public key, and the Signature field includes a certificate signature used for the Home Network Root Certificate 702. The certificate signature uses the home network private key. The Home Network Root Certificate 702 may include additional fields omitted in Figure 7 for clarity.

[0059] The service network intermediate certificate 704 includes a publisher field, a subject field, a subject pubkey (public key) field, and a signature field. The service network intermediate certificate is cryptographically signed by the home network root using a trusted private key. The publisher field includes a unique PLMN code assigned to the home network. The subject field identifies the home network root certificate 702 and includes the public key used for the service network PLMN. The subject pubkey includes the service network root public key, and the signature field includes the certificate signature used for the service network intermediate certificate 704. The service network intermediate certificate 704 may include additional fields omitted in Figure 7 for clarity.

[0060] Optionally or additionally, the certificate trust chain may include a tracking area certificate 706 and / or a base station (e.g., eNb or gNb) certificate 708. Including a tracking area certificate 706 and / or a base station certificate 708 in the trust chain increases the geographic granularity used for authenticating system information blocks.

[0061] The most convenient path to installing the root trust public key for verifying signatures is to include it in the UE110's provisioning SIM card or eSIM. Using a single long-term root trust key, the serving network can use short-term signing keys, each of which is countersigned by the root trust key. The UE will only need the RoT public key to verify the signature. Each certificate (704, 702, and / or 708) is identified using the Public Land Mobile Network (PLMN) code of the serving network used for the serving network certificate or the home network PLMN used for the root certificate.

[0062] The final link in the trust certificate chain is the signing SIB 710. Signed broadcasts are transmitted via the signing SIB. This signing SIB includes space for the network's primary PLMN, a basic list and hash of SIBs providing integrity protection for other SIBs periodically broadcast by the RAN, an optional list and hash of primary SIBs, an optional list and hash of secondary SIBs, and a signature providing integrity protection for the signing SIB 710 itself. Whenever the network needs to temporarily broadcast one or more non-critical SIBs or one or more SIBs (e.g., a weather alert transmitted on SIB type 12), an optional list and hash of primary SIBs and an optional list and hash of secondary SIBs can be added.

[0063] For each hash (basic hash, main hash, auxiliary hash) included in the signed SIB 710, the SIBs included in that hash are concatenated in ascending SIB number order and hashed using a cryptographically secure hash algorithm (e.g., hash = SHA256{SIB1 || SIB2 || … || SIBn}). The SIBs included in each hash are explicitly signaled using the same structure as the SIB mapping information list in SIB1. The basic SIB hash includes SIB1 and SIB2, and if either is missing, the UE 110 should reject the signed SIB 710. The basic hash, main hash, and auxiliary hashes are transmitted in plaintext but are protected for integrity by the signature of the signed SIB 710.

[0064] The signature SIB 710 (excluding the signature) and the current time rounded down to the time interval (e.g., every 10 minutes) are then signed using the private key of the serving network (e.g., signature = Sign{sk, Hash(Time || SignSIB)}, where sk is the private key of the serving network). The time source can be provided by a Global Navigation Satellite System (GNSS). Optionally or additionally, the UE 110 can detect sudden, unexpected changes in time and refuse to update the system time or complete the network attachment process, as this type of time change can indicate an ongoing attack in the area using GNSS time spoofing plus replay attacks.

[0065] UE 110 can verify the integrity of all SIBs broadcast by the network by first decoding the new signed SIB 710 and recovering the PLMN and the list of SIB mapping information for basic blocks and optional main and auxiliary blocks. Then, UE 110 calculates the hash for all SIBs included in each signature and compares this hash with the signed hash included in the signed SIB 710. If the signatures match, UE 110 accepts the SIB as valid. If the hash for the SIB group does not match, or if the SIB is not included in any of the signatures, the SIB is considered invalid and discarded by UE 110. Optionally or additionally, to account for the possibility of bit errors in the radio transmission of the signed SIB, a number of retries to receive and verify the signed SIB 710 are envisioned before abandoning (banning) the cell. UE 110 may optionally refuse to attach to the network and warn the user that a fake base station may be operating in the area. If UE 110 attempts to attach to a network that does not support the signature SIB 710, UE 110 can display a warning indicating that the network cannot be authenticated and ask the user if they still want to connect to the network.

[0066] All aspects of the authentication system information block maintain backward compatibility with older UE 110, ensuring that UE 110 conforming to existing standards will not be negatively affected by the use of signature SIB 710. Older UE 110 will simply ignore signature SIB 710.

[0067] Data and control transactions

[0068] Figure 8 illustrates example data and control transactions between base station 120 and user equipment 110 that can implement various aspects of the authentication system information block. At 805, base station 120 generates a signed SIB 710. At 810, base station 120 packages the SIB for transmission, as described in more detail below. In some cases, 810 may occur before or in parallel with 805. At 815, base station 120 transmits SIB1 to UE 110; at 820, base station 120 transmits the signed SIB to UE 110; and at 825, if any other SIBs are scheduled for transmission, those SIBs are transmitted to UE 110.

[0069] At 830, if signing SIB 710 is scheduled in SIB1, then UE 110 verifies signing SIB 710, as discussed in detail below. At 835, UE 110 verifies the SIB (e.g., the basic SIB, the primary optional SIB, and the secondary optional SIB).

[0070] SIB Packing

[0071] Figure 9 illustrates an example process for a base station to package SIBs according to various aspects of the authentication system information block. At 905, base station 120 determines whether signed SIB 710 is scheduled for transmission. If not, at 950, base station 120 packages and schedules the remaining SIBs for transmission. If signed SIB 710 is scheduled, base station 120 begins the packaging process of signed SIB 710 by obtaining the master PLMNID at 910. At 915, base station 120 packages a basic SIB group and generates a hash for the basic SIB group.

[0072] At 920, base station 120 determines whether any SIBs in the primary SIB group have been scheduled. If any primary SIBs have been scheduled, at 925, base station 120 packages the primary SIB group and generates a hash for the primary SIB group. At 930, base station 120 determines whether any SIBs in the secondary SIB group have been scheduled. If any secondary SIBs have been scheduled, at 935, base station 120 packages the secondary SIB group and generates a hash for the secondary SIB group.

[0073] At 940, base station 120 generates a signature to sign SIB 710. At 945, base station 120 packages (serializes) the signed SIB 710 (including the basic hash value, main hash value, and auxiliary hash value) into ASN.1 format for transmission. After signing and packaging the signed SIB 710, at 950, base station 120 packages and schedules the remaining SIBs for transmission. As previously mentioned, in some implementations, 950 may occur before or together with 945.

[0074] SIB unpacking

[0075] Figures 10a and 10b illustrate an example process of UE unpacking and verifying SIBs based on various aspects of the authentication system information block. At 1002, UE 110 unpacks and processes the received SIB1. At 1004, based on the unpacked SIB1, UE 110 determines whether the signed SIB 710 is scheduled. If SIB1 includes scheduling information for the signed SIB 710, then at 1006, UE 110 receives the signed SIB 710. At 1008, UE 110 compares the PLMN code (first PLMN identifier) ​​in the signed SIB 710 with the PLMN code in the CarrierConfig (second PLMN identifier) ​​included in UE 110 to determine if the PLMN codes match. Optionally or additionally, the primary PLMN is also compared with the list of approved PLMNs in the CarrierConfig information in the UE. If the PLMNs do not match, then at 1018, UE 110 abandons the cell and restarts cell search. If the PLMN matches, UE 110 (e.g., from SIM / eSIM or CarrierConfig) obtains the corresponding PLMN RoT public key and verifies the serving network public key by verifying that the serving network certificate is chained back to the home network root certificate known to the UE. The UE then verifies that the signature in the signed SIB at 1010 is valid. If the serving network public key is not chained back to the PLMN's RoT key, or if the signature is not valid, at 1018, UE 110 abandons the cell and restarts the cell search. If the signature is valid, at 1012, UE 110 determines if there are any SIBs (SIB1, SIB2) to acquire in the basic group, and if so, at 1014, the UE receives the remaining basic SIBs. At 1016, after acquiring all SIBs in the basic group, the UE verifies that the basic SIBs are valid by performing a hash function on the linked basic SIB values ​​and then matching them with the basic hash value from the signed SIB 602. If the basic SIB is not valid, at 1018, UE 110 abandons the cell and restarts the cell search. If the basic SIB is valid, UE 110 calculates the hash of the corresponding SIB in the basic group and verifies the hash by comparing it with the signed hash present in the signed SIB. If the two hashes successfully match, the UE processes the SIB in the basic group at 1015 (as described in the 3GPP standard, performing actions upon receiving the SIB#) and performs the unsealing attachment procedure at 1017.

[0076] At 1004, if SIB 710 is not scheduled in SIB1, UE 110 determines whether SIB 710 needs to be signed at 1020 based on its CarrierConfig. If SIB 710 needs to be signed, then at 1018, UE 110 abandons the cell and restarts cell search. If SIB 710 does not need to be signed, then at 1022, UE 110 unblocks the attachment procedure, and at 1024 receives and processes (acquires) any remaining SIBs.

[0077] The example continues at 1052 in Figure 10b, where UE 110 determines, for example, whether any SIBs have been scheduled in the primary SIB group by checking if the primary SIB group has an presence flag. If SIBs have been scheduled in the primary group, then at 1054, UE 110 determines whether the SIBs in the primary group have been acquired. If the SIBs in the primary group have not yet been acquired, then at 1056, UE 110 receives the remaining SIBs. If the SIBs in the primary group have been received, then at 1058, UE 110 verifies that the primary SIB group is valid. If the primary SIB group is valid, then at 1060, UE 110 processes the SIBs in the primary group. If the primary SIB group is not valid, then at 1062, UE 110 rejects the SIBs in the primary group.

[0078] If no SIB is scheduled in the primary group at 1052, the SIB in the primary group is verified at 1060, or the SIB in the primary group is rejected at 1062, then SIB unpacking continues, where at 1064, UE 110 determines whether any SIBs have been scheduled in the secondary SIB group. If no SIB is scheduled in the secondary SIB group at 1064, the SIB unpacking and verification process ends. If an SIB has been scheduled in the secondary group, then at 1066, UE 110 determines whether an SIB in the primary group has been acquired. If no SIB in the secondary group has been acquired, then at 1068, UE 110 receives the remaining SIBs. If an SIB in the secondary group has been received, then at 1070, UE 110 verifies the validity of the primary SIB group. If the primary SIB group is valid, then at 1072, UE 110 processes the SIBs in the primary group. If the auxiliary SIB group is not valid, then at 1074, UE 110 rejects the SIB in the auxiliary group.

[0079] Example Method

[0080] Example methods 1100, 1200, and 1300 are described with reference to Figures 11 through 13, respectively, based on one or more aspects of the authentication system information block. Generally, any of the components, modules, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., a fixed logic circuit system), manual processing, or any combination thereof. Some operations of the example methods can be described in a general context of executable instructions stored on computer-readable storage located locally and / or remotely on a computer processing system, and implementations can include software applications, programs, functions, etc. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), etc.

[0081] Figure 11 illustrates an example method 1100 of a base station-supported authenticated system information block according to various aspects of the techniques described herein. The order in which the method blocks are described is not intended to be limiting, and any number of the described method blocks can be skipped or combined in any order to implement one method or an alternative method.

[0082] At box 1102, the base station schedules the signed SIB for transmission. For example, the base station (e.g., base station 120) schedules the signed SIB (e.g., signed SIB 710) for transmission by including the scheduling of the signed SIB in the scheduling information element of SIB1.

[0083] At box 1104, the base station generates a signing SIB. For example, and as described with respect to Figure 9, the base station generates the signing SIB by inserting the master PLMN code into the signing SIB. The base station packages and hashes the basic SIB group, and optionally the master SIB group and auxiliary SIB groups. The base station then signs the signing SIB using the serving network private key.

[0084] At box 1106, the base station packages the signed SIB for transmission. For example, and as described with respect to Figure 9, the base station packages (serializes) the signed SIB into a byte stream in ASN.1 format for transmission.

[0085] At box 1108, the base station transmits SIB1, which includes an indication of a signed SIB in the scheduling information. For example, and at 815 in Figure 8, the base station transmits SIB1 on the broadcast channel, SIB1 including scheduling information for a signed SIB.

[0086] At box 1110, the base station transmits the signed SIB according to the SIB1 scheduling information. For example, as described in Figures 8, 10a, and 10b, the base station transmits the signed SIB scheduled in SIB1, effectively instructing the UE (e.g., UE 110) to authenticate the SIB message and attach to the cell provided by the base station using the authenticated SIB.

[0087] Figure 12 illustrates an example method 1200 of user equipment authentication system information blocks according to various aspects of the techniques described herein. The order in which the method blocks are described is not intended to be construed as a limitation, and any number of the described method blocks can be skipped or combined in any order to implement one method or an alternative method.

[0088] At 1202, the UE receives SIB1, which includes scheduling information, from the base station. For example, the UE (e.g., UE 110) receives SIB1 from the base station (e.g., base station 120).

[0089] At 1204, the UE evaluates SIB1 to determine whether the signature SIB is scheduled in SIB1. For example, and as described with respect to Figures 10a and 10b, the UE evaluates the scheduling information element of SIB1 to determine whether the signature SIB is scheduled by the base station.

[0090] At 1206, the UE uses scheduling information to obtain the signature SIB from the base station. For example, and as described with respect to Figures 10a and 10b, the UE receives the signature SIB from the base station by evaluating the scheduling information elements in SIB1.

[0091] At 1208, the UE determines whether the primary PLMN code (first PLMN identifier) ​​in the signature SIB matches the primary PLMN code (second PLMN identifier) ​​in the UE's CarrierConfig information. For example, and as described with respect to Figures 10a and 10b, the UE determines whether the primary PLMN code in the signature SIB matches the primary PLMN code in the CarrierConfig information of the SIM or eSIM included in the UE. If the primary PLMN codes match, the method continues at 1210; otherwise, at 1218, the UE abandons the cell and restarts the cell search.

[0092] At 1210, the UE verifies the signature of the signing SIB to verify its contents. For example, and as described with respect to Figures 10a and 10b, the UE uses the home network public key to verify the signature of the signing SIB to verify its contents. If the signature is verified, the method continues at 1212; otherwise, at 1218, the UE abandons the cell and restarts the cell search.

[0093] At 1212, the UE verifies the basic SIB group from the signature SIB. For example, and as described with respect to Figures 6, 10a, and 10b, the UE verifies the basic SIB group by generating a hash value and comparing that value with the hash data included in the signature SIB (e.g., hash data 624). If the signature is verified, the method continues at 1214; otherwise, at 1218, the UE abandons the cell and restarts the cell search.

[0094] At 1214, the UE performs an action after verifying the SIBs in the basic SIB group. For example, and as described with respect to Figures 10a and 10b, the UE performs an action after verifying SIB1 in the basic SIB group to determine the parameters required to attach to the cell provided by the base station.

[0095] At 1216, the UE unsealing and reattaching process is performed to reattach to the cell provided by the base station using SIB1. For example, and as described with respect to Figures 10a and 10b, the UE unsealing and reattaching process is performed to reattach to the cell provided by the base station using SIB1.

[0096] Figure 13 illustrates an example method 1300 for authenticating system information blocks by a certification authority server according to various aspects of the techniques described herein. The order in which the method boxes are described is not intended to be construed as a limitation, and any number of the described method boxes can be skipped or combined in any order to implement one method or an alternative method.

[0097] At 1302, the Certification Authority (CA) server generates the home network root certificate. For example, and as described with respect to Figure 7, the CA server (e.g., Certification Authority 118, Certification Authority 318, Certification Authority 418) generates the home network root certificate (e.g., Home Network Root Certificate 702). The CA server also distributes the home network public key corresponding to the home network private key to the UE.

[0098] At 1304, the CA server signs the home network root certificate using the home network private key. For example, and as described with respect to Figure 7, the CA server uses the home network private key to sign the home network root certificate 702.

[0099] At 1306, the CA server generates one or more service network certificates. For example, and as described with respect to Figure 7, the CA server generates one or more service network certificates (e.g., service network intermediate certificate 704). The CA uses the HPLMN private key to sign the intermediate service network certificate. Optionally or additionally, the CA server may also generate tracking area (e.g., tracking area certificate 706) and / or base station certificates (e.g., base station certificate 708).

[0100] At 1308, the CA server signs one or more serving network certificates using the home network private key. The RAN uses one or more serving network certificates to authenticate the SIB for the cell. For example, and as described with respect to Figure 7, the CA server signs one or more serving network certificates using the home network private key, and these one or more serving network certificates can be used by a base station (e.g., base station 120) to authenticate the SIB for the cell in the radio access network (e.g., RAN 130).

[0101] Some examples are described below: Example 1: A method for a base station to support authenticated System Information Blocks (SIBs) such as basic SIBs (SIB1, SIB2, etc.), the method comprising: scheduling a signature SIB for transmission; generating the signature SIB, the generation of the signature SIB comprising: inserting a list of basic SIBs into the signature SIB; generating a hash of the value of the basic SIB; and inserting the hash of the value of the basic SIB into the signature SIB; packaging the signature SIB for transmission; transmitting the basic SIB (SIB1) wherein the signature SIB is indicated in scheduling information; and transmitting the signature SIB according to the scheduling information of the basic SIB (SIB1).

[0102] Example 2: The method as described in Example 1, wherein the generation of the signature SIB further comprises: inserting a primary public land mobile network (PLMN) identifier into the signature SIB; generating a signature for the signature SIB; and inserting the signature into the signature SIB.

[0103] Example 3: The method as described in Example 1, wherein the generation of the hash of the value of the basic SIB includes: concatenating the basic SIB in numerical order; and hashing the concatenated basic SIB using a cryptographically secure hash algorithm.

[0104] Example 4: The method described in Example 3, wherein the cryptographically secure hash algorithm is 256-bit secure hash algorithm 2 (SHA-256 algorithm) or any currently acceptable cryptographically secure hash algorithm.

[0105] Example 5: The method as described in Example 2, wherein generating the signature for the signature SIB includes: using a service network private key to generate the signature for the signature SIB.

[0106] Example 6: The method of any one of Examples 1 to 5 further includes: inserting a list of master SIBs into the signature SIB; generating a hash of the value of the master SIB; and inserting the hash of the value of the master SIB into the signature SIB.

[0107] Example 7: The method as described in Example 6 further includes: inserting a list of auxiliary SIBs into the signature SIB; generating a hash of the value of the auxiliary SIBs; and inserting the hash of the value of the auxiliary SIBs into the signature SIB.

[0108] Example 8: The method as described in any one of Examples 1 to 7, wherein the packing comprises: serializing the signature SIB into a byte stream in Abstract Syntax Symbol 1 (ASN.1) format.

[0109] Example 9: The method as described in any one of Examples 1 to 9 further includes: transmitting other SIBs that are not authenticated by the signed SIB.

[0110] Example 10: A method for authenticating an SIB such as a Basic System Information Block (SIB) (SIB1, SIB2, etc.), the method comprising: receiving a basic SIB (SIB1) including scheduling information from a base station; using the scheduling information to obtain a signature SIB; comparing a first primary Public Land Mobile Network (PLMN) identifier in the signature SIB with a second primary PLMN identifier; when the compared PLMN identifiers match: verifying whether the signing public key is chained back to a root of trust (RoT) public key; verifying the signature of the signature SIB; when the signature of the signature SIB is valid: verifying a basic SIB group, such as including basic SIBs (SIB1, SIB2, etc.); when the basic SIB group is valid: performing an action on the SIBs in the basic SIB group; and an unsealing attachment process to attach to a cell provided by the base station using the basic SIB (SIB1).

[0111] Example 11: The method as described in Example 10, wherein: when the compared PLMN identifiers do not match, or when the signature of the signed SIB is not valid, or when the basic SIB group is not valid: the cell provided by the base station is disabled; and cell search is restarted.

[0112] Example 12: The method as described in Example 10 or Example 11, wherein: when the serving network public key does not have a chain back to the PLMN RoT key: the cell provided by the base station is disabled; and cell search is restarted.

[0113] Example 13: The method as described in Example 10, wherein the signing SIB is not scheduled in SIB1: when the CarrierConfig requires a signing SIB: the cell provided by the base station is disabled; and cell search is restarted; or when the CarrierConfig does not require a signing SIB: the attachment process is unblocked; and an additional SIB is obtained.

[0114] Example 14: The method of Example 10 further includes: checking a primary SIB hash presence flag for an indication that the signature SIB includes a primary SIB group; obtaining SIBs listed in the primary SIB group; verifying the primary SIB group value; and when the primary SIB group value is valid: processing the SIB in the primary SIB group; and when the primary SIB group value is not valid: rejecting the SIB in the primary SIB group.

[0115] Example 15: The method as described in Example 14, wherein the verification of the main SIB group includes: verifying the cryptographic hash in the signed SIB by locally calculating the corresponding hash of the received SIB message.

[0116] Example 16: The method as described in Example 14 further includes: checking an auxiliary SIB hash presence flag for an indication that the signature SIB includes an auxiliary SIB group; obtaining SIBs listed in the auxiliary SIB group; verifying an auxiliary SIB group value; and when the auxiliary SIB group value is valid: processing the SIB in the auxiliary SIB group; and when the auxiliary SIB group value is not valid: rejecting the SIB in the auxiliary SIB group.

[0117] Example 17: The method as described in any one of Examples 10 to 16, wherein the verification of the signature of the signing SIB comprises: verifying the signature of the signing SIB using a public key.

[0118] Example 18: The method as described in any one of Examples 10 to 17, wherein the verification of the basic SIB group comprises: verifying the cryptographic hash in the signed SIB by locally calculating the corresponding hash of the received SIB message.

[0119] Example 19: The method of any one of Examples 10 to 18, wherein comparing the first primary public land mobile network (PLMN) identifier in the signature SIB with the second primary PLMN identifier further comprises: comparing the first primary public land mobile network (PLMN) identifier in the signature SIB with an approved list of PLMN identifiers stored in the CarrierConfig information in the UE.

[0120] Example 20: The method as described in any one of Examples 10 to 19, wherein verifying the signature of the signature SIB includes: verifying whether the signature public key is chained back to the RoT public key.

[0121] Example 21: A method for supporting an authenticated System Information Block (SIB) by a certification authority server, the method comprising: generating a home network root certificate; signing the home network root certificate using a home network private key; generating one or more serving network certificates; and signing the one or more serving network certificates using the home network private key, the one or more serving network certificates being capable of authenticating an SIB for a cell in a radio access network (RAN).

[0122] Example 22: The method as described in Example 21, the method further comprising: generating one or more tracking area certificates to authenticate the SIB of a cell in a tracking area for use in the RAN.

[0123] Example 23: The method as described in Example 21, the method further comprising: generating one or more base station certificates to authenticate the SIB of a cell in a tracking area for the RAN.

[0124] Example 24: The method described in Example 21 further includes: distributing a home network public key corresponding to the home network private key to the user equipment.

[0125] Example 25: The method as described in Example 24, wherein the home network public key is stored in the subscriber identity module of the user equipment.

[0126] Example 26: The method of any one of Examples 21 to 25, wherein at least one or more service network certificates are used by the base station to authenticate the SIB in the method according to any one of Examples 1 to 9.

[0127] Example 27: A device includes: a processor; and a memory including instructions executable by the device to perform the method as described in any of the preceding examples.

[0128] Although aspects of the authentication system information block have been described in feature- and / or method-specific language, the subject matter of the appended claims is not necessarily limited to the specific features or methods described. Rather, these specific features and methods are disclosed as exemplary implementations of the authentication system information block, and other equivalent features and methods are intended to fall within the scope of the appended claims. Furthermore, various different aspects have been described, and it should be understood that each described aspect can be implemented independently or in combination with one or more other described aspects.

Claims

1. A method for a base station (120) to support an authenticated SIB including basic system information blocks (SIB1, SIB2), the method comprising: Schedule (1102) the signed SIB (602, 710) for transmission; generate (805, 1104) the signed SIB (602, 710), the generation (805, 1104) of the signed SIB (602, 710) comprising: inserting a list (618) of base SIBs (SIB1, SIB2) into the signed SIB (602, 710); generating a hash (606) of the value of the base SIB; and inserting the hash (606) of the value of the base SIB into the signed SIB (602, 710); pack (810) the signed SIB (602, 710) for transmission; transmit (815) the base SIB (SIB1), wherein the scheduling information contains an indication of the signed SIB (602, 710); and according to the base SIB (SIB1) scheduling information to transmit (820) the signature SIB (602, 710).

2. The method as described in claim 1, wherein, The generation (805, 1104) of the signature SIB (602, 710) further includes: inserting (910, 915) the primary public land mobile network (PLMN) identifier (604) into the signature SIB (602, 710); generating (940) a signature for the signature SIB (602, 710); and inserting the signature into the signature SIB (602, 710).

3. The method as described in claim 2, wherein, The generation (940) of the signature for the signature SIB (602, 710) includes: using the service network private key to generate the signature for the signature SIB (602, 710).

4. The method of claim 1, wherein, The generation of the hash (606) of the value of the basic SIB (606) includes: concatenating the basic SIBs (SIB1, SIB2) in numerical order; and hashing (915) the concatenated basic SIBs using a cryptographically secure hash algorithm.

5. The method according to any one of claims 1 to 4, further comprising: Insert the list of main SIBs (920) into the signature SIBs (602, 710); Generate (925) a hash of the value of the main SIB; and insert the hash of the value of the main SIB into the signature SIB (602, 710).

6. A method (1200) for a user equipment (UE) (110) to authenticate an SIB including basic system information blocks (SIB1, SIB2), the method comprising: Receive (1002, 1202) a basic SIB (SIB1) including scheduling information from base station (120); use the scheduling information to obtain (1006, 1206) a signing SIB (710); compare the first primary public land mobile network (PLMN) identifier in the signing SIB (710) with the second primary PLMN identifier (1008, 1208); when the compared PLMN identifiers match: verify whether the signing public key is chained back to the root of trust (RoT) public key; verify (1010, 1210) the signature of the signing SIB; when the signature of the signing SIB is valid: verify (1016, 1212) a basic SIB group; when the basic SIB group is valid: perform actions (1015, 1214) on the SIBs in the basic SIB group; and perform an unsealing attachment process (1017, 1216) to attach to the cell provided by the base station (120) using the basic SIB (SIB1).

7. The method of claim 6, wherein: When the compared PLMN identifiers do not match (1008, 1208), or when the signature of the signed SIB is not valid (1010, 1210), or when the basic SIB group is not valid (1016, 1212): the cell provided by the base station (120) is disabled; and cell search is restarted (1018, 1218).

8. The method of claim 6 or claim 7, wherein: When the service network public key does not have a chain back to the PLMN RoT key: the cell provided by the base station (120) is disabled; and cell search (1018, 1218) is restarted.

9. The method of claim 6, wherein, If the signing SIB is not scheduled in the basic SIB (SIB1) (1004): when the CarrierConfig requires a signing SIB (1020): the cell provided by the base station (120) is blocked; and the cell search is restarted (1018); or when the CarrierConfig does not require a signing SIB (1020): the attachment process is unblocked (1022); and the additional SIB is obtained (1024).

10. The method of claim 6, further comprising: For the signature SIB (602), the following steps are included: a primary SIB group indication check (1052) and a primary SIB hash presence flag (608): obtaining (1054, 1056) the SIBs listed in the primary SIB group; verifying the primary SIB group value (1058); and when the primary SIB group value is valid: processing the SIB in the primary SIB group (1060); and when the primary SIB group value is not valid: rejecting the SIB in the primary SIB group (1062).

11. The method of claim 10, further comprising: The signature SIB (602) includes an indication check (1064) for the auxiliary SIB group and an auxiliary SIB hash presence flag (612): obtaining (1066, 1068) the SIBs listed in the auxiliary SIB group; verifying the auxiliary SIB group value (1070); and when the auxiliary SIB group value is valid: processing the SIB in the auxiliary SIB group (1072); and when the auxiliary SIB group value is not valid: rejecting the SIB in the auxiliary SIB group (1074).

12. The method according to any one of claims 6 to 11, wherein, Comparing the first primary public land mobile network (PLMN) identifier in the signature SIB with the second primary PLMN identifier (1008, 1208) further includes: comparing the first primary public land mobile network (PLMN) identifier in the signature SIB (602, 710) with an approved list of PLMN identifiers stored in the CarrierConfig information of the UE (110).

13. The method according to any one of claims 6 to 12, wherein, The verification of the signature (1010, 1210) of the signature SIB includes: verifying whether the signature public key is chained back to the RoT public key.

14. A method for supporting certified System Information Blocks (SIBs) by a certification authority server (118, 318, 418), the method comprising: Generate (1302) home network root certificate (702); The home network root certificate is signed using the home network private key (1304); one or more service network certificates are generated (1306) (704); and the one or more service network certificates (704) are signed using the home network private key (1308), the one or more service network certificates being used to authenticate the SIB of a cell in the radio access network RAN ​​(130).

15. The method of claim 14, further comprising: Generate one or more tracking area certificates (706) to authenticate the SIB of the cell in the tracking area used for the RAN (130); Generate one or more base station certificates (708) to authenticate the SIB of the cell in the tracking area of ​​the RAN (130); or distribute the home network public key corresponding to the home network private key to the user equipment (110).

16. The method of claim 14 or 15, wherein, At least one or more Service Network Certificates (704) are used by the base station (120) to authenticate the SIB in the method according to any one of claims 1 to 5.

17. An apparatus (110, 120, 502), comprising: Processors (210, 260, 504); And a memory (212, 262, 506) comprising instructions executable by the device (110, 120, 502) to cause the device (110, 120, 502) to perform the method as described in any of the preceding claims.

Images