Authenticating system information blocks

Abstract

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

Description

AUTHENTICATING SYSTEM INFORMATION BLOCKSBACKGROUND

[0001] A user equipment (UE) that connects to a cellular network is vulnerable to false base station (FBS) attacks. This vulnerability applies to multiple generations of wireless mobility technologies and is a systemic security threat, not specific to a particular device manufacturer or wireless carrier. As a result, UEs are vulnerable to protocol exploits, such as international mobile subscriber identity' (IMSI) catcher devices, surveillance and tracking, spoofing wireless 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] A root exploit of all these attacks is the fact that UEs cannot verify the legitimacy of cellular networks prior to executing security and privacy sensitive operations. Specifically, UEs cannot verify the integrity of system information blocks (SIBs) broadcast by base stations. SIBs contain critical connection setup information and are broadcast without integrity protection in order to be decodable by UEs that have not established integrity protection keys with the network. There are opportunities to improve the security of wireless networks and UEs using authentication techniques without hampering existing UEs that do not implement authentication techniques.SUMMARY

[0003] This summary is provided to introduce simplified concepts of coordinating user equipment selection. The simplified concepts are further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining the scope of the claimed subj ect matter.

[0004] In aspects, methods, devices, systems, and means for authenticating System Information Blocks (SIBs) by a base station are described in which the base station schedules a signing SIB for transmission and generates the signing SIB. The base station packs the signing SIB for transmission, transmits a SIB1 and SIB2, and transmits the signing SIB with an indication of the signing SIB in scheduling information.

[0005] In other aspects, methods, devices, systems, and means for authenticating System Information Blocks (SIBs) by a user equipment are described in which the user equipment receives a SIB 1 from a base station that includes scheduling information. If the signing SIB is scheduled, the UE acquires the signing SIB, compares the public land mobile network (PLMN) identifier in the signing SIB to the primary' PLMN identifier in the SIB 1. If the compared PLMN identifiers match, the UE validates a signature of the signing SIB to verify the contents of the signing SIB.If the signature of the signing SIB is valid, the UE validates an essential SIB group. If the essential SIB group is valid, the UE performs actions using the SIBs in the essential SIB group and proceeds with the attach process to attach to the cell provided by the base station transmitting the SIB1.

[0006] In further aspects, methods, devices, systems, and means for authenticating System Information Blocks (SIBs) by a certificate authority (CA) server are described in which the CA server generates a home network root certificate and signs the home network root certificate with a home network private key. The CA server generates one or more serving network certificates and signs the one or more serving network certificates with the home network private key, the one or more serving network certificates to authenticate SIBs for cells in a radio access network (RAN).BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The details of one or more aspects of authenticating system information blocks are described below. The use of the same reference numbers in different instances in the description and the figures indicate similar elements:FIG. 1 illustrates an example wireless network system in which various aspects of authenticating system information blocks can be implemented.FIG. 2 illustrates an example device diagram that can implement various aspects of authenticating system information blocks.FIG. 3 illustrates an example diagram of a 4G LTE core network architecture.FIG. 4 illustrates an example diagram of a 5G core network architecture.FIG. 5 illustrates an example device diagram that can implement various aspects of authenticating system information blocks.FIG. 6 illustrates an example implementation of a signing SIB for authenticating system information blocks.FIG. 7 illustrates another example certificate chain of trust for authenticating system information blocks.FIG. 8 illustrates example data and control transactions between a base station and a user equipment for implementation of authenticating system information blocks.FIG. 9 illustrates an example process for SIB packing by a base station in accordance with aspects of the techniques described herein.FIGs. 10a and 10b illustrate an example process for SIB unpacking and verification by a UE in accordance with aspects of the techniques described herein.FIG. 11 depicts an example method of authenticating system information blocks in a user device in accordance with aspects of the techniques described herein.FIG. 12 depicts an example method of authenticating system information blocks in a network in accordance with aspects of the techniques described herein.FIG. 13 depicts an example method of authenticating system information blocks in a network in accordance with aspects of the techniques described herein.DETAILED DESCRIPTION

[0008] This document describes techniques and systems for authenticating system information blocks. Currently, adversaries can broadcast malicious SIBs to force UEs to display fake warning messages, encourage UEs to connect to rogue base stations to perform surveillance of UEs in a local area, or carry out other cellular network attacks. The techniques described herein introduce a new signature broadcast and a certificate chain of trust to cellular standards that, in combination, permit a UE to verify the integrity' and authenticity of one or more system information blocks (SIBs) broadcast by a Radio Access Network (RAN). By adding a new SIB that contains the signatures for other SIBs, the described techniques maintain backwards compatibility with older UEs while providing SIB authentication to UEs that support the authentication techniques described herein. Further, these techniques have a smaller overhead as the signatures for multiple SIBs are contained in a single signature, rather than having a signature on a per-SIB basis.

[0009] The certificate chain of trust has a single root certificate along with one or more serving network certificates. Each home netyvork operator yvill serve as its oyvn certificate authority, with a long term root certificate serving as the Root-of-Trust (RoT) within the operator’s network. The network operator is expected to secure this long-tenn RoT key via contemporary’ mechanisms that include but not limited to Hardware Security Modules (HSMs). This home network root certificate is used to sign one or more serving netyvork certificates (other network operators providing wireless service, for example roaming partners). The home netyvork operator is also considered a serving netyvork operator; thus, the home netyvork also possesses a serving network certificate. A serving network certificate is generated for the home network operator and for every network operator with which the home network operator has an established roaming agreement, thereby permitting roaming on authorized netyvorks. A netyvork operator may choose to generate short-lived, serving netyvork certificates - counter-signed by the long-tenn RoT certificate - thus reducing the operational burden of potentially revoking serving netyvork certificates. One or multiple home network root certificates may be preloaded on a UE by the carrier or the OEM. Alternatively, carriers may choose to have their home network root certificates signed by a 3rd party' Internet CA. In that case, one or multiple Internet root CAs may be preloaded on a UE or a Subscriber Identity Module (SIM) by the carrier or OEM. The SIMmay be a SIM card or an eSIM. The same public key used in a serving network certificate will be shared across all serving network certificates for a particular serving mobile network operator, thereby permitting a single serving network operator to have roaming agreements with multiple home network operators, including itself. The home network operator may also generate certificates for other networks that lack the resources to do so, such as a Mobile Virtual Network Operator (MVNO) that uses the RAN of the home network operator.

[0010] In aspects, a Root-of-Trust (RoT) public key that is used for verifying the signatures is included in the provisioning Subscriber Identify Module (SIM) card or embedded SIM (eSIM) for a UE. By using a single long-lived Root-of-Trust key, the serving network can use short-lived 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 signatures generated by the network. Each certificate is identified using the serving network’s Public Land Mobile Network (PLMN) code for serving network certificates or the home network PLMN code for the root certificate.

[0011] A signature broadcast is transmitted via a new system information block, a signing SIB. This signing SIB contains space for the primary PLMN code (primary PLMN identifier) of the network, an essential hash that provides integrity protection for all essential SIBs (e.g., SIB1, SIB2) broadcast regularly by the network, an optional primary' hash for additional SIBs, an optional secondary hash, and a signature that provides integrity protection for the signing SIB itself. For example, the secondary' hash can be added whenever the network needs to broadcast one or more SIBs temporarily (e.g., an emergency alert conveyed on a SIB type 12). Segmenting the SIBs into the essential, primary', and secondary' groups allows a UE to more quickly attach to a cell than if all the involved SIBs were packed into a single hash because only the essential SIB group must be verified before the attach process can start. Additionally, the set of SIBs included in the essential SIB group, primary SIB group, and secondary' SIB group can be mutually exclusive or partially overlapping.

[0012] For each hash, the SIBs included in that hash are concatenated in ascending SIB number and hashed using a cryptographically secure hashing algorithm (e.g., hash = SHA256{SIB1 || SIB2 || ... || SIBn}). The SIBs included in each of the hashes are explicitly signaled using the same structure as the SIB Mapping Info list in SIB1. The essential hash is required to contain SIBs 1 and 2 and the signing SIB should be rejected by the mobile device if either are missing. All three hashes are transmitted in plain text but are integrity-protected by the signature.

[0013] As an example, a network entity (e.g., a base station) signs the entire signing SIB (excluding the signature) along with the current time rounded down to a time interval (e.g., every' 10 minutes) using the serving network’s private key (e.g., signature = Sign{sk, Hash(Time ||SignS IB)}, where sk is the serving network’s private key). In one alternative, the time source for the signature generation can be provided by a Global Navigation Satellite System (GNSS). To provide protection against GNSS time-spoofing attacks coupled with a replay attack, the UE may monitor for sudden, unexpected changes in time and refuse to complete the network attach process because that change in time could indicate an ongoing attack using GNSS time-spoofing.

[0014] The UE can verify the integrity of all SIBs broadcast by the network by first decoding a received signing SIB and recovering the PLMN and the SIB mapping info list for the essential, primary, and secondary SIB blocks. The UE will then obtain the RoT key corresponding to the PLMN (e.g., via the SIM. eSIM, or CarrierConfig), and verify the validity of the serving network Public Key by checking if the serving network certificate chains back to the home network root certificate known by the UE. A failure in validating this signature is cause for dropping the SIB and the UE should not proceed with further connection with the PLMN. After the signature is validated, the UE then computes the hash across the corresponding SIB groups (essential, primary, secondary) included for each signature and then compares that hash against the signed hash included in the signing SIB. If the signatures match, the UE will accept the signing SIB as valid. If the hash for a group of SIBs (essential, primary', or secondary') does not match or the SIB w as not included in any of the signatures, the SIB is assumed to be invalid and is dropped. Optionally or additionally, to account for the possibility of bit errors during wireless transmission, a number of retries of receiving and verifying the signing SIB are contemplated. Optionally or additionally, the UE can refuse to attach to the network and warn the user that a fake base station may be operating in the area. If the UE tries to attach to a network that does not support the signing SIB, then the UE can show a warning indicating that the network cannot be authenticated and ask the user if they still want to connect.

[0015] The techniques for authenticating system information messages (e.g., multiple SIBs) maintain backwards compatibility' with older UEs that do not support these authentication techniques for SIBs. An existing standards-compliant UE will not be negatively impacted by the techniques described herein. For example, LTE was designed to be upgradeable as new features are added to the netw ork and SIBs have been added in LTE releases in the past. An older UE will simply ignore the signing SIB and connect to the network as previously defined by the 3GPP standards, whereas new er UEs would check for the presence of the signing SIB before attempting to attach to the network.

[0016] The techniques for authenticating system information blocks establishes a certificate chain of trust that can be used to verify' if the UE is connecting to a valid base station. For example, the contents of the signing SIB are signed using an Elliptic Curve Digital Signature Algorithm (ECDSA) key pair. Any suitable signing algorithm and keypair can be used to providethe best available cryptographic techniques and can evolve over time (e.g., to incorporate postquantum cryptography techniques). The network retains the private key while the public key is distributed to UEs as X.509 certificates. Using the public key, a UE can simultaneously check the integrity of the signing SIB and verify the identity of the serving network base station.

[0017] Attackers will no longer be able to use false base stations, message overshadowing, or man-in-the-middle attacks that alter system information blocks for UEs that implement this technique. UEs that check the signing broadcast message wi 11 reject the altered SIBs and can optionally display a warning message indicating that an attacker may be operating in the local area.

[0018] The techniques for authenticating system information blocks also support roaming and can be used to enforce carrier roaming agreements. An intermediate serving network intermediate certificate is installed on the device which is signed by the home network's root certificate. These intermediate certificates can be updated by over-the-air means via the carrier 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 signing broadcast or does not have an intermediate certificate for that network.Operating Environment

[0019] FIG. 1 illustrates an example environment 100 which includes a user equipment 110 (UE 110) that can communicate with base stations 120 (illustrated as base stations 121 and 122) through one or more wireless communication links 130 (wireless link 130), illustrated as wireless links 131 and 132. For simplicity, the UE 110 is implemented as a smartphone but may 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 an Intemet-of-Things (loT) device such as a sensor or an actuator. The base stations 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, or the like) may be implemented in a macrocell, microcell, small cell, picocell, distributed base station, and the like, or any combination or future evolution thereof. Although the base station icons represent terrestrial networks (TNs), the base stations 120 may be implemented using non-terrestrial network (NTN) elements such as satellite gateways, satellites, planes, drones, and other high altitude platforms (HAPS). Nothing herein should be construed to be limited to current wireless standards and associated network elements. The techniques described herein could be used in anywireless environment where there is need for strong (cryptographic) verification of the corresponding network element being connected to by a user’s device.

[0020] The base stations 120 communicate with the user equipment 110 using the wireless links 131 and 132, which may be implemented as any suitable type of wireless link. The wireless links 131 and 132 include control and data communication, such as downlink of data and control information communicated from the base stations 120 to the user equipment 110, uplink of other data and control information communicated from the user equipment 110 to the base stations 120, or both. The wireless links 130 may include one or more wireless links (e.g., radio links) or bearers implemented using any suitable communication protocol or standard, or combination of communication protocols or standards, such as 3rd Generation Partnership Project Long-Term Evolution (3GPP LTE), Fifth Generation New Radio (5GNR), and so forth. Multiple wireless links 130 may be aggregated in a carrier aggregation or multi-connectivity to provide a higher data rate for the UE 110. Multiple wireless links 130 from multiple base stations 120 may be configured for Coordinated Multipoint (CoMP) communication with the UE 110.

[0021] The base stations 120 are collectively a Radio Access Network 140 (e.g., RAN, Evolved Universal Terrestrial Radio Access Network, E-UTRAN, 5G NR RAN or NR RAN). The base stations 121 and 122 in the RAN 140 are connected to a core network 150. The base stations 121 and 122 connect, at 102 and 104 respectively, to the core network 150 through an NG2 interface for control-plane signaling and using an NG3 interface for user-plane data communications when connecting to a 5G core netw ork, or using an S 1 interface for control-plane signaling and user-plane data communications when connecting to an Evolved Packet Core (EPC) network. The base stations 121 and 122 can communicate using an Xn Application Protocol (XnAP) through an Xn interface, or using an X2 Application Protocol (X2AP) through an X2 interface, at 106, to exchange user-plane and control-plane data. The user equipment 110 may connect, via the core network 150, to public networks, such as the Internet 160 to interact with a remote service 170. The core network 150 includes a certificate authority 118 (CA 118) to generate network certificates for the serving network and for networks that have roaming agreements with the operator of the core network 150 and its associated RAN.Example Devices

[0022] FIG. 2 illustrates an example device diagram 200 of the UE 110 and one of the base stations 120 that can implement various aspects of authenticating system information blocks in a wireless communication system. The UE 110 and / or the base station 120 may include additional functions and interfaces that are omitted from FIG. 2 for the sake of clarity.

[0023] The UE 110 includes antennas 202, a radio frequency front end 204 (RF front end 204), and a wireless transceiver (e g., an LTE transceiver 206, and / or a 5GNR transceiver 208) for communicating with the base station 120 in the RAN 140. The RF front end 204 of the UE 110 can couple or connect the LTE transceiver 206 and the 5GNR transceiver 208 to the antennas 202 to facilitate various types of wireless communication. The antennas 202 of the UE 1 10 may include an array of multiple antennas that are configured in a manner similar to or different from each other. The antennas 202 and the RF front end 204 can be tuned to, and / or be tunable 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, the antennas 202, the RF front end 204, the LTE transceiver 206, and / or the 5G NR transceiver 208 may be configured to support beamforming for the transmission and reception of communications with the base station 120. By way of example and not limitation, the antennas 202 and the RF front end 204 can be implemented for operation in sub-gigahertz (GHz) bands, sub-6 GHz bands, and / or above 6 GHz bands that are defined by the 3GPP LTE and 5G NR communication standards.

[0024] The UE 110 also includes processor(s) 210 and computer-readable storage media 212 (CRM 212). The processor 210 may be a single-core processor or a multiple-core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. The computer-readable storage media described herein excludes propagating signals. CRM 212 may include any suitable memory or storage device such as random-access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory’ useable to store device data 214 of the UE 110. The device data 214 includes user data, multimedia data, beamforming codebooks, applications, and / or an operating system of the UE 110, some of which are executable by processor(s) 210 to enable user-plane data, control -plane information, and user interaction with the UE 110.

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

[0026] The device diagram for the base station 120, shown in FIG. 2, includes a single network node (e.g., a gNode B). The functionality of the base station 120 may be distributed across multiple network nodes or devices and may be distributed in any fashion suitable to perform the functions described herein. The nomenclature for this split base station functionality variesand includes terms such Central Unit (CU), Distributed Unit (DU), Baseband Unit (BBU), Remote Radio Head (RRH), and / or Remote Radio Unit (RRU). The base station 120 includes antennas 252, a radio frequency front end 254 (RF front end 254), one or more wireless transceivers (e.g. , one or more LTE transceivers 256, and / or one or more 5G NR transceivers 258) for communicating with the UE 110. The RF front end 254 of the base station 120 can couple or connect the LTE transceivers 256 and the 5G NR transceivers 258 to the antennas 252 to facilitate various types of wireless communication. The antennas 252 of the base station 120 may include an array of multiple antennas that are configured in a manner similar to, or different from, each other. The antennas 252 and the RF front end 254 can be tuned to, and / or be tunable to, one or more frequency bands defined by the 3 GPP LTE and 5G NR communication standards, and implemented by the LTE transceivers 256, and / or the 5G NR transceivers 258. Additionally, the antennas 252, the RF front end 254, the LTE transceivers 256, and / or the 5G NR transceivers 258 may be configured to support beamfonning. such as Massive multiple-input, multiple-output (Massive-MIMO), for the transmission and reception of communications with the UE 110.

[0027] The base station 120 also includes processor(s) 260 and computer-readable storage media 262 (CRM 262). The processor 260 may be a single-core processor or a multiple-core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. CRM 262 may include any suitable memory or storage device such as randomaccess memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory useable to store device data 264 of the base station 120. The device data 264 includes network scheduling data, radio resource management data, beamforming codebooks, applications, and / or an operating system of the base station 120, which are executable by processor(s) 260 to enable communication with the UE 110.

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

[0029] The base station 120 also includes an inter-base station interface 268, such as an Xn and / or X2 interface, which the base station manager 266 configures to exchange user-plane data, control -plane information, and / or other data / information between other base stations, tomanage the communication of the base station 120 with the UE 1 10. The base station 120 includes a core network interface 270 that the 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.

[0030] FIG. 3 illustrates an example diagram 300 of a 4G LTE network architecture for a service-provider network. The elements in the example network architecture communicate with one another via a variety of non-roaming interfaces. The example network includes a user equipment 110 communicating with an eNB 321 (e.g., using the well-known LTE-Uu interface). The eNB communicates with a Mobility Management Entity (MME) 306 in the Evolved Packet Core network 350 (EPC 350) via an interface, (e.g.. a well-known S 1 -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 Sl-U interface. The SGW 310 can interface with the MME 306 (e.g, via a well-known S i l interface) as well as a Packet Gateway (PGW) 312 (e.g., via a well- known S5 interface). The PGW 312 is configured to interface with an Internet Protocol Multimedia Subsystem (IMS) 314 (e.g., via a well-known SGi interface) and the Internet 360.

[0031] In aspects, the EPC 350 includes a certificate authority 318 (CA 318) to generate network certificates for the serving network and for networks that have roaming agreements with the operator of the EPC 350 and its associated RAN. In one option, the CA 318 generates certificates based on a root certificate from a root C A, such as a root CA operated by a third-party company, a governmental organization, a standards body, or the like. In another option, the CA 318 can act as the root CA and generate and self-sign the root certificate for the RoT. The CA 318 is configured to connect to the MME 306 using the interface 322. Optionally, the CA 318 may be connected to the MME 306 via a firewall 320 to protect the CA 318 from potential core network intrusions. The CA 318 generates certificates for authentication of SIBs on a RAN-wide basis, a tracking area- wide basis, or for individual base stations (eNBs).

[0032] FIG. 4 illustrates an example architecture 400 of a 5G core network. In the illustrated example 400, control and user planes are separated. Here, network functions within the 5G Core Control Plane (5GC-CP) 450 use Service-Based Interfaces for their interactions. In aspects, a control plane network function can provide one or more network function services.

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

[0034] The 5GC-CP 450 is configured to communicate with User Data Management (UDM) 414 and an Application Function (AF) 416. In addition, the 5GC-CP 450 communicates with the radio access network (RAN) 140 and a User Plane Function (UPF) 424. The UPF 424 communicates with a Data Network (DN) 422. User-plane data for the UE 110 is communicated over the Uu interface to and from the RAN 140, is communicated over the N3 reference point between the RAN 140 and the UPF 424, and is communicated to and from the DN 422 over the N6 reference point. SMS Subscription data retrieval between the AMF 406 and the UDM 414 occurs over the N8 reference point. Application function requests are sent to the PCF 412 using the N5 reference point.

[0035] In aspects, the 5GC-CP 450 includes a certificate authority 418 (CA 418) to generate network certificates for the serving network and for networks that have roaming agreements with the operator of the 5GC-CP 450 and its associated RAN. In one option, the CA 418 generates certificates based on a root certificate from a root CA, such as a root CA operated by a third-part}' company, a governmental organization, a standards body, or the like. In another option, the CA 418 can act as the root CA and generate and self-sign the root certificate for the RoT. The CA 418 is configured to connect to the AMF 406 using the reference point 428. Optionally, the CA 418 may be connected to the AMF 406 via a firewall 420 to protect the CA 418 from potential core network intrusions. The CA 418 generates certificates for authentication of SIBs on a RAN-wide basis, a tracking area- wide basis, or for individual base stations (gNBs).

[0036] FIG. 5 illustrates an example device diagram 500 of a core network server 502. The core network server 502 may include additional functions and interfaces that are omitted from FIG. 5 for the sake of clarity.

[0037] The core network server 502 may provide all or part of a function, entity, service, and / or gateway in the core network 150. Each function, entity, service, and / or gateway in the core network 150 may be provided as a service in the core network 150, distributed across multiple servers, or embodied on a dedicated server. For example, the core netw ork server 502 may providethe all or a portion of the services or functions of the MME 306, HSS 308, SGW 310, PGW, 312, CA 118, 318, 418, NSSF 404, AMF 406, SMF 408, AUSF 410, PCF 412, or firewall 320, 420. The core network server 502 is illustrated as being embodied on a single server that includes processor(s) 504 and computer-readable storage media 506 (CRM 506). The processor 504 may be a single core processor or a multiple core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. CRM 506 may include any suitable memory or storage device such as random-access memory7(RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), hard disk drives, or Flash memory useful to store device data 508 of the core network server 502. The device data 508 includes data to support a core network function or entity', and / or an operating system of the core network server 502, which are executable by processor(s) 504. For example, the root certificate that is used to generate certificates by the CA 318 or CA 418 may be stored in the device data 508.

[0038] CRM 506 also includes one or more core network applications 510, which, in one implementation, is embodied on CRM 506 (as shown). The one or more core network applications 510 may implement the functionality' of the 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. Alternately or additionally, the one or more core network applications 510 may be implemented in whole or part 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 and control-plane data with the other functions or entities in the core network 150 or base stations 120.Signing SIB Structure

[0039] FIG. 6 illustrates an example implementation 600 of a signing SIB 602. The signing SIB 602 includes a primary7PLMN identifier (ID) 604 (PLMN code) of the wireless network that generated the signing SIB 602, an essential SIB hash 606, a primary SIB hash present flag 608, optionally a primary SIB hash 610, a secondary SIB hash present flag 612, optionally a secondary' SIB hash 614, and a signature 616. The essential SIB 606 includes SIBs required for a UE to connect to a RAN (e.g., SIB1 and SIB2).

[0040] In embodiments, each SIB hash (e.g., essential SIB hash 606, primary SIB hash 610, secondary SIB hash 614) includes a SIB list 618 of the SIBs in the hash with each list item being a SIB type indication 620, a hash algorithm indicator 622 that indicates the algorithm used to generate the hash data 624. The list of SIBs in each hash (e.g., essential SIB hash 606, primary7SIB hash 610, secondary SIB hash 614) are, by default in numerical order. Alternatively, theorder of the SIBs in each SIB hash can be specified in the SIB list 618. The signature 616 includes a signature algorithm indication 626 of the algorithm used to generate signature data 630, a hash algorithm indication 628, and the signature data 630. In another embodiment of the invention, the combination of hash algorithm, signing algorithm and the signing scheme could be indicated by a single '"signing version” identifier - so as to reduce the size of the signing SIB. Correspondingly, newer wireless standards and evolving cryptography standards could indicate a higher (or newer) “signing version.”Certificate Chain of Trust

[0041] FIG. 7 illustrates an example certificate chain of trust 700 comprising X.509 certificates and the signing SIB. The certificate chain of trust consists of a single root certificate (e.g., a home network root certificate 702) along with one or more serving network certificates (a serving network intermediate certificate 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; thus, the home network also possesses a short term serving network intermediate certificate 704. A serving network intermediate certificate 704 is generated for the home network operator and for every network operator with which the home network operator has an established roaming agreement, thereby permitting roaming on only authorized networks. The same public key pair used in a serving network intermediate certificate 704 will be shared across all serving network intermediate certificates 704 for a particular serving mobile network operator, thereby permitting a single serving network operator to have roaming agreements with multiple home network operators, including itself.

[0042] The home network root certificate 702 includes an issuer field, a subject field, a subject pubkey (public key) field, and a signature field. The issuer field includes a unique Public Land Mobile Network (PLMN) code that is assigned to the home network. The subject field identifies that the home network root certificate 702 includes a public key for the home network PLMN. The subject pubkey includes the home network root public key, and the signature field includes a certificate signature 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 that are omitted in FIG. 7 for the sake of illustration clarity.

[0043] The serving network intermediate certificate 704 includes an issuer field, a subject field, a subject pubkey (public key) field, and a signature field. The serving network intermediate certificate is cryptographically signed by the home network root of trust private key. The issuer field includes the unique PLMN code that is assigned to the home network. The subject fieldidentifies that home network root certificate 702 includes a public key for a serving network PLMN. The subject pubkey includes the serving network root public key, and the signature field includes a certificate signature for the serving network intermediate certificate 704. The serving network intermediate certificate 704 may include additional fields that are omitted in FIG. 7 for the sake of illustration clarity.

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

[0045] The most expedient path for installing a Root-of-Trust public key for verifying the signatures is to include it in a provisioning SIM card or eSIM of a UE 110. By using a single long-lived Root-of-Trust key, the serving network can use short-lived 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 signatures. Each certificate (704, 702, and / or 708) is identified using the serving network’s Public Land Mobile Network (PLMN) code for serv ing network certificates or the home network PLMN for the root certificate.

[0046] The final link in the certificate chain of trust is the signing SIB 710. The signature broadcast is transmitted via the signing SIB. This signing SIB includes space for the primary’ PLMN of the network, an essential SIB list and hash that provides integrity protection for other SIBs regularly broadcast by the RAN, an optional primary SIB list and hash, an optional secondary' SIB list and hash, and a signature that provides integrity protection for the signing SIB 710 itself. The optional primary SIB list and hash and the optional secondary’ SIB list and hash can be added whenever the network needs to broadcast one or more non-critical SIBs or one or more SIBs temporarily (e g., a weather alert conveyed on a SIB type 12).

[0047] For each hash (essential, primary', secondary ) included in the signing SIB 710, the SIBs included in that hash are concatenated in ascending SIB number numerical order and hashed using a cryptographically-secure hashing algorithm (e.g., hash = SHA256{SIB1 || SIB2 || ... || SIBn}). The SIBs included in each of the hashes are explicitly signaled using the same structure as the SIB Mapping Info list in SIB1. The essential SIB hash includes SIB1 and SIB2 and the signing SIB 710 should be rejected by the UE 110 if either are missing. The essential hash, the primary’ hash, and the secondary hash are transmitted in plain text, but are integrity -protected by the signature of the signing SIB 710.

[0048] The signing SIB 710 (excluding the signature) along with a current time, rounded dow n to a time interval (e.g., every’ 10 minutes), is then signed using the serving network’s private key (e.g., signature = Sign{sk, Hash(Time || SignSIB)}, where sk is the serving network's privatekey). The time source can be provided by a Global Navigation Satellite System (GNSS). Optionally or additionally, the UE 110 can monitor for sudden, unexpected changes in time and refuse to update the system time or complete the network attach process as this type of change in time could indicate an ongoing attack in an area that utilizes GNSS time spoofing coupled with a replay attack.

[0049] The UE 110 can verify the integrity of all SIBs broadcast by the network by first decoding the new signing SIB 710 and recovering the PLMN and the SIB mapping info list for the essential and optional primary and secondary blocks. The UE 110 then computes the hash across all SIBs included for each signature and then compares that hash against the signed hash included in the signing SIB 710. If the signatures match, the UE 110 will accept the SIB(s) as valid. If the hash for a group of SIBs does not match or the SIB was not included in any of the signatures, the SIB is assumed to be invalid and is dropped by the UE 110. Optionally or additionally, to account for the possibilities of bit errors in wireless transmission of the signing SIB, a number of retries of receiving and verifying the signing SIB 710 before abandoning (barring) a cell are contemplated. The UE 110 can optionally refuse to attach to the network and warn the user that a fake base station may be operating in the area. If the UE 110 tries to attach to a netw ork that does not support the signing SIB 710, then the UE 110 can show a warning indicating that the network cannot be authenticated and ask the user if they still want to connect to the network.

[0050] The aspects of authenticating system information blocks maintain backwards compatibility with older UEs 110, such that an existing standards compliant UE 110 will not be negatively impacted by the use of the signing SIB 710. An older UE 110 will simply ignore the signing SIB 710.Data and Control Transactions

[0051] FIG. 8 illustrates example data and control transactions between a base station 120 and a user equipment 110 that can implement various aspects of authenticating system information blocks. At 805, the base station 120 generates the signing SIB 710 contents. At 810, the base station 120 packs the SIBs for transmission as described in greater detail below. In some situations, 810 can occur prior to or parallel to 805. At 815 the base station 120 transmits SIB1 to the UE 110, at 820 the base station 120 transmits the signing SIB to the UE 110. and at 825, if any other SIBs are scheduled for transmission, those SIBs are transmitted to the UE 110.

[0052] At 830, the UE 110 verifies the signing SIB 710 if the signing SIB 710 is scheduled in SIB1, as discussed in detail below'. At 835 the UE 110 verifies SIBs (e.g., the essential SIBs, the primary optional SIBs, and the secondary optional SIBs).SIB Packing

[0053] FIG. 9 illustrates an example process for SIB packing by a base station in accordance with aspects of authenticating system information blocks. At 905, the base station 120 determines if the signing SIB 710 is scheduled for transmission. If not, the base station 120 packs and schedules remaining SIBs for transmission at 950. If the signing SIB 710 is scheduled, the base station 120 begins the packing process for the signing SIB 710 by obtaining the primary' PLMN ID at 910. At 915, the base station 120 packs the essential SIB group and generates ahash for the essential SIB group.

[0054] At 920. the base station 120 determines if there are any SIBs scheduled in the primary' SIB group. If there are primary SIBs scheduled, the base station 120 packs the primary' SIB group and generates a hash for the primary SIB group at 925. At 930, the base station 120 determines if there are any SIBs scheduled in the secondary SIB group. If there are secondary' SIBs scheduled, the base station 120 packs the secondary SIB group and generates a hash for the secondary SIB group at 935.

[0055] At 940, the base station 120 generates a signature to sign the signing SIB 710. At 945 the base station 120 packs (serializes) the signing SIB 710, including essential, primary, and secondary' hash values, into an ASN. 1 format for transmission. After signing and packing the signing SIB 710, the base station 120 packs and schedules remaining SIBs for transmission at 950. As mentioned earlier, 950 may be before or alongside 945 in some implementations.SIB Unpacking

[0056] FIGs. 10a and 10b illustrate an example process for SIB unpacking and verification by a UE in accordance with aspects of authenticating system information blocks. At 1002, the UE 1 10 unpacks and processes a received SIB1. At 1004, from the unpacked SIB1, the UE 110 determines whether a signing SIB 710 is scheduled. If the SIB1 includes scheduling information for a signing SIB 710, the UE 110 receives the signing SIB 710 at 1006. At 1008, the UE 110 compares the PLMN code in the signing SIB 710 (the first PLMN identifier) to the PLMN code in the CarrierConfig (the second PLMN identifier) included in the UE 110 to determine if the PLMN codes match. Optionally or additionally, the primary' PLMN is also compared to a list of approved PLMNs in the CarrierConfig information in the UE.-If the PLMN does not match, the UE 110 abandons the cell and restarts a cell search at 1018. If the PLMN is a match, the UE 110 obtains the corresponding PLMN RoT public key (e.g., from the SIM / eSIM or CarrierConfig) and validates the serving network public key by verifying that the serving network certificate chains back to the home network root certificate known by the UE. The UE then verifies 1010 that the signature in the signing SIB is valid. If the serving network Public Key does not chain back tothe PLMN’s RoT key OR if the signature is not valid, the UE 110 abandons the cell and restarts a cell search at 1018. If the signature is valid, the UE 110 determines if there are SIBs (SIB 1, SIB2) in the essential group to obtain at 1012, and if there are, the UE receives the remaining essential SIBs at 1014. At 1016, after obtaining all the SIBs in the essential group, the UE verifies that the essential SIBs are valid by performing the hash function on the concatenated essential SIB values and then matching to the essential hash value from the signing SIB 602. If the essential SIBs are not valid, the UE 110 abandons the cell and restarts a cell search at 1018. If the essential SIBs are valid, the UE 110 computes the hash of the corresponding SIBs in the essential group and verifies the hash against the signed hash present in the signing SIB. Upon successful matching of the two hashes, the UE processes (actions performed upon receipt of SIB# as described in 3GPP standards) the SIBs in the essential group at 1015 and unblocks the attach process at 1017.

[0057] At 1004, if the signing SIB 710 is not scheduled in SIB1, the UE 110 determines 1020 from its CarrierConfig if the signing SIB 710 is required. If the signing SIB 710 is required, the UE 1 10 abandons the cell and restarts a cell search at 1018. If the signing SIB 710 is not required, the UE 1 10 unblocks the attach process at 1022 and receives and processes (acquires) any remaining SIBs at 1024.

[0058] The example continues at 1052 in FIG. 10b with the UE 110 detennining if any SIBs are scheduled in the primary SIB group, e.g., by checking a primary has present flag. If SIBs are scheduled in the primary group, at 1054, the UE 1 10 determines if the SIBs in the primary group have been obtained. If the SIBs in the primary group have not been obtained (acquired), the UE 110 receives the remaining SIBs at 1056. With the SIBs in the primary group received, the UE 110 verifies that the primary SIB group is valid at 1058. If the primary’ SIB group is valid, the UE 110 processes the SIBs in the primary' group at 1060. If the primary SIB group is not valid, the UE 110 rejects the SIBs in the primary group at 1062.

[0059] If SIBs are not scheduled in the primary group at 1052, the SIBs in the primary group are validated at 1060, or the SIBs in the primary' group are rejected at 1062, SIB unpacking continues with the UE 110 determining if any SIBs are scheduled in the secondary’ SIB group at 1064. If SIBs are not scheduled in the secondary' group at 1064, the process of SIB unpacking and verification concludes. If SIBs are scheduled in the secondary' group, the UE 110 determines if the SIBs in the primary' group have been obtained at 1066. If the SIBs in the secondary group have not been obtained, the UE 110 receives the remaining SIBs at 1068. With the SIBs in the secondary group received, the UE 110 verifies that the primary SIB group is valid at 1070. If the primary' SIB group is valid, the UE 110 processes the SIBs in the primary group at 1072. If the secondary’ SIB group is not valid, the UE 110 rejects the SIBs in the secondary’ group at 1074.Example Methods

[0060] Example methods 1100, 1200, and 1300 are described with reference to FIGS. 11- 13, respectively, in accordance with one or more aspects of authenticating system information blocks. Generally, any of the components, modules, methods, and operations described herein can be implemented using software, firmware, hardware (e.g.. fixed logic circuitry), manual processing, or any combination thereof. Some operations of the example methods may be described in the general context of executable instructions stored on computer-readable storage memory' that is local and / or remote to a computer processing system, and implementations can include software applications, programs, functions, and the like. Alternatively or in addition, any of the functionality’ described herein can be performed, at least in part, by one or more hardware logic components, such as, and without limitation, Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SoCs), Complex Programmable Logic Devices (CPLDs), and the like.

[0061] FIG. 11 depicts an example method 1100 for supporting authenticated system information blocks by a base station in accordance with 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 a method, or an alternate method.

[0062] At block 1102, a base station schedules a signing SIB for transmission. For example, the base station (e.g., the base station 120) schedules a signing SIB (e.g., the signing SIB 710) for transmission by including the schedule for the signing SIB in the scheduling information elements of SIB I.

[0063] At block 1104, the base station generates the signing SIB. For example, and as described with respect to FIG. 9, the base station generates the signing SIB by inserting the primary' PLMN code into the signing SIB. The base station packs and hashes the essential SIB group and optionally the primary and secondary SIB groups. The base station then signs the signing SIB using the serving network private key.

[0064] At block 1106, the base station packs the signing SIB for transmission. For example, and as described with respect to FIG. 9, the base station packs (serializes) the signing SIB into an ASN. 1 formatted byte stream for transmission.

[0065] At block 1108, the base station transmits a SIB1 with an indication of the signing SIB in the scheduling information. For example and at 815 in FIG. 8, the base station transmits a SIB1 on a broadcast channel, the SIB1 including scheduling information for the signing SIB.

[0066] At block 1110, the base station transmits the signing SIB according to the SIB1 scheduling information. For example and as described in FIGs. 8, 10a, and 10b, the base station transmits the signing SIB as scheduled in the SIB1, the transmission being effective to direct a UE (e.g., the UE 110) to authenticate contents of SIB messages and use the authenticated SIBs to attach to the cell provided by the base station.

[0067] FIG. 12 depicts an example method 1200 for authenticating system information blocks by a user equipment in accordance with 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 a method, or an alternate method.

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

[0069] At 1204, the UE evaluates the SIB1 to determine if a signing SIB is scheduled in the SIB1 . For example and as described with respect to FIGs. 10a and 10b, the UE evaluates the scheduling information elements of the SIB1 to determine if a signing SIB is scheduled by the base station.

[0070] At 1206, the UE acquires, using the scheduling information, the signing SIB from the base station. For example and as described with respect to FIGs. 10a and 10b, by evaluating the scheduling information elements in the SIB1, the UE receives the signing SIB from the base station.

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

[0072] At 1210, the UE validates a signature of the signing SIB to verify the contents of the signing SIB. For example and as described with respect to FIGs. 10a and 10b, the UE uses the home network public key to validate the signature of the signing SIB to verify’ the contents of the signing SIB. If the signature is validated, the method continues at 1212, otherwise the UE abandons the cell and restarts the cell search at 1218.

[0073] At 1212, the UE validates an essential SIB group from the signing SIB. For example and as described with respect to FIGs. 6, 10a, and 10b, the UE validates the essential SIBgroup by generating a hash value and comparing that value to the hash data (e.g., the hash data 624) included in the signing SIB to validate the essential SIBs. If the signature is validated, the method continues at 1214, otherwise the UE abandons the cell and restarts the cell search at 1218.

[0074] At 1214, the UE perfonns actions upon the validation of the SIBs in the essential SIB group. For example, and as described with respect to FIGs. 10a and 10b, the UE performs actions upon validation of the SIB1 in the essential SIB group to determine parameters required to attach to the cell provided by the base station.

[0075] At 1216, the UE unblocks an attach process to attach to the cell provided by the base station using the SIB1. For example, and as described with respect to FIGs. 10a and 10b, the UE unblocks an attach process to attach to the cell provided by the base station using the SIB1.

[0076] FIG. 13 depicts an example method 1300 by a certificate authority server for authenticating system information blocks in accordance with 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 a method, or an alternate method.

[0077] At 1302, a certificate authority (CA) server generates a home network root certificate. For example and as described with respect to FIG. 7, a CA server (e.g., certificate authority 118, certificate authority 318, certificate authority 418) generates a home network root certificate (e.g., home network root certificate 702). The CA server also distributes a home network public key corresponding to the home netw ork private key in the UE.

[0078] At 1304, the CA server signs the home network root certificate with a home network private key. For example and as described with respect to FIG. 7, the CA server signs the home network root certificate 702 using a home network private key.

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

[0080] At 1308, the CA server signs the one or more serving network certificates with the home network private key. A RAN uses one or more serving network certificates to authenticate SIBs for cells. For example and as described with respect to FIG. 7, the CA server signs the one or more serving network certificates with the home network private key, the one or more serving network certificates being usable by a base station (e.g., the base station 120) to authenticate SIBs for cells in a radio access network (e.g., the RAN 130).

[0081] In the following some examples are described:Example 1: A method, by a base station, for supporting authenticated System Information Blocks (SIBs), such as essential SIBs (SIB 1, SIB2, etc.), the method comprising: scheduling a signing SIB for transmission; generating the signing SIB, the generating of the signing SIB comprising: inserting a list of essential SIBs into the signing SIB; generating a hash of values of the essential SIBs; and inserting the hash of values of the essential SIBs into the signing SIB; packing the signing SIB for transmission; transmitting an essential SIB, SIB1, with an indication of the signing SIB in scheduling information; and transmitting the signing SIB according to the essential SIB, SIB1, scheduling information.Example 2: The method of example 1, wherein the generating of the signing SIB further comprises: inserting a primary public land mobile network (PLMN) identifier into the signing SIB; generating a signature for the signing SIB; and inserting the signature into the signing SIB.Example 3: The method of example 1, wherein the generating of the hash of the values of the essential SIBs comprises: concatenating the essential SIBs in numerical order; and hashing the concatenated essential SIBs using a cryptographical ly-secure hashing algorithm.Example 4: The method of example 3, wherein the cryptographically -secure hashing algorithm is a 256-bit Secure Hash Algorithm 2 (SHA-256 algorithm) or any current, acceptable, cryptograph! cally-secure hashing algorithm.Example 5: The method of example 2, wherein the generating the signature for the signing SIB comprises: generating the signature for the signing SIB using a serving network private key.Example 6: The method of any one of examples 1 to 5, further comprising: inserting a list of primary SIBs into the signing SIB;generating a hash of the values of the primary SIBs; and inserting the hash of the values of the primary SIBs into the signing SIB.Example 7: The method of example 6, further comprising: inserting a list of secondary SIBs into the signing SIB; generating a hash of the values of the secondary SIBs; and inserting the hash of the values of the secondary7SIBs into the signing SIB.Example 8: The method of any of examples 1 to 7. wherein the packing comprises: serializing the signing SIB into an Abstract Syntax Notation One (ASN. l) format byte stream.Example 9: The method of any of examples 1 to 9, further comprising: transmitting other SIBs not authenticated by the signing SIB.Example 10: A method of authenticating System Information Blocks (SIBs), such as essential SIBs (SIB1, SIB2, etc.), by a user equipment, the method comprising: receiving, from a base station, an essential SIB, SIB1. that includes scheduling information; acquiring, using the scheduling information, a signing SIB; comparing a first primary7public land mobile network (PLMN) identifier in the signing SIB to a second primary PLMN identifier; when the compared PLMN identifiers match: validating the signing public key chains back to a Root-of-Trust (RoT) public key validating a signature of the signing SIB; when the signature of the signing SIB is valid: validating an essential SIB group, e.g. comprising essential SIBsSIB1, SIB2, etc.; when the essential SIB group is valid: performing actions upon SIBs in the essential SIB group; and unblocking an attach process to attach to a cell provided by the base station using the essential SIB, SIB1.Example 11 : The method of example 10, wherein: when the compared PLMN identifiers do not match, or when the signature of the signing SIB is not valid, or when the essential SIB group is not valid: barring the cell provided by the base station; and restarting a cell search.Example 12: The method of example 10 or example 11, wherein: when the serving network public key does not chain to the PLMN RoT Key: barring the cell provided by the base station; and restarting a cell search.Example 13: The method of example 10, wherein a signing SIB is not scheduled in SIB1: when the CarrierConfig requires a signing SIB: barring the cell provided by the base station; and restarting a cell search; or when the CarrierConfig does not require a signing SIB: unblocking the attach process; and acquire additional SIBs.Example 14: The method of example 10, further comprising: checking a primary SIB hash present flag for an indication that the signing SIB includes a primary SIB group: acquiring the SIBs listed in the primary' SIB group; validating the primary SIB group values; and when the primary' SIB group values are valid: processing the SIBs in the primary SIB group; and when the primary SIB group values are not valid: rejecting the SIBs in the primary SIB group.Example 15: The method of example 14, wherein the validating of the primary SIB group comprises: validating cryptographic hashes in the signing SIB by locally computing the corresponding hashes of the received SIB messages.Example 16: The method of example 14, further comprising:checking a secondary SIB hash present flag for an indication that the signing SIB includes a secondary SIB group: acquiring the SIBs listed in the secondary' SIB group; validating the secondary SIB group values; and when the secondary SIB group values are valid: processing the SIBs in the secondary SIB group; and when the secondary SIB group values are not valid: rejecting the SIBs in the secondary SIB group.Example 17: The method of any one of examples 10 to 16, wherein the validating of the signature of the signing SIB comprises: validating the signature of the signing SIB using a public key.Example 18 : The method of any one of examples 10 to 17, wherein the validating of the essential SIB group comprises: validating cry ptographic hashes in the signing SIB by locally computing the corresponding hashes of the received SIB messages.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 signing SIB to the second primary' PLMN identifier further comprises: comparing the first primary' public land mobile network (PLMN) identifier in the signing SIB to a list of approved PLMN identifiers stored within CarrierConfig information in the UE.Example 20: The method of any one of examples 10 to 19, wherein the validating the signature of the signing SIB comprises: validating that the signing public key chains back to the RoT public key.Example 21 : A method, by a certificate authority server, of supporting authenticated System Information Blocks (SIBs), the method comprising: generating a home network root certificate; signing the home network root certificate with a home network private key: generating one or more serving network certificates; and signing the one or more serving network certificates with the home network private key, the one or more serving network certificates being usable to authenticate SIBs for cells in a radio access network (RAN).Example 22: The method of example 21 , the method further comprising: generating one or more tracking area certificates to authenticate SIBs for cells in a tracking area of a RAN.Example 23: The method of example 21, the method further comprising: generating one or more base stations certificates to authenticate SIBs for a cell in a tracking area of a RAN.Example 24: The method of example 21, further comprising: distributing a home network public key, corresponding to the home network private key, to a user equipment.Example 25 : The method of example 24, wherein the home network public key is stored in a subscriber identity module of the user equipment.Example 26:. The method of any one of examples 21 to 25, wherein at least the one or more serving network certificates are used by a base station for authenticating SIBs in a method according to any of examples 1 to 9.Example 27 : An apparatus comprising: a processor; and memory’ comprising instructions executable by the apparatus to perform the method of any one of the preceding examples.

[0082] Although aspects of authenticating system information blocks have been described in language specific to features and / or methods, the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as example implementations of authenticating system information blocks, and other equivalent features and methods are intended to be within the scope of the appended claims. Further, various different aspects are described, and it is to be appreciated that each described aspect can be implemented independently or in connection with one or more other described aspects.

Claims

CLAIMSWhat is claimed is:

1. A method for supporting authenticated System Information Blocks, SIBs, including essential SIBs (SIB1, SIB2) by a base station (120), the method comprising: scheduling (1102) a signing SIB (602, 710) for transmission; generating (805, 1104) the signing SIB (602, 710), the generating (805, 1104) of the signing SIB (602, 710) comprising: inserting a list (618) of essential SIBs (SIB1, SIB2) into the signing SIB (602, 710); generating a hash of values of the essential SIBs (606); and inserting the hash of values of the essential SIBs (606) into the signing SIB (602, 710); packing (810) the signing SIB (602, 710) for transmission; transmitting (815) an essential SIB (SIB1) with an indication of the signing SIB (602, 710) in scheduling information; and transmitting (820) the signing SIB (602, 710) according to the essential SIB (SIB1) scheduling information.

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

3. The method of claim 2. wherein the generating (940) the signature for the signing SIB (602, 710) comprises: generating the signature for the signing SIB (602, 710) using a serving network private key.

4. The method of claim 1, wherein the generating of the hash of the values of the essential SIBs (606) comprises: concatenating the essential SIBs (SIB1, SIB2) in numerical order; and hashing (915) the concatenated essential SIBs using a ciyptographically-secure hashing algorithm.

5. The method of any one of claims 1 to 4, further comprising: inserting (920) a list of primary SIBs into the signing SIB (602, 710); generating (925) a hash of the values of the primary SIBs; and inserting the hash of the values of the primary SIBs into the signing SIB (602, 710).

6. A method (1200) of authenticating System Information Blocks, SIBs, including essential SIBs (SIB1, SIB2) by a user equipment, UE, (110), the method comprising: receiving (1002, 1202), from a base station (120), an essential SIB (SIB1) that includes scheduling information; acquiring (1006, 1206), using the scheduling information, a signing SIB (710); comparing (1008, 1208) a first primary public land mobile network, PLMN, identifier in the signing SIB (710) to a second primary PLMN identifier; when the compared PLMN identifiers match: validating the signing public key chains back to a Root-of-Trust. RoT, public key validating (1010, 1210) a signature of the signing SIB; when the signature of the signing SIB is valid: validating (1016, 1212) an essential SIB group; when the essential SIB group is valid: performing actions upon SIBs in the essential SIB group (1015, 1214); and unblocking an attach process (1017. 1216) to attach to a cell provided by the base station (120) using the essential SIB (SIB1).

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

8. The method of claim 6 or claim 7, wherein: when the serving network public key does not chain to the PL MN RoT Key: barring the cell provided by the base station (120); and restarting a cell search (1018, 1218).

9. The method of claim 6, wherein a signing SIB is not scheduled (1004) in the essential SIB (SIB1): when the CarrierConfig requires a signing SIB (1020): barring the cell provided by the base station (120); and restarting a cell search (1018); or when the CarrierConfig does not require a signing SIB (1020): unblocking the attach process (1022); and acquiring additional SIBs (1024).

10. The method of claim 6, further comprising: checking (1052) a primary' SIB hash present flag (608) for an indication that the signing SIB (602) includes a primary' SIB group: acquiring (1054, 1056) the SIBs listed in the primary’ SIB group; validating the primary SIB group values (1058); and when the primary' SIB group values are valid: processing the SIBs in the primary SIB group (1060); and when the primary SIB group values are not valid: rejecting the SIBs in the primary SIB group (1062).

11. The method of claim 10, further comprising: checking (1064) a secondary SIB hash present flag (612) for an indication that the signing SIB (602) includes a secondary SIB group: acquiring (1066, 1068) the SIBs listed in the secondary SIB group; validating the secondary’ SIB group values (1070); and when the secondary SIB group values are valid: processing the SIBs in the secondary SIB group (1072); and when the secondary SIB group values are not valid: rejecting the SIBs in the secondary SIB group (1074).

12. The method of any one of claims 6 to 11, wherein comparing the first primary public land mobile network (PLMN) identifier in the signing SIB to the second primary PLMN identifier (1008, 1208) further comprises: comparing the first primary’ public land mobile network (PLMN) identifier in the signing SIB (602, 710) to a list of approved PLMN identifiers stored within CarrierConfig information in the UE (HO).

13. The method of any one of claims 6 to 12, wherein the validating the signature of the signing SIB (1010, 1210) comprises: validating that the signing public key chains back to the RoT public key.

14. A method of supporting authenticated System Information Blocks, SIBs, by a certificate authority’ server (118, 318, 418), the method comprising: generating (1302) a home network root certificate (702); signing the home network root certificate with a home netw ork private key (1304); generating (1306) one or more serving network certificates (704); and signing (1308) the one or more serving network certificates (704) w ith the home network private key, the one or more serving network certificates being useable to authenticate SIBs for cells in a radio access network, RAN, (130).

15. The method of claim 14, the method further comprising: generating one or more tracking area certificates (706) to authenticate SIBs for cells in a tracking area of a RAN (130); generating one or more base stations certificates (708) to authenticate SIBs for a cell in a tracking area of a RAN (130); or. distributing a home network public key, corresponding to the home network private key, to a user equipment (110).

16. The method of claim 14 or 15, wherein at least the one or more serving network certificates (704) are used by a base station (120) for authenticating SIBs in a method according to any of claims 1 to 5.

17. An apparatus (110, 120, 502) comprising: a processor (210, 260, 504); and memory' (212, 262, 506) comprising instructions executable by the apparatus (110, 120, 502) to cause the apparatus (110, 120, 502) perform the method of any one of the preceding claims.

Images