Re: Who needs secure wireless / tappable wireless infrastructure

2003-09-09 Thread John Gilmore
   And this says nothing at all about the need for tactical
 military wiretaps on GSM systems under battlefield conditions when
 soldiers lives may depend on determining what the enemy is saying over
 cellphones used to direct attacks against friendly forces.

Or when innocent civilians need secure wireless infrastructures, to be
able to coordinate to avoid murderous US military forces.  See, for
example:

  http://electroniciraq.net/news/1014.shtml

which I found via SF writer James P. Hogan's blog:

  http://www.jamesphogan.com/bb/bb.shtml

Prudent citizens should now know that before stepping into the street
to hail a taxi, they should use a secure phone to determine whether
any American tanks are in the area.  But beware of American
direction-finding equipment -- make those calls short!

John


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Code breakers crack GSM cellphone encryption

2003-09-09 Thread John Gilmore
 See their paper at CRYPTO 2003 for more details.  I am disappointed that
 you seem to be criticizing their work before even reading their paper.
 I encourage you to read the paper -- it really is interesting.

OK, then, where is it?  I looked on:

  www.iacr.org under Crypto 2003 -- no papers there.  The title of the
  paper, presented in Session 15, is:

Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communication
Elad Barkan,  Eli Biham,  Nathan Keller

  www.iacr.org under Conference Proceedings -- Crypto 2003 not there.
  www.iacr.org under Cryptology ePrint archive -- no Biham or GSM papers there.
  www.cs.technion.ac.il/~biham/ -- latest paper is from 2000.
  www.cs.technion.ac.il/~barkan/ -- access denied
  www.cs.technion.ac.il -- a news item about the GSM crack, but no paper.

I'm even a dues-paying IACR member, but I don't seem to have online
access to the papers from recent conferences.  I'm sure a copy will
show up in the mail a few months from now.  Let me guess -- the devils
at Springer-Verlag have stolen IACR's copyrights and the researchers
were dumb enough to hand their copyright to IACR...

John

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification

2003-09-09 Thread Peter Gutmann
Rich Salz [EMAIL PROTECTED] writes:

Sure, that's why it's *the first.*  They have never done this before, and it
is very different to how they (or their Ft Meade experts) have done things
before.  I suppose one could argue that they're doing this for Level 1 to
increase the industry demand for Level 2, but I'm not that paranoid.  I think
they finally get it.

I think this uniquely broad certification, if permitted, would be mostly a
sign that the politicians have finally won out over the certification purists.
Let me explain... it's been known for a long time (at least from talking to
evaluators, I don't know if NIST will admit to it) that there's large-scale
use of unevaluated crypto going on, with the FIPS eval requirement being
ignored by USG agencies, contractors, etc etc whenever it gets in the way of
them getting their job done.  If NIST allow this extremely broad
certification, it'd be a sign that they're following the Calvin and Hobbes
recipe for success: The secret to [success] is to lower your expectations to
the point where they're already met.  In other words the unevaluated crypto
problem (or a major part of it) suddenly goes away, and it's possible to
report that the certification effort has been wonderfully successful, because
a large portion of the noncompliant usage is (at least on paper) magically
made compliant overnight.

The only potential downside to this is that a pile of vendors who previously
got a very narrowly-interpreted certification will presumably be queueing up
to do the I'll have what she's having thing as soon as an open-ended
certification is issued.

As with others who have commented on this, I'm going to believe this when I
see it.

Peter.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: fyi: bear/enforcer open-source TCPA project

2003-09-09 Thread Sean Smith
 
 How can you verify that a remote computer is the real thing, doing
 the right thing?
 
 You cannot.

Using a high-end secure coprocessor (such as the 4758, but not
with a flawed application) will raise the threshold for the adversary
significantly.

No, there are no absolutes.  But there are things you can do.
 
 The correct security approach is to never give a remote machine
 any data that you don't want an untrusted machine to have. 

So you never buy anything online, or use a medical facility
that uses computers?





-- 
Sean W. Smith, Ph.D. [EMAIL PROTECTED]   
http://www.cs.dartmouth.edu/~sws/   (has ssl link to pgp key)
Department of Computer Science, Dartmouth College, Hanover NH USA




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Is cryptography where security took the wrong branch?

2003-09-09 Thread Anne Lynn Wheeler
At 04:25 PM 9/8/2003 -0700, Joseph Ashwood wrote:
Actually they do target very different aspects. SET, 3D-Secure, and any
other similar have a different target then SSL. To understand this it is
important to realize that instead of the usual view of two-party
transactions, credit card transactions actually take 3 parties; Issuer,
Seller, and Buyer. SSL covers the Seller-Buyer communication, and can also
be applied to the Seller-Issuer communication, but on a transaction basis it
offers nothing for the Issuer-Buyer (the important one for minimizing costs
for the Issuer).
actually, physical credit card ... is a number of pair-wise communications 
 card-holder to merchant terminal ... merchant terminal to merchant 
acquirer, merchant acquirer to interchange, interchange to issuer (credit 
card model is sometimes referred to as the 4-corner box  with 
interchange trying to be transparent in the acquirer to issuer communication).

original electronic commerce with the netscape commerce server ... had SSL 
for the shopping experience ... with the credit card done at the end. 
Depending on the mall version of the commerce server had dedicated leased 
line directly to merchant acquirer. The wider userd commerce server had a 
SSL connection from the commerce server to the payment gateway (which then 
interfaced to the merchant acquirer) ... effectively emulating the real 
world (two pair-wise communcations).
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

In the real-world  SSL use got cut-back to only handling the credit 
card part of the transaction ... and not being used for the rest of the 
shopping experience.

In any case, the SSL flows exactly emulate the physical world (effectively 
the front side of the virtual POS running at the merchant website ... and 
the backside of the virtual POS  to the acquirer) . ... modulo previous 
comment that the merchant transaction file in the physical world wasn't 
accessable via the internet (even tho it directly doesn't show up in the 
flows). The major exploits haven't been in the transaction flow part of the 
operation  but in the business mechanics  the major exploits have 
been harvesting the merchant transaction file. Neither SSL, nor SET have 
counter-measure against the major exploit (harvesting the merchant 
transaction file). Both SSL and SET hid the credit card number while in 
transit.

SET had all this other certificates and PKI gorp ... that significantly 
increased the crypto-related burden ( much more so than SSL).  In theory, 
SET had an opportunity for end-to-end authentication  but even a single 
certificate represented on the order of two-orders of magnitude bloat 
increase for the payload in the standard payment network (aka a single PKI 
certificate tends to be one hundred times larger than the typical, base 
payment transaction). The SET burden was orders of magnitude worse than the 
SSL burden. This, in part is what gave way to the SET payment gateway  
all the PKI gorp would occur at the SET payment gateway then all SET 
related information would be thown away, a standard 8583/x9.15 transaction 
created  with an additional flag indicating that digital signature 
authentication had been correctly performed ...and off it goes.

One of the VISA business people later gave a presentation at an ISO meeting 
about the number of 8583 transactions flowing thru the payment network with 
the SET-authenticated flag set but they could prove that no PKI 
technology was even remotely possible for the transaction  aka a slight 
issue of end-to-end security was violated.  The important issue here was 
that the vision for SET ... was that if SET-authenticated transaction were 
involved ... the merchant eventually would be eligible for card-holder 
present discount rates ... rather than MOTO discount rates (aka having SET 
authentication was proposed as being as safe as a) card-holder present, b) 
card-preset, and c) track 12 readable). It was therefor in the interest of 
the merchant side of the business to tell the issuing side of the business 
that transactions were SET authenticated and the mrechant could get a much 
better discount rate).

The claim was that SET enormously increased the complexity, overhead, and 
payload processing ... while having little practical impact on the major 
vulnerabilities.

Out of all this ... the X9A10 standards working group was giving the 
requirement to preserve the integrity of the financial infrastructure for 
all retail payments. The result is X9.59 which addresses all the major 
exploits at both POS as well as internet (and not just credit, but debit, 
stored-value, ACH, etc ... as well).
http://www.garlic.com/~lynn/index.html#x959
One of the things addressed by X9.59 was not the elimination of the ability 
to harvest the merchant transaction file ... but to make the account 
numbers in the merchant transaction file useless for fraud. 

X9.59 where is it?

2003-09-09 Thread Victor . Duchovni
On Tue, 9 Sep 2003, Anne  Lynn Wheeler wrote:

 http://www.garlic.com/~lynn/index.html#x959
 One of the things addressed by X9.59 was not the elimination of the ability
 to harvest the merchant transaction file ... but to make the account
 numbers in the merchant transaction file useless for fraud. slightly
 related discussion of the security proportional to risk and the
 vulnerability represented by the merchant transaction file

Is X9.59 actually in use for consumer retail transactions anywhere?

-- 
Victor Duchovni
IT Security,
Morgan Stanley

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Code breakers crack GSM cellphone encryption

2003-09-09 Thread David Wagner
Vin McLellan  wrote:
A5/2 was the equivalent of 40-bit DES, presumed to be relatively weak and 
developed as an export standard.

Yeah.  Except it would be more accurate to place A5/2's strength as
roughly equivalent to 17-bit DES.  A5/1's strength is roughly equivalent
to that of 40-bit DES.

Of course, the GSM folks didn't exactly do a great job of disclosing
these facts.  They did disclose that A5/2 was the exportable version.
However, when A5/2 was first designed, SAGE put out a report that claimed
years of security analysis on A5/2 had been done and no mathematical
weaknesses had been found.  Now that we've seen A5/2, that report suffers
from a certain credibility gap, to put it mildly...

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


x9.59

2003-09-09 Thread Ian Grigg
Anne  Lynn Wheeler wrote:
 
  The result is X9.59 which addresses all the major
 exploits at both POS as well as internet (and not just credit, but debit,
 stored-value, ACH, etc ... as well).
 http://www.garlic.com/~lynn/index.html#x959


Lynn,

Whatever happened to x9.59?

Also, is there a single short summary description of what
x9.59 does?  I don't mean a bucket full of links to plough
through, I mean some sort of technical overview that wasn't
approved by the marketing department.

iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


OT: Swiss ATM Bancomat 5.0 BM5.0

2003-09-09 Thread Carsten Kuckuk
The September/October 2003 edition of the German magazine
Objektspektrum contains an article about the development of an ATM
system to be used in Switzerland. (Alexander Rietsch: Die
Neuentwicklung des Raiffeisen-Bankomaten, p.30-34. In passing
it mentions that they use Windows 2000, an MS Access database for
resources, MSDE for money transfer data, MSVS remote debugging,
C++ for speed reasons, COM, IE, and have everything connected via
TCP/IP networks. Unfortunately the focus of the article is not on
security, so all the obvious question are unanswered.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Code breakers crack GSM cellphone encryption

2003-09-09 Thread David Wagner
One point your analysis misses is that there are public policy
implications to deploying a phone system that enemy countries can
routinely intercept.  Not all attacks are financially motivated.

Is it a good thing for our infrastructure to be so insecure?
Do we want other countries listening to our GSM calls?  Do other
countries want us listening to their GSM calls?  Is it a good thing
if such interception is made easier?  Sure, it may be in the SIGINT
agencies' interests for GSM to be crackable, but is it in the
public interest?  It's not clear.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Is cryptography where security took the wrong branch?

2003-09-09 Thread Anne Lynn Wheeler
At 05:19 PM 9/7/2003 -0600, Anne  Lynn Wheeler wrote:
Out of all this, there is somewhat a request from the CA/PKI industry that 
a public key be registered as part of domain name registration (no 
certificate, just a public key registration). Then SSL domain name 
certificate requests coming into a CA/PKI can be digitally signed, the 
CA/PKI can retrieve the authoritative authentication public key (for the 
domain name ownership) from the domain name infrastructure and 
authenticate the request  eliminating all the identification gorp (and 
also done w/o the use of certificates).

misc. additional recent musings:
http://www.garlic.com/~lynn/2003l.html#60  Proposal for a new PKI model 
(At least I hope it's new)
The Database gaps make ID fraud easier, GAO says
http://www.gcn.com/vol1_no1/daily-updates/23446-1.html
is somewhat analogous to the SSL domain name certificate problem ... a 
primary purpose for existing is to authenticate that the website you think 
you are talking to is the website you are talking to.

The problem is that the domain name infrastructure has a database of domain 
name owners  but no real good infrastructure ... and the CA/PKI 
operations doing SSL domain name certifications are disjoint from the 
domain name infrastructure operations. As a result  effectively the 
CA/PKI industry has to treat requests for SSL domain name certificates 
effectively as if it was a random person walking in from the street ... and 
then they have to try and match up such seemingly random requests ... with 
what little bit of information that they can extract from the domain name 
infrastructure (seeing if they can establish an identity in the real world 
based on the DNS database information ... and see if that identity then can 
be matched against the identity of the entity requesting the certificate).

Adding a public key to the domain name infrastructure database as part of 
the domain name registration process  then eliminates the requirement 
of trying to establishing corresponding identities in the real world ... 
and it just reduces to a question of authentication.

Of course, the bottom line is if the domain name infrastructure has a 
real-time database of public keys for authentication purposes  in part 
for use by the CA/PKI industry for authenticating SSL domain name 
certificate requests  for use in authentication operations  the use 
of the domain name infrastructure's authentication public keys don't have 
to just be restricted to authentication use by the CA/PKI industry. In 
fact, domain name infrastructure authentication public keys could be used 
to effectively for authentication operations that actually subsume the SSL 
domain name certificates authentication operations.



--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


GSM Crack Paper

2003-09-09 Thread John Young
Instant Ciphertext-Only Cryptanalysis of GSM Encrypted
Communications, by Elad Barkan, Eli Biham, Nathan Keller

  http://cryptome.org/gsm-crack-bbk.pdf  (18 Pages, 234KB)

Abstract. In this paper we present a very practical cipher-text only
cryptanalysis of GSM encrypted communications, and various active
attacks on the GSM protocols. These attacks can even break into
GSM networks that use unbreakable ciphers. We describe a
ciphertext-only attack on A5/2 that requires a few dozen milliseconds
of encrypted off-the-air cellular conversation and finds the correct
key in less than a second on a personal computer. We then extend
this attack to a (more complex) ciphertext-only attack on A5/1. We
describe new attacks on the protocols of networks that use A5/1, A5/3,
or even GPRS. These attacks are based on security flaws of the GSM
protocols, and work whenever the mobile phone supports A5/2. We
emphasize that these attacks are on the protocols, and are thus
applicable whenever the cellular phone supports a weak cipher, for
instance they are also applicable using the cryptanalysis of A5/1.
Unlike previous attacks on GSM that require unrealistic information,
like long known plaintext periods, our attacks are very practical and
do not require any knowledge of the content of the conversation.
These attacks allow attackers to tap conversations and decrypt
them either in real-time, or at any later time. We also show active
attacks, such as call hijacking, altering data messages and call
theft.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital cash and campaign finance reform

2003-09-09 Thread Joseph Ashwood
- Original Message - 
From: Steve Schear [EMAIL PROTECTED]
Subject: Re: Digital cash and campaign finance reform


 At 04:51 PM 9/8/2003 -0700, Joseph Ashwood wrote:
 - Original Message -
 From: Steve Schear [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 [anonymous funding of politicians]
   Comments?
 
 Simple attack: Bob talks to soon to be bought politician. Tomorrow
you'll
 recieve a donation of $50k, you'll know where it came from.
 Next day, buyer makes 500 $100 donations (remember you can't link him to
any
 transaction), 50k arrives through the mix. Politician knows where it came
 from, but no one can prove it.

 Not so fast.  I said the mix would delay and randomize the arrival of
 payments.  So, some of the contributions would arrive almost immediately
 others/many might take weeks to arrive.

You act like they aren't already used to addressing that problem. I'll go
back to the Bustamante, simply because it is convenient right now.
Bustamante recieved a multi-million dollar donation from the Native
Americans, this was not done through a single check, that would be illegal,
instead it was done through multiple smaller checks, each of which ends up
randomized and delayed in processing (USPS is wonderful source of
randomness), so the actual occurance of the donations is scattered acros
several days, from several accounts, by several people, and I'm sure
Bustamante never even looked to see who the donations were actually from,
just that the full amount arrived. The problem that you found, is already
addressed, and already not a problem.
Joe

Trust Laboratories
Changing Software Development
http://www.trustlaboratories.com


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Is cryptography where security took the wrong branch?

2003-09-09 Thread Anne Lynn Wheeler
At 05:07 PM 9/9/2003 -0700, Joseph Ashwood wrote:
Now that the waters have been muddied (by several of us). My point was that
3D-Secure (and SET and whatever else comes along) covers a different
position in the system than SSL does (or can). As such they do have a
purpose, even though they may be horribly bloated and nearly non-functional.
Visa at least seems to be supporting the 3D-Secure concept (they should,
they developed it), and looks like anyone can grab the spec from
... while SET, 3d-secure, etc may have been designed for all sorts of 
reasons  I guess my point was that w/o a adequately specified threat 
model  for the primary vulnerabilities ... there turned out to be 
little effective difference between the use of SET and the use of SSL 
(regardless of what the designers may have original thot). Also technology 
adoption/uptake typically requires the transition to be less painful than 
the problem it is fixing. SSL was already in the market space ... so SET 
had to demonstrate that it was incrementally better (not effectively the 
same as for the major vulnerabilities) in order to justify its 
significantly more difficult and costly deployment.

The other issue that has been the bane of major PKI/certificate deployments 
(and I've repeatedly raised the issue) ... is that certificate-based 
operations typically have the key owner paying for the certificate  
while the major benefit accrues to the relying-party ... the the 
key/certificate owner. In the case of SET ... there was the consumer payng 
for their certificate   and the merchant not only receiving a better 
than MOTO-discount (making interchange transactions with the SET flag 
turned on ... somewhat suspecious) ... but also the possibility that the 
transaction would be treated as authenticated and potentially shifting 
the burden of proof in a dispute from the merchant to the consumer. There 
was the possibility that not only would the consumer be footing the bill 
(buying their own certificate) for the sole benefit of reducing what the 
merchant paid on the transaction  but there was also speculation that 
it might also be used to make it more difficult for the consumer (there was 
sporadic mention of shifting the burden of proof from the merchant to the 
consumer in a dispute).

At least in the SSL domain name certificate, the merchant pays because of 
some belief that it will help attracted (internet) consumers/business.

In the SET/PKI scenario ... it was nearly impossible to figure out a value 
proposition for the consumer  where the consumer is footing the 
(certificate) bill ... that turns out to be totally for the benefit of the 
merchant.  It wasn't so much that cryptography took a wrong branch ... 
but many of the PKI business models don't conform to any sane business 
operation  with the entity (key-owner) footing the bill not getting any 
benefit ... and all the benefit going to the relying-party.

The other generalized PKI issue (again not just SET) ... is any contract 
tends to be between the CA?PKI and the consumer  aka the entity in a 
contract that purchases something. Frequently is no contractual 
relationship between the relying-parties  who effectively the sole 
reason that the certificates exist ... and the CA/PKI. As mentioned 
elsewhere, the GSA PKI has attempted to somewhat address this by having all 
relying-parties sign contracts with the GSA  and all the CA/PKI 
certificate issuing entities have a contract with the GSA where they are 
effectively issuing certificates on behalf of the GSA. Those set of 
contracts then preovide the legal foundation for some generic reason for 
relying-parties to do anything with certificates (since the relying-parties 
and the CA/PKI agency, aka GSA ... have contractual relationship and 
therefor a legal reason to deal with certificates). The slightly different 
SET scenario ... the associations just told the merchants that they would 
be charged less per transaction ... aka instead of MOTO (mail order, 
telephone order) discount, they could get something closer to card present 
discount.

--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]