Have we really lost the SIM card security? Of course not.
Lately news has reported multiple SIM card attacks[1][2][3]. In both of these cases the SIM card lets third parties to do undesirable things because SIM card security is (at least partially) disabled. [6].
A SIM card can have multiple applets, and it usually has at least applets for card management (RFM, RAM), but often many more. For these specific attacks to work, the SIM browser applet must have been configured with Minimum Security Level (MSL) setting of 00 (disabled). Anybody doing production cards should use minimum MSL 06 or 16 for all applets [4][5].
Having any applet with MSL 00 is acceptable for test SIM cards, but on field deployed cards it is an open invitation for just anybody to access that applet, and if that applet happens to be the card management (RFM, RAM) or some browser (WIB, S@T) to do unpredictable things. At minimum that is against operator’s business interests.
A long established mobile operator has typically long established relationships with SIM card suppliers, and there is no need to modify or even review old established card definitions, only add new ones for e.g. UMTS, LTE, 5G. An S@T-browser being one example of those old things. Therefore an old mistake is very likely to stay in latest card definitions.
This is a similar thing to having SIM cards using OTA keys of 56 bit DES type, which took a long while to get out of use, even after an attack against single-DES on SIM cards was demonstrated.
An overall card definition review is a good thing to do every now and then.
Protection Approaches
SIMalliance[5] recommends implementing filtering at the network level, to intercept and block the illegitimate binary SMS messages. However, a lot of MNOs seem to find the “SIMalliance advice to filter illegitimate messages” unclear and have gone on to filter all binary SMS (i.e. with PID=7F, DCS=F6) messages destined to all users. Unconstrained filtering such as this will lead to a break in some MNO service which must then be fixed afterwards.
The SIMalliance recommendation thus has one major omission or clarification: All MNO’s OTA server’s (such as file management OTA, MSSP Service OTA, etc.) must be excluded from filtering. Hence, below are some additional SMSC specific supplements/clarifications on the general SIMalliance recommendation.
- SMSC should allow every SMS originating or destined to any SMSC Short Number (Large Account, ESME) pass as is.
- SMSC should allow every SMS originating or destined to Kiuru MSSP (i.e. Alauda OTA or other OTAs) short number pass as is.
- SMSC should check in the SMS content if it is actually ETSI TS 102225 Command packet (maybe as is, or inside first segment of SMS CONCAT headers), and sent with SPI=00XX (again excluding all OTA ESMEs)
Note: Some MobileID systems (G&D WIB) sends Command packets in both Mobile Terminated and Mobile Originated direction. Do not block this traffic.
References
[1] AdaptiveMobile Security, 2019. Simjacker.
[2] Dan Goodin in Ars Technica, Sepetember 2019. SIMJACKER — Hackers are exploiting a platform-agnostic flaw to track mobile phone locations.
[3] Catalin Cimpanu in ZDNet, September 2019. New SIM card attack disclosed, similar to Simjacker.
[4] ETSI, July 2018. ETSI TS 102 225: Smart Cards; Secured packet structure for UICC based applications. Coding of the SPI first byte, and MSL setting. Add together:
02 = cryptographic checksum
04 = ciphering
10 = require counter incrementing
[5] SIMalliance, August 2019. Security guidelines for S@T Push.
[6] Security Research Labs, September 2019. New SIM attacks de-mystified.