NiPC (“network in a PC”) is a mode of operation supported by YateBTS that allows the basestation to operate in 2.5G GSM/GPRS mode without a core network. While YateBTS NiPC mode does support normal authentication and ciphering with a local SIM database, NiPC also offers a feature that bypasses all security procedures and allows a phone to connect without authentication. Although we have moved along to private LTE/5G networks like everyone else in the world, there are still some use cases where this bypass can make GSM/GPRS as the best (or only) choice.
This article describes the 2G security architecture that allows NiPC’s non-authenticated sub-mode to work, use cases for this type of operation, and how to configure the feature in a YateBTS LabKit or SateSite basestation unit.
Why Authentication Bypassing Works
NiPC authentication-bypassing mode works by exploiting a security hole in the GSM protocol. This hole was closed in later generations (starting with 3G UMTS), and so GSM is the only widely available protocol that can support service without access to Ki.
What’s in a SIM
In any cellular technology, the SIM contains two critical numbers:
- the IMSI (“international subscriber mobile identity”), a 15-digit number which is like a username for the cellular network and
- the “Ki”, a 128-bit secret number that is like a password for the cellular network.
The Ki value is hidden in the SIM, and cannot be read directly. Ideally, Ki exists only in the SIM and in the authentication center in the HLR (“home location register”, a kind of SIM database) of the operator who issued the SIM. The SIM also contains software that implements some standard encryption functions that are used in various security procedures. There are many other things in the SIM as well, but only the IMSI, Ki, and cryptographic algorithms are relevant to this discussion.
The Role of Ki
In the cellular network, all authentication tokens and encryption keys are derived from Ki. Again, this is true of all cellular technologies. So, for example, to authenticate a phone (a phone with a SIM), the network does this:
- The network requests the IMSI, or some other identity from which it can derive the IMSI, which the phone provides.
- The network determines from the IMSI what authentication algorithm is used by the SIM, an algorithm called “A3”.
- The network generates a 128-bit random number, called “RAND”, and encrypts it with A3 using Ki as the key. The result is called “RES”.
- The network sends the RAND to the phone.
- The phone also encrypts RAND with A3 using Ki as the key to make its own version of RES, called RES’.
- The phone sends RES’ back to the network.
- If RES and RES’ match, then the phone and the network must be using the same A3 and the same Ki. So the phone is authenticated.
- The network sends a message to the phone telling it that authentication is successful and that it has permission to access the network.
This is called challenge-response authentication. Steps 2, 3, and 7 happen in the HLR of the operator who issued the SIM, since that is the only place where Ki is available. In 3G networks and later, this same process is repeated in the other direction, so that the phone can also authenticate the network, so-called “2-way authentication” or “mutual authentication”. HOWEVER, in 2G networks, this authentication is one-way only.
Look again at the steps of the authentication procedure. The phone sees only Steps 1, 4-6, and 8. If the network generates the expected messages at Steps 1, 4, and 8, the phone has no way to know what really happened in Steps 2, 3, and 7. This means that the network can accept the phone and provide service without even knowing Ki, just by generating the expected signaling at these steps.
There are some limitations to this technique:
- This works only for 2G, not for 3G or 4G. These later technologies added a mutual authentication procedure that is impossible to complete without access to the HLR of the operator who issued the SIM.
- Phones authenticated in this way cannot use encryption. This is because session ciphering keys are a byproduct of Steps 3 and 5.
- Phones authenticated in this way cannot receive inbound calls and text messages to their normal telephone number. This is because the home operator, the operator who owns that number, does not know where the phone is.
But within these limitations, the following are still possible:
- Route outbound calls, which is easy via VoIP operators. Routing outbound SMS is also possible, but more difficult to find a service.
- Route inbound calls, and possibly SMS, to a temporarily assigned number. Again, for voice calls, this is easy to arrange with a VoIP operator.
- Provide a fully working internet connection with GPRS. GPRS data rates are low (maybe as low as 19 kbit/sec), but the connection will be fully functional and can even have a public IP address.
This NiPC approach is particularly useful for isolated private networks, where roaming agreements may not be practical, especially if the alternative is no service at all. (We used this same approach running OpenBTS at Burning Man.)
To prevent abuse, YateBTS generates an SMS “welcome message” the first time each phone connects, advising the user that his/her phone is attached to the private network. The network operator can change the text that is used in the message, but cannot disable it.
Authentication Bypassing with YateBTS
Lab Kits and SatSites run the same YateBTS software and support NiPC authentication-bypassing mode in the same way. Configuration is the same. There is detailed documentation at the YateBTS web site, but we give a short summary here.
Selecting an IMSI
In NiPC mode, YateBTS can be configured to bypass Ki authentication by setting a regular expression. Any phone whose IMSI matches the regular expression will be accepted for service. Here some examples:
- ^00101 — Accept any IMSI starting with 00101, which is the PLMN for test networks.
- ^310 — Any SIM starting with 310, which would be any SIM issued by a US operator.
- 001010123456789 — Accept only IMSI 001010123456789.
- .* — Accept any SIM with any IMSI.
Configuring from the LMI
The NiPC regular expression can be set from the “Regexp” item under the “Subscribers” tab.
Configuring from the configuration file
For automated systems, it may be better to control the regular expression from a file. The file is located in /etc/yate/sdr/subscribers.conf. Here is an example:
; Subscribers are accepted by either matching the IMSI against this configured ; regular expression or by setting subscribers individually ; Note! If a regular expression is used, 2G/3G authentication cannot be used. ; Ex: regexp=^001 ;regexp=^001
The NiPC authentication bypassing takes advantage of a limitation in GSM security to provide a useful service for private GSM networks, allowing a private network to provide limited voice and data service to a phone while still using a SIM issued by any operator. For more information on the LabKits and SatSite basestations that implement this mode, please contact email@example.com or fill out the contact form below.