no indication when the cellular network connection is not encrypted

[Antti Kaijanmäki]

From TS 100 920 - V8.1.0:

3.3.3 Functional Requirements:

"""
The ME has to check if the user data confidentiality is switched on using one of the seven algorithms. In the event that
the ME detects that this is not the case, or ceases to be the case (e.g. during handover), then an indication is given to the
user.

This ciphering indicator feature may be disabled by the SIM (see GSM 11.11).

In case the SIM does not support the feature that disables the ciphering indicator, then the ciphering indicator feature in
the ME shall be enabled by default.
"""

My understanding of this is that we should at least show a warning icon and maybe explanatory text inside the i-network and maybe relevant apps like phone-app and messaging-app that the cellular communication channel is not encrypted. Without encryption anyone with sufficient equipment can eavesdrop the voice and data communication between the cell tower and users phone.

[Matthew Paul Thomas (mpt)]

TS 100 920: http://www.etsi.org/deliver/etsi_ts/100900_100999/100920/08.00.01_60/ts_100920v080001p.pdf
GSM 02.07: http://www.etsi.org/deliver/etsi_gts/02/0207/05.00.00_60/gsmts_0207v050000p.pdf

As usual, "need" in the summary indicates that the problem is under-specified. What is the threat model here? Are we trying to protect users against interceptor cell towers? Are we trying to protect against anything else?
<http://www.popsci.com/article/technology/mysterious-phony-cell-towers-could-be-intercepting-your-calls>

Assuming that interceptors are the only relevant threat:

1. What is the Type I error: About what percentage of voice calls or data connections, going through interceptors, are nevertheless encrypted? (This might be unknowable, but if it is known it would be useful.)

2. What is the Type II error: About what percentage of voice calls or data connections, going through legitimate cell towers, are unencrypted? (If the answer is depressingly high, it may be useful to compare with the gradual effort by Chrome to warn about unencrypted HTTP. <http://www.chromium.org/Home/chromium-security/marking-http-as-non-secure>)

3. Why would anyone use Signal or Telegram instead of relying on this encryption?

4. Which, if any, of the seven encryption algorithms are worthwhile? Are any of them so weak that it would be misleading to mark them as secure? (If so, we might present them as insecure, as with SHA-1 in HTTPS. <http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html>)

[Tony Espy (awe)]

Updated importance to Wishlist, as this is a new feature request.

Currently, there's no way to get any cipher information from the baseband processor using the standard RIL API.

Furthermore, this issue has been discussed extensively with respect to Android support, and it's pretty clear that Google has no intention to support this by default. Very interesting discussion here:

https://code.google.com/p/android/issues/detail?id=5353

It's also been raised on Jolla's issue tracker site, with no response either:

https://together.jolla.com/question/63141/ciphering-indicator/

[Matthew Paul Thomas (mpt)]

Tony, thanks for the links to those bug reports. Quotes from the Android bug report that address my earlier questions:

0. What is the threat model: "it's about exposing and tracking surveillance, not necessarily directly increasing security."

1. What is the Type I error: "Nation state attackers are just going to intercept traffic when it hits the carrier network. Link level encryption won't slow them down in any way." And: "All link level encryption is broken, because via SS7 you can retrieve the encryption keys and SS7 isn't authenticated. And there is no easy way to change that, because without key handover your mobile phone would in fact be a stationary phone."

2. What is the Type II error: "Carriers routinely turn off network security in cases of natural disasters or popular events such as concerts, when networks become overwhelmed. Displaying a notice in those cases only serves to confuse people."

3. Why would anyone use Signal or Telegram instead: "Android traffic routinely traverses untrusted networks, such as open wifi access points, and end to end encryption is the only solution that guarantees the integrity and confidentiality of the data."

4. Which, if any, of the seven encryption algorithms are worthwhile: "A5/1 and A5/2 are broken. There has been no published work on A5/3 or A5/4 ... Also all the active interception gear just doesn't use ciphering at all."

To summarize my understanding, then: If the cellular network connection is not encrypted, you might be being spied on ... or you might just be at a concert or in a natural disaster. And if it *is* encrypted, that does not mean that you are *not* being spied on, either. So even if we limited our goal just to notifying you of surveillance, we couldn't be confident either way.

So, while I would be delighted if we could provide some just-in-time indication -- or even bad-TLS-style blocking -- for insecure connections, I don't think we can with the networks currently in use. If this changes five or ten years from now, such that legitimate connections always use well-researched link-level security, maybe that can be revisited. Or if there is some specific situation where we could be confident that you were being spied on, that might be presentable too.

In the meantime, though, it's reasonable to show the encryption type in System Settings somewhere, so I'm moving this report there.