GSM eavesdropping

[Jerry Leichter]

On Aug 2, 2010, at 1:25 PM, Nicolas Williams wrote:

> On Mon, Aug 02, 2010 at 12:32:23PM -0400, Perry E. Metzger wrote:
>> 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. [...]
>
> Well, to be fair, there is much content to be accessed insecurely for
> the simple reason that there may be no way to authenticate a peer.   
> For
> much of the web this is the case.
>
> For example, if I'm listening to music on an Internet radio station, I
> could care less about authenticating the server (unless it needs to
> authenticate me, in which case I'll want mutual authentication).  Same
> thing if I'm reading a randmon blog entry or a random news story.
>
> By analogy to the off-line world, we authenticate business partners,  
> but
> in asymmetric broadcast-type media, authentication is very weak and  
> only
> of the broadcaster to the receiver.  If we authenticate broadcasters  
> at
> all, we do it by such weak methods as recognizing logos, broadcast
> frequencies, etcetera.
And, indeed, there are movie cons - and many episodes of Mission:  
Impossible - that turn on the ability to plant false information by  
convincingly impersonating such a medium.

> In other words, context matters.  And the user has to understand the
> context.  This also means that the UI matters.  I hate to demand any
> expertise of the user, but it seems unavoidable.  By analogy to the
> off-line world, con-jobs happen, and they happen because victims are
> naive, inexperienced, ill, senile, etcetera.  We can no more protect  
> the
> innocent at all times online as off, not without their help.
It's not as if identification solves all problems anyway.  A  
completely secure link to use when sending your money to Bernie Madoff  
still leaves you with nothing.

> "There should be one mode, and it should be secure" is a good idea,  
> but
> it's not as universally applicable as one might like.  *sadness*
I think it's an oversimplification.  Cryptography can, in effect,  
guarantee the syntax:  You receive the right bytes from a source whose  
identify matches some purely internal description, and no one else  
could have seen those bytes.  But any real-world binding - of those  
bytes to semantics, of that identity to some actual actor, of "no one  
else" to trust that the sender didn't send it to Wikileaks because he  
doesn't actually trust you ... all of this is entirely outside the  
cryptographic envelope.  There's no escaping the need to understand  
the semantics, not just the syntax - as valuable as the syntax is.

> SMTP and IMAP, then, definitely require secure modes.  So does LDAP,
> even though it's used to access -mostly- public data, and so is more
> like broadcast media.  NNTP must not even bother with a secure mode ;)
Are you sure?  How about maintaining the privacy of the groups to  
which a user subscribes?  (Granted, whoever you get your feed from  
obviously knows - but why should anyone in a position to see the  
message stream?)

> Another problem you might add to the list is tunneling.  Firewalls  
> have
> led us to build every app as a web or HTTP application, and to tunnel
> all the others over port 80.
Indeed.  Consider the all-too-well-named SOAP, which lets arbitrary  
commands and data slip right through your firewall.  If you step back  
a moment and look at the whole notion of using firewalls to control  
port numbers, you see just what an absurd corner we've gotten  
ourselves into.  We have an OS that can run multiple independent  
programs at different port numbers, and is actually very competent at  
keeping them isolated from each other, relying at base on hardware  
protection.  We've replaced it with a browser which nominally allows  
only one kind of connection, but then runs multiple independent  
programs at different HTTP addresses - and, with no hardware  
protection to help, has proved quite incompetent at keeping them  
isolated from each other.  This is progress?

>  This makes the relevant context harder, if
> not impossible to resolve without the user's help.
...but it opens the door to generations of improved DPI and other  
technologies that try to do it for you.  With limited success at the  
original mission, but all kinds of interesting privacy-invading and  
censorship-enabling new missions discovered along the way.

> HTTP, sadly, needs an insecure mode.
Hmm.  I'm not sure exactly sure how that follows.

                                                         -- Jerry

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