Idea: government-grade encrypted calls without Internet connection

[Luxferre]

If you had heard about old-school crypto phones which didn't even have GPRS connectivity but managed to maintain end-to-end voice encryption that the carrier cannot tap into (of course, both conversation parties must possess such a device), you were probably wondering how they managed to do this.

Well, it's simple: data calls. Yep, long forgotten but still working CSD. This is what happens when you forget to type in ";" after "ATD[number]" command - it makes the call not in the voice mode, but in the data mode. The price of such data calls is another story, but my personal opinion is that real privacy always comes with a cost.

In the voice mode, modem firmware itself (which can be dumped, but is closed and pretty much untamperable) captures the exclusive access to the microphone and speaker. In data mode, this doesn't happen. So, we need to find a way how to do this ourselves (via /dev/ file system, just like we access the AT interface with /dev/smd8). After this, everything should be straightforward:

1. Using a pre-shared key and current time, TOTP session key is generated on both sides.

2. The caller places a data call to the target and then runs the speech through the custom GSM codec and overlaid stream ciphering with that session key.

3. The receiver does the same thing on its end, using the same session key.

So, the idea is to split the project into three phases:

1. GSMpipe utility - the utility that could expose the standard I/O pipe (probably named pipe) after dialing or answering the data call, abstracting the rest from the device-specific bits (for instance, on MediaTek devices it would be /dev/radio/pttycmd1, not /dev/smd8);

2. Cryptocodec utility - the utility for speech device capturing, GSM en/decoding and custom en/decryption;

3. Frontend to deploy and control all this from KaiOS GUI.

P.S. There might be some possibility that CLI data call tooling already exists in current KaiOS builds, we just haven't found it...Or it could be fine if we could leverage busybox minicom to some extent, but I'm not too sure about this.

[Luxferre]

So, after a bit of research of our local GSM carriers I found out that absolutely all of them removed CSD support for prepaid plans and only left its support for contract M2M plans, which kind of defeats the purpose of performing secure calls not only in terms of encryption, but also in terms of anonymity.

So, another idea is to utilize the existing voice channel to do the scrambling or cryptographic modulation on it. The main obstacle as of now is, of course, (in)ability to intercept both microphone and (headset) speaker during the call. Since this is not achievable with KaiOS userspace anyway, we'll have to resort to sound subsystem device manipulation directly.

For instance, I found out that on my Nokia 8110 4G (the one with GerdaOS flashed) these devices get opened during the call: /dev/snd/pcmC0D27c for microphone and /dev/snd/pcmC0D27p for speaker. This info can be monitored when looking into /proc/asound/card0/ directory. But there doesn't seem to be a way of accessing these devices directly. Another approach whould be to look into tinymix command output and figure out the necessary audio route.

If anyone has any info about how this voice channel can be accessed, pls share your thoughts.

[Luxferre]

A bit of info about 8110 sound interception

Here's what I managed to find out as of now regarding audio routing:

KaiOS, as well as Android, use ALSA version called TinyALSA. And beside the /proc/asound and /dev/snd filesystems, only three utilities are exposed: tinyplay (play WAV at specified device), tinycap (record WAV from specified defice) and tinymix (mixer parameter control).

The tinymix utility shows all mixing options exposed by chipset itself and a handful of other properties. Most properties are boolean but there also are enum and string values. To get/set the option, one has to refer to it by its id.

Option format is the following: [id] [type] [amount_of_parameters] [name] [current value]

Where [name], when we're talking about audio commutation properties on Qualcomm devices, always has the form "[channel_to] Mixer [channel_from]".

For instance, take a look at this line from tinymix output:

244 BOOL 1 VoiceMMode1_Tx Mixer AFE_PCM_TX_MMode1 Off

This means literally the following: boolean flag with a single parameter and id 244, that routes the AFE_PCM_TX_MMode1 channel to VoiceMMode1_Tx channel, is now off.

To change the value(s), just issue tinymix [prop_id] [prop_value(s)]. In out case, to turn this particular routing on, just issue tinymix 244 1, then we see it's on:

root@Nokia 8110 4G:/data/local/tmp # tinymix 244
VoiceMMode1_Tx Mixer AFE_PCM_TX_MMode1: On

Now, let's talk about channels of interest (for the purpose of audio traffic interception) particularly on 8110 (they may differ from chipset to chipset or even from microcode to microcode). Note that properties having "TX" or "UL" markings are related to microphone, and the ones having  "RX" or "DL" markings are related to speakers respectively.

Note: most of the below are guesses from the monitoring of live call behavior. They have yet to be verified!

1. TERT_MI2S_TX_MMode1 - local microphone input channel during the call.
2. VoiceMMode1_Tx - uplink microphone channel during the call.
3. PRI_MI2S_RX_Voice - local speaker output channel during the call.
4. VoiceMMode1 - downlink speaker channel during the call.

5. AFE_PCM_TX_MMode1 - reference to a proxy PCM device where we can grab the stream from during the call.

6. AFE_PCM_RX_Voice -  reference to a proxy PCM device where we can send the stream into during the call.

7. VOC_REC_DL - the channel to record all speaker traffic from multimedia mixers without interception. Already verified (see the thread about recording).

8. VOC_REC_UL - the channel to record all microphone traffic from multimedia mixers without interception. Already verified (see the thread about recording).

To be continued...