no indication when the cellular network connection is not encrypted
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical System Image |
Confirmed
|
Wishlist
|
Bill Filler | ||
indicator-network (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned | ||
ofono (Ubuntu) |
Confirmed
|
Wishlist
|
Unassigned | ||
ubuntu-system-settings (Ubuntu) |
Confirmed
|
Medium
|
Matthew Paul Thomas |
Bug Description
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.
Changed in ubuntu-ux: | |
importance: | Undecided → Medium |
Changed in ubuntu-ux: | |
status: | New → Triaged |
Changed in ofono (Ubuntu): | |
status: | New → Opinion |
importance: | Undecided → Wishlist |
status: | Opinion → Incomplete |
no longer affects: | indicator-network |
Changed in indicator-network (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
Changed in canonical-devices-system-image: | |
assignee: | nobody → Bill Filler (bfiller) |
importance: | Undecided → Wishlist |
milestone: | none → backlog |
status: | New → Confirmed |
TS 100 920: http:// www.etsi. org/deliver/ etsi_ts/ 100900_ 100999/ 100920/ 08.00.01_ 60/ts_100920v08 0001p.pdf www.etsi. org/deliver/ etsi_gts/ 02/0207/ 05.00.00_ 60/gsmts_ 0207v050000p. pdf
GSM 02.07: http://
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? www.popsci. com/article/ technology/ mysterious- phony-cell- towers- could-be- intercepting- your-calls>
<http://
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:// googleonlinesec urity.blogspot. co.uk/2014/ 09/gradually- sunsetting- sha-1.html>)