Questions relating to GSM encryption at the intersection of SIM card and baseband processor

cQQkie · October 14, 2024, 3:14pm

Hi everyone,

this is my first post here. I’m working on a student research project concering 2G encryption, especially A5/1,A5/3,A5/4 and their usage in German networks and I came across a few questions that I wasn’t able to answer so far or find resources for.

Let me shortly summarize what I know so far concerning the real-time encryption:

The secret key K_i is saved on the smartcard with SIM-app and the session keys K_c are completely generated on the SIM card itself
For real-time encryption the K_c needs to be shared with the mobile device, i.e. transfered via the T=0 protocol to the baseband processor, which takes care of the real-time encryption
Newer Android versions allow for complete disabling of GSM connections except for emergencies (for some smart phones like Google Pixel etc.)
From the standards 3GPP TS 43.020 and 3GPP TS 03.20:

When an MS wishes to establish a connection with the network, the MS shall indicate to the network which of the seven versions of the A5 algorithm it supports. The network shall not provide service to an MS which indicates that it does not support the ciphering algorithm A5/1.

Here are my questions:

Is the transmission of the K_c between SIM card and baseband processor encrypted in any way or transmitted in plain text?
How exactly are the different A5/* algorithms implemented in the baseband? Directly in hardware or with software solution? Is it dependent on the age of the device, say e.g. older phones / baseband processors might only do the older versions (like A5/1) in hardware, but newer ones might offer the software implementations / the possibily of updates?
The sources I found here are 3GPP TS 03.20 version 8.6.0 Release 1999 / ETSI TS 100 929 V8.6.0, where 4.9 says:

It is mandatory for A5/1 and non encrypted mode to be implemented in mobile stations

or the more recent version 3GPP TS 43.020 version 18.0.0 Release 18, 4.9:

It is mandatory for A5/1, A5/3, A5/4 and non encrypted mode to be implemented in mobile stations. It is prohibited to implement A5/2 in mobile stations. Only A5 algorithms that are included in 3GPP specifications shall be implemented in mobile stations
What are the preventing factors, that optional deactivation of 2G for all end users with sufficiently modern OS versions (e.g. Android > 12) is not generally possible / done? Is this mainly an issue of device manufacturers? Or of baseband manufactures to pass through the existing solutions in Android OS to the baseband?
In 3GPP TS 43.020 and 3GPP TS 03.20, section 4.8 respectively, it is described what a “Negotiation of A5 algorithm” should is supposed to achieve. I frequently see in my test monitoring that A5/1 still occurs quite often, but I cannot categorize which tpyes of devices exactly use the A571 (different devices or individual old devices?).
Since I do not know exactly how the negotiation proceeds - apart from the key points in the standards - I wonder if it is also possible that more modern devices use A5/1 or if it is exclusively either old devices or old SIM cards in newer devices (where the newer devices would support A5/3 and A5/4 at the baseband processor level, but not on the SIM side, e.g., because the smart card only has a SIM application or because A5/3, A5/4 are listed in EF ‘Disabled Algorithms’?)
Can anyone shed light on that?
Lastly, who is responsible for ensuring that A5/1 is no longer used in a specific network? The network operators? If so, at what level? Does it start with the personalization of the SIMs, or can it be managed afterwards through adjustments in the network, e.g., that BSS no longer supports A5/1 or through updates of EF ‘Disabled Algorithms’ (where possible)? Does this need to be implemented by the MS / BP manufacturers?

I know these are a lot of detailed questions and I’d be happy if someone was able to shed some light on any of them. I’m also open to splitting up these questions into several subquestions for better overview if wished for.

Best regards,
Matt

Manawyrm · October 16, 2024, 11:30am

Hi,

first of all: Welcome

If you want to play with SIM cards, listen to their communication or even manipulate/play around with their packets, you can look into:

which is a fully virtual SIM card implementation in software

as well as: SIMtrace2 Hardware Kit | simtrace2-kit

With the combination between onomondo-uicc (virtual SIM) and SIMtrace (being able to both emulate the virtual SIM against a real device) and being able to sniff communcations between real devices and a SIM, you can do a very deep dive into the communications involved

You could even use osmocom-bb against a “real” osmocom network, purely virtually, with no physical RF or SIM cards involved.

The pySim library can be used to directly talk to a SIM card in a PC/SC (aka standard PC) smartcard reader and ask it for a keypair (often called “triplet”)

github.com

mixja/eap-sim-lab/blob/master/lib/pySim/pySim-run-gsm.py

#!/usr/bin/env python

#
# Utility to run the 2G gsm algorithm on the SIM card
# used to generate authentication triplets for EAP-SIM
#
# Copyright (C) 2009  Sylvain Munaut <tnt@246tNt.com>
# Copyright (C) 2010  Harald Welte <laforge@gnumonks.org>
# Copyright (C) 2013  Alexander Chemeris <alexander.chemeris@gmail.com>
# Copyright (C) 2013  Darell Tan <darell.tan@gmail.com>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

This file has been truncated. show original

You can look at the code of run_gsm():

github.com

mixja/eap-sim-lab/blob/master/lib/pySim/pySim/commands.py#L84


      
          		return self._tp.send_apdu_checksw(pdu)
          
          	def record_size(self, ef):
          		r = self.select_file(ef)
          		return int(r[-1][28:30], 16)
          
          	def record_count(self, ef):
          		r = self.select_file(ef)
          		return int(r[-1][4:8], 16) // int(r[-1][28:30], 16)
          
          	def run_gsm(self, rand):
          		if len(rand) != 32:
          			raise ValueError('Invalid rand')
          		self.select_file(['3f00', '7f20'])
          		return self._tp.send_apdu('a088000010' + rand)
          
          	def reset_card(self):
          		return self._tp.reset_card()
          
          	def verify_chv(self, chv_no, code):
          		fc = rpad(b2h(code), 16)

and see that it’s quite a simple operation → SIM receives a RAND challenge (from the network) and replies with SRES and Kc.

In other words, no, there is no encryption involved. You can even call this function externally. There are AT commands and even Bluetooth profiles (SIM-Access-Profile) to allow external devices to send APDUs to a SIM.
As the same RAND will always generate the same SRES and Kc, you can just ask the SIM for the keys.

Users still need 2G connectivity in rural areas. Most devices offer a menu option to disable 2G these days. iPhones can disable 2G as part of the “lockdown mode” security features.

In a commercial network, the algorithms used would typically be configured in the BSC. The operator can select which algorithms they want to offer.

I’m hoping the other folks here can offer some more advice (ideally with sources/links to the applicable standards) regarding your other questions.