A Journey Into the Depths of VoWiFi Security

T-mobile pioneered with the native seamless support for WiFi calling technology embedded within the smartphones. This integrated WiFi calling feature is adopted by most major providers as well as many smartphones today. T-mobile introduced VoWiFi in Germany in May 2016. You can make voice calls that allows to switch between LTE and WiFi networks seamlessly. This post is going to be about security analysis of Voice over WiFi (VoWiFi), another name for WiFi calling, from the user end. Before we get started, let me warn you in advance. If you are not familiar with telecommunication network protocols, then you might get lost in the heavy usage of acronyms and abbreviations. I am sorry about that. But trust me, after a while, you get used to it 🙂 .

Let me describe some important things to know before we get into the analysis. Our main target interface is the interface between the user client and the IP Multimedia Subsystem (IMS) server. There are epdg1(virtual interface) and wlan0 (real wireless interface) that we look into. We use Samsung S6 gadget and a Telekom (Germany) SIM to carry out the analysis. Most of the security is with IPSec using ISAKMP [3] as part of IKEv2 making use of EAP-AKA [5]. We also use SIMtrace [2] to extract the session keys by sniffing the traffic between the SIM and the phone.

As a result of our analysis, there are some interesting findings such as information disclosures like leaking IMEI of the caller, private IP, IMS server version and provider name. This is obtained by sniffing the virtual interface called epdg1, that contained the Session Initiation Protocol (SIP) – the signaling traffic within the user client. The virtual interface, epdg1, is encapsulated as ESP packets within the IPSec. But these are not encrypted at this point. When this is sent via wlan0 interface, to the server, then it is encrypted using IPSec. We are still in the process of trying to decrypt the wlan0 encrypted packets to see if we can find anything interesting. But before getting into the details, let us first do some background study.

What is VoWiFi?

Voice over Wi-Fi (VoWiFi), as the name implies, is delivering voice service via WiFi network. Users can make calls without the need of mobile signal. VoWiFi is a complementary technology to Voice over LTE (VoLTE). Both make use of the IP Multimedia Subsystem (IMS) technology to realize the voice traffic as IP packets.

What is IKEv2 protocol?

In the IKEv2 protocol flow, there are mainly two phases. This is mainly done for establishing SA (security association) for either ESP (Encapsulated security protocol) or AH (Authentication header) both of which are IPSec protocols.

The first phase, that consists of IKE_SA_INIT is for negotiating mainly four parameters for the next phase. The encryption algorithm, authentication algorithm (integrity check), Pseudorandom Function (PRF), and Diffie Helman group. Based on the negotiation, and with DH key exchange, there is an encrypted traffic in the following phase. Now, during this encrypted traffic, the actual crypto parameters and SAs for the ESP or AH are agreed. This means that you will find ESP packets (or AH) soon after the SAs are established using IKEv2.

How does EAP-AKA authentication works?

Below is a diagram that explains EAP-AKA authentication briefly. Peer is the user client and authenticator is the server. I don’t want to get into the details of server names or the protocol flow there. There are proxies, authentication server, and so on. But let us just call it server. It is not relevant for us to know what happens between the servers.

There is an initial identity exchange between the peer and the authenticator. Authenticator runs AKA (Authentication and Key Agreement) algorithm and generates a session key. Based on the session key, server generates AUTN and RAND values. This is sent to the peer. AUTN is for authentication of the server. RAND is a random challenge. This can be considered as the server sending a puzzle for the peer to solve. The peer performs the same AKA algorithm and verifies AUTN, derives session key based on the RAND that is sent, and then sends a response value, RES, so that the server can authenticate the peer. If the RES matches the expected values, then it sends an EAP success message. The session key is never transmitted during the authentication.

Now, in order to get the session key, we used the Osmocom Simtracer [2]. This basically allows to sniff the communication between the SIM and the phone. We place the SIM card inside simtracer and connect the simtracer to the phone’s sim slot. The peer runs the AKA algorithm within the SIM. The SIM contains the pre-shared secret for performing this. Once the session key is generated, this is sent to the telephony app. This can be seen as a response gsm_sim packet if we run the capture in wireshark. The payload, called as APDU, contains the session key. It is split into two keys. It is called the IK and CK (integrity key and the confidentiality key).

What can we do now?

In order to make the Wifi call, an IPSec tunnel is to be created in the phone. There is an integrated vpnclient daemon that starts running when the call is made for the first time.

—————————————— logcat snippet ————————————

10-06 20:53:27.450 5872 5872 I vpnclientd: Added interfaces:

10-06 20:53:27.450 5872 5872 I vpnclientd: 15: ‘epdg1’ mtu 1500

————————————————————————————————

We are able to sniff the virtual interface, epdg1. We easily notice that the packets in this interface are not encrypted – but it is integrity protected. This directly uses the IK that we sniffed with the simtracer.

Using Gcrypt library in wireshark, we can decode the packets inroder to see the underlying packets.

We are then able to see SIP (session initiation protocol) packets that are embedded inside the ESP packets..

Within the SIP invite packet, that initiates a WiFi call, we can find interesting information disclosures like private IP, IMEI of the caller, provider. Hendrik had mentioned more about information disclosures in his previous post on VoLTE.

Is that all? Do we have everything?

Currently, we had a look at the virtual interface that was created by the vpnclient daemon. But the real packets are sent via wlan0. These are encrypted and the keys are obtained using IKEv2 protocol. Both, the authentication and encryption keys are agreed using EAP-AKA, you also can see in logcat.

——————————————————————————————————————————————————————-

10-06 20:53:29.180 5872 5872 I vpnclientd: IKEv2 SA [Initiator, NAT-T] negotiation completed:

10-06 20:53:29.180 5872 5872 I vpnclientd: Local Authentication Method : EAP AKA

10-06 20:53:29.180 5872 5872 I vpnclientd: Remote Authentication Method : EAP AKA

10-06 20:53:29.180 5872 5872 I vpnclientd: IKE algorithms : aes256-cbc, hmac-sha1, hmac-sha1-96

10-06 20:53:29.180 5872 5872 I vpnclientd: Diffie-Hellman : group 2 (dh-modp-1024)

10-06 20:53:29.180 5872 5872 I vpnclientd: Local IKE peer 192.168.1.1:54621 ID (intentionally suppressed)

10-06 20:53:29.180 5872 5872 I vpnclientd: Remote IKE peer 10.20.1.1:4500 ID epdg.epc.mnc001.mcc262.pub.3gppnetwork.org

10-06 20:53:29.180 5872 5872 I vpnclientd: Initiator SPI 660cfdc3 0ff7a47c Responder SPI 92810520 15282ee2

——————————————————————————————————————————————————————-

 

How to decrypt EAP-AKA?

Let us try to understand how the keys are generated. As we discussed before, there are two phases with which the SAs are exchanged. In the first phase, the SA for the second phase is exchanged. In the second phase, the actual SAs for the following ESP packets are exchanged. We are interested in the second phase. We already have the CK and IK that we obtained by sniffing the interface between the phone and SIM. So we don’t necessarily need to decrypt it. But we need to know what happens next. Below are some excerpts from RFC 4187 about a PRNG (pseudo random number generator) which is used for obtaining the keys.

From RFC 4187:

On EAP-AKA full authentication, a Master Key (MK) is derived from the
   underlying AKA values (CK and IK keys), and the identity, as follows.

   MK = SHA1(Identity|IK|CK)

The Master Key is fed into a Pseudo-Random number Function (PRF),
   which generates separate Transient EAP Keys (TEKs) for protecting
   EAP-AKA packets, as well as a Master Session Key (MSK) for link layer
   security and an Extended Master Session Key (EMSK) for other
   purposes. 

 The "|" character denotes concatenation, and "^" denotes
   exponentiation.

   Step 1: Choose a new, secret value for the seed-key, XKEY

   Step 2: In hexadecimal notation let
       t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
       This is the initial value for H0|H1|H2|H3|H4
       in the FIPS SHS [SHA-1]

   Step 3: For j = 0 to m - 1 do
         3.1.  XSEED_j = 0 /* no optional user input */
         3.2.  For i = 0 to 1 do
               a.  XVAL = (XKEY + XSEED_j) mod 2^b (here b=160, and XKEY is MK)
               b.  w_i = G(t, XVAL) (I still need to figure out what this is :) )
               c.  XKEY = (1 + XKEY + w_i) mod 2^b
         3.3.  x_j = w_0|w_1

From the logs, we get the identity string that looks like something similar:

Remote IKE peer 109.237.187.231:4500 ID epdg.epc.mnc001.mcc262.pub.3gppnetwork.org.

We also have the CK and IK.

The next step would be to perform the algorithm and try to see if we can actually decrypt the packets and verify if the SIP packets are same as what we were able to see within the virtual interface epdg1. And, of course, this way we are able to inject packets manually to the interface.

What did we learn so far?

In the blog post, we went through a set of security aspects within the user side regarding how VoWiFi call is secured. Following are some key points to keep in mind.

• The VoWiFi (WiFi calling facility) is secured via Ipsec tunnel.
• There is a virtual interface called epdg1 on the phone that allows us to see non encrypted traffic.
• When this traffic is sent via wlan0, then this is encrypted.
• Inorder to create the IPsec tunnel, the vpnclient on the phone uses IKEv2. Within the IKEv2, the main protocol used for authentication is EAP-AKA.
• We can obtain the session keys IK and CK by sniffing the interface between the SIM and phone using Simtracer.
• The keys obtained can be used to generate the transient keys used for encrypting and authenticating the ESP packets.

VoWiFi is relatively new and less explored from a security perspective. It was fun learning about the protocol and understanding the basic security structure. I hope you enjoyed the reading. I will definitely post my learning as soon as I have some more updates.

Cheers,

Priya

References

1. White paper, Nokia, Voice over WiFi. http://resources.alcatel-lucent.com/asset/200329 (Seen on 11^th October 2016)
2. Simtracer, Osmocom. https://osmocom.org/projects/simtrace/wiki/SIMtrace (Seen on 11^th October 2016)
3. Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408. https://tools.ietf.org/html/rfc2408
4. Internet Key Exchange Protocol (IKEv2), RFC 4306. https://tools.ietf.org/html/rfc4306
5. Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), RFC 4187. https://tools.ietf.org/html/rfc4187
6. Efficient Authentication for Users Autonomy in Next Generation All-IP Networks, Christoforos Ntantogian , Christos Xenakis , Ioannis Stavrakakis .