Uncrackable beams of light

[R. A. Hettinga]

The Economist






MONITOR

Uncrackable beams of light
Sep 4th 2003
>From The Economist print edition


Quantum cryptography±hailed by theoreticians as the ultimate of uncrackable
codes±is finally going commercial

IN THE 1992 film 1Ž4Sneakers1Ž2, the ostensible research topic of one of
the main characters was something called 1Ž4setec astronomy1Ž2. This was an
anagram of the words 1Ž4too many secrets1Ž2. The research was supposed to
be about developing a method for decoding all existing encryption codes.
Well, if that were ever the case, it certainly isn't any more±thanks to a
start-up in Somerville, Massachusetts, called Magi Q.

Magi Qis in the final stages of testing a system for quantum cryptography,
which it plans to release commercially within the next few months.
Encryption engineers have long waxed lyrical about quantum cryptography,
but this is among the very first commercial implementations. The advantage
of quantum cryptography schemes is that the code they generate are simply
not±even in theory±breakable.

The scheme devised by Magi Q, called Navajo, does not use quantum effects
to transmit the secret data. Instead, it is the keys used to encrypt the
data that rely on quantum theory. If these keys are changed frequently (up
to 1,000 times a second in Navajo's case), the risk that an eavesdropper
without the key would be able to decrypt the data can be proved
mathematically to be zero. Of course, given the key, the task would become
a trivial one.

Navajo transmits the changing key sequence over a secure fibre-optic link
as a stream of polarised photons (indivisible particles of light). Because
the polarisation reflects the amount of electro-magnetic radiation allowed
to radiate at an angle to a light beam's direction, it can be considered to
be a measure of the angular dependence of the light.

Should an eavesdropper tap into the secure fibre-optic line, he would
disrupt this stream of polarised photons by the very act of observing
them±and the tampering could be instantly detected. By changing the key
frequently, Navajo could turn an off-the-shelf encryption scheme such as
AES (Advanced Encryption System) into something that was essentially
uncrackable.

As in all good encryption schemes, Navajo employs an element of redundancy.
The sender has two random-number generators. The first is used to generate
a random stream of zeros and ones±part of which will form the key. The
second random-number generator chooses which 1Ž4polarisation basis1Ž2 the
sender will use to transmit a given bit of the key. The sender uses two
different polarisation bases, which are at right-angles to one another.
Only by measuring in the correct polarisation basis can a receiver see
which bit was sent±otherwise the result is meaningless.

For each bit, the receiver arbitrarily chooses which polarisation basis to
use. The sender and receiver then talk over an open channel and find out
which bits they measured using the same basis. These bits (about half of
the total) then constitute the key. If someone has been eavesdropping, some
of these bits will have been disrupted. In that case the receiver will be
unable to decode the message, and will thus conclude that someone is
listening in.

This much is standard quantum cryptography. What is harder is building the
hardware that can do it quickly and cheaply enough to be commercially
viable. Magi Qis in a race with a Swiss company called ID Quantique to be
the first to do so, and currently appears to be in the lead.

Of course, if the quantum signal could be transmitted wirelessly, it would
liberate users from the cost and constraints of a fibre-optic line. Bob
Gelfond, Magi Q's founder and chief executive, is coy about the
possibility. He admits that his firm is working on the idea, but is not
saying anything at the moment.

For the time being, Navajo requires a dedicated fibre-optic link, which
only large corporations or governments are likely to have. And it currently
works only at distances of up to 50 kilometres. Any longer than that and
random interference degrades the stream of photons and makes them unusable.
But within these constraints, Navajo is fairly cheap. Magi Qplans to sell
it for $50,000 a set.

Given the glut of unused optical fibre buried beneath the streets of the
world, Magi Qis optimistic about Navajo's prospects. Andrew Hammond, a
vice-president at the company, reckons the market could potentially be
worth more than $1 billion a year, with much of the business coming from
firms with valuable intellectual property, such as drugmakers and aircraft
companies.



Copyright ' 2003 The Economist Newspaper and The Economist Group. All
rights reserved.



-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the en

Re: Is cryptography where security took the wrong branch?

[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]

GSM Crack Paper

[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: Is cryptography where security took the wrong branch?

[Joseph Ashwood]

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
http://international.visa.com/fb/paytech/secure/main.jsp . SET seems to be a
bit more elusive, although still available from
http://www.mastercardintl.com/newtechnology/set/ . Mastercard SecureCode
appears to be the current direction for MasterCard it's available at
http://www.mastercardmerchant.com/securecode/ . All of these differ in
target from SSL in the same way, they are designed to address the
Buyer-Issuer link (although some not as simply as others, e.g. SET). And yes
I am using a much simplified view of the credit card transaction, with only
3 (buyer, seller, issuer) parties instead of the absurd number actually
present in a real transaction (buyer seller, issuer, accepter, processor,
central card distributor, plus whoever I missed), I did this for clarity.
Joe

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


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

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

[Ben Laurie]

Tolga Acar wrote:
> Well, that is sort of my point.
> SHA1 is not a signature algorithm, sha1-with-rsa is, and that RSA is not
> a certified algorithm in OpenSSL's FIPS 140 certification, 
> sha1-with-rsa isn't, either.
> Perhaps, my understanding of the OpenSSL FIPS 140 certification is not
> entirely accurate.

My fault. RSA is not validated (there are no validation tests for it),
but it will be in the code we are submitting for certification.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



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

Police smash UK's biggest credit card fraud ring

[Anne & Lynn Wheeler]

here is example of downloading the database ... but not (necessarily) over 
the internet ... and not involving internet transactions.

not in general there is some amount of counterfeit cards going on from 
skimming. There are even reports in the UK press ... of counterfeit 
EMV  (chip) "yes cards" being produced.

the initial "847" in the following seems a little inconsistent 2m to 20m in 
fraud ... maybe it was 8 thousand or 80 thousand ... not 847

http://www.theregister.co.uk/content/55/32704.html

Police smash UK's biggest credit card fraud ring
By Drew Cullen
Posted: 08/09/2003 at 13:14 GMT
Three men are facing long jail sentences after pleading guilty, Friday 
(Sept. 5) to running the UK's biggest ever credit card fraud at Middlesex 
Guildhall Crown Court.

The trio stole details of 847 cards of Heathrow Express rail passengers who 
had paid for their journey by credit cards. They passed on the infor a gang 
of forgers who cloned 8,790 credit cards for use in the UK and on the 
Continent. The cloners were able to use only 10 per cent of the numbers, 
pocketing £2m for the gang. Police estimate that the gang could have gained 
£20m if all the credit card numbers had been used.

... snip ...
--
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]

Re: Is cryptography where security took the wrong branch?

[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]

Re: Code breakers crack GSM cellphone encryption

[John Young]

Ian Grigg wrote:

>What's not clear is whether the GSM group can pull this
>trick off next time.  They may have to put in real security
>into the G3, to counter the third threat.  Or, maybe not,
>as now, there is the additional weapon of the law on their
>side, which might be enough to keep the third threat at
>bay.

We'd like to publish examples of GSM threatening researchers,
or threats from authorities instigated by GSM or by the
authorities themselves.

While not likely, did the recent GSM crackers mention at
Crypto 2003 any concern about being threatened by GSM
and friends. The researchers' comment in news reports that 
the crack had been sent to GSM for corrective action is 
provocative.

Finally, did the GSM crackers mention withholding the paper
from public distribution in order to head off a threat.

Times are weird for researchers these days. Self-censorship
is a temptation when research funds are placed at risk, or
worse, when institutions and publishers run scared from 
potential threats and warn scholars to tread carefully.

Recall that Dr. Simon John Shepherd's research in 1994,
"Cryptanalysis of the GSM A5 Cipher Algorithm," is still being 
withheld as classified.







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

Re: Code breakers crack GSM cellphone encryption

[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: Code breakers crack GSM cellphone encryption

[Ian Grigg]

David Wagner wrote:
> 
> 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...

Within the context of their threat model, it is quite instructive
to consider how successful these algorithms are.

AFAIK, the phone threat model includes these two attackers:

  * johnny phone thief who steals billing identities and sells
cheap spoofed phones, and
  * janie papparazzi that records the famous and foolish revealing
themselves over the phone, and then publishes in the media

Empirically, the GSM system defeated these threats.  GSM first
hit the market about 10 years ago, and since then, the victims
of the above have enjoyed peace and prosperity, with no risk
of spoofed (GSM) phones and no risk of (GSM) eavesdroppers.

Yet, they did it with 17 bit crypto.

(Well, that's not quite the whole story.  We can probably guess
that they were encouraged to do is with very weak crypto.  In
fact, there is sufficient anecdotal evidence to conclude that
there were strange and unrelated people involved who diverted
the security equations from strength into weakness.)

By doing it with such superficial crypto, GSM was now faced
with a third threat:

  * the researcher who reveals the way to the other attackers.

To cover this threat, GSM instigated security-by-secrecy,
and wrapped it up in a marketing campaign that claimed the
crypto was unbreakable.  Basically, a lie.  I recall being
told by the salesman of my first phone that the crypto was
unbreakable, and I had to kick myself for buying it, when,
a year later, I realised that it could not be encrypted
beyond the basestation, and therefore, strong crypto was
pointless.

And, it worked.  Eli Biham said 

   "I told him (Barkan) that it was impossible,"

Everyone in the community bought it.  Even post-Lucky Green,
there was no real thought that there was a bigger better
hack hiding in there.

   "The 450 participants, many of whom are leaders
   in encryption research, 'were shocked and astounded'
   by their revelation that most cellphones are
   susceptible to misuse."

The crack finally occurred a decade after deployment.  GSM
security even survived the infamous Lucky Green crack that
Dave Wagner and Ian Goldberg helped with;  there was no
practical fallout to that other than embarressment, that
I ever heard of, due to the difficulty of exploitation.

Lucky tells the story of how the one GSM security expert
brazenly said, "hey, it worked for 8 years!"  (Words from
my memory, perhaps Lucky can retell the story.)  It worked
for longer...

What's even better, or worse, depending on your pov, is
that the the timing couldn't be better:  there is still
time to beef up the G3 security, and its close enough to
rollout of that technology such that this crack will
*help* takeup.

Nothing more desirable could happen to the GSM group than
the first hand-built or grey-import GSM-2 phone crackers
start appearing, just as GSM3 is starting to roll out.

Perfect!  It's the huge win for GSM.  You simply can't
purchase help like that (not that I'm suggesting they
did, of course).

What can we learn from this?  I guess:

   * institutional crypto systems will always be perverted,

   * believe no claims of invulnerability,

   * large crypto systems need only a modicum of strength
 to do a sufficient job against their direct threats,

   * the independant researcher is part of the threat
 model, as an indirect threat, and

   * security-by-secrecy / obscurity can work, and can
 work exceedingly well.

What's not clear is whether the GSM group can pull this
trick off next time.  They may have to put in real security
into the G3, to counter the third threat.  Or, maybe not,
as now, there is the additional weapon of the law on their
side, which might be enough to keep the third threat at
bay.

iang

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

Re: x9.59

[Anne & Lynn Wheeler]

At 01:44 PM 9/9/2003 -0400, Ian Grigg wrote:
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


look at:
http://www.garlic.com/~lynn/index.html#x959
and it has a pointer to the standards document at ANSI. I think there may 
be some discussion at the oct. x9 meeting about progressing x9.59 to ISO.

but slightly simpler description is the mapping of x9.59 to iso8583 
(basically the credit/debit network standards protocol) at:
http://www.garlic.com/~lynn/8583flow.htm

the above lists the x9.59 elements and the iso 8583 elements  and some 
mapping equivalence ... and how to carry the additional x9.59 values in an 
iso 8583 addenda field  so you can achieve end-to-end authentication 
 rather than truncated high integrity authentication at something like 
a boundary interface between the internet and the real payment 
infrastructure  show how x9.59 can operate in all payment card 
processing environments (not just internet) and be able to provide x9.59 
authentication on an end-to-end basis.

In this particular mapping between x9.59 and iso 8583 ... the original 
signed x9.59 object isn't carried end-to-end ... but there is a methodology 
defined for being able to reconstitute and verify the x9.59 object and the 
issuing financial institution.

The X9.59 standards document actual lists the ASN.1 encoding for the 
signing object (and therefor any reconstituted object)  ... although there 
has been investigation into a x9.59 "version number" for XML specification. 
One of the original issues for XML encoding specification was that there 
was no deterministic encoding rules for XML  allowing for an object to 
be mangled in transmission and then reconstituted for authentication.  This 
is something that FSTC
http://www.fstc.org/
did for FSML  the deterministic encoding rules to cover the scenario 
where a signed electronic check object was mangled for transmission thru 
the ACH network ... and then had to be reconstituted for signature 
authentication. Since then W3C has incorporated FSML into the xml signature 
specification work. some overview:.
http://www.echeck.org/overview/echecktech.html

The problem wasn't whether XML or ASN.1 was better encoding method ... the 
issue was that given that the signed string of bits were mangled during 
transmission and how to be reconstituted, there had to be identical, 
deterministic encoding rules at both the signing end and the authentication 
end. This was very close to what was used in the NACHA AADS trials ... 
reference at:
http://www.garlic.com/~lynn/index.html#aads

Although not in available document ... there was work mapping x9.59 
directly to ACH network (the message formats in ACH are different than the 
message formats in the payment card networks  actually many of the 
payment card networks ... both interchange and various acquiring networks 
... have frequently proprietary differences from the ISO 8583  although 
there is lots of recent work to achieve convergence). These are primary 
electronic electronic networks for payment transactions. There has also 
been some work mapping of x9.59 to wholesale networks, aka FEDWIRE, SWIFT, 
etc. The original X9.59 work was done in X9A which deals with retail 
standards. In the past there has been some differentiation between the 
retail and wholesale financial networks under the assumption that the 
values in the wholesale transactions were a lot larger and therefor 
required much higher level of security which, in turn, should cost 
significantly more. However, I think we managed to demonstrate in X9.59 a 
level of integrity that is as high as anything required for wholesale 
transactions at the same time being able to achieve a cost that was 
acceptable for retail transactions.

To be effective ... the standard deployment just about needs a hardware 
token that can be trusted to house the private key and perform the 
signature operation. My joke from 5-6 years ago was that I was going to 
take a $500 mil-spec part and cost reduce by it two orders of magnitude 
while at the same time increasing the security ... and cut the time & power 
requirements so that it could meet the transit gate elapsed time 
requirements in a ISO 14443 contactless configuration (the transit 
constraint model was basically the octopus sony/mitsubishi card used in HK 
transit system)..
http://www.garlic.com/~lynn/index.html#aadsstraw

I needled the chip module guys on this subject at a talk I gave two years 
ago at the intel developer's conference trusted platform track ...

OT: Swiss ATM Bancomat 5.0 BM5.0

[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]

x9.59

[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]

Re: Code breakers crack GSM cellphone encryption

[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 where is it?

[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: Is cryptography where security took the wrong branch?

[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 1&2 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. sl

Re: Digital cash and campaign finance reform

[Amir Herzberg]

Steve suggested (see below) that anonymous cash may be useful to hide the 
identities of contributors from the party/candidate they contribute to. I'm 
afraid this won't work: e-cash protocols are not trying to prevent a 
`covert channel` between the payer and payee, e.g. via the choice of random 
numbers or amounts. Furthermore even if the e-cash system had such a 
feature, it would be of little help, since (a) there will be plenty of 
other ways the payer can convince the payee that it made the contribution 
and (b) in reality, candidates will have to return the favors even without 
knowing for sure they got the money - kind of `risk management` - I'm not 
sure what we want is to allow big contributors to gain favors while not 
really making as big a contribution as they promised...

Best, Amir Herzberg

At 10:11 08/09/2003 -0700, Steve Schear wrote:
Everyone knows that money is the life blood of politics.  The topic of 
campaign finance reform in the U.S. has been on and off the front burner 
of the major media, for decades.  Although the ability of citizens and 
corporations to support the candidates and parties of their choice can be 
a positive political force, the ability of political contributors to buy 
access and influence legislation is probably the major source of 
governmental corruption.  Despite some, apparently, honest efforts at 
limiting these legal payoffs there has been little real progress.  The 
challenge is to encourage "neutral" campaign contributions.  Perhaps 
technology could lend a hand.

One of the features of Chaimian digital cash is unlinkability.  Normally, 
this has been viewed from the perspective of the payer and payee not 
wishing to be linked to a transaction.  But it also follows that that the 
payee can be prevented from learning the identity of the payee even if 
they wished.  Since the final payee in politics is either the candidate or 
the party, this lack of knowledge could make it much more difficult for 
the money to be involved in influence peddling and quid pro quo back room 
deals.

By combining a mandated digital cash system for contributions, a cap on 
the size of each individual contribution (perhaps as small as $100), 
randomized delays (perhaps up to a few weeks) in the "posting" of each 
transaction to the account of the counter party, it could create mix 
conditions which would thwart the ability of contributors to easily 
convince candidates and parties that they were the source of particular 
funds and therefore entitled to special treatment.

Comments?

steve

A foolish Constitutional inconsistency is the hobgoblin of freedom, adored 
by judges and demagogue statesmen.
- Steve Schear

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


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

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

[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: OpenSSL *source* to get FIPS 140-2 Level 1 certification

[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: Digital cash and campaign finance reform

[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: Code breakers crack GSM cellphone encryption

[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: Who needs secure wireless / tappable wireless infrastructure

[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: Digital cash and campaign finance reform

[Steve Schear]

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.

steve

"...for every complex problem, there is a solution that is simple, neat, 
and wrong."
-- H.L. Mencken 

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