Re: GSM eavesdropping

2010-08-04 Thread Jerry Leichter

On Aug 2, 2010, at 4:19 PM, Paul Wouters wrote:
...Of course, TLS hasn't been successful in the sense that we care  
about

most.  TLS has had no impact on how users authenticate (we still send
usernames and passwords) to servers, and the way TLS authenticates
servers to users turns out to be very weak (because of the plethora  
of

CAs, and because transitive trust isn't all that strong).


Let's first focus on foiling the grand scale of things by protecting
against passive attacks of large scale monitoring. Then let's worry
about protecting against active targetted attacks
It's worth pointing out that you're here making a value judgement -  
and, in effect, a political argument.  Large scale monitoring is  
mainly, if not entirely, something governments do.  It's unlikely to  
be cost-effective for the commercial attackers we see today.  Active,  
targeted attacks, on the other hand, seem to be the purview of many  
sophisticated attackers today - both governmental and non-governmental.


Cryptographic theory can help you decide which of these classes of  
attackers you should be more concerned about.


BTW, economics is everywhere.  Suppose you had a cryptographic  
technique that was quick and easy to apply, but also cheap to break -  
say, $1 per message.  Pretty useless, right?  But now imagine that  
every message is encrypted using this poor technique.  No individual  
message, once known through external signals to have value greater  
than $1, is safe - but  the aggregate of billions of messages being  
transfered every day is safe against any plausible attacker.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-03 Thread Paul Wouters

On Mon, 2 Aug 2010, Nicolas Williams wrote:


If that was a major issue, then SSL would have been much more successful
then it has been.


How should we measure success?


The default mode for any internet communication is encrypted


By that measure TLS has been so much more successful than IPsec as to
prove the point.


I never claimed IPsec was more successfulIt was not.


Of course, TLS hasn't been successful in the sense that we care about
most.  TLS has had no impact on how users authenticate (we still send
usernames and passwords) to servers, and the way TLS authenticates
servers to users turns out to be very weak (because of the plethora of
CAs, and because transitive trust isn't all that strong).


Let's first focus on foiling the grand scale of things by protecting
against passive attacks of large scale monitoring. Then let's worry
about protecting against active targetted attacks.


But note that the one bit you're talking about is necessarily a part of
a resolver API, thus proving my point :)


Yes, but in some the API is pretty much done. If you trust your (local)
resolver, the one bit is the only thing you need to check. You let the
resolver do most of the bootstrap crypto. One you have that, your app
can rip out most of the X.509 nonsense and use the public key obtained
from DNS for its further crypto needs.


...but we grow technologies organically, therefore we'll never have a
situation where the necessary infrastructure gets deployed in a secure
mode from the get-go.  This necessarily means that applications need
APIs by which to cause and/or determine whether secure modes are in
effect.


But by now, upgrades happen more automatic and more quickly. Adding something
new to DNS won't take 10 years to get deployed. We've come a long way. It's
time to reap the benefits from our new infrastructure.

Paul

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-03 Thread Nicolas Williams
On Mon, Aug 02, 2010 at 04:19:38PM -0400, Paul Wouters wrote:
 On Mon, 2 Aug 2010, Nicolas Williams wrote:
 How should we measure success?
 
 The default mode for any internet communication is encrypted

That's... extreme.  There are many things that will not be encrypted,
starting with the DNS itself, and also most public contents (because
their purveyors won't want to pay for the crypto; sad but true).

 By that measure TLS has been so much more successful than IPsec as to
 prove the point.
 
 I never claimed IPsec was more successfulIt was not.

No, but you claimed that APIs weren't a major issue.  I believe they are.

 But note that the one bit you're talking about is necessarily a part of
 a resolver API, thus proving my point :)
 
 Yes, but in some the API is pretty much done. If you trust your (local)
 resolver, the one bit is the only thing you need to check. You let the
 resolver do most of the bootstrap crypto. One you have that, your app
 can rip out most of the X.509 nonsense and use the public key obtained
 from DNS for its further crypto needs.

You missed the point.  The point was: do not design security solutions
without designing their interfaces.

IPsec has no user-/sysadmin-/developer-friendly interfaces - IPsec is
not used.  DNS has interfaces - when DNSSEC comes along we can extend
those intefaces.

Note that IPsec could have had trivial APIs -- trivial by comparison to
the IPsec configuration interfaces that operating systems typically
have.  For example, there's a proposal in the IETF apps area for an API
that creates connections to named servers, hiding all the details of
name resolution, IPv4/v6/v4-mapped-v6 addressing.  Such an API could
trivially have a bit by which the app can request cryptographic
protection (via IPsec, TLS, whatever can be negotiated).  Optional
complexity could be added to deal with subtleties of the secure
transport (e.g., what cipher suites do you want, if not the default).
But back in the day APIs were seen as not really in scope, so IPsec
never got them, so IPsec has been underused (and rightly so).

 ...but we grow technologies organically, therefore we'll never have a
 situation where the necessary infrastructure gets deployed in a secure
 mode from the get-go.  This necessarily means that applications need
 APIs by which to cause and/or determine whether secure modes are in
 effect.
 
 But by now, upgrades happen more automatic and more quickly. Adding something
 new to DNS won't take 10 years to get deployed. We've come a long way. It's
 time to reap the benefits from our new infrastructure.

No objection there.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-03 Thread Perry E. Metzger
On Mon, 2 Aug 2010 16:19:38 -0400 (EDT) Paul Wouters
p...@xelerance.com wrote:
 [Speaking here about DNSSEC...]
 Yes, but in some the API is pretty much done. If you trust your
 (local) resolver, the one bit is the only thing you need to check.
 You let the resolver do most of the bootstrap crypto. One you have
 that, your app can rip out most of the X.509 nonsense and use the
 public key obtained from DNS for its further crypto needs.

I would like to note that this is not sufficient for the sort of
security I've been talking about.

If, for example, users are still authenticating to web sites by typing
in passwords over an encrypted channel, DNSSEC based keys don't
help. The user still has to actively make sure that they're not giving
their key away to the wrong web site.

You still need to re-engineer the system so that the user cannot
give away their credentials without serious effort. Simply changing
where the opaque third party certified key comes from doesn't help.

What DNSSEC really gives you is the ability to trust the replies the
DNS gives you -- to trust that a DNS label and IP address really are
bound together. It doesn't change the fact that the current user
authentication models are broken.

  ...but we grow technologies organically, therefore we'll never
  have a situation where the necessary infrastructure gets deployed
  in a secure mode from the get-go.  This necessarily means that
  applications need APIs by which to cause and/or determine whether
  secure modes are in effect.
 
 But by now, upgrades happen more automatic and more quickly. Adding
 something new to DNS won't take 10 years to get deployed. We've
 come a long way. It's time to reap the benefits from our new
 infrastructure.

I disagree that we can deploy new systems quickly. See, for example,
the large fraction of IE6 users in the world. Indeed, I suspect it
will be another 10 years before over 95% of machines are even paying
attention to DNSSEC.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-03 Thread 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 

Re: GSM eavesdropping

2010-08-03 Thread Eugen Leitl
On Mon, Aug 02, 2010 at 03:46:24PM -0500, Nicolas Williams wrote:

  The default mode for any internet communication is encrypted
 
 That's... extreme.  There are many things that will not be encrypted,

Extreme? I don't see why my ISP should be able to inspect and monetize
my data stream.

 starting with the DNS itself, and also most public contents (because

Encryption is cheap enough (especially if you cache keys from
previous sessions). Why not encrypt everything?

 their purveyors won't want to pay for the crypto; sad but true).

-- 
Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-03 Thread Perry E. Metzger
On Tue, 3 Aug 2010 17:49:00 +0200 Eugen Leitl eu...@leitl.org wrote:
 Encryption is cheap enough (especially if you cache keys from
 previous sessions). Why not encrypt everything?

I'm not sure it is actually cheap enough in all cases. Imagine the
state explosion problem that DNS root servers would face, for
example, in providing pairwise crytpographic sessions for all
queries, especially in a situation where for the most part one only
wants to get a response that is authenticated but which is not per se
secret.

Also, as a practical matter, we don't really have protocol
infrastructure for encrypting absolutely everything at this point.
There is, for example, no protocol by which anonymous DNS queries
could be easily encrypted.

-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


GSM eavesdropping

2010-08-02 Thread Bill Squier
...In his presentation at the Black Hat Conference, German GSM expert Karsten 
Nohl presented a tool he calls Kraken, which he claims can crack the A5/1 
encryption used for cell phone calls within seconds.

http://www.h-online.com/security/news/item/Quickly-decrypting-cell-phone-calls-1048850.html

-wps
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread Perry E. Metzger
On Mon, 2 Aug 2010 11:02:54 -0400 Bill Squier g...@old-ones.com
wrote:
 ...In his presentation at the Black Hat Conference, German GSM
 expert Karsten Nohl presented a tool he calls Kraken, which he
 claims can crack the A5/1 encryption used for cell phone calls
 within seconds.

 http://www.h-online.com/security/news/item/Quickly-decrypting-cell-phone-calls-1048850.html

This is a really important development. I'll quote a bit more of the
article so people can understand why:

   In his presentation at the Black Hat Conference, German GSM expert
   Karsten Nohl presented a tool he calls Kraken, which he claims can
   crack the A5/1 encryption used for cell phone calls within
   seconds. But first, you have to record the GSM call with a GSM
   catcher, which you can build yourself based on a Universal Software
   Programmable Radio (USRP), which costs just under $1500, and the
   open source GNURadio software.

   To crack the key, Kraken uses rainbow tables, which Nohl calculated
   with ATI graphics processors (GPUs). During a live demonstration,
   the tool cracked the key for a recorded phone call within about 30
   seconds. Nohl then decoded the file with Airprobe and converted it
   into an audio file using Toast.

   Today, recording and cracking GSM is as easy as attacking WiFi was
   a few years ago, the security expert told The H's associates at
   heise Security.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread Frank A. Stevenson
On Mon, 2010-08-02 at 11:02 -0400, Bill Squier wrote:
 ...In his presentation at the Black Hat Conference, German GSM expert 
 Karsten Nohl presented a tool he calls Kraken, which he claims can crack the 
 A5/1 encryption used for cell phone calls within seconds.
 
 http://www.h-online.com/security/news/item/Quickly-decrypting-cell-phone-calls-1048850.html
 

A quick list of bullet points on what is new here:

* 2TB (1.7 compressed) of GSM A5/1 rainbow tables have been created
* These tables leverage the fact that A5/1 suffers from keyspace
convergence. After the initial 100 warm-up clockings, only 16% of the
keyspace remains valid.
* The rainbow tables only sample the converged space, such samples are
equivalent to sampling all of the on average 13 initial states that
converge to the sampled point.
* Efficient ATI GPU code has been written, that allowed us to compute
the tables in 8 GPU months, and were effectively completed in just 4
weeks, using 4 computers and 850kWh of power.
* Depending on the random access speed of the storage medium, 64 bits
keys for a particular conversation can be cracked in minutes or seconds.
* We have made all software and the tables freely available.

Frank A. Stevenson


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread Adrian Hayter
In a related story, hacker Chris Paget created his own cell-phone base station 
that turned off encryption on all devices connecting to it. The station then 
routes the calls through VoIP.

http://www.wired.com/threatlevel/2010/07/intercepting-cell-phone-calls/

-Adrian

On 2 Aug 2010, at 16:02, Bill Squier wrote:

 ...In his presentation at the Black Hat Conference, German GSM expert 
 Karsten Nohl presented a tool he calls Kraken, which he claims can crack the 
 A5/1 encryption used for cell phone calls within seconds.
 
 http://www.h-online.com/security/news/item/Quickly-decrypting-cell-phone-calls-1048850.html
 
 -wps
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread Adam Fields
On Mon, Aug 02, 2010 at 04:55:04PM +0100, Adrian Hayter wrote:
 In a related story, hacker Chris Paget created his own cell-phone base 
 station that turned off encryption on all devices connecting to it. The 
 station then routes the calls through VoIP.
 
 http://www.wired.com/threatlevel/2010/07/intercepting-cell-phone-calls/

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.

-- 
- Adam
--
If you liked this email, you might also like:
Some iPad apps I like 
-- http://workstuff.tumblr.com/post/680301206
Sous Vide Black Beans 
-- http://www.aquick.org/blog/2010/07/28/sous-vide-black-beans/
Sous Vide Black Beans 
-- http://www.flickr.com/photos/fields/4838987109/
fields: Readdle turns 3: Follow @readdle, RT to win an #iPad. $0.99 for any 
ap... 
-- http://twitter.com/fields/statuses/20072241887
--
** I design intricate-yet-elegant processes for user and machine problems.
** Custom development project broken? Contact me, I can help.
** Some of what I do: http://workstuff.tumblr.com/post/70505118/aboutworkstuff

[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.morningside-analytics.com ] .. Latest Venture
[ http://www.confabb.com ]  Founder

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread Perry E. Metzger
On Mon, 2 Aug 2010 12:12:25 -0400 Adam Fields
cryptography23094...@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. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread John Kemp
On Aug 2, 2010, at 11:08 AM, Perry E. Metzger wrote:

 On Mon, 2 Aug 2010 11:02:54 -0400 Bill Squier g...@old-ones.com
 wrote:
 ...In his presentation at the Black Hat Conference, German GSM
 expert Karsten Nohl presented a tool he calls Kraken, which he
 claims can crack the A5/1 encryption used for cell phone calls
 within seconds.
 
 http://www.h-online.com/security/news/item/Quickly-decrypting-cell-phone-calls-1048850.html
 
 This is a really important development.

Others have previously cracked A5/1, and Mr Nohl's efforts are not news: 
http://www.pcworld.com/businesscenter/article/185552/gsm_encryption_cracked_showing_its_age.html
 but the main thing here appears to be the compilation of the rainbow tables.

Also, it's worth noting that the GSMA has had A5/3 GSM encryption available 
(http://gsmworld.com/documents/a5_3_and_gea3_specifications.pdf -- PDF) since 
2008, but that the improved technology has apparently not yet seen large-scale 
adoption by mobile operators. 

Regards,

- johnk

 -- 
 Perry E. Metzger  pe...@piermont.com
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread Paul Wouters

On Mon, 2 Aug 2010, Perry E. Metzger wrote:


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.)


If that was a major issue, then SSL would have been much more successful
then it has been.

I have good hopes that soon we'll see use of our new biggest cryptographically
signed distributed database. And part of the signalling can come in via the
AD bit in DNSSEC (eg by adding an EDNS option to ask for special additional
records signifying SHOULD do crypto with this pubkey)

The AD bit might be a crude signal, but it's fairly easy to implement at
the application level. Requesting specific additional records will remove
the need for another latency driven DNS lookup to get more crypto information.

And obsolete the broken CA model while gaining improved support for SSL certs
by removing all those enduser warnings.

Paul

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread Perry E. Metzger
On Mon, 2 Aug 2010 12:45:46 -0400 John Kemp j...@jkemp.net wrote:
 On Aug 2, 2010, at 11:08 AM, Perry E. Metzger wrote:
 
  On Mon, 2 Aug 2010 11:02:54 -0400 Bill Squier g...@old-ones.com
  wrote:
  ...In his presentation at the Black Hat Conference, German GSM
  expert Karsten Nohl presented a tool he calls Kraken, which he
  claims can crack the A5/1 encryption used for cell phone calls
  within seconds.
  
  http://www.h-online.com/security/news/item/Quickly-decrypting-cell-phone-calls-1048850.html
  
  This is a really important development.
 
 Others have previously cracked A5/1, and Mr Nohl's efforts are not
 news:

I think demonstrating the whole thing being done for a
negligible amount of money is indeed news.

 Also, it's worth noting that the GSMA has had A5/3 GSM encryption
 available
 (http://gsmworld.com/documents/a5_3_and_gea3_specifications.pdf --
 PDF) since 2008, but that the improved technology has apparently
 not yet seen large-scale adoption by mobile operators. 

Perhaps they hadn't seen a low cost demonstration of the threat yet.

-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread Nicolas Williams
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.

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.

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*

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 ;)

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.  This makes the relevant context harder, if
not impossible to resolve without the user's help.

HTTP, sadly, needs an insecure mode.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: GSM eavesdropping

2010-08-02 Thread Nicolas Williams
On Mon, Aug 02, 2010 at 01:05:53PM -0400, Paul Wouters wrote:
 On Mon, 2 Aug 2010, Perry E. Metzger wrote:
 
 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.)
 
 If that was a major issue, then SSL would have been much more successful
 then it has been.

How should we measure success?  Every user on the Internet uses TLS
(SSL) on a daily basis.  None uses IPsec for anything other than VPN
(the three people who use IPsec for end-to-end protection on the
Internet are too few to count).

By that measure TLS has been so much more successful than IPsec as to
prove the point.

Of course, TLS hasn't been successful in the sense that we care about
most.  TLS has had no impact on how users authenticate (we still send
usernames and passwords) to servers, and the way TLS authenticates
servers to users turns out to be very weak (because of the plethora of
CAs, and because transitive trust isn't all that strong).

 I have good hopes that soon we'll see use of our new biggest
 cryptographically signed distributed database. And part of the
 signalling can come in via the AD bit in DNSSEC (eg by adding an EDNS
 option to ask for special additional records signifying SHOULD do
 crypto with this pubkey)
 
 The AD bit might be a crude signal, but it's fairly easy to implement
 at the application level. Requesting specific additional records will
 remove the need for another latency driven DNS lookup to get more
 crypto information.
 
 And obsolete the broken CA model while gaining improved support for
 SSL certs by removing all those enduser warnings.

DNSSEC will help immensely, no doubt, and mostly by giving us a single
root CA.

But note that the one bit you're talking about is necessarily a part of
a resolver API, thus proving my point :)

The only way we can avoid having such an API requirement is by ensuring
that all zones are signed and all resolvers always validate RRs.  An API
is required in part because we won't get there from day one (that day
was decades ago).

The same logic applies to IPsec.  Suppose we'd deployed IPsec and DNSSEC
back in 1983... then we might have many, many apps that rely on those
protocols unknowingly, and that might be just fine...

...but we grow technologies organically, therefore we'll never have a
situation where the necessary infrastructure gets deployed in a secure
mode from the get-go.  This necessarily means that applications need
APIs by which to cause and/or determine whether secure modes are in
effect.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com