GSM eavesdropping

[Perry E. Metzger]

On Mon, 2 Aug 2010 12:12:25 -0400 Adam Fields
<cryptography23094893 at aquick.org> wrote:
> 
> Apropos the theses thread, this article contains mention of an
> interesting security "feature":
> 
> 'Although the GSM specifications say that a phone should pop up a
> warning when it connects to a station that does not have encryption,
> SIM cards disable that setting so that alerts are not displayed'
> 
> That would be an example of a bad security tradeoff with the
> intended result of not bugging the user about something over which
> they have neither control nor recourse, but with the actual result
> of opening a significant security hole. The incentives are also all
> misaligned here. Presumably the right thing to do is refuse to
> connect to any unencrypted towers, but assuming that there are some
> legitimate ones out in the wild, the net effect is probably just
> worse service for the end user. The user has no way to tell the
> difference, which is of course the point of using encryption in the
> first place.

The GSM situation is an example of many problems at once -- bad UI
decisions, the bad decision to allow unencrypted traffic, bad crypto
algorithms even when you get crypto, susceptibility to downgrade
attacks, etc.

Looking forward, the "there should be one mode, and it should be
secure" philosophy would claim that there should be no insecure
mode for a protocol. Of course, virtually all protocols we use right
now had their origins in the days of the Crypto Wars (in which case,
we often added too many knobs) or before (in the days when people
assumed no crypto at all) and thus come in encrypted and unencrypted
varieties of all sorts.

For example, in the internet space, we have http, smtp, imap and other
protocols in both plain and ssl flavors. (IPSec was originally
intended to mitigate this by providing a common security layer for
everything, but it failed, for many reasons. Nico mentioned one that
isn't sufficiently appreciated, which was the lack of APIs to permit
binding of IPSec connections to users.)


Perry
-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com