Editing P2p mobile carriers (section)

= 10. Technical requirements for a solution =

The last problem to solve is undoubtedly the hardest: the sheer technical difficulty of creating a program that implements such a heavily modified GSM protocol.

I have already proposed two such protocols. The first protocol details authentication with a MsC via a sellers challenge response, and the second protocol details a multi-party computation scheme that ensures the two parties cannot learn anything they shouldn’t.

The problem is that both protocols depend critically on being able to access protected portions of the SIM card, as well as being able to send and receive custom messages to the base station (BS) – and all modern phones have been engineered to prevent this! That’s quite the dilemma.

To make things a little easier, I’ll start by assuming that our program will be running on a rooted android device. This shouldn’t be too difficult as there are already lots of one-click methods for rooting android phones. That gets us full access to a phone- but we still need a way to hook API methods in the device. There is a really cool project called “Xposed” that allows custom module hooks for Android API calls [xposed].

<span id="a-look-at-the-android-code"></span>
== 10.1. A look at the Android code ==

[/platform/hardware/ril/+/refs/heads/master/rild/rild.c]

<syntaxhighlight lang="cpp">//...
    funcs = rilInit(&s_rilEnv, argc, rilArgv);
    RLOGD("RIL_Init rilInit completed");
    RIL_register(funcs);
//...</syntaxhighlight>
Everything starts in the rild.cpp file (RILD = radio interface layer daemon.) This code starts a service designed to handle response messages from the phones radio. The fragment above registers functions for handling responses for the different types of messages.

[/platform/hardware/ril/+/refs/heads/master/libril/ril_commands.h]

<syntaxhighlight lang="cpp">    {RIL_REQUEST_GET_IMSI, radio::getIMSIForAppResponse},
    {RIL_REQUEST_ISIM_AUTHENTICATION, radio::requestIsimAuthenticationResponse},
    {RIL_REQUEST_SIM_AUTHENTICATION, radio::requestIccSimAuthenticationResponse},
</syntaxhighlight>
The RILD allows vendors to write their own libraries for responding to various radio messages [rild]. The required functions are defined in /platform/hardware/ril/+/refs/heads/master/include/telephony/ril.h.

There is also a reference implementation in /platform/hardware/ril/+/refs/heads/master/reference-ril/reference-ril.c. From here on assume that’s what I’m talking about.

[/platform/hardware/ril/+/refs/heads/master/reference-ril/reference-ril.c]

<syntaxhighlight lang="cpp">        case RIL_REQUEST_GET_IMSI:
            p_response = NULL;
            err = at_send_command_numeric("AT+CIMI", &p_response);
            if (err < 0 || p_response->success == 0) {
                RIL_onRequestComplete(t, RIL_E_GENERIC_FAILURE, NULL, 0);
            } else {
                RIL_onRequestComplete(t, RIL_E_SUCCESS,
                    p_response->p_intermediates->line, sizeof(char *));
            }
            at_response_free(p_response);
            break;</syntaxhighlight>
The MsC may send a message to request the phones T/IMSI number. To access the IMSI the phone uses AT commands to talk to the baseband processor - secret key extract is possible here [baseband-ki-extraction].

The baseband processor runs its own OS that interacts with the phones radio, GPS, and WIFI. It controls access to parts of the SIM. The SIM also has its own operating system that supports applications that can interact with the baseband, and hence the network [java-card][sim-os].

[/platform/frameworks/opt/telephony/+/refs/heads/master/src/java/com/android/internal/telephony/PhoneSubInfoController.java]

<syntaxhighlight lang="java">
 public String getIccSimChallengeResponse(int subId, int appType, int authType, String data)
            throws RemoteException {
        CallPhoneMethodHelper<String> toExecute = (phone)-> {
            UiccCard uiccCard = phone.getUiccCard();
            if (uiccCard == null) {
                loge("getIccSimChallengeResponse() UiccCard is null");
                return null;
            }
            UiccCardApplication uiccApp = uiccCard.getApplicationByType(appType);
            if (uiccApp == null) {
                loge("getIccSimChallengeResponse() no app with specified type -- " + appType);
                return null;
            } else {
                loge("getIccSimChallengeResponse() found app " + uiccApp.getAid()
                        + " specified type -- " + appType);
            }
            if (authType != UiccCardApplication.AUTH_CONTEXT_EAP_SIM
                    && authType != UiccCardApplication.AUTH_CONTEXT_EAP_AKA) {
                loge("getIccSimChallengeResponse() unsupported authType: " + authType);
                return null;
            }
            return uiccApp.getIccRecords().getIccSimChallengeResponse(authType, data);
        };
        return callPhoneMethodWithPermissionCheck(
                subId, null, "getIccSimChallengeResponse", toExecute,
                (aContext, aSubId, aCallingPackage, aMessage)-> {
                    enforcePrivilegedPermissionOrCarrierPrivilege(aSubId, aMessage);
                    return true;
                });
    }
</syntaxhighlight>
Heading back towards the official Android API functions you start to see the relevant functions for implementing the challenge-response authentication functions in various phone networks. This code makes a request to RILD -&gt; baseband -&gt; SIM card to retrieve a response to a challenge.

[/platform/frameworks/opt/telephony/+/refs/heads/master/src/java/com/android/internal/telephony/uicc/IccRecords.java]

<syntaxhighlight lang="java">
    public String getIccSimChallengeResponse(int authContext, String data) {
        if (DBG) log("getIccSimChallengeResponse:");
        try {
            synchronized(mLock) {
                CommandsInterface ci = mCi;
                UiccCardApplication parentApp = mParentApp;
                if (ci != null && parentApp != null) {
                    ci.requestIccSimAuthentication(authContext, data,
                            parentApp.getAid(),
                            obtainMessage(EVENT_AKA_AUTHENTICATE_DONE));
                    try {
                        mLock.wait();
                    } catch (InterruptedException e) {
                        loge("getIccSimChallengeResponse: Fail, interrupted"
                                + " while trying to request Icc Sim Auth");
                        return null;
                    }
                } else {
                    loge( "getIccSimChallengeResponse: "
                            + "Fail, ci or parentApp is null");
                    return null;
                }
            }
        } catch(Exception e) {
            loge( "getIccSimChallengeResponse: "
                    + "Fail while trying to request Icc Sim Auth");
            return null;
        }
        if (auth_rsp == null) {
            loge("getIccSimChallengeResponse: No authentication response");
            return null;
        }
        if (DBG) log("getIccSimChallengeResponse: return auth_rsp");
        return android.util.Base64.encodeToString(auth_rsp.payload, android.util.Base64.NO_WRAP);
    }</syntaxhighlight>
Remember the RILD mentioned earlier? Here is some client code that talks to that server. It will send a request to the radio interface layer daemon to request a response to an authentication challenge message.

[/platform/frameworks/opt/telephony/+/refs/heads/master/src/java/com/android/internal/telephony/RIL.java]

<syntaxhighlight lang="java">    @Override
    public void requestIccSimAuthentication(int authContext, String data, String aid,
                                            Message result) {
        IRadio radioProxy = getRadioProxy(result);
        if (radioProxy != null) {
            RILRequest rr = obtainRequest(RIL_REQUEST_SIM_AUTHENTICATION, result,
                    mRILDefaultWorkSource);
            // Do not log function args for privacy
            if (RILJ_LOGD) riljLog(rr.serialString() + "> " + requestToString(rr.mRequest));
            try {
                radioProxy.requestIccSimAuthentication(rr.mSerial,
                        authContext,
                        convertNullToEmptyString(data),
                        convertNullToEmptyString(aid));
            } catch (RemoteException | RuntimeException e) {
                handleRadioProxyExceptionForRR(rr, "requestIccSimAuthentication", e);
            }
        }
    }</syntaxhighlight>
Here is the code in the client for sending requests to the RILD. It’s not very interesting- but the handler for that code is.

[/platform/hardware/ril/+/refs/heads/master/libril/ril_service.cpp]

<syntaxhighlight lang="cpp">
Return<void> RadioImpl::requestIccSimAuthentication(int32_t serial, int32_t authContext,
        const hidl_string& authData, const hidl_string& aid) {
#if VDBG
    RLOGD("requestIccSimAuthentication: serial %d", serial);
#endif
   **RequestInfo *pRI = android::addRequestToList(serial, mSlotId, RIL_REQUEST_SIM_AUTHENTICATION);**
    if (pRI == NULL) {
        return Void();
    }
    RIL_SimAuthentication pf = {};
    pf.authContext = authContext;
    if (!copyHidlStringToRil(&pf.authData, authData, pRI)) {
        return Void();
    }
    if (!copyHidlStringToRil(&pf.aid, aid, pRI)) {
        memsetAndFreeStrings(1, pf.authData);
        return Void();
    }
    **CALL_ONREQUEST(pRI->pCI->requestNumber, &pf, sizeof(pf), pRI, mSlotId);**
    memsetAndFreeStrings(2, pf.authData, pf.aid);
    return Void();
</syntaxhighlight>
I’m afraid this is where the trail goes cold. The function CALL_ONREQUEST is a macro that replaces the function name with a call to a vendor-specific library. The vendor thus must supply the function that implements the code to talk to the baseband. Which is fitting really, because they’re the ones who have to manufacture the chip.

So now we know some details about the relevant code in Android for writing hooks. We can use this information to pretend to have a third-parties SIM card by intercepting messages from the radio (more research is required here.) But to implement the full secret contracts there also needs to be a way to extract SIM secret keys, as well as implement the relevant authentication routines for a carrier network.

Here are the options.

<span id="full-usim-secrets-authentication-routines-or-see-backup-plans"></span>
== 10.2. Full U/SIM secrets &amp; authentication routines (OR see backup plans) ==

Every android phone contains an application processor and a special processor called the “baseband processor.” The application processor is what runs the Android operating system and developer applications. Whereas the baseband processor is for implementing the GSM protocol suite / sending messages back to the radio.
[[File:P2p mobile carriers 4.png|thumb]]

What makes the baseband modem special is that it has full access to the SIM card, meaning that it can read and write anything via a restricted interface. In older android phones this can be exploited to run arbitrary commands on the SIM card by issuing AT commands to the baseband modem [baseband-ki-extraction].

A proof-of-concept on an older Samsung Galaxy will work. Other ideas include using a known vulnerable GSM USB stick.

<span id="ideally-full-knowledge-of-authentication-routines"></span>
=== 10.2.1. … Ideally full knowledge of authentication routines ===

For authentication with the MsC, the GSMA have specified many authentication procedures and key derivation functions that can be used depending on the network (2G, 3G, and so on.)

Unfortunately, while ciphering functions have been standardised [ciphering], the functions to use for authentication '''are only a suggestion''' [closed-auth][carrier-milenage][op-specific]. The mobile system is flexible enough to allow each operator to use a different set of algorithms, and some of the standard functions allow an operator to “customise” the algorithm with an operator-specific key (you can think of this like a salt) [op-key].

If every operator were to use a proprietary group of authentication algorithms its not going to be practical to study them. To be determined. The bigger problem is operator-specific keys. How hard are they to extract from a SIM? It might be practical to reverse a few operator keys from the most popular carriers if they only change every few months, but not on a per-SIM basis. And that’s assuming that the chips can be reversed.

Numerous attacks have been found in UUIC U/SIM cards [java-card-attacks], but this is a very specialised area of research [java-card-reverse][oscilloscope].

<span id="plan-b-authentication-oracles"></span>
== 10.3. Plan B) Authentication oracles ==

If Option A fails an oracle can be used to compute responses and cipher keys. An oracle would accept a sellers SIM secret and return an authentication response to a buyer.

What’s interesting about this is the oracle wouldn’t need to know enough to authenticate because they would lack a valid IMSI or T-IMSI. Even if the oracle and the buyer were the same person, a T-IMSI would only allow for a one-time use (not an ideal scenario, but its better than nothing.)
[[File:P2p mobile carriers 5.png|thumb]]

The benefit of this scheme is it allows the U/SIM to be used without understanding the full details of the internal algorithms. But critically, '''it breaks the moment these algorithms vary between U/SIM cards.''' If there are no other alternatives we are forced to move on to Plan C.

<span id="plan-c-public-key-cryptography"></span>
== 10.3. Plan C) Public-key cryptography ==

Option C is open if the buyer is calling someone within the same network. In this case, the buyer can just use a recipients public key to encrypt calls. Signal and WhatsApp are all compatible with this method.

<span id="plan-d-tls-options"></span>
== 10.4. Plan D) TLS options ==

<span id="g-eap-tls"></span>
=== 10.4.1. 5G EAP-TLS ===

While both standard authentication protocols in 5G (5G AKA and 5G EAP’) transmit challenges without encryption, there is an optional extension called “5G EAP-TLS” which does not [eap-tls][5g-security].

The caveat is that 5G support is still catching up to other technologies, and the EAP-TLS protocol is optional to support [5g-optional-tls]. But there is some hope because EAP-TLS is extremely useful for IoT devices because it provides a way to validate certificates.

<span id="g-ng-masa"></span>
== 10.4.2. 5G NG-MASA ==

A provisional patent mentions an authentication protocol for 5G called “MASA” [5g-masa]. Similar to EAP-TLS, MASA uses public key cryptography and might be something that is supported on some MsCs.

<span id="higher-level-protocol-encryption"></span>
== 10.4.3. Higher level protocol encryption ==

If a secure channel cannot be established during authentication, then there is always the option of enabling encryption at a higher layer in the protocol stack. To understand where this can happen its worthwhile to go over calling in the various networks.

* 2G / GSM uses a circuit-switched network for calls.
* 3G / UMTS switches between 2G for calls and GPRS for data services. GPRS is a packet-switched network that provides IP services for GSM.
* 4G / LTE uses VoLTE (voice over LTE) for calls and falls back to 3G if VoLTE is too busy. 4G is a packet-switched network, so everything is IP-based.
* 5G is still being standardised, and there are a number of options that might be used for calling. For the moment, VoLTE will be compatible. Needless to say, 5G is a packet-switched network.

To start with the obvious: GPRS [voip-gprs], 4G, and 5G can support any regular Internet VOIP application, and end-to-end encryption will prevent packet sniffing between the mobile and the MsC.

Then there is VoLTE. With VoLTE, IPSec can be optionally enabled [4g-link-security] to setup an encrypted tunnel for voice traffic [volte-ipsec]. The IPSec standard uses a protocol called IKE (Internet Key Exchange) for authentication and key exchange [ike-5g].

The way keys are exchanged in IKE is with the Diffie-Hellman-Merkle key exchange algorithm– and guess what that is? Public key cryptography. So even if the owner is sniffing radio packets and sees this exchange they won’t be able to decrypt anything.

<span id="plan-e-a-less-naive-protocol-with-location-checks"></span>
== 10.5. Plan E) A less naive protocol with location checks ==

The most concerning part about the naive protocol is the potential for the seller to monitor calls made by the buyer. All of the schemes so far have aimed at avoiding this possibility, noting that the original protocol allows a seller to listen in on calls if they’re within radio range.

Most people aren’t going to use a service like this. So if there’s absolutely no other options, Plan E is to somehow ensure there’s enough physical distance between a buyer and seller prior to making a call. Assuming a worse case scenario where a seller knows the approximate location of a buyer '''after''' they connect, it would require a huge amount of luck to be within range of a caller during that time.

The United States has over 80,000 cell phone towers and a buyer can use any one of them [tower-count]. Knowing which one to use before a buyer makes a call would enable an attacker to sniff traffic, but there is a higher chance of being hit by a car and dying than correctly guessing a tower. Obviously if an attacker is working with a group they can monitor more towers and increase their odds, but this also raises the cost of an attack.

There is a way to improve the protocol using proof-of-location and secret contracts to solve the millionaires problem. This would help keep out some people and might be a good idea considering there is likely to be a heavy bias around base stations in densely populated areas.

<span id="proof-of-location"></span>
=== 10.5.1. Proof-of-location ===

A novel startup called Foam Protocol have been working to create a network of radio devices they call “beacons” to allow things to be located in real time [foam-protocol]. Currently this isn’t possible with GPS, as GPS relies on timing delays to determine location, and these are easily spoofed.

Foam Protocol gets around these issues by creating real-time reference points from radio beacons and using them to attest to an objects location. Whats-more, because an object cannot disappear and reappear (duh), an objects path over time also serves as an audit log that automatically collects more signatures of radio beacons over time.

Proof-of-location is useful because it can be used as a safe-guard: if a proof-of-location is generated by both sides and fed into a secret contract the buyer and seller can be sure they’re at least an hours drive apart from each other. The use of random numbers in these proofs forces the buyer and seller to have physical control over at least one valid location.

If a seller manages to somehow fall in the same area as a buyer they are able to be avoid. What this stops is opportunistic attackers that would otherwise be motivated to listen in on calls if it were easy to do. A seller can still posses a valid location and be somewhere else, of course, but that means putting in more effort and getting lucky.

This precaution does not stop attacks, it simply increases the cost for an attacker and makes it (a little) harder to do so. It would be better to use other options than this, or even to sell resources to buy access to a more secure option (e.g. data access with VOIP credit.)

<span id="carriers-banning-accounts"></span>