Create the very raw base API

[SecUpwN]

Good evening, @PrivacyCollective and welcome to all contributors!

Ever since you've been posting in the Android Issue 5353, I've been following you. Judging from our private chat, you have eager plans to create something that will hopefully be forked and used by @Google some day. Having monitored your repository for more than a week without any progress now, I feel like this project needs a small "kick in the ass" to start off! :smiling_imp: I really want this to happen, especially because it would very much improve Android overall and especially our Android IMSI-Catcher Detector. Hence, I feel honored opening this very first "Issue" on your repository to launch this whole thing and encourage people contributing to it. What I found in the process, was also this interesting blog post.

I know you've been sending multiple E-Mails to Nick from the Android Security Team, who has stated that he wants to help crafting such an API and merge it into the Android Open Source Project. Important: Android on GitHub. Since you obviously have not received any message back from him, I either assume he has been ignoring your E-Mails, simply finds no time to respond, or may need another hint to your repository. And that is where I used my search-foo to digg him up here. I found this pull request revealing that his real name is Nick Kralevich and that he moves under the nick @piskor.

@piskor, we all know that this project will be extremely hard to accomplish, especially since most of the data needed is closed source. But personally speaking, I see the potential and willingness of the @PrivacyCollective to make this happen - and this in itself makes me thrilled to help this project. Would you please point us to some resources on how to cleanly start off this API so that merging it into AOSP will be as hassle-free as possible, should this project ever succeed? From the top of my head:

• Which license shall the whole thing have?
• Which specific API guides to follow?
• Any other important requirements?
• Any documents you can provide to us?

As soon as the very raw base API and some sort of development roadmap has been published on this repository, I am sure more developers will join in. Let's hack to improve Android! Never give up on it!

[fengtimozz]

@SecUpwN Great points, I'm hoping to get answers to some of these myself. Haven't heard back from @piskor in a little bit, but as I mentioned though theirs been a holiday in the states for the last week or so.

Still hunting down the Cipher information as well. I've now reached out to 4 members of the Google Dev team as well as some industry infosec experts. Going to leave this issue open until I can get some answers to these questions.

[SecUpwN]

Any news from the people you've written to? I'm sure one of the best people you can have for development on this project is @scintill. Judging from what he said and from our internal chatrooms, he can tell you many things and possibly even how to best create the very raw base API to start off with.

[scintill]

At the moment, I don't really know more than you about how to actually implement it, but I will propose a rough API for apps to work with it. Basically, add a method to query the current cipher to TelephonyManager, and do a broadcast Intent whenever the active cipher changes, which interested apps can listen for.

class TelephonyManager {
    // Send this intent when cipher changes. Maybe on boot/first radio connect too?
    // Put Cipher enum into extras, or just have apps query TelephonyManager when they receive the intent?
    // There might be known security/data integrity concerns about broadcasting with extras... look into that.
    public static final String ACTION_CIPHER_STATE_CHANGED =
            "android.intent.action.PHONE_CIPHER_STATE";

    public enum Cipher {
        Unsupported, // baseband doesn't support reporting the cipher. Better name?
        Unknown, // the radio is off, no current cell connection, or for some other reason the baseband is not reporting right now (but it does support it)
        None, // A5/0, no cipher (or similar for other network types)
        A51, // A5/1, GSM "strong" cipher
        A52, // A5/2, GSM "export/weak" cipher
        A53, // A5/3, GSM newer cipher (KASUMI)
        A54, // A5/4, like A5/3 but [The only essential change is the change of external key length input from 64 bits to 128 bits.](http://www.in2eps.com/3g55/tk-3gpp-55-226.html#e-3)
        GEA3, //
        GEA4, // GPRS variants - is it important to distinguish?
        Other, // a known, non-null cipher that is not named here (ideally, all will be listed, but I don't want to have to fall back on one of the other generic types if lower-level code sees something it can't match up here)
    };

    public Cipher getCipher(); // getCurrentCipher(), getNetworkCipher(), etc.? getCipher() feels too generic
}

TODO:

• Multi-sim? I think AOSP doesn't support that, but it may have changed as of Lollipop.
• Multi-cell? I need to read up on specs to see if there is any meaningful information the API could offer about what ciphers other cells support, or even what other ciphers the current cell supports.
• Should apps require permissions to see this?
• Other ciphers I'm missing? I found references to seven GSM ciphers, but I don't know if they are all specified and implemented, or if there are just 7 slots and only 4 used right now.
• Add other network types' ciphers too, but I think the initial implementation will be just GSM and its successors.
• Throw in cipher indicator bit from the SIM while we're at it? (I can actually implement this now, I think.) I'm not sure of a good name for it. doesNetworkOperatorWantToHideCipher() is the snarky but accurate version. :P I'd see this as only being informative to the user ("OK, so my operator is not committed to encryption. If I care, time to find a new one."), and wouldn't want it affecting the behavior of Android or apps.

[SecUpwN]

Thanks for chiming in, @scintill! As for doesNetworkOperatorWantToHideCipher(): Personally I like this naming, but we should craft everything in a way that a hassle-free merge into AOSP is possible when this API is finished. @E3V3A, here is something interesting I just found: The A5/3 Call Encryption Library .

[smarek]

Throw in cipher indicator bit from the SIM, I'm just curious, do we need this bit to be of specific value if we want to provide these kind of information or not? Does the TelephonyManager know the encryption status and used cipher if the SIM has this bit set (does it have to be enabled or disabled) ?

[scintill]

@smarek As far as I know, the Android layer (at least in standard builds) does not know the encryption status, and doesn't pay attention to this bit on the SIM (although it does load the Administrative Data file which contains the bit)

Here is a post with some information: http://www.mirider.com/weblog/2010/08/03/ It seems if the bit is set (value="1"), then encryption status would be displayed. As I've said here, the phone doesn't really have to honor this bit, so I think Android shouldn't. But maybe providing the value is useful.

Also, as for implementation, SnoopSnitch can see the cipher in use on Qualcomm devices. It feels a bit heavyweight (sniffing packets from /dev/diag), so I'm looking for an OEM hook or QMI if possible, but am thinking about using their sniff-and-parse solution for an initial implementation. I would probably have it running inside rild, and propagate cipher updates up to the Java side with an "unsolicited" RIL command.

[E3V3A]

Just a small note. As scintill said the SIM CI bit isn't honored in AOS, but if your current network want's to use A5 encryption, then this SIM bit has to be enabled, or it will be downgraded to A5/0 (none).

[SecUpwN]

@PrivacyCollective, please transfer ownership to me or someone else if you don't want to run this project due to it's difficulty. But letting it die away, ignoring pull requests and talks, is no solution! Thanks.

[smarek]

Heads up group, could you please at least provide Pull-Request against CyanogenMod Telephony package? https://github.com/CyanogenMod/android_packages_services_Telephony That would be a quite good start to test this idea with community support in my humble opinion.

[scintill]

@smarek I would like to do something like that eventually. Right now we have no backend to actually provide this data, so it would not be very useful of a test. I haven't been working on it the last few months, but lately I've been getting into it again, so maybe we will have something soon-ish.