Category Archives: SDM

PyHSS – Python 3GPP LTE Home Subscriber Server

EPC, EUTRAN, IMS / VoLTE, LTE, Mobile Networks, Python, RF, RFCs & Standards, SDM, , ,

I recently started working on an issue that I’d seen was to do with the HSS response to the MME on an Update Location Answer.

I took some Wireshark traces of a connection from the MME to the HSS, and compared that to a trace from a different HSS. (Amarisoft EPC/HSS)

The Update Location Answer sent by the Amarisoft HSS to the MME over the S6a (Diameter) interface includes an AVP for “Multiple APN Configuration” which has the the dedicated bearer for IMS, while the HSS in the software I was working on didn’t.

After a bit of bashing trying to modify the S6a responses, I decided I’d just implement my own Home Subscriber Server.

The Diameter interface is pretty straight forward to understand, using a similar structure to RADIUS, and with the exception of the Crypto for the EUTRAN Authentication Vectors, it was all pretty straight forward.

If you’d like to know more you can download PyHSS from my GitLab page, and view my Diameter Primer post and my post on Diameter packet structure.

Diameter Basics

EPC, EUTRAN, LTE, Mobile Networks, RF, RFCs & Standards, SDM, VoIP,

3GPP selected Diameter protocol to take care of Authentication, Authorization, and Accounting (AAA).

It’s typically used to authenticate users on a network, authorize them to use services they’re allowed to use and account for how much of the services they used.

In a EPC scenario the Authentication function takes the form verifying the subscriber is valid and knows the K & OP/OPc keys for their specific IMSI.

The Authorization function checks to find out which features, APNs, QCI values and services the subscriber is allowed to use.

The Accounting function records session usage of a subscriber, for example how many sessional units of talk time, Mb of data transferred, etc.

Diameter Packets are pretty simple in structure, there’s the packet itself, containing the basic information in the headers you’d expect, and then a series of one or more Attribute Value Pairs or “AVPs”.

These AVPs are exactly as they sound, there’s an attribute name, for example username, and a value, for example, “Nick”.

This could just as easily be for ordering food; we could send a Diameter packet with an imaginary command code for Food Order Request, containing a series of AVPs containing what we want. The AVPs could belike Food: Hawian Pizza, Food: Garlic Bread, Drink: Milkshake, Address: MyHouse.
The Diameter server could then verify we’re allowed to order this food (Authorization) and charge us for the food (Accounting), and send back a Food Order Response containing a series of AVPs such as Delivery Time: 30 minutes, Price: $30.00, etc.

Diameter packets generally take the form of a request – response, for example a Capabilities Exchange Request contains a series of AVPs denoting the features supported by the requester, which is sent to a Diameter peer. The Diameter peer then sends back a Capabilities Exchange Response, containing a series of AVPs denoting the features that it supports.

Diameter is designed to be extensible, allowing vendors to define their own type of AVP and Diameter requests/responses and 3GPP have defined their own types of messages (Diameter Command Codes) and types of data to be transferred (AVP Codes).

LTE/EPC relies on Diameter and the 3GPP/ETSI defined AVP / Diameter Packet requests/responses to form the S6a Interface between an MME and a HSS, the Gx Interface between the PCEF and the PCRF, Cx Interface between the HSS and the CSCF, and many more interfaces used for Authentication in 3GPP networks.

LTE (4G) – TMSI & GUTI

EPC, EUTRAN, LTE, Mobile Networks, Notes, RF, SDM, , , ,

We’ve already touched on how subscribers are authenticated to the network, how the network is authenticated to subscribers and how the key hierarchy works for encryption of user data and control plane data.

If the IMSI was broadcast in the clear over the air, anyone listening would have the unique identifier of the subscriber nearby and be able to track their movements.

We want to limit the use of the IMSI over the air to a minimum.

During the first exchange the terminal is forced to send it’s IMSI, it’s the only way we can go about authenticating to the network, but once the terminal is authenticated and encryption of the radio link has been established, the network allocates a temporary identifier to the terminal, called the Temporary Mobile Subscriber Identity (TMSI) by the serving MME.

The TMSI is given to the terminal once encryption is setup, so only the network and the terminal know the mapping between IMSI and TMSI.

The TMSI is used for all future communication between the Network and the Terminal, hiding the IMSI.

The TMSI can be updated / changed at regular intervals to ensure the IMSI-TMSI mapping cannot be ascertained by a process of elimination.

The TMSI is short – only 4 bytes long – and this only has significance for the serving MME.

For the network to ascertain what MME is serving what TMSI the terminal is also assigned a Globally Unique Temporary (UE) Identity (GUTI), to identify the MME that knows the TMSI to IMSI mapping.

The GUTI is made up of the MNC/MCC combination, then an MME group ID to identify the MME group the serving MME is in, a MME code to identify the MME that allocated the TMSI and finally the TMSI itself.

The decision to use the TMSI or GUTI in a dialog is dependant on the needs of the dialog and what information both sides have. For example in an MME change the GUTI is needed so the original IMSI can be determined by the new MME, while in a normal handover the TMSI is enough.

LTE (4G) – EUTRAN – Key Distribution and Hierarchy

LTE, Mobile Networks, RF, RFCs & Standards, Security, SIM Cards, , , ,

We’ve talked a bit in the past few posts about keys, K and all it’s derivatives, such as Kenc, Kint, etc.

Each of these is derived from our single secret key K, known only to the HSS and the USIM.

To minimise the load on the HSS, the HSS transfers some of the key management roles to the MME, without ever actually revealing what the secret key K actually is to the MME.

This means the HSS is only consulted by the MME when a UE/Terminal attaches to the network, and not each time it attaches to different cell etc.

When the UE/Terminal first attaches to the network, as outlined in my previous post, the HSS also generates an additional key it sends to the MME, called K-ASME.

K-ASME is the K key derived value generated by the HSS and sent to the MME. It sands for “Access Security Management Entity” key.

When the MME has the K-ASME it’s then able to generate the other keys for use within the network, for example the Kenb key, used by the eNodeB to generate the keys required for communications.

The USIM generates the K-ASME itself, and as it’s got the same input parameters, the K-ASME generated by the USIM is the same as that generated by the HSS.

The USIM can then give the terminal the K-ASME key, so it can generate the same Kenb key required to generate keys for complete communications.

Showing Kamse generation sequence in LTE. Image sourced from IMTx: NET02x course on Edx,

LTE (4G) – Authenticating the Network

EPC, LTE, Mobile Networks, RF, RFCs & Standards, Security, SIM Cards, , , ,

In my last post we discussed how the network authenticated a subscriber, now we’ll look at how a subscriber authenticates to a network. There’s a glaring issue there in that the MME could look at the RES and the XRES and just say “Yup, OK” even if the results differed.

To combat this LTE networks have mutual authentication, meaning the network authenticates the subscribers as we’ve discussed, and the subscribers authenticate the network.

To do this our HSS will take the same random key (RAND) we used to authenticate the subscriber, and using a different cryptographic function (called g) take the RAND, the K value and a sequence number called SQN, and using these 3 inputs, generate a new result we’ll call AUTN.

The HSS sends the RAND (same as RAND used to authenticate the subscriber) and the output of AUTN to the MME which forwards it to the eNB to the UE which passes the RAND and AUTH values to the USIM.

The USIM takes the RAND and the K value from the HSS, and it’s expected sequence number. With these 3 values it applies the cryptographic function g generates it’s own AUTN result.

If it matches the AUTN result generated by the HSS, the USIM has authenticated the network.

LTE (4G) – Authenticating Subscribers

EPC, LTE, Mobile Networks, RF, RFCs & Standards, SDM, SIM Cards, , , ,

The USIM and the HSS contain the subscriber’s K key. The K key is a 128 bit long key that is stored on the subscriber’s USIM and in the HSS along with the IMSI.

The terminal cannot read the K key, neither can the network, it is never transmitted / exposed.

When the Terminal starts the attach procedure, it includes it’s IMSI, which is sent to the MME.

The MME then sends the the HSS a copy of the IMSI.

The HSS looks up the K key for that IMSI, and generates a random key called RAND.

The HSS and runs a cryptographic function (called f) using the input of RAND and K key for that IMSI, the result is called XRES (Expected result).

The HSS sends the output of this cryptographic function (XRES), and the random value (RAND) back to the MME.

The MME forwards the RAND value to the USIM (via eNB / Terminal), and stores a copy of the expected output of the cryptographic function.

The USIM take the RAND and the K key and performs the same cryptographic function the HSS did on it with the input of the K key and RAND value to generate it’s own result (RES).

The result of this same function (RES) is then sent from the USIM to the terminal which forwards it to the MME.

The MME and comparing the result the HSS generated (XRES) with the result the USIM generated. (RES)

If the two match it means both the USIM knows the K key, and is therefore the subscriber they’re claiming to be.

If the two do not match the UE is refused access to the network.

Next up, how the UE authenticates the network.

LTE (4G) – USIM Basics

LTE, Mobile Networks, RF, RFCs & Standards, Security, SIM Cards, , , , , , , ,

I’ve been working on private LTE recently, and one of the first barriers you’ll hit will be authentication.

LTE doesn’t allow you to just use any SIM to authenticate to the network, but instead relies on mutual authentication of the UE and the network, so the Network knows it’s talking to the right UE and the UE knows it’s talking to the right network.

So because of this, you have to have full control over the SIM and the network. So let’s take a bit of a dive into USIMs.

So it’s a SIM card right?

As a bit of background; the ever shrinking card we all know as a SIM is a “Universal integrated circuit card” – a microcontroller with it’s own OS that generally has the ability to run Java applets.

One of the Java applets on the card / microcontroller will be the software stack for a SIM, used in GSM networks to authenticate the subscriber.

For UMTS and LTE networks the card would have a USIM software stack allowing it to act as a USIM, the evolved version of the SIM.

Because it’s just software a single card can run both a USIM and SIM software stack, and most do.

As I’m building an LTE network we’ll just talk about the USIM side of things.

USIM’s role in Authentication

When you fire up your mobile handset the baseband module in it communicates with the USIM application on the card.

When it comes time to authenticate to the network, and authenticate the network itself, the baseband module sends the provided challenge information from the network to the USIM which does the crypto magic to generate responses to the authentication challenges issued by the network, and the USIM issues it’s own challenges to the network.

The Baseband module provides the ingredients, but the USIM uses it’s secret recipe / ingredients combo, known only to the USIM and HSS, to perform the authentication.

Because the card challenges the network it means we’ve got mutual authentication of the network.

This prevents anyone from setting up their own radio network from going all Lionel Ritche and saying “Hello, is it me you’re looking for” and having all the UEs attach to the malicious network. (Something that could be done on GSM).

It’s worth noting too that because the USIM handles all this the baseband module, and therefore the mobile handset itself, doesn’t know any of the secret sauce used to negotiate with the network. It just gets the challenge and forwards the ingredients down to the USIM which spits back the correct response to send, without sharing the magic recipe.

This also means operators can implement their own Crypto functions for f and g, so long as the HSS and the USIM know how to generate the RES and AUTN results, it’ll work.

What’s Inside?

Let’s take a look at the information that’s stored on your USIM:

All the GSM stuff for legacy SIM application

Generally USIMs also have the ability to operate as SIMs in a GSM network, after all it’s just a different software stack. We won’t touch on GSM SIMs here.

ICCID

Because a USIM is just an application running on a Universal Integrated Circuit Card, it’s got a ICCID or Universal Integrated Circuit Card ID. Generally this is the long barcode / string of numbers printed on the card itself.

The network generally doesn’t care about this value, but operators may use it for logistics like shipping out cards.

PIN & PUK

PINs and PUKs are codes to unlock the card. If you get the PIN wrong too many times you need the longer PUK to unlock it.

These fields can be written to (when authenticated to the card) but not read directly, only challenged. (You can try a PIN, but you can’t see what it’s set too).

As we mentioned before the terminal will ask the card if that’s correct, but the terminal doesn’t know the PIN either.

IMSI

Each subscriber has an IMSI, an International Mobile Subscriber Identity.

IMSIs are hierarchical, starting with 3 digit Mobile Country Code MCC, then the Mobile Network Code (MNC) (2/3 digits) and finally a Mobile Subscription Identification Number (MSIN), a unique number allocated by the operator to the subscribers in their network.

This means although two subscribers could theoretically have the same MSIN they wouldn’t share the same MNC and MCC so the ISMI would still be unique.

The IMSI never changes, unless the subscriber changes operators when they’ll be issued a new USIM card by the new operator, with a different IMSI (differing MNC).

The MSIN isn’t the same as the phone number / MSISDN Number, but an IMSI generally has a MSISDN associated with it by the network. This allows you to port / change MSISDN numbers without changing the USIM/SIM.

K – Subscriber Key

Subscriber’s secret key known only to the Subscriber and the Authentication Center (AuC/ HSS).

All the authentication rests on the principle that this one single secret key (K) known only to the USIM and the AuC/HHS.

OP – Operator Code

Operator Code – same for all SIMs from a single operator.

Used in combination with K as an input for some authentication / authorisation crypto generation.

Because the Operator Code is common to all subscribers in the network, if this key were to be recovered it could lead to security issues, so instead OPc is generally used.

OPc – Operator Code (Derived)

Instead of giving each USIM the Operator Code a derived operator code can be precomputed when the USIM is written with the K key.

This means the OP is not stored on the USIM.

OPc=Encypt-Algo(OP,Key)

PLMN (Public Land Mobile Network)

The PLMN is the combination of MCC & MNC that identifies the operator’s radio access network (RAN) from other operators.

While there isn’t a specific PLMN field in most USIMs it’s worth understanding as several fields require a PLMN.

HPLMNwAcT (HPLMN selector with Access Technology)

Contains in order of priority, the Home-PLMN codes with the access technology specified.

This allows the USIM to work out which PLMN to attach to and which access technology (RAN), for example if the operator’s PLMN was 50599 we could have:

  • 50599 E-UTRAN
  • 50599 UTRAN

To try 4G and if that fails use 3G.

In situations where operators might partner to share networks in different areas, this could be set to the PLMN of the operator first, then it’s partnered operator second.

OPLMNwACT (Operator controlled PLMN selector with Access
Technology)

This is a list of PLMNs the operator has a roaming agreement with in order of priority and with the access technology.

An operator may roam to Carrier X but only permit UTRAN access, not E-TRAN.

FEHPLMN (Equivalent HPLMN)

Used to define equivalent HPMNs, for example if two carriers merge and still have two PLMNs.

FPLMN (Forbidden PLMN list)

A list of PLMNs the subscriber is not permitted to roam to.

HPPLMN (Higher Priority PLMN search period)

How long in seconds to spend between each PLMN/Access Technology in HPLMNwAcT list.

ACC (Access Control Class)

The ACC allows values from 0-15, and determines the access control class of the subscriber.

In the UK the ACC values is used to restrict civilian access to cell phone networks during emergencies.

Ordinary subscribers have ACC numbers in the range 0 – 9. Higher priority users are allocated numbers 12-14.

During an emergency, some or all access classes in the range 0 – 9 are disabled.

This means service would be could be cut off to the public who have ACC value of 0-9, but those like first responders and emergency services would have a higher ACC value and the network would allow them to attach.

AD (Administrative Data)

Like the ACC field the AD field allows operators to drive test networks without valid paying subscribers attaching to the network.

The defined levels are:

  • ’00’ normal operation.
  • ’80’ type approval operations.
  • ’01’ normal operation + specific facilities.
  • ’81’ type approval operations + specific facilities.
  • ’02’ maintenance (off line).
  • ’04’ cell test operation.

GID 1 / 2 – Group Identifier

Two group identifier fields that allow the operator to identify a group of USIMs for a particular application.

SPN (Service Provider Name)

The SPN is an optional field containing the human-readable name of the network.

The SPN allows MVNOs to provide their own USIMs with their name as the operator on the handset.

ECC (Emergency Call Codes)

Codes up to 6 digits long the subscriber is allowed to dial from home screen / in emergency / while not authenticated etc.

MSISDN

Mobile Station International Subscriber Directory Number. The E.164 formatted phone number of the subscriber.

This is optional, as porting may overwrite this, so it doesn’t always match up.

References:

https://www.etsi.org/deliver/etsi_ts/131100_131199/131102/12.05.00_60/ts_131102v120500p.pdf

Wireshark trace showing a "401 Unauthorized" Response to an IMS REGISTER request, using the AKAv1-MD5 Algorithm

All About IMS Authentication (AKAv1-MD5) in VoLTE Networks

EPC, IMS / VoLTE, LTE, Mobile Networks, Notes, RFCs & Standards, SDM, Security, SIM Cards, Software, VoIP, , , , ,

I recently began integrating IMS Authentication functions into PyHSS, and thought I’d share my notes / research into the authentication used by IMS networks & served by a IMS capable HSS.

There’s very little useful info online on AKAv1-MD5 algorithm, but it’s actually fairly simple to understand.

RFC 2617 introduces two authentication methods for HTTP, one is Plain Text and is as it sounds – the password sent over the wire, the other is using Digest scheme authentication. This is the authentication used in standard SIP MD5 auth which I covered ages back in this post.

Authentication and Key Agreement (AKA) is a method for authentication and key distribution in a EUTRAN network. AKA is challenge-response based using symmetric cryptography. AKA runs on the ISIM function of a USIM card.

I’ve covered the AKA process in my post on USIM/HSS authentication.

The Nonce field is the Base64 encoded version of the RAND value and concatenated with the AUTN token from our AKA response. (Often called the Authentication Vectors).

That’s it!

It’s put in the SIP 401 response by the S-CSCF and sent to the UE. (Note, the Cyperhing Key & Integrity Keys are removed by the P-CSCF and used for IPsec SA establishment.

Wireshark trace showing a "401 Unauthorized" Response to an IMS REGISTER request, using the AKAv1-MD5 Algorithm
Click for Full Size version of this image